Цей допис було вперше опубліковано в блозі Tempest.
Уявіть, що ви зібрали в одній кімнаті від 20 до 50 випадкових людей, які мають працювати над спільним проєктом. У них різний бекграунд, освіта, часові пояси та культура — а ваше завдання полягає в тому, щоб привести їх до успіху. Звучить як виклик? А тепер додайте, що ці люди приходять і йдуть коли заманеться: хтось доробляє завдання до кінця, хтось кидає на пів дорозі, хтось використовує AI без жодної перевірки, а дехто просто вигукує образи збоку.
Якщо описувати це так, то сама думка про успіх будь-якого open source проєкту здається божевіллям.
Проте багато з них стають успішними, і я бачив це на власні очі, працюючи в цій сфері понад десять років. Спочатку це були хобі-проєкти, потім робота в Spatie, де я допомагав підтримувати близько 200 пакетів для Laravel та PHP. Останні кілька років я займаюся Tempest. Цікаво те, що попри мій досвід у програмуванні, "open source" виявився окремою навичкою, яку мені довелося опановувати з нуля. І я полюбив цей процес не менше (а може й більше), ніж написання коду.
За своєю суттю open source — це проблема не технічна, а людська. І для мене вирішення цього рівняння — саме те, що робить open source таким захопливим.
За ці роки я вивчив кілька способів взаємодії з цією "людською проблемою". Дещо підказали колеги, дещо — інші мейнтейнери, а деякі уроки довелося пройти самотужки. У цьому дописі я хочу зібрати ці спостереження докупи.
Відкинути власне его
Раніше я працював над open source проєктами, почасти переслідуючи власну славу. Проте, дивлячись на статистику контриб’юторів Tempest, я розумію: не існує такого поняття, як мій open source проєкт. Він став таким, як зараз, лише завдяки зусиллям багатьох людей — часто значно талановитіших за мене.
Я усвідомив: коли ви даєте простір іншим, проєкт від цього лише виграє. Іноді це означає відсунути власні потреби на другий план і по-справжньому прислухатися до спільноти. Це не завжди легко, але результат вражає: коли контриб’ютори відчувають, що їх цінують, вони хочуть долучатися ще більше. Згодом вони стають амбасадорами проєкту, залучають нових людей, і цей цикл повторюється.
Допомагати іншим розвиватися — це фундаментальний принцип успішної колаборації.
BDFL (Благородний диктатор)
Це може здатися суперечливим попередньому пункту, але я переконаний: остання думка має бути за однією людиною. У спільноті це називають Benevolent Dictator For Life (BDFL).
Там, де збираються люди, неминуче виникають розбіжності в поглядах. Деякі ідеї можуть бути об’єктивно невдалими, але часто ми стикаємося з "сірими зонами", де немає єдиної правильної відповіді. У таких ситуаціях проєкту потрібна людина, яка прийме остаточне рішення. Цей "диктатор", звісно, має враховувати всі аргументи та покладатися на коло довірених осіб, але відповідальність за фінальний вибір лежить тільки на ньому. Він оберігає візію проєкту та стежить, щоб той не збився з курсу.
Вміти казати «ні»
Іноді ідея зовсім не погана, але я все одно мушу відповісти "ні".
Через відкриту природу таких проєктів люди приходять і йдуть. Вони безплатно додають код, але так само не зобов'язані його підтримувати надалі. Зрештою, відповідальність за життєздатність проєкту лежить на мені. Тому я іноді відмовляю, якщо не впевнений, що зможу підтримувати запропонований функціонал у довгостроковій перспективі.
Дякуйте
Незалежно від того, чи приймаю я PR, і навіть якщо цей код — повний безлад, я завжди кажу "дякую". Подумайте самі: люди витратили свій час, щоб допомогти проєкту. Найменше, що я можу зробити — це щиро подякувати.
З тієї ж причини я намагаюся максимально швидко реагувати на нові issues та PR. Це дає людям зрозуміти, що їхні зусилля помітили. Я намагаюся цінувати намір більше, ніж результат. Це знову ж таки про те, щоб давати іншим стимул для розвитку.
Принциповий підхід
Я віддаю перевагу opinionated-коду (коду з власною думкою). Спроба розв'язати всі проблеми та врахувати кожен edge case — це помилка. Особливо в open source, де завжди знайдеться хтось із унікальним сценарієм використання, про який ніхто раніше не думав. Час і ресурси обмежені, тому неможливо додати всі можливі конфігурації, щоб догодити кожному.
Роки практики доводять: ця стратегія працює. Хоча спочатку людей може лякати певна обмеженість інструменту, зрештою виявляється, що це не стає перешкодою, якої вони боялися.
Автоматизуйте рутину
Попри увагу до людського фактора, я залишаюся програмістом. У роботі над Tempest мені пощастило з другом, який чудово розбирається в devops. Він допоміг налаштувати надійний CI-пайплайн. Сам би я навряд чи впорався без зайвих нервів, але тепер не уявляю життя без автоматизації: від перевірки стилю коду та static analysis до тестування та розділення пакетів. Це заощаджує колосальну кількість часу.
Рухайтеся вперед
Я часто випускаю теги — фактично щоразу, коли є що зафіксувати. Я не прив'язаний до жорсткого циклу релізів. Це дозволяє внескам контриб’юторів дуже швидко ставати доступними для всіх, що вони надзвичайно цінують.
При такому підході (коли нові версії виходять кілька разів на тиждень або навіть на день) важливо розділяти "релізи" та "маркетинг". Багато проєктів сприймають мажорний реліз як подію, що стається раз на рік і має створити багато шуму. Мені ж простіше жити без цієї прив'язки. Я пишу про нові фічі в блозі, коли маю час, просто зазначаючи: "ця можливість доступна, починаючи з версії X".
Це також дозволяє рівномірно розподіляти новини про проєкт у часі, що дає кращий довгостроковий ефект, ніж один величезний допис про "все нове одразу".
Робіть перерви
І останнє: світ не зупиниться, якщо ви візьмете відпустку. Нещодавно я мав тритижневу перерву, під час якої повністю відключився від справ. Це допомогло відновити сили та знову сфокусуватися. Я закликаю всіх активних контриб’юторів робити так само. Відпочинок — це інвестиція в успіх на довгій дистанції.
Це основні принципи, які я хотів зафіксувати. Я використовуватиму цей список як нагадування для себе, щоб тримати пріоритети в порядку. Сподіваюся, він стане в пригоді й вам.