×Закрыть

Світ 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!, ще спить, і навпаки.

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

  • day 0: я створив issue
  • day 0: відмітив ключових учасників: @user1, @user2
  • day 1: user1 відреагував 👀
  • day 2: user2 додав мітку «bug» і прокоментував «Thanks for contribution. I’ll take a look»
  • day 5: user1 прокоментував «please add details about X and Y»
  • day 6: я додав коментар з деталями по X і Y
  • day 7: user1 прокоментував «okay thanks»
  • day 12: я прокоментував «any progress»
  • day 24: я прокоментував «friendly reminder»
  • day 30: я прокоментував «ping ping»
  • day 60: user2 прокоментував «was busy for last months, will take a look soon»
  • day 60: я прокоментував «sounds great, thanks»
  • day 65: user2 прокоментував «PR with fix # 000»
  • day 67: issue закрито після успішно прийнятого PR

Note: Даруйте за такий формат замість посилань/скріншотів з реальним прикладом, не хочу «палити контору».

Висновок

Можливо, я вчинив не зовсім коректно, порівнявши Open Source та комерційну розробку. Я не планував розкритикувати або захвалити один з підходів, адже вони безумовно відрізняються, хоча й мають однакову мету — створити продукт. Я дивлюся на світ open source зі світу out source і вирішив поділитись власними спостереженнями, які можуть бути комусь корисні.

Побачимось у коментарях до якогось issue чи PR 😉

LinkedIn

21 комментарий

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Подальше читання:
1. The Cathedral and Bazaar monoskop.org/...​and_the_Bazaar_rev_ed.pdf
2. Критика книги pld.cs.luc.edu/...​/spr20/mnotes/bazaar.html

Цікавий матеріал, дякую!

якшо «проєкт» українське слово то «привєт» і «тоже» — також українські :)

mon.gov.ua/...​ya/osnovni-zminy 2019.pdf

проєкт, проєкція
(так само як ін’єкція, траєкторія, об’єкт та інші слова з латинським коренем -ject-)

«Словарь нєояза» випуск 7 © 1984. Оруелл, йой, вибачте, Орвел, Орвел одобрює

Дякую, гарна стаття!

Figma Plugin Helpers

взяв на озброєння.

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

Картинки найс!

Приходиш на співбесіду, а тобі пропонують каву, печиво та офер, тому що ти Core Contributor у create-react-app.

Это из реальной жизни?

Самый интересный момент с этими open-source проектами, это насколько повышается твой шанс получить ту самую ЗП 200k удалённо в Украину.

Примеры из реальной жизни № 1
Собеседование на JS бекенд разработчика, в украинскую аутсорс компанию. Упомянув что я активный контрибьютор в Node.js, мы пропустили вопросы а-ля «как устроен eventloop» и перешли сразу к более узконапраленным вопросам по проекту. После обсуждения деталей конкретно их реализации и вопроса «есть желание работать с таким?» техническое собеседование было пройдено.

Пример из реальной жизни № 2
Собеседование на JS разработчика в зарубежный стартап.
История почти повторилась, только мне не пришлось ничего упоминать, потому что Senior, который меня собеседовал, нашел меня в репозитории Node.js

Если ты потратил 3000 личных часов (экв 100 тыс $), и в результате тебя не спросили 2 раза про eventloop, то вроде как смысла не так много. Если еще и дали ЗП x2, например не 5к, а 10к, то эта инвестиция еще как, make sense.

Наличие опыта в open source не гарантирует увеличение инвойса, но повышает шансы получения работы. Остается только подавать резюме на вакансии с х2, х3, х4 ЗП. То есть не бывает такого, что ты приходишь на собеседование на позицию за 5k, рассказываешь про свою жизнь на GitHub и получаешь новый оффер на 10k. Вывод — ходить на собеседования на 10k.

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

Реальний приклад: в Twitter в CA була відкрита позиція на лінукс кернел дева із мандаторі умовою — не менше п’яти комітів в мейнлайн ядро. На той момент я цього не мав, тож тупо по цьому пункту одразу відмовили. Зараз його прошов би :)

ок я понял фишку боюсь вы все путаете опенсорс с комитами в ядро линукса ))

Вау. А що, ядро лінукс вже не опен-сорс? Розкажіть про це (взяв попкорн).

толковая и правильная статья, спасибо большое !

Дуже гарна стаття! Звісно і в Open Source розробці є свої недоліки, але я згоден що залучатись краще ніж не залучатись :)

Гарна сттаття, але моєю першою реакцією було «Oh, my sweet summer child». Мені здається, що і плюси і мінуси в тексті трохи зсунуті в позитивну сторону. Моя ложка дьогтю:

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

Якщо проект більше-менш масштабний, то там завжди буде рутина. Нудні задачі, які треба робити, бо інакше буде накопичуватись технічний борг. Відповідати на issue вигляду «у мене нічого не працює». Реагувати на проблеми з безпекою в залежностях. Організаційні питання, підтримка інфраструктури, тощо. Якщо ставитись відповідально, то цим доводиться займатись. На особистих проектах на це можна з чистою совістю забити, звичайно.

Приходиш на співбесіду, а тобі пропонують каву, печиво та офер, тому що ти Core Contributor у create-react-app.

В більшості випадків — ні. Тільки якщо співбесідуєтесь в create-react-app consulting ltd. або вас там особисто знає більшість розробників. Інакше — core contributor це плюс до загальної оцінки, але не перепустка.

Розвиток soft skills

У цього пункту є і темна сторона. Це негативно налаштовані або відверто токсичні користувачі. Для більших проектів — такі ж колеги або лідери проекту. Конфлікти/драми в ком’юніті раз в кілька місяців. Іноді серед користувачів трапляються клінічні божевільні з періодичними загостреннями (я не перебільшую). Це теж корисна школа, але є ймовірність пройти через пару криз/вигорянь перш ніж відросте товста шкіра, тут все залежить від людини.

day 67: issue закрито після успішно прийнятого PR

Непогано, насправді. Часто буває, що автор втратив інтерес до проекту і нічого з вашим PR робити не буде. Треба бути готовим, що у відповідь на ваші ping буде лише тиша. Але будь-який слід в Гуглі це позитивний результат, тому я намагаюсь викласти навіть незавершену роботу, комусь згодиться.

Не сприймайте це як заперечення вашої тези. Незважаючи на всі ці мінуси, участь в open source, на мою думку, це безперечний net positive.

Спасибі, цей коментар органічно доповнює статтю 👍
Погоджуся, є така ложка дьогтю, але для мене вона виглядає досить незначною, можливо через мій оптимізм

Подписаться на комментарии