Підхід be PRO & be BRO є частиною ДНК MOJAM. Одна із цілей компанії — give back IT-спільноті, результати роботи якої допомагають створювати й розвивати game-changing продукти.
З листопада 2024-го року MOJAM системно інвестує у підтримку open-source проєктів, які далі використовує у власній розробці. Це дає команді змогу швидше вдосконалювати продукти та реалізовувати нові технічні ідеї.
Back-end Team Lead та NodeJS Team Lead діляться інсайтами про те, як MOJAM підтримує open-source ініціативи та чому в команді вважають таку модель взаємодії win-win для всіх гравців IT-ринку.
Синк по базі: все про open-source проєкти
Open Source — це модель розробки програмного забезпечення з відкритим вихідним кодом. Будь-який розробник може використовувати, трансформувати, шерити або просто вивчати його для своїх завдань. Це спосіб ділитися кодом зі світом: автор викладає бібліотеки, інструменти або цілі рішення, щоб інші могли застосовувати їх у своїх продуктах.
Але не весь код в інтернеті — справді «відкритий». Усе залежить від ліцензії, яка визначає, чи можна вільно брати, змінювати й поширювати проєкт, чи все ж існують обмеження.
«Ліцензію обирає творець проєкту в момент публікації. Наприклад, створює файл LICENSE.md у корені репозиторію. Автор застосовує певний шаблон ліцензії залежно від того, як хоче, щоб його код використовували й розвивали. Потім ліцензію публікують разом із вихідним кодом, і її порушення накладає певні юридичні ризики, особливо для великих компаній», — каже Костя Гобеляк.
Не всі open-source ліцензії однакові — у кожної свої правила, які варто врахувати перед використанням коду. Ось найпопулярніші формати ліцензій:
- Заборона комерційного використання. Код доступний лише для некомерційних проєктів.
- Вимога успадковувати ліцензію. Якщо ти включаєш open-source модуль у свій проєкт, то зобов’язаний поширювати весь код під тією ж ліцензією.
- Обов’язкове зазначення авторства. Потрібно вказати оригінального автора, наприклад, у документації або в секції про програму.
- Обмежене комерційне використання. Автори можуть заборонити монетизацію конкретних частин продукту, створених за допомогою open-source коду.
- Без обмежень. Код можна використовувати, змінювати й комерційно реалізовувати — повний простір для творчості.
Якщо вам треба швидко розібратися в конкретній ліцензії — допоможе сайт TLDR Legal.
Як ми бустимо open-source проєкти?
MOJAM запустив фінансову підтримку продуктів із відкритим кодом у листопаді 2024-го року — ініціатива почалася з ідеї Chief Technical Officer компанії.
«Спочатку СТО визначив бюджет, який компанія готова спрямовувати на open-source, — $3000 доларів на місяць. Далі ми розділили його між всіма IT-відділами, по $1000 кожному. Та тимліди мали можливість самостійно обирати, які проєкти підтримувати, виходячи з потреб і інструментів, які використовуються у роботі», — розповідає Паша Бездверний.
Ця ініціатива переросла в системний процес: зараз MOJAM щомісяця підтримує шість open-source проєктів, а також періодично донатить більші суми одноразово. Станом на листопад 2025-го року компанія підтримала open-source проєктів на $60 000.
У MOJAM свідомо фокусуються не на гігантах, бо багато з них too big to fail і вже перебувають під патронатом великих корпорацій. Тому команда донатить середнім і малим проєктам, які MOJAM активно використовує у кодингу.
Щомісячно по $1000 компанія MOJAM надсилає таким проєктам:
А також по $500:
Цінність open-source продуктів на практиці
Фактично навіть внутрішні «велосипеди» Google у чомусь базуються на ПЗ з відкритим вихідним кодом. Щоб створити IT-продукт, який повністю обходиться без використання open-source ПЗ у розробці чи експлуатації — треба дуже постаратися. Умовно, навіть сильно ізольовані й закриті програми на кшталт BIOS, найімовірніше, збираються open-source компілятором.
Фінансова вигода
Розробляти власні рішення з нуля економічно невигідно. Натомість оpen-source допомагає стандартизувати процеси, пришвидшувати розробку, фокусуватися на продукті та рухатися вперед, не переписуючи вже створені хороші рішення. А ще це вигідно з точки зору команди: на ринку вже є компетентні фахівці, тож немає потреби навчати їх із нуля.
«У нас немає ситуації, де вибір стоїть лише між власним кодом і open-source. Можна взяти пропрієтарні рішення як сервіс або підписку. Але в довгостроковій перспективі open-source безпечніший — через можливість у будь-який момент зробити копію. Коли ти використовуєш пропрієтарний продукт, компанія-автор може його закрити чи повністю переробити, і це стає великим ризиком. Хоча якісні closed-source продукти ми все одно використовуємо», — пояснює Костя Гобеляк.
Зручний темплейт
Open-source — це як готовий шаблон, який допомагає швидше досягати цілей. Наприклад, для стартапу це особливо важливо: є прагнення мінімізувати time to market, і саме open-source дозволяє тримати темп.
Коли код не пишуть з нуля, а беруть готову бібліотеку, робота зводиться до інтеграції — це економить і час, і ресурси. Те саме можна сказати і про пропрієтарні рішення. Але перевага open-source у тому, що він часто вже адаптований під типові інфраструктури та закриває рутинні завдання на кшталт білінгу, генерації PDF чи надсилання email-сповіщень. А отже, команда може фокусуватися на цінності продукту, а не на технічних дрібницях.
Розвиток бренду компанії
Інвестиції в такі проєкти «прокачують» HR-бренд. Багато розробників цінують компанії, які активно підтримують open-source. Наприклад, MOJAM бере участь у тих же проєктах і спонсорських ініціативах, що й технологічні гіганти: вони такі ж Principal Sponsors NestJS, як і Microsoft. І саме такий підхід також допомагає залучати сильних кандидатів і утримувати талановитих співробітників.
Чому б не писати все in-house?
«Якщо коротко — це невигідно. Часто простіше підтримувати наявні open-source проєкти, ніж створювати все з нуля. Наприклад, донатити п’ятьом ключовим open-source проєктам по $5000 на місяць може коштувати дешевше, ніж розробка аналогічних рішень всередині компанії. In-house розробка потребує наявності штату спеціалістів, управління ними та процесами, постійної роботи з мотивацією. Open-source же цінний тим, що поганий код просто ніхто не використовує — свого роду природний відбір, де проєкт виживає лише тоді, коли він справді корисний», — каже Паша Бездверний.
Деякі компанії обирають шлях inner-source — аналог open-source, але всередині компанії. Код не публікується у відкритому доступі, проте процеси і принципи роботи побудовані за схожою логікою. Спочатку проєкт використовують тільки співробітники, а з часом він може перетворитися на продукт для широкої аудиторії. Хоча економічно це виправдано лише для компаній із тисячами розробників. Втім, і open-source, і inner-source здатні додавати мотивації розробникам викладатися на максимум:
«Коли ти як owner проєкту знаєш, що над твоїм кодом працюватимуть люди зовні, виникає зацікавленість зробити поріг входу мінімальним. Є мотивація спрощувати код, залишати менше технічного боргу, будувати просту архітектуру й писати вичерпну документацію. Треба слідкувати, щоб нові фічі було можна масштабувати й щоб вони не ламали логіку інших частин проєкту. Зрештою, багатьом соромно показувати поганий код — доводиться писати хороший», — говорить Костя Гобеляк.
З’явився ще один вид проєктів із відкритим кодом: AI-моделі та датасети. Навіть інженери Google у 2023-му році визнавали, що їхній відрив від open-source проєктів скорочується напрочуд швидко. Секрет у тому, що в open-source колаборації народжуються проривні ідеї, які значно рідше виникають у межах закритої inner-source системи. Тому великі компанії все частіше відкривають свій код для community у пошуках свіжих інсайтів.
Є різні рівні open-source проєктів. Багато найвідоміших технологій, без яких важко уявити IT-індустрію, мають відкритий код:
- Linux;
- Firefox;
- WordPress;
- Android (частково);
- Chrome (частково).
Утім, всі ці приклади — це «єдинороги», унікальні випадки, коли open-source продукти перетворилися на масові рішення для мільярдів людей. Набагато частіше у відкритому доступі публікуються рішення різного масштабу та популярності:
- Проєкти з нульовою популярністю. Їх зазвичай пишуть для себе або з навчальною метою.
- Проєкти, якими стабільно користуються кілька людей. Вузькоспеціалізовані бібліотеки, скрипти та інструменти для персональної автоматизації завдань.
- Нішеві популярні проєкти. Утиліти для конкретних мов чи фреймворків.
- Успішні масові проєкти, які активно використовують розробники. Наприклад, популярні CSS-фреймворки або плагіни для оптимізації кодингу.
- Гіганти, без яких індустрія зазнає колапсу, якщо вони раптом зникнуть. Мова не лише про кінцеві продукти для користувачів, але й про критично важливі інструменти для девелоперів. Наприклад, якщо GCC — основний компілятор мови C++ — перестане працювати, то не зможуть збиратися всі програми на цій мові: від фінансових бірж і операційних систем до модулів для навчання нових версій LLM.
Важливий нюанс: проєкти на різних рівнях «ніші» можуть розв’язувати одні й ті самі проблеми — просто різними методами або в різних масштабах. Загальна мета багатьох open-source продуктів — спростити рутинні завдання: зберігання даних, обробку вебзапитів, автоматизацію специфічних обчислень.
Звідки походить продукт з відкритим кодом?
Безкоштовні open-source продукти зазвичай ростуть не так швидко, як комерційні, зате за ними завжди стоять люди, яких мотивує не лише прибуток, а щирий інтерес і бажання робити круті інструменти для всіх. Часто все починається з хобі або «побічної» ідеї, яка з часом перетворюється на щось більше. Якщо подивитися на origin story проєктів, які підтримує MOJAM, то:
- Nest народився як внутрішній проєкт для автоматизації рутини.
- PHPStan — справа одного ентузіаста, який просто вирішив поділитися своїм кодом.
- Laravel починався як особиста ініціатива розробника, який повністю присвятив себе фреймворку.
Але, звісно, є й гіганти на кшталт TypeScript, над кодом яких працюють цілі команди Google і Microsoft. Такі компанії свідомо виділяють людей і ресурси, щоб розвивати інструменти для спільноти та посилювати екосистему, на якій тримається tech-світ.
Як open-source проєкт може залишатися на плаву?
Питання фінансової підтримки — вразливе місце багатьох open-source ініціатив. Більшість авторів нічого не просять: ти можеш використовувати їхній код безкоштовно, а способу «подякувати доларом» просто немає. Дехто залишає посилання на донати або додає невеликі функції для підтримки авторів.
На головній платформі open-source, GitHub, є вже вбудована можливість монетизації: можна оформити регулярне спонсорство або разово задонатити розробнику напряму. Іноді навколо проєкту створюються цілі кампанії для збору коштів та продовження розвитку продукту. Так, автори open-source додатку для малювання Krita запустили краудфандинг-кампанію Accelerate Development, щоб додати 24 нові фічі. А трапляється й навпаки — автор вигорає, пише чесний пост про те, що не тягне, і знаходить підтримку спільноти. Наприклад, у 2025-му році через вигорання покинув посаду проджект-ліда Asahi Linux.
Іноді підключаються фонди (foundations), які допомагають проєктам рости. Mozilla Foundation, The Linux Foundation, Core Infrastructure Initiative та багато інших організацій регулярно підтримують зовнішні open-source проєкти. Деякі продукти починають заробляти самі: публікують базову версію безкоштовно, а додаткові можливості пропонують за донат. Хороший приклад — Bitwarden, який викладає вихідний код безкоштовно на GitHub, але також пропонує платні преміум-функції.
Проте open-source тримається не лише на великих сумах. Не варто недооцінювати вагу невеликих донатів від учасників IT-ком’юніті. Велика кількість людей підтримує проєкти по 1–5 доларів, і це теж надзвичайно цінно.
«У моменті важко відчути, як саме твій донат вплинув на проєкт. Це робота на перспективу, адже команда open-source продукту ніколи не знає, як довго ти плануєш їх підтримувати. І це нормально, навіть добре — так вони адекватно сприймають реальність і розуміють, що для виживання їм потрібно мати багато контриб’юторів. Тому ми не обираємо донатити, наприклад, $10 000 в один проєкт. Так автори не залежать від одного джерела і сприймають ринок більш реально», — каже Паша Бездверний.
Sharing is caring: як ділитися досвідом в open-source
Контриб’ютити можна не лише грошима, а й експертизою: допомагати іншим розробникам вдосконалювати код, документувати, оптимізувати та тестувати. Команда ділиться інсайдом: часто автори зацікавлені в цьому навіть більше, ніж у грошах. Так мейнтейнер відчуває, що він не один у процесі — адже більшість open-source проєктів тримається на ентузіазмі кількох людей.
Тим не менш, knowledge sharing часто складно реалізувати на практиці. Для цього потрібно мати вільний час у графіку, виділяти окрему команду або вводити open-source чергування. Проблема схожа на технічний борг: усі розуміють, що це важливо, але часто відкладають, бо бізнесу потрібні нові рішення ASAP.
Як донат на open-source може стати твоїм щитом?
Звісно, є й зворотна сторона — ризик, що проєкт можуть раптово закинути або закрити. Тоді доведеться або взяти його розвиток на себе, або шукати обхідні шляхи. Саме тому в MOJAM підтримують проєкти, якими реально користуються самі.
В open-source є проста істина: щоб проєкт залишався корисним, його потрібно постійно розвивати. Інакше він застаріває — змінюються версії бібліотек, залежності, операційні системи. Код, який ніхто не підтримує, швидко втрачає цінність і іноді навіть може зашкодити проєкту. Підтримка людей, які розвивають open-source, — це інвестиція у власну ефективність на ринку, навіть якщо при цьому підвищується ефективність конкурентів.
«У світі, мабуть, немає компанії, яка заробляє гроші без використання open-source. Тому я вважаю, що кожен бізнес повинен робити свій внесок. Але у багатьох компаній виникає питання: навіщо платити, якщо це й так доступно безкоштовно? Тут важлива усвідомленість: якщо не підтримувати авторів, проєкти не зможуть розвиватися і перестануть існувати, що зрештою обійдеться компанії дорожче через необхідність міграції», — говорить Паша Бездверний.
Підтримка талантів має стати нормою, і тільки так, спільно, можна прискорювати процеси та робити стрибки у розвитку IT-сфери. Донат на open-source проєкт — це про:
- подяку спільноті;
- усвідомлення цінності проєкту для розвитку технічних рішень;
- повагу до тих, хто робить tech-прогрес можливим.
Be BRO, Be PRO & Support Open Source. Якщо тобі близькі такі цінності та підхід — давай разом рухати IT-ком’юніті та tech-світ вперед. Let’s Add More Jam Together.