Єдиний українець у програмі GitHub Stars — про опенсорс-розробку, доходи з таких проєктів і зміну пріоритетів
Олексій Голуб — Software Development Consultant у Bitwarden. А ще він затятий опенсорс-розробник, за плечима якого 17 таких проєктів. Сьогодні айтівець — єдиний українець у програмі GitHub Stars. В інтерв’ю DOU він розповів, чому захопився опенсорсом, що дає програма GitHub Stars і чому вміння казати «ні» — одне з найважливіших для опенсорс-розробника.
«На фрилансі година цінується набагато більше, ніж у типовому 9-to-5 середовищі». Про освіту й любов до ремоуту
Я ніколи не мав конкретного плану — піти в IT. Та мої дитячі інтереси так чи так були пов’язані з комп’ютером, тож здавалося, що ця діяльність мені під силу. І я вважав, що за допомогою програмування можна реалізувати те, що буде корисним і мені, і іншим.
Але зі спеціальністю я прогадав — вступив у КПІ на «Мікро- та наноелектроніку». Мати дуже хотіла, щоб я потрапив в один з «елітних» ВНЗ, а за балами ЗНО я не проходив на жодну з програмістських спеціальностей, принаймні у перших хвилях. Сьогодні в ретроспективі розумію, що це було погане рішення — обирати нецікавий для себе фах. До того ж у КПІ вільного часу на фриланс та розвиток здібностей залишалося небагато (я кожного семестру був на межі відрахування). Але маємо, що маємо.
Я швидко зрозумів, що майбутнього в мікро- та наноелектроніці не маю, тож у вільний час зайнявся програмуванням. Хоча тоді й думки не виникало, що це стане справою мого життя. Просто мені подобалося годинами просиджувати за цим заняттям, та й навчання давалося відносно легко.
Спочатку я вчився на уривках навчального контенту, який знаходив в інтернеті: Stack Overflow, випадкові статті, форуми. Тобто я не підходив до вивчення програмування методично, а більше точково розбирався в питаннях, які мене тоді цікавили. У певний момент вирішив, ніби я вже все знаю (це лише тоді так здавалося [сміється]) — і час використовувати знання на практиці. Тоді були популярними майданчики для фрилансу штибу oDesk, Elance та Freelancer, на яких я і дивився, які завдання ставлять замовники, та пробував їх виконати. Так намагався зрозуміти, чи мені це під силу. А десь за пів року мав уже перше оплачене замовлення.
Це був
Спочатку фриланс мені дуже подобався. Навіть не припускав, що зможу настільки вільно обирати робочий графік: працювати після пар, між парами чи навіть замість них [сміється]. Спочатку завдань, що я виконував, для саморозвитку вистачало з головою. Так було до кінця
У першій компанії — 3Shape — я пропрацював майже три роки. Хоча кортіло повернутися до ремоут-формату. В офісі я зрозумів, що вкрай неефективно використовую свій час через специфіку монотонного восьмигодинного графіка. На фрилансі година цінується набагато більше, ніж у типовому 9-to-5 середовищі. Отож я дійшов висновку, що найкращий спосіб розв’язати цю проблему — отримувати більше грошей за той самий час, щоб компенсувати його непродуктивність.
Згодом я зрозумів, що найефективніший спосіб отримувати кращу зарплату, умови й нове середовище з викликами — це частіше змінювати роботу. Та й за рік-півтора я досягав періоду стагнації в особистісному розвитку, не надто просувався кар’єрно, втрачав зацікавленість у проєкті. Якщо сказати простіше, мені ставало нудно і я прагнув чогось нового. Тому випрацював для себе оптимальний формат: переходити до іншої компанії через пів року — рік роботи в попередній. Окрім того, намагався брати паузу, перш ніж іти на нове місце. Тоді я повертався до роботи із запалом, а не просто переходив у новий офіс, ніби нічого не змінилося.
Раніше під час вибору нової компанії я відштовхувався від технологій, з якими доведеться працювати, проєкту та людей (намагався зрозуміти на співбесіді, чи буде нам комфортно). Але зарплата була серед пріоритетів. Якщо я знав, що це буде legacy code, який підтримується роками, і мені доведеться з ним працювати, то і зарплата мала бути суттєво вища. Та я міг знехтувати компенсацією, якщо пропонували цікавий проєкт з технологіями, досвіду роботи з якими я не мав, але хотів би набути. Тепер пріоритети змінилися: зарплата перестала бути настільки впливовим фактором, важливішими ж стали технології, проєкт, люди — все, що раніше вважав другорядним.
«На роботі немає відчуття, що цього всього не було б, якби не я». Про захоплення опенсорсом і найпопулярніший проєкт
Орієнтовно з 2016 року я став серйозно займатися опенсорсом, але без конкретної мети. Просто були певні власні потреби, які можна було вирішити кодом — це я і робив. Якось мені знадобилася програма, що змінює яскравість і гамму дисплея так, аби вона відповідала освітленню навкруги. А оскільки я грав в ігри, рішення мало працювати швидко й без мерехтінь.
Зараз для цього є сотні рішень, але у
Утім, у мене не було мотивації стати одним з опенсорс-мейнтейнерів. І я не продумував наперед, які проєкти слід зробити. Навпаки: я просто робив те, що було цікаво. Передусім подобався сам процес, а опенсорс лишався другорядною деталлю.
Сьогодні мій найпопулярніший проєкт, відповідно до зірочок на GitHub, — DiscordChatExporter. Це програма для експортування чатів з Discord. Я написав її приблизно у
Напевно, цей проєкт став популярним через нашу сентиментальність. Користувачам хочеться зберегти переписку зі своїми близькими, особливо якщо цих людей більше немає. Для них цінно перенести ті історії й емоції, які вони відчували під час спілкування, на флешку чи Google-диск: у такому разі, навіть якщо Discord одного дня перестане працювати, вони зможуть відкрити переписку й переглянути бажані моменти.
Загалом в опенсорсі люди нечасто пишуть, коли їм щось подобається. Проте в цьому випадку приходило чимало вдячних відгуків, що моя програма допомогла зберегти важливі спогади. Від цього особливо приємно на душі: такий зворотний зв’язок підтверджує, що я роблю щось корисне. Це відчуття унікальне. І навіть коли працюю на найкращій роботі над класним продуктом і цікавим з технологічної точки зору, — немає відчуття, що цього всього не було б, якби не я.
«Завжди вигідніше рік пропрацювати на звичайній роботі, піти на рік у відпустку й займатися опенсорсом». Про монетизацію опенсорс-проєктів і зароблені гроші
Я не починав робити опенсорс з думкою про монетизацію цієї справи. Тривалий час узагалі відмовлявся від будь-яких грошей, але у
У середньому я отримую близько $100 на місяць з донатів (за посиланням наведено суми майже за весь час опенсорс-діяльності, — ред.). Іноді більше: коли великі компанії проводять аудит і бачать, що користуються моїм кодом, можуть задонатити $10 на знак подяки й підтримки. Це незначні гроші, але вони дають мені змогу виходити в нуль з опенсорсом. Наприклад, є проєкт SpellingUkraine, який популяризує офіційні та правильно транслітеровані топоніми, імена тощо. Він потребує витрат, як-от оплата домена для сайту, ботів для соцмереж, — кошти на це я беру якраз з донатів.
Ставити за мету робити опенсорс і отримувати з цього нормальні гроші — провальна ідея. Звісно, буває, на донатах заробляють по $10 тисяч на місяць. Але це не те, чого варто очікувати всім: найімовірніше, такі проєкти підтримує не одна людина. В такому разі дохід ділиться між кількома, і тоді це вже не такі й великі гроші.
Загалом завжди вигідніше рік пропрацювати на звичайній роботі, відкласти гроші, піти на рік у відпустку і займатися в цей час опенсорсом. Люди дивляться на кейси, де дуже круті опенсорс-мейнтейнери отримують сотні тисяч за рік на донатах, корпоративній підтримці (коли клієнтам за гроші надають швидшу та якіснішу підтримку) тощо. Але ті самі люди, відповідно до своїх здібностей та компетентності, і на звичайному ринку праці дуже високо оплачувані. Тому їм, як і будь-кому іншому, вигідніше попрацювати на звичайній роботі, а опенсорсом займатися в перервах між нею або у вільний час. Бо так і нерви збережеш, і грошей більше буде [усміхається].
Є інший шлях заробітку — зробити напівкомерційний проєкт. Це, наприклад, той випадок, коли розробники пропонують платформу, за яку і беруть гроші. Тобто кінцевий користувач платить саме за платформу або послугу, яка реалізується цим опенсорс-кодом, а не за код як такий. Якщо продуктом вдасться зробити не код, а щось інше, з цього вийде стартап і опенсорс буде своєрідною бекграунд-особливістю проєкту. Однак коли опенсорс — це головна характеристика, тоді код стає основним продуктом, а за код ніхто гроші платити не буде.
«Є нішева сфера діяльності, де я наче мікроселебриті». Про користь опенсорсу в пошуку роботи та комунікацію з користувачами
Опенсорс може допомогти в пошуку роботи, та є «але». На початку кар’єри ця діяльність практично не давала мені переваги. Я проходив стандартний процес найму, під час якого хіба наприкінці технічної співбесіди могли сказати щось на кшталт: «А, то це в тебе багато зірок на GitHub?» Це пов’язано зі специфікою українського IT-ринку: рекрутери працюють на масу, а не на якість (не вчитуються в профіль/резюме). І вже потім на технічних співбесідах розбирають, хто з кандидатів вартий позиції. Тому, власне, і люди, які проводять співбесіду, не надто цікавляться кандидатом до того, як він себе зарекомендує під час зустрічі: у них таких сотні на рік.
Лише у
Ще з цікавого: виявилося, що компанії, у яких я працював, послуговуються моїми опенсорс-рішеннями. Наприклад, у Bitwarden, де я працюю зараз, активно користуються проєктом CliWrap (який входить до п’ятірки моїх найпопулярніших). Також колеги писали, що читали мої статті, застосовували в розробці мої ідеї. Це дивне відчуття: ти тільки-но прийшов у компанію, а там уже використовують твій код [усміхається]. Про мене, по суті, ніхто не знає з широкого загалу, але є нішева сфера діяльності, де я наче мікроселебриті.
Дуже подобається, коли сторонні люди пишуть, що користуються моїми напрацюваннями. Особливо багато отримую повідомлень, якщо йдеться про застосунок для широкого кола користувачів. Бо, якщо це бібліотека для розробників, вони переважно створюють на GitHub issue на моєму репозиторії в разі, коли щось не працює.
А от користувачі з-поза розробницького кола дають фідбек по-іншому. Мені могли писати і в інстаграм, і в телеграм, і у фейсбук... Навіть SMS надсилали. І переважно це були питання з категорії: «У мене нічого не працює, допоможи».
Тоді я зрозумів: хай як мені цікаво й важливо отримувати такі повідомлення, варто все якось урегулювати. Тому, щоби відокремити цю частину життя від особистої, звів спілкування з користувачами в Discord: він є майже в усіх, дає змогу легко і швидко написати повідомлення в загальний чат, а також вести двосторонню комунікацію. Для порівняння: GitHub Issues або Discussions — формальніші, забирають більше часу. І комунікація там тільки одностороння, тобто від користувачів до мейнтейнера. Я не можу, наприклад, запитати сам у всіх своїх користувачів щось настільки легко, як у Discord.
Однак те, що вийшло в підсумку в Discord, мене здивувало. Я думав, що потрохи відповідатиму сам на всі запити в цьому каналі. Та навколо моїх проєктів утворилися різні маленькі ком’юніті, в яких знайшлося кілька активних людей, що закривали питання користувачів і без моєї допомоги. Отож тепер я зрідка відповідаю сам. Це дуже зручно.
«Вони самі виконали за мене найважчу роботу». Про те, як завадити росіянам користуватися власним опенсорс-рішенням
Від початку повномасштабного вторгнення я подумав, що не хочу, аби росіяни користувалися моїми напрацюваннями. Фактично прямо заборонити використовувати свій код в опенсорсі неможливо — на те він і опенсорс. Але мені спало на думку кілька ідей.
Найуспішніша — додати в Terms of Service пункт про те, що якщо ви використовуєте цей код, застосунок чи бібліотеку, то маєте підтримувати суверенітет України, не визнавати російську агресію легітимною і так далі. Здавалося, ці слова доволі просто проігнорувати. Та вони виявилися ефективними: чимало користувачів злилися через них і вирішували не користуватися проєктами. По суті, вони самі виконали за мене найважчу роботу [сміється].
Крім того, такий текст може відлякувати з юридичної точки зору, особливо якщо йдеться про використання бібліотеки тією чи іншою компанією. Корпоративні юристи можуть розцінити це як зайвий ризик, який краще оминути.
Але це стосується бібліотек і десктопних застосунків, тобто того, що запускається в користувача на комп’ютері. Якщо йдеться про вебзастосунок, то до частини, що відкривається в браузері, дуже легко обмежити доступ, наприклад, за IP-адресою. Код, звісно, все одно буде доступний, і якщо людина захоче, вона запустить його в себе на сервері. Та все ж це вставляє палки в колеса.
Окрім того, опенсорс-мейнтейнерам є сенс додати в readme інформацію про те, що ви з України, що війна стосується вас напряму, і вказати, як вас можна підтримати. Мені здається, найкраще, що тут можна зробити, — встановити безпосередній зв’язок між бойовими діями й наявністю застосунку, яким людина користується. Тоді користувач зрозуміє: якщо цього українського розробника вб’є ракетою, то цього застосунку просто не буде. Це дасть усвідомлення, що війна стосується і його, нехай і не напряму.
Та загалом інформаційний активізм більше не дає стільки користі, як на початку вторгнення. Привертати увагу можна в різний спосіб, але той, хто хотів дізнатися щось про війну в Україні й зробити власні висновки, вже зробив це.
«Я досі не знаю, чому я єдина людина з України в програмі». Про GitHub Stars і бенефіти для учасників
Чимало компаній, які є лідерами в технічній галузі, мають власні програми заохочення тих, хто активно користується їхніми продуктами й просуває їх у маси. У
GitHub Stars охоплює найбільш впливових і популярних розробників, які користуються платформою компанії. Вона переважно спрямована на адвокацію опенсорсу. Засновники програми хочуть підтримати й винагородити певним чином людей, які розхвалюють опенсорс, а разом з ним і GitHub як чудову для цього платформу. Та є цікавий момент: вони наголошують навіть у правилах, що опенсорс-розробка, тобто написання коду, не має бути єдиною діяльністю номінантів.
Висунути когось на участь у програмі може абсолютно будь-яка людина через спеціальну форму на сайті. Робити це можна протягом року. На місяць GitHub отримує до 10 тисяч номінацій — це дуже багато. З них відбирають з десяток претендентів, яких розглядає фінальна комісія та вирішує, чи брати в програму.
За якими критеріями визначають номінантів, мені невідомо. Але фактично що популярніша людина в опенсорс-ком’юніті, то вищі в неї шанси потрапити в програму.
Я й досі не знаю, чому я єдина людина з України в GitHub Stars. Українське ком’юніті невелике — кілька десятків людей, але в ньому є багато інших відомих опенсорс-діячів. Усіх їх номінували, втім, у програму не взяли. Чому? Хотілося б знати, однак процес відбору — закрита чорна скринька. Проте не мені на неї жалітися [сміється].
Для тих, хто стає частиною GitHub Stars, найбільший бенефіт — це нетворкінг. Наприклад, я можу напряму спілкуватися з розробниками GitHub: ставити їм запитання чи пропонувати власні ідеї. Також з’являється можливість комунікувати з іншими учасниками програми, які зазвичай впливові в тій чи іншій сфері: переймати їхній досвід і ділитися своїм.
Друга перевага — інсайти. Часто розробки GitHub як платформи проходять стадію закритого бета-тестування. А учасники GitHub Stars — ті, хто отримують раніше за всіх доступ до нововведень. Наприклад, з найбільших я міг протестувати GitHub Copilot і Codespaces ще на дуже ранніх стадіях, десь у
«Мені подобається в усьому звинувачувати аутсорс». Про обмеженість опенсорсу України та зміну пріоритетів
Український опенсорс — це дуже обмежена ніша, про яку мало з ким поговориш. В опенсорс-спільноті України загалом кілька десятків людей, але з 30 — дуже відомих, які відповідають за популярні репозиторії. І ці ж люди спілкуються в закритому телеграм-чаті Ukrainian Open Source (потрапити в нього можна за запрошенням).
Чому так склалося — дуже гарне запитання. Мені подобається в усьому звинувачувати аутсорс [сміється]. Річ у тім, що ставлення до проєктів, яке випрацьовується в українській IT-індустрії, так чи так пов’язане з галерним світоглядом: розробники ізольовані від замовника, але ще більше — від користувача. Через це випрацьовується погана практика або ставлення до певних аспектів індустрії. Зокрема, ставлення до опенсорсу в українському сегменті переважно таке: «Я і так працюю на роботі, навіщо мені ще поза цим писати код?» Мало хто сприймає опенсорс як прикольне хобі. Хоча це просто моє припущення. Можливо, є інші причини, мені невідомі.
Особисто я зараз суттєво менше уваги приділяю опенсорсу: відбулася переоцінка пріоритетів. У
Хотілося б повернути той запал до опенсорсу, який відчував у минулому. Але я розумію, чому його немає. Одна з причин — я досяг і навчився того, чого хотів. І тепер, коли замислююся, а чи не почати писати щось нове, не уявляю — який проєкт міг би мене зацікавити й чи вартуватиме він витраченого часу.
Тому в підсумку все зводиться до підтримки вже наявних проєктів, тих восьми, які активні (загалом їх 17). Користь від цього велика, просто це не виглядає і не сприймається так ефектно, як коли ти стартуєш з нуля.
До того ж в IT я вже 12 років — за такий час відчувається певна втома. Тому одну діяльність доводиться скорочувати, а іншу ставити в пріоритет. Потрібно шукати баланс між життям, роботою і розробкою як хобі.
Та все ж, якби дозволяли часи й фінанси, я б обрав опенсорс, а не стабільну роботу з
«Людей об’єднують проблеми». Про те, як почати опенсорс-проєкт і не закинути
Якщо ви плануєте зайнятися опенсорсом, маю одну важливу пораду, яка допомогла й мені свого часу. Я часто бачу, що люди ставлять собі за мету увійти в опенсорс і думають, який проєкт краще написати, аби він точно став популярним. Це програшна позиція. Найкраще, що ви можете зробити, — просто написати те, що розв’язує вашу особисту проблему. Якщо ця проблема є у вас, вона 100% є в когось іншого. Нехай не в мільйонів, але точно знайдеться декілька десятків, сотень або тисяча таких людей. Так і утворюються спільноти: людей об’єднують проблеми. А з часом, може, за рік, назбирається в рази більше користувачів, які також горітимуть цією проблемою та ідеєю, як її вирішити. Тоді вже можна будувати щось масштабне.
Інший важливий момент — маркетинг. Навіть якщо ваш проєкт дуже класний, сам собою він не просунеться. Над цим треба працювати: розповідати про нього на доступних майданчиках. Мені найбільше в цьому плані подобається Reddit, де допис не губиться серед тисячі інших. І там одразу можна отримати фідбек: якщо твій проєкт паршивий, тобі неодмінно про це скажуть [сміється]. А якщо він класний, люди про нього дізнаються та з більшою ймовірністю стануть користуватися.
До речі, про людей. Слід враховувати, що в опенсорсі доводиться працювати з людьми, коли ті проявляють себе в найгіршому вигляді. Є нормальні, звісно, вдячні. Але не всі будуть читати документацію. Більшість писатимуть, що нічого не працює, що треба негайно пофіксити ту чи іншу проблему, хай чим ви там зайняті. Це при тому, що оплати за це жодної. І, як правило, люди, які вимагають найбільше, в обмін пропонують найменше (найчастіше — нічого).
Часом я помічаю за іншими мейнтейнерами, як опенсорс із проєкту для себе, для задоволення, перетворюється на другу роботу. Й опенсорсери не розуміють, коли відбувся той переломний момент, після якого вони стали комусь щось винні. Люди схильні забувати, чому вони вирішили зайнятися опенсорсом, і це відбиває будь-яке бажання продовжувати.
У мене була своя мотивація: попрацювати над тим, що мені подобається, використовувати цікаві для себе технології — з можливістю все припинити, щойно стане нудно. Це основне, що відрізняє опенсорс від типової роботи. Я можу сказати «ні» чи «так» на будь-яку річ, навіть якщо вона абсолютно абсурдна. Коли це забувається, опенсорс стає виснажливим і зникає бажання ним займатися.
Просто є те, чого треба навчитися, — казати «ні» своїм же користувачам, коли відчуваєш, що твої кордони порушили. Це складно: здається, наче ти винен цим користувачам просто через те, що вони користуються твоїм проєктом, адже колись дуже цього хотів (спочатку). Звісно, насправді все не так: ти нікому нічого не винен. Проте цієї думки іноді складно позбутися. Мені було важко це зробити, але врешті вдалося.
Про цей психологічний аспект опенсорс-діяльності мало говорять, коли все ще можна змінити. Зазвичай усвідомлення приходить після вигоряння, і проблемі зарадити пізно. Опенсорс тим і прикольний: не ти під нього підлаштовуєшся, а він під тебе. Це діяльність, яка дарує відчуття свободи. І бажано його не втрачати. Але кожному своє.
