ГлавнаяНовости ITСвіт Open Source: чому розробнику з аутсорсу варто долучатися

Світ Open Source: чому розробнику з аутсорсу варто долучатися

Суб’єктивний погляд на світ Open Source з позиції простого розробника з двома роками активної участі. Не претендую на істину, не завалюю порадами, тільки структуровані персональні спостереження. Можливо, ця стаття допоможе зрозуміти — бути чи не бути Open Source Contributor’ом, адже краще вчитися на чужому досвіді.

Note: Наведені приклади розглядаємо в контексті GitHub, тож, прихильники Bitbucket і GitLab, вибачте за «дискримінацію».

Як розробник я з самого початку використовував готові рішення зі світу відкритого коду. Це був бездумний Ctrl+C/Ctrl+V команд для встановлення і запуску чужого пакету з документації. Як теля не думає, звідки береться молоко, так і джун не морочиться над тим, хто і як пише ці пакети. Проблема вирішена — закрили таск, не працює — шукаємо далі.

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

Довгий час я обирав шлях «написання власних рішень», але коли став більш досвідченим, почав створювати issues і незабаром перейшов до роботи над виправленнями та новим функціоналом. Звичайно, було лячно відразу вносити зміни в код, тому я зайшов з боку документації. Зрозумів, як усе працює, і пробував вирішувати функціональні завдання. Так почався мій шлях в Open Source, і тепер я сприймаю цей світ по-іншому, адже знаю, «звідки молоко» і як зробити краще.

За кілька років я достатньо освоївся в Open Source. Наразі маю три персональних проєкти, за які не соромно (+7 проєктів «так собі»). Очолюю організацію Figma Plugin Helpers і намагаюся побудувати Open Source ком’юніті навколо Figma. Беру активну участь в комітеті i18n проєкту Node.js, де займаюся побудовою процесів локалізації. Ну й безліч разових issues та PR у різних проєктах, з якими випадково стикався. Нижче я виділив деякі недоліки та переваги, які помітив протягом цих років.

Переваги

Почну з хорошого. А саме — чому мені подобається витрачати +30 хвилин на день на безкоштовні проєкти з відкритим вихідним кодом.

Різноманітний досвід у програмуванні

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

Рутина — головний вбивця інтересу як у щоденній роботі, так і в професії загалом. Наші дбайливі й не дуже керівники щосили намагаються догодити, адже незадоволений співробітник завтра втече до сусідів. Тут тобі й смузі вранці, й електрогітара в офісі, й абонементи в спорткомплекси. Але як би вони не старалися, вирішальним фактором (після зарплати) залишається проєкт. Чи це цікавий стартап на модних фреймворках, чи велика компанія на Angular 1.X, так чи інак настане момент, коли все набридне. Така природа людини — знецінювати все, чим вона володіє, і зазіхати на сусідське.

Набридло писати на своєму стеку? Не поспішай бігати по співбесідах, просто знайди цікавий проєкт у світі Open Source — і вперед.

Note: Я не проти зміни роботи, але потрібно мислити адекватно. Якщо проєкт об’єктивно хороший, команда класна, проте «набридло одне й те саме», не варто відразу міняти футболку EServe на SoftPAM.

Бувають випадки, коли вже понад рік сидиш на проєкті й не можеш підтримати розмову про інші технології. Щоб не випадати з контексту світових подій, приділяйте по 30 хвилин на Twitter/Habr/DOU. Але як щодо практики? Hackerrank, Codewars, LeetCode та інші платформи допоможуть з алгоритмами, але все одно реальної роботи з патернів програмування, архітектури та іншого не буде. Тут приходить Open Source!

Величезний вибір проєктів на будь-який смак, від інді-розробок до трендових фреймворків, від великих monorepo до однофайлових пакетів. Захотілося спробувати новий фреймворк/підхід/мову — глобальний пошук GitHub вже чекає.

Свобода

Хай пробачить вчителька з математики мої старання:

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

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

Якщо ж застосувати цей розрахунок на Open Source, то всі змінні будуть викреслені. В цьому і полягає свобода: жодних обмежень, вимог, босів і дедлайнів, тільки цікаві завдання, які можна розв’язати з новим підходом або стеком. З’явилося бажання — покриваю тестами v14 Node.js, якщо завтра набридне, дивитимуся YouTube. І ніхто не сваритиме мене за тести, навіть якщо я ніколи їх не закінчу.

Note: Вищенаведені формули не більше як літературний прийом. Прохання не шукати в них глибинний зміст або математичне обґрунтування.

Розвиток soft skills

Одна голова добре, дві краще, а всі maintainer’и одразу — відмінно, але складно. Працюючи над черговим виправленням або новим функціоналом, звичайно ж, хочеться в результаті залити його в master. Для цього потрібно не лише написати добрий код, а й відстояти свою ідею та довести слушність. У світі Open Source панує демократія, і кожен готовий озвучити свою позицію.

Що серйозніший проєкт і що активніше в ньому ком’юніті, то більше доведеться спілкуватися. Кожен PR і issue — це нова дискусія, новий шанс потренуватися в мистецтві переконання та попрактикувати англійську.

Крім комунікативних умінь, ви розвиваєте додатково лідерські якості. Це може бути як створення та управління своїм проєктом, так і лідерські позиції в чужому. Звісно, в особистому проєкті не варто очікувати напливу сотень тисяч користувачів, яких треба координувати. Але щоб правильно відповісти на перший issue, теж необхідна навичка. Наприклад, у моєму найбільш активному персональному проєкті react-microsoft-login за півтора року існування набралося всього 18 issues. Беручи участь у більш масштабних Open Source проєктах від Node.js, Figma, Adobe, я вчуся вести перемовини, керувати командами та бути ментором. Навряд чи я б міг займатися тим самим на основній роботі через специфіку outsource, та й просто тому, що наше діло гребти.

Самореклама

Під час роботи над проєктом можна перетнутися з різними людьми по всьому світу, тим самим формуючи мережу знайомств. Звучить трохи популістськи, але зв’язки сильніші за гроші. На них тримається Кремнієва долина, де команда для стартапу формується в черзі за кавою. Тут те саме, тільки онлайн. Подискутували під кількома issues, потім у Slack просиш переглянути твій PR. Слово за слово — і вже ніби знайомі.

Note: Так-так, великі Open Source проєкти часто мають свій Slack workspace.

Як використовувати такі знайомства, вирішувати вам: почати разом стартап або домовитись про безкоштовну ночівлю на випадок подорожей чи просто сказати «шукаю роботу» і отримати гарячу позицію з готовою рекомендацією. У будь-якому разі гірше від таких зв’язків не буде.

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

Та якщо не вдаватися в романтичні мрії про власну справу і повернутися в галерні будні, то тут теж є вигода. Приходиш на співбесіду, а тобі пропонують каву, печиво та офер, тому що ти Core Contributor у create-react-app. Іншому кандидату з ідентичним досвідом, найімовірніше, доведеться відповідати на банальні запитання на кщталт «Які ви знаєте типи в JavaScript?». Ну, ви розумієте.

Карма

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

Недоліки

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

Ієрархія

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

Пам’ятаю, як протягом двох тижнів я намагався зрозуміти, хто головний у перекладах у Node.js. Питав у всіх підряд про процеси, про те, як правильно і неправильно робити, і хто може перевірити мою роботу. В результаті усе з’ясував і так занурився в ті справи, що зараз очолюю їх. Зрозуміти, як усе влаштовано в проєкті, зайняло в мене немало часу. Я й досі не розумію всіх аспектів і не знаю, в кого спитати про них.

Якщо прочитати всі contribution.md і взяти участь у кількох обговореннях, можна визначити активних учасників і «теоретичних» босів. Здавалося б, усе, питання вирішене, але ні! Ніхто ні за що не відповідає ні в межах проєкту, ні в межах окремого завдання. Немає керівника, який призначить таск і дедлайн, немає виконавця, який зобов’язаний закрити issue. Як від мене ніхто не може вимагати написання тестів для v14 Node.js, так і я не можу вимагати цього від інших. Тож може статися так, що ці тести ніхто й ніколи не напише.

Трохи лицемірства: мені подобається безвідповідальний підхід, коли це стосується мене, і дратує, коли стосується інших.

  • Як можна релізити не покриту тестами нову версію продукту?
  • Хто за це відповідає?
  • Хто мав написати тести?

На комерційному проєкті ці питання резонні, в Open Source — ні. Це так звана колективна відповідальність, в якій немає ні героїв, ні поганців.

Планування

На відміну від комерційних проєктів, тут немає звичного плану розробки. Немає Jira/Trello-карток, прикріплених до конкретних людей. Це non-paid участь, а отже, ніхто не може встановлювати терміни та вимагати виконання завдань. Це призводить до хаосу, де кожен робить те, що йому заманеться.

Можна заперечити, що, мовляв, є GitHub Projects (Trello «на мінімалках», вбудований у GitHub) і Milestones, які використовують на серйозних проєктах.

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

Напевно, пора прочинити завісу таємниці — Діда Мороза не існує ці дошки підтримують «зацікавлені» люди. Інтерес може бути такий:

  • фінансова підтримка — зі спонсорських внесків;
  • ентузіазм — автори ідеї або core-розробники, які просто вболівають за продукт.

У такому разі все працює за правилами комерційної розробки. І якщо з грошовою мотивацією все зрозуміло — працює, поки платять, то з ентузіазмом все неконтрольовано. З цього я зробив висновок, що модель безкоштовного Open Source не може похвалитися стабільністю і планомірністю, що, своєю чергою, впливає на кінцевий продукт і developer experience. В Open Source фінансування досить нове та не поширене явище, тому поки що чекаємо.

Пінг

Останнє і, мабуть, найненависніше для мене — це затримка в комунікації. Якщо я зробив PR з фіксом сьогодні, то ніхто не гарантує, що його подивляться, схвалять і змерджать того ж дня. Перша проблема — географічне розташування всіх учасників. У мене розпал робочого настрою, а єдиний товариш, від якого я чекаю LGTM!, ще спить, і навпаки.

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

Яндекс.Метрика