7 важни неща, които да имате предвид, ако се интересувате от проекти с отворен код

30 септември
Денис Циплаков, Solution Architect в DataArt
7 важни неща, които да имате предвид, ако се интересувате от проекти с отворен код
През май 2020 г. броят на колегите в DataArt, които останаха без проекти, се оказа неочаквано висок. Въпреки че ситуацията бързо се върна към нормален ритъм, решихме да привлечем тези от тях, които желаят да работят с отворен код. DataArt има опит в създаването на свои собствени Open Source продукти като IoT платформа DeviceHive.NET framework Atlasплатформата Kiddo, но това направление никога не е било наш основен фокус.

В тази статия един от авторите на идеята – Solution архитектът Денис Циплаков - споделя своите наблюдения, които могат да бъдат полезни за всички с професионален интерес към Open Source софтуера:

1. СОБСТВЕНИТЕ ПРОДУКТИ С ОТВОРЕН КОД МОГАТ ДА ПРИВЛЕКАТ ВНИМАНИЕ, НО ИЗИСКВАТ ЗНАЧИТЕЛНИ РЕСУРСИ

Вероятно вече се досещате за това, но мога да ви уверя, позовавайки се на своя личен опит: дори и със силни разработчици, няма да е възможно бързо да се създаде нещо забележително, базирано на отворен код. Следователно - не бива да разчитате на работата със софтуер с отворен код като инструмент за популяризиране на компанията на пазара.

Дори и да е възможно приносът ви в Open Source хранилището най-накрая да убеди потенциален клиент да подпише договор с вас, не всичко приключва с това. Подобен сценарий би сработил, ако концентрирате усилията си в относително тясна технологична ниша. За тези, които, подобно на DataArt, се фокусират върху възможно най-широк набор от платформи и работят с най-популярните от тях, вероятността от подобен развой е близка до нула.

Собствените продукти с отворен код могат да привлекат внимание, но изискват значителни ресурси и постоянна грижа. Казано иначе, ще са необходими много усилия и средства, за да бъдете забелязани. 

2. ОТВОРЕНИЯТ КОД НЯМА ДА доведе до НЕЗАБАВНА РАЗПОЗНАВАЕМОСт СРЕД ПРОГРАМИСТИТЕ

Преди двадесет години, докато програмирах с Delphi, можех да напиша за един уикенд logging library, която хората действително използваха - тя беше качена в Torry. Сега вече не е чак толкова лесно да се привлече вниманието на останалите.

Всяка собствена библиотека ще изисква постоянен екип или поне собственик на продукт. Някой трябва да следи за последователността, да гарантира трансфера на знания, да решава цял куп проблеми и да намери начини да насърчи развитието в общността. Може да успеете да се справите само с един човек за по-малко от 40 часа седмично, но той ще има достатъчно задачи. Това означава, че ръководството на компанията ще трябва да го освободи от останалите ангажименти и да се лиши от човешки ресурс в основната си дейност.

Опитът на DataArt в създаването на свои собствени продукти с отворен код показва, че в крайна сметка успехът им зависи от ангажирания с продукта. Той трябва да е отдаден и енергичен човек, който е абсолютно уверен в стойността и развитието на проекта. Аутсорсинг компаниите не разполагат с много хора, които не просто искат да работят с отворен код, но и самият продукт е важна част от живота им.

Ако успеете да измислите уникален проект или нова функционалност за добре позната рамка, която не изисква големи инвестиции, поздравления (казвам го без ирония)! Подобно нещо е равносилно на инженерно откритие. Всеки полезен принос към софтуера с отворен код допринася за развитието му, но в същото време трябва да установите защо и дали вашата компания се нуждае от него. Това е единственият начин да се определи посоката на усилията и размера на ресурсите, които бихте отделили.

3. ПРОЕКТИте С ОТВОРЕН КОД често включват дребни и не чак толкова предизвикателни задачи

Всеки проект изпитва редица типични проблеми - той винаги съдържа не най-трудните и следователно - не най-вълнуващите задачи. Така че – не очаквайте единствено предизвикателства, с които никой все още не се е справил. Тези задачи обикновено са много специфични: от проверка на документацията до отстраняване на незначителни грешки. Решаването на такива проблеми обаче е от важно значение за бъдещите потребители. 

Например, в библиотеката с отворен код, при създаването на шаблон на проект, една от опциите се обработваше неправилно. Бързо поправихме това с помощта на двама млади разработчици. Въпреки че не ставаше дума за нещо грандиозно, за тях бе важен опитът и знанията, които натрупаха.

4. изборът на хранилище става лесено

Ясно е, че технологията е най-добрата отправна точка при избор на хранилище. В нашия случай имаше повече разработчици с JavaScript, които в онзи момент бяха свободни, като двама от тях проявиха интерес към проектите с отворен код. Друг подход е просто да вземете топ 100 от проектите в GitHub, да ги филтрирате според технологията и да изберете тези, които най-много ви интересуват. В рамките на проектите, които харесвате, просто изберете тикетите, отбелязани от самите разработчици, като важни. Трябва да прецените и дали имате достатъчно време, за да се справите с описания в тях проблем.

image article

Важно е как е подреден самият проект: има ли насоки и готов избор на най-важните задачи, има ли много фиксирани проблеми колко на брой са заявките за изтегляне и т.н.. Ако всичко това липсва, изглежда, че съответното repository едва ли ви очаква с нетърпение.  За пример разгледайте Angular.

image article

При добре настроен проект, даден проблем може да бъде решен за два часа. 

5. ПРАГЪТ ЗА ВЛИЗАНЕ в проект С ОТВОРЕН КОД СЪЩЕСТВУВА, НО Е МНОГО НИСЪК

Ако проектът има нормален работен процес, можете лесно да участвате в него. За компаниите обаче все още е малко по-трудно, отколкото за отделните разработчици. Angular, React и други хранилища с подобен мащаб са защитени от специална правна рамка. За да участвате в проекта в свободното си време от вкъщи, е достатъчно просто да поставите отметка „да, съгласен съм“. Но ако искате да се включите като служител на компания, ще ви е необходим правно съгласие от името на компанията, за която работите

Споразумението за използване на софтуер с отворен код и неговото развитие са две различни неща. Това е логично, тъй като по този начин проектите се стремят да се предпазят от нелоялни организации, които биха могли да претендират, че са част от написаното чрез труда на техните служители. Всичко би било наред, ако сте сигурни, че юристите във вашата компания имат положително отношение към инициативите с отворен код. При нас в DataArt няма пречки при подобни ситуации и нещата, от които се притеснявахме в началото, много бързо бяха преодолени.

image article

В същото време има проекти с отворен код, в разработването на които едва ли ще бъде възможно да се участва. Те се управляват от стабилни екипи, готови да приемат само наистина гениални предложения. Защо е така, можете да видите тук.

Ако искате да допринесете за проект като Angular или React, това е напълно възможно, но трябва да сте подготвени, че промените ви ще бъдат проверявани дълго и щателно, като се има предвид всяка буква (не преувеличавам). Това е мотивиращо преживяване, но не всеки е готов за него. Ако просто искате да направите нещо полезно и да избегнете изтощителния преглед, можете да се спрете на по-просто хранилище. Например - не самият React, а някаква популярна библиотека с компоненти за него. Там процесът е по-прост и по-неформален.

6. проектите с отворен код са добър учител, особено за начинаещи разработчици

Open Source проектите могат да бъдат полезни за всички програмисти, но за начинаещите разработчици са наистина чудесен учител. Самият процес може да ги научи на много неща, а обемът и сложността винаги могат да бъдат избрани според познанията на съответния човек. Всичко, което е необходимо за участие, е възможността да напишете кода достатъчно добре. Останалите ще ви помогнат - ще ви кажат например дали написаното от вас е на ниво или не съвсем. Освен това големите проекти се правят на базата на най-добри практики, които да усвоите.

Ниският праг за влизане в проектите ви позволява да работите с различни хранилища за кратко време и да получите доста разнообразен опит. Ето защо, когато инициативата с проектите с отворен код беше стартирана в DataArt, ние я считахме за образователна. 

7. НЕ БЪРЗАЙТЕ ДА ДАВАТЕ ОБЕЩАНИЯ

Често се случва така, че малки компании и независими разработчици се захващат с много и различни задачи. Стига се до там, че те поемат ангажимент да решат даден проблем след няколко часа, но се връщат към него след месец или дори година. Ето един забавен пример:

image article

Не винаги е ясно дали случаи като този са умишлена стратегия, случайност или резултат от лошо планиране. Във всеки случай това са примери, които едва ли могат да служат за подражание.