Опенсорс на рівні компанії: перші уроки участі у сторонніх проектах

22 вересня
Денис Циплаков, Solution-архітектор, DataArt
Опенсорс на рівні компанії: перші уроки участі у сторонніх проектах
У травні 2020 року, коли відсоток колег без проектів виявився несподівано високим, ми вирішили залучити бажаючих до роботи з опенсорсом. DataArt має досвід створення власних продуктів з відкритим вихідним кодом: IoT-платформа DeviceHive, .NET-фреймворк Atlas, ігрова платформа Kiddo. Але контриб’ютором сторонніх проектів на рівні компанії ми раніше не виступали, і відразу вкладати в нову ініціативу великі ресурси не планували. Більше просто хотіли подивитися, як це працює та для чого може стати у пригоді в майбутньому.

Один з авторів ідеї — Solution-архітектор Денис Циплаков — поділився кількома спостереженнями з усіма, хто хотів би створювати відкрите ПЗ не лише у вільний, а й у робочий час, або надати таку можливість своїм командам.

1. ОПЕНСОРС МОЖЕ ПРАЦЮВАТИ НА ПРОСУВАННЯ КОМПАНІЇ, АЛЕ ЦЕ ДОРОГО

Напевно, ви й самі про це здогадуєтесь, але я можу вас запевнити, пославшись на власний досвід: навіть із сильними розробниками швидко створити щось помітне в опенсорсі не вийде. Тому не варто розраховувати на роботу з відкритим ПЗ як інструментом просування компанії на зовнішньому ринку, якщо збираєтеся направляти на такі проекти тільки бажаючих з idle.

Можна уявити, як один внесок у репозиторій остаточно переконає потенційного замовника підписати з вами контракт. Але, найімовірніше, це спрацює, тільки якщо ви сконцентруєте зусилля у порівняно вузькій технологічній ніші. Для тих, хто, як і DataArt, орієнтується на максимально широкий набір платформ і найчастіше працює з найпоширенішими з них, імовірність втілення такого сценарію прагне до нуля.

Власні опенсорс-продукти здатні привертати увагу, але вимагають значних ресурсів і постійної уваги. До того ж іноді потенційні замовники, що працюють у суміжній галузі, можуть дивитися на вашу незалежну розробку з професійною заздрістю.

У будь-якому випадку, щоб вас помітили, доведеться витратити чимало зусиль і грошей, але відкритим ПЗ можна займатися не лише заради більшої популярності.

2. ОПЕНСОРС НЕ ПРИНЕСЕ МИТТЄВОГО ВИЗНАННЯ СЕРЕД ПРОГРАМІСТІВ

Двадцять років тому, програмуючи на Delphi, я цілком міг за вихідні написати бібліотеку для логування, якою люди дійсно користувались, — вона була викладена на Torry. Зараз для будь-яких фреймворків придумано стільки, що привернути увагу можна, хіба що граючи на обмеженому полі найсучасніших і найексклюзивніших технологій, вгадуючи тренди та залучаючи значні ресурси — навряд менше тисячі людино-годин на рік. Погодьтеся, що зробити круту фічу, скажімо, для React, за тиждень силами тих, хто зараз опинився в idle, не вийде.

Будь-яка власна бібліотека потребує постійної команди або принаймні продакт-оунера. Адже хтось має стежити за консистентністю, забезпечувати передачу знань, розв’язувати цілий букет проблем та знаходити способи просування вашої розробки всередині спільноти. Можливо, ви зможете обійтися однією людиною, причому навіть не на всі 40 годин на тиждень, але задач їй вистачить. Значить, менеджменту компанії доведеться дуже докладно пояснити, чому таку людину не відпустити на повну зайнятість у комерційний проект.

Власне, DataArt якраз має досвід створення власних опенсорс-продуктів, і вони розвивалися за класичним для продуктової розробки шляхом. Гадаю, здебільшого їхній успіх залежить від продакт-оунера — тут завжди потрібна харизматична й енергійна людина, цілком упевнена в цінності розробки, яку вона представляє. Людей, для яких не просто робота, а й сам продукт є важливою частиною життя, в аутсорсингових компаніях не буває багато.

Якщо вам вдасться вигадати унікальний проект або новий функціонал для відомого фреймворка, які не потребують великих вкладень, вітаю (без тіні іронії). Дуже схоже на геніальне осяяння, це рівень якщо не фундаментального наукового відкриття, то інженерного винаходу. Залишається уточнити в колег, які у вашу ініціативу поки не залучені, чи потрібна їм така розробка, чи будуть вони новою фічею користуватись. Але розраховувати на такі спалахи на етапі запуску роботи з опенсорсом я б не став: вони точно не носитимуть системного характеру.

Будь-який корисний внесок у відкрите ПЗ робить світ трохи кращим, але все одно доведеться розібратися, для чого це потрібно вашій компанії. Тільки таким чином можна визначити напрямок зусиль і обсяг ресурсів, доступний для вкладання в опенсорс-проекти.

3. У НАЙБІЛЬШИХ ОПЕНСОРС-ПРОЕКТАХ УСІМ ВИСТАЧИТЬ НЕВЕЛИКИХ ЗАДАЧ

Будь-який проект зіштовхується з рядом типових проблем, у ньому завжди є не дуже складні й тому не дуже захоплюючі задачі, до яких у жодного колеги поки не дійшли руки. Вони зазвичай дуже конкретні: від перевірки документації до усунення дрібних багів. Розв’язання таких проблем — незначна, але цілком явна допомога майбутнім користувачам.

Припустимо, в опенсорсній бібліотеці при створенні шаблону проекту одна з опцій інтерферувала з чимось і неправильно оброблялась. Ми це швидко виправили силами двох джуніор-розробників. Подія не епохальна, власне, тому ніхто з цим питанням раніше не розібрався. Але комусь стало трохи комфортніше працювати.

Для програмістів із невеликим досвідом такий проект все одно виявляється корисним. Хоча нічого складного в тому, що вони зробили, для них самих немає.

4. ВІДПОВІДНИЙ РЕПОЗИТОРІЙ ЛЕГКО ВИБРАТИ НА ОКО

Зрозуміло, що відштовхуватися найпростіше від технології. У нашому випадку на момент високого idle без проектів опинилося найбільше JavaScript-розробників, і першими на нашу пропозицію відгукнулися двоє з них. Далі найзручніше — просто взяти топ-100 проектів з GitHub, відфільтрувати їх за потрібною технологією та вибирати ті, на які відгукується ваше серце. Усередині таких проектів залишається вибрати тікети, відмічені самими розробниками як важливі, та оцінити, чи вистачить вам часу, щоб напевно впоратися з описаною в них проблемою.

article image

Важливо, як влаштований сам проект: чи є гайдлайни й готова добірка найважливіших задач, чи багато зафіксовано проблем та чи багато там pull requests. Якщо ні, схоже, що на вас у цьому репозиторії не дуже чекають. У принципі можна уявити, що ви розглядаєте чужий город: якщо грядки рівні й бур'яни регулярно прополюють, значить, допомагати господарям буде легко і приємно. Для прикладу можна подивитися на Angular.

article image

У добре налаштованому проекті з обраною проблемою можна впоратися години за дві. Ми знаємо, як шукати відповідний тікет, тому рекомендуємо колегам у DataArt, що ненадовго опинилися без проекту, написати нам. Ми підкажемо, куди йти, разом виберемо задачу. Іноді зробити щось руками може бути корисніше, ніж на один день занурюватись у невідомий вам розділ теорії.

5. ПОРІГ ДЛЯ ВХОДУ В ОПЕНСОРС ІСНУЄ, АЛЕ ВІН ДУЖЕ НИЗЬКИЙ

Якщо у проекті налаштований нормальний воркфлоу, брати у ньому участь легко. Проте для компаній це все ж трохи складніше, ніж для індивідуальних розробників. Репозиторії Angular, React та інші, зіставні з ними за масштабом, захищені спеціальним юридичним фреймворком. Поки ти не намагаєшся зробити pull request, ти його навіть не бачиш, а для участі у проекті у вільний час з дому вистачить і простої галочки “так, згоден”. Але якщо ви зіткнулися з ним як співробітник компанії, вам знадобиться підпис від аналогічного лігал-фреймворку твоєї компанії — у цьому немає нічого складного, але й тривіальною цю задачу я б не назвав. Якщо ваші колеги раніше в робочий час опенсорсом не займалися, юристи можуть здивуватись.

Угода на використання відкритого ПЗ і на його розвиток — різні речі. Це логічно, таким чином проекти прагнуть убезпечити себе від хитрих організацій, які інакше могли б претендувати на частину написаного своїми співробітниками. Загалом добре, якщо ви впевнені, що юристи у вашій компанії позитивно ставляться до ініціатив розробників. Наші розібралися дуже швидко, перешкоду, якої ми спершу побоювались, подолати виявилося дуже легко.

article image

При цьому є й ліби, у розвитку яких взяти участь навряд вийде. Ними займаються стабільні команди, готові прийняти тільки по-справжньому геніальну пропозицію. Чому — непогано пояснюють, наприклад, тут. Власне, тому так важливо уважно подивитися на репозиторій, перш ніж хапатися за цікавий тікет. Раптом ніхто й ніколи не прийме вашої роботи — буде шкода витраченого часу.

Ще один момент — зробити внесок у такий проект, як Angular або React, цілком реально, але треба бути готовим, що ваші зміни будуть довго та прискіпливо обговорювати, розглядаючи кожну букву (буквально). Це корисний досвід, але не кожен і не завжди до нього готовий. Якщо хочеться просто зробити щось корисне, уникнувши виснажливого рев’ю — можна взяти більш простий репозиторій. Наприклад, не сам React, а якусь популярну бібліотеку компонентів до нього. Ці хлопці значно менше розпещені увагою, тому процес протікає простіше і дружелюбніше.

6. В ОПЕНСОРСІ Є ЧОМУ ПОВЧИТИСЯ

Перш за все, це стосується джуніор-програмістів і тих, хто дуже давно працює виключно в одному закритому проекті. Сам процес тут може виглядати досить повчальним, а обсяг і складність завжди можна підібрати під силу конкретної людини. Як не дивно, все, що потрібно для участі — вміння досить акуратно писати код. Із рештою в хорошому проекті допоможуть: підкажуть, наприклад, чи не випадає написане вами з code style. До того ж великі проекти робляться на основі кращих практик — беручи участь у них безпосередньо, можна трохи набити руку.

Низький поріг входу і нескладний процес дозволяють за короткий час попрацювати з різними репозиторіями та отримати досить різноманітний досвід. Тому до моменту запуску ініціативи ми розглядали її як освітню. У кризові моменти, яким для багатьох була весна 2020, така практика дозволяє колегам триматися в тонусі. Зараз ми активно набираємо людей, і в idle народу зовсім мало, тому активно просувати опенсорс усередині компанії поки немає особливого сенсу. Але ми завжди готові допомогти тим, хто чекає на новий проект, і раді прийняти всіх бажаючих.

7. НЕ ВАРТО ПОСПІШАТИ З ОБІЦЯНКАМИ

Цікаво, що в опенсорсі є справжні серійні контриб’ютори — невеликі компанії й самостійні розробники, які беруть на себе дуже багато задач. Доходить до смішного: людина пише, що розбереться з проблемою за кілька годин, але не повертається до неї роками. Навіть тривожно стає, чи все з людиною добре.

article image

Мабуть, так деякі люди і фірми прогрівають свої профайли, хоча ми так і не зрозуміли, що це — усвідомлена стратегія, збіг обставин (ми сподіваємося, що з людиною нічого не сталося) чи невдале планування.

У будь-якому випадку це приклади, навряд гідні наслідування. Ми посилали pull requests, тільки завершивши задачу і провівши необхідні тести. Треба сказати, що не відмітившись заздалегідь, ви знижуєте рівень власної відповідальності. Якщо людина, що взяла тікет, раптово йде у проект до клієнта чи просто не справляється, ви нікого не підвели — свій досвід ваш колега все одно отримав.

Про всяк випадок приготуйтеся, що ваші реквести у проектах оброблятимуть з різною швидкістю. На це може піти від декількох годин до декількох тижнів, незалежно від масштабу задачі та обсягу написаного вами коду.

Замість висновку

  1. Досвід комунікації з кращими опенсорс-проектами є дуже корисним. Будь-який програміст може відразу подивитися, як працюють у вищій лізі, і навіть трохи в ній пограти.
  2. Участь в опенсорсі дозволить відповісти на запитання про знайомство з технологією Х: “Взагалі-то, я є одним з її контриб’юторів”.
  3. Опенсорс покращує карму та дозволяє людині, а іноді й усій компанії, набути нового досвіду в галузі, де комерційних проектів поки було мало.

Ми не чекаємо від нашої ініціативи швидких маркетингових результатів. Проте впевнені, що приносити людям навіть невелику користь завжди приємно, а будь-які теоретичні заняття корисно розбавляти практикою. Ми трохи потренувались і переконались, що працювати з опенсорсом на рівні компанії легко — значить, завжди можна допомогти колегам не нудьгувати в idle.

  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    31 грудня
  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    19 листопада
  • Україна, Дніпро; Україна, Харків; Україна, Херсон
    1 листопада
  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    30 жовтня