Сьогодні відкритий вихідний код є звичним явищем для розробників та бізнесів. Згідно зі звітом State of Open Source 2024, 95% компаній користуються опенсорсом. Важко уявити сучасну розробку без GitHub, Docker, Redis, MongoDB, Jenkins та десятків інших інструментів, які зʼявилися завдяки концепції відкритого коду. Їх могло б не існувати, якби не ідея Річарда Метью Столмена, що усі компʼютерні програми мають бути вільними та безкоштовними. У цьому матеріалі розбираємось, як невеликий протест хакерів проти ліцензійного ПЗ виріс у глобальне комʼюніті розміром у 100 млн, чому історія опенсорсу почалася зі зламаного принтера в MIT, та як ключовий противник вільного коду Microsoft став одним з найактивніших учасників спільноти.
Павло Кушнерик, Senior Software Engineer у Solidgate та Антон Пінкевич, Engineering Team Lead в Universe Group поділилися своїм досвідом контрибʼюшена в опенсорс проєктах, пояснили, що це дає, та як працює ця концепція сьогодні.
Компʼютери розміром з кімнату та вільний код
Насправді поняття вільного програмного забезпечення зʼявилося із першими серійними компʼютерами. Відправною точкою можна вважати появу моделі IBM 701, яку компанія надавала науковим центрам, військовим та державним підприємствам в лізинг. Компʼютери поставлялися без операційної системи та програм, тому науковці писали їх власноруч та ділилися один з одним. Оскільки вони були основними користувачами комп'ютерів, то вільно обмінювалися кодом для поліпшення своїх розробок. На той час усе ПЗ було безкоштовним.
Серед подібних науковців був Річард Столмен, який на початку 1970-х працював у лабораторії штучного інтелекту MIT над створенням операційної системи. Він приєднався до спільноти хакерів — самі вони визначали себе, як людей, які постійно експериментують та шукають, що ще можна зробити з компʼютерними програмами. «Хакери вірять, що світ сповнений захопливих проблем. З поваги до колег вони не змушують один одного винаходити велосипед і відкрито діляться творчими рішеннями. Наше ставлення до ПЗ ґрунтується на філософії доступу», — так описував хакерський рух Ерік Реймонд, розробник програмного забезпечення та прихильник відкритого коду. Фактично саме спільнота хакерів і створила інтернет таким, яким ми знаємо його сьогодні.
Індустрія компʼютерів стрімко розвивалася і ставала доступнішою для бізнесу. Це призвело до змін у підході до розробки та розповсюдження програмного забезпечення — воно почало розглядатися як окремий продукт, який можна продавати. Поява мейнфреймів і мінікомп'ютерів, таких як IBM System/360, створила додатковий попит на спеціалізоване програмне забезпечення.
Microsoft була однією з перших компаній, яка зрозуміла, що софт — це окремий продуктом, який можна ліцензувати й продавати. 1975 року Білл Гейтс і Пол Аллен створили інтерпретатор мови BASIC для комп'ютера Altair 8800 і почали його продаж. Далі Microsoft вдосконалила модель ліцензування програмного забезпечення. Замість того, щоби продавати його одноразово або разом з апаратним забезпеченням, Microsoft розробила ліцензійні угоди, які дозволяли користувачам використовувати ПЗ лише відповідно до умов, визначених компанією. Це дозволило засновникам мати постійний дохід. Агресивне просування продуктів Microsoft стало зразком для інших компаній, що значною мірою вплинуло на розвиток індустрії інформаційних технологій. Ліцензії та NDA поширювалися і на наукові центри, працівникам яких це не подобалося.
Як зламаний принтер змінив історію інтернету
У 1970-х принтери були ключовим девайсом серед розробників. Кількість компʼютерів у наукових центрах була обмеженою, і кожним з них користувалося чимало інженерів. Крім того, працювати з кодом через екрани було складно через невеликий обсяг пам'яті та низьку роздільну здатність дисплеїв. Тому програмісти друкували десятки сторінок коду на папері, ділилися один з одним та редагували з допомогою олівця — саме так виглядало код-ревʼю тих часів.
Якось компанія Xerox подарували MIT новий лазерний принтер. Проте з часом через високе навантаження у ньому зʼявилася проблема — він «зажовував» папір та аварійно зупинявся. Ним користувалися десятки розробників, паралельно відправляючи на друк свої документи. В результаті принтер друкував їх хаотично, змішуючи сторінки — після кожного збою робота в MIT зупинялася на певний час.
Річард Столмен вже стикався з цією проблемою раніше. На попередньому графічному принтері він знайшов «костильне», але дієве рішення, переробивши код дравейра та додавши чимало корисних фічей. Наприклад, програмне забезпечення повідомляло користувачів про завершення завдання друку або проблеми — застрягання паперу чи його нестачу. Це сприяло безперебійній роботі та значно економило час.
Проте в новому принтері вихідний код був закритим. Він керувався власним програмним забезпеченням, яке працювало на окремому комп’ютері, до якого не було доступу. Столмен звернувся до компанії Xerox та запропонував свої ідеї допрацювання драйвера — це б могло полегшити життя усім користувачам девайсів компанії. Проте менеджер відмовив йому, посилаючись на ліцензійні угоди. Це шокувало Річарда і сформувало вороже ставлення до всього пропрієтарного ПЗ. Він прийняв рішення уникати будь-яких ліцензій на софт, і дотримується його і донині.
В пошуках аналогів Unix
На той час однією з найпопулярніших операційних систем був Unix, розроблений в Bell Labs, підрозділі AT&T. Оскільки AT&T була під антимонопольними обмеженнями, компанія не могла комерціалізувати Unix, тому вихідний код операційної системи поширювався серед університетів та дослідницьких центрів на умовах некомерційного використання. 1982 року обмеження було знято, і AT&T почала продавати Unix та закрила код. Ціна за користування операційною системою була співставна з покупкою самого компʼютера.
Щоби купити компʼютер на початку 80-х, потрібно було за замовченням придбати пропрієтарну операційну систему Unix. Річард Столмен почав шукати їй альтернативу. Оскільки якісних відкритих операційних систем не було, він вирішив створити власну та опублікувати її у вільний доступ для всіх користувачів. Він хотів сформувати комʼюніті навколо та дозволити змінювати її як завгодно. Це стало метою його життя.
Робота над проєктом розпочалася у січні 1984 року. Столмен звільнився з MIT та розпочав розробку ОС GNU (рекурсивна абревіатура, яка розшифровується як GNU’s not UNIX). Щоби уникнути проблем із авторським правом, він почав писати код з нуля. Оскільки Unix складався з сотень модулів (компілятор, дебагер, текстовий редактор, програма для форматування тексту, поштовий клієнт тощо), він мусив крок за кроком переписати їх усі. Тоді Річард оголосив, що займається розробкою альтернативою Unix, і до його проєкту почали долучатися люди, комʼюніті зростало. Пізніше він заснував рух Free Software Foundation (FSF), який підтримував проєкти з вільним кодом.
Річард Столмен планував не просто зробити аналог Unix, а додати туди чимало нових фічей. «GNU буде ядром з усіма утилітами, необхідними для написання та запуску програм на С: редактор, оболонка, компілятор, компонувальник, асемблер та кілька інших речей. Після цього ми додамо засіб форматування тексту, YACC, гру Empire, електронну таблицю та сотні інших речей. Ми внесемо всі зручні вдосконалення, виходячи з нашого досвіду роботи з іншими операційними системами. Зокрема, ми плануємо мати довші імена файлів, номери версій файлів, стійку до збоїв файлову систему, віконну систему на основі Lisp. Ми матимемо мережеве програмне забезпечення, засноване на протоколі chaosnet Массачусетського технологічного інституту, значно кращому за UUCP», — зазначалося в анонсі.
Так, з допомогою комʼюніті до 1991 року усі модулі нової операційної системи були готові. Не вистачало лише ядра, яке б надавало ресурси усім цим програмам.
Linux — останній пазл у GNU
Ядро, яке отримало назву Hurd, було останнім компонентом в операційній системі GNU. Команда хотіла створити Mach-подібне ядро, в основі якого лежить мікросервісна архітектура. Основною ідеєю було розбиття функцій ядра на невеликі, незалежні сервіси, які взаємодіяли б між собою через інтерфейси. Проте мікросервісна архітектура ядра була складним шляхом і потребувала тривалих налаштувань і дебагу.
У цей час фінський студент Лінус Торвальдс, який навчався в Університеті Гельсінкі, почав роботу над власною операційною системою. Він намагався знайти програмне забезпечення, схоже на університетські комп’ютери Sun Microsystems, створені на базі Unix. Так само як і Столмена, його не влаштовувала ліцензійна Unix, тому він почав писати власну, не знаючи про існування GNU. Проте, на відміну від Річарда, він почав з ядра та обрав монолітний варіант архітектури, тому реалізував його значно швидше. У вересні 1991 року він випустив першу версію ядра Linux (версія 0.01), яка мала обмежену функціональність, але могла виконувати базові завдання.
Розвиток Linux
Версія | Рік релізу | Кількість рядків коду | Кількість користувачів |
0.01 | 1991 | 10 000 | 1 |
0.96 | 1992 | 40 000 | 1 000 |
2.1 | 1997 | 800 000 | 3,5 млн |
2.110 | 1998 | 1,5 млн | 7,5 млн |
2.2 | 1999 | 2,5 млн | 12 млн |
Лінус вирішив поділитися кодом Linux, і до проєкту приєдналося чимало розробників з усього світу. Зрештою спільнота вирішила використовувати ядро Linux як частину операційної системи GNU. Змусити їх добре працювати разом було нетривіальним завданням. Поступово Linux інтегрувався з інструментами та програмами проєкту GNU, утворюючи повноцінну операційну систему GNU/Linux.
Сьогодні більшість користувачів сприймають усю операційну систему GNU під назвою Linux. Вона була б неможливою без ядра, проте і Лінус не зміг би розробити Linux без C-компілятора з відкритим кодом GNU.
Велика хартія вольностей 2.0
Річард прагнув справжньої свободи ПЗ — щоби його можна було копіювати, використовувати у комерційних цілях, як завгодно ділитися з іншими людьми.
«Щоби зрозуміти концепцію, ви повинні думати про «безкоштовне» як про «свободу слова», а не як про «безкоштовне пиво», — пояснював Річард Столмен.
Будь-які ліцензії він сприймав як зраду та порушення прав. Водночас вільне ПЗ мало також бути захищеним авторським правом, і спільнота створила ліцензію General Public License (GPL). «Якщо просто викладати софт в інтернет як free ware, хтось обовʼязково внесе в нього невеликі зміни та почне продавати як закрите ПЗ. Суть нашої ліцензії в тому, що весь софт захищений авторським правом. Його автори дозволяють людям його використовувати, змінювати, доповнювати та розповсюджувати, проте на цих самих умовах. Таким чином, де б не опинився наш софт, свобода крокуватиме поруч з ним», — пояснював Столмен.
Він назвав її «Copyleft», щоби підкреслити, що його ліцензія захищає права і свободи користувачів, на відміну від традиційного copyright, який їх обмежував. Еван Лейбовіч, технічний колумніст ZDNet Tech Update порівнював GPL з Великою хартією вольностей, яка свого часу стала першим юридичним документом про права людини. Ліцензія від спільноти вільного коду забезпечувала дотримання прав і свобод користувачів комп’ютерного програмного забезпечення.
Зокрема ліцензія GPL містить чотири компоненти:
Свобода запускати програму з будь-якою метою.
Свобода вивчати, як працює програма, і адаптувати її до своїх потреб.
Свобода розповсюджувати копії програми.
Свобода вдосконалювати програму та оприлюднювати свої покращення для спільноти.
Відкрите ПЗ проти вільного ПЗ: у чому різниця
Не всі сприйняли «Copyleft». Деякі ідеї Річарда виглядали занадто радикально, зокрема те, що на ПЗ не можна заробляти. Група розробників почала просувати практичні переваги концепції для бізнесу та комерційного використання. Вони вважали, що термін «вільний код» асоціювався з чимось дешевим, неякісним та нікому непотрібним. Крім того, вони розуміли, що без підтримки великих бізнесів ця ідея не зможе розвиватися. Так на основі поняття «вільний код» зʼявився «відкритий код».
Якщо Річард Столмен у концепції вільного коду акцентував на етиці, соціальних цінностях та забезпеченні користувачів правами й свободами, то відкритий код фокусувався на практичних перевагах розробки: висока якість, безпека, швидкість, прозорість і співпраця.
1997 року вийшло есе американського програміста Еріка Реймонда «Собор і Базар» (The Cathedral and the Bazaar). У ньому автор порівнював пропрієтарний підхід до розробки з ідеями відкритого коду — децентралізованій системі з налагодженою комунікацією учасників та короткими релізами. Ерік Реймонд представив свої ідеї на конгресі Linux, де ними зацікавився представник Netscape. Компанія розвивала інтернет-браузер Netscape Navigator та вела жорстку конкурентну боротьбу з Internet Explorer.
Ідеї Еріка Реймонда також підтримав Брюс Перенс, активний учасник руху вільного програмного забезпечення та один з лідерів продукту Debian, дистрибутиву Linux. Саме на основі політики Debian була створена нова концепція та ліцензія опенсорс, до якої входило 10 правил. 1998 року вони заснували організацію Open Source Initiative (OSI), яка займалася популяризацією Open Source.
Незабаром Netscape став першим великим бізнесом, який прийшов в опенсорс. Битву Internet Explorer він все ж таки програв, але з його коду народився інший успішний опенсорс проєкт — Mozilla Firefox, який згодом став лідером ринку. З часом Linux також приєднався до OSI, а за ним потягнулися й інші.
Як Microsoft став найліпшим другом опенсорс
Надалі розвиток відкритого та вільного коду йшов паралельно. Ідеї Річарда Столмена отримали значну підтримку в академічних і наукових колах. FSF продовжувала активно підтримувати нові проєкти і працювала над захистом юридичних прав користувачів. Натомість опенсорс поширився у бізнес-середовищі й став основою таких технологій, як Apache, MySQL, PostgreSQL. Згодом такі компанії як IBM, Sun Microsystems, і навіть Microsoft, почали визнавати переваги відкритого коду і активно підтримувати проєкти з відкритим кодом.
Далі навколо OSI почали формуватися фонди та спільноти. Наприклад, Python 2001 року заснував Python Software Foundation (PSF). Apache Software Foundation (ASF) було засновано в 1999 році.
На початку 2000-х років компанії, які створювали проєкти з відкритим кодом, пропонували безкоштовний доступ до свого вихідного коду, але стягували плату за підписку на підтримку корпоративного рівня. Одними з перших таку модель застосували Red Hat, які надавали доступ до сервера Linux, відомий як «Red Hat Linux Advanced Se». Розробники могли отримати доступ до вихідного коду сервера Red Hat Linux безкоштовно, але мали платити за підтримку.
Згодом модель підписки з відкритим вихідним кодом перетворилася на щось схоже на модель freemium. Компанії випустили безкоштовні версії свого програмного забезпечення, а розробники та підприємства платили за доступ до додаткових функцій або якщо хотіли, наприклад, збільшити масштаб.
Також проєкти з відкритим кодом отримують фінансування від великих технологічних компаній та у вигляді пожертв від кінцевих користувачів.
Починаючи з 2000-х 2005 року відбулося експонентне зростання відкритого коду. 2005 року Лінус Торвальдс створив систему контролю версій Git. Завдяки платформам GitHub і GitLab опенсорс проєкти залучали ще більше розробників, адже тепер працювати разом з кодовою базою стало значно простіше. 2013 та 2014 року запущені проєкти з контейнеризації та оркестрації Docker та Kubernetes.
Великі технологічні компанії, такі як Google, Facebook і Amazon, активно використовують проєкти з відкритим кодом та є активними учасниками опенсорс-спільноти.
За даними звіту Github за 2023 рік, загальна кількість відкритих репозиторіїв на платформі склала 284 млн. Здавалося б, Річард Столмен мав би бути щасливим, що його ідеї набули таких масштабів. Проте він негативно ставиться до трансформації концепції до бізнес-спільноти. Між ним та авторами руху опенсорсу не раз виникали суперечки, а на форумі Reddit жартують: «Ви нічого не добилися у своєму житті, якщо Річард Столмен жодного разу не писав вам гнівного листа». Загалом він виступає проти Git, хмарних технологій, будь-якої ідентифікації в інтернеті, електронної комерції та ліцензій, заходить в мережу тільки через анонімний браузер Tor і користується ПЗ GNU, який написав сам.
Сама ідея, що все ПЗ має бути відкритим, — геніальна. Це певне перевтілення підходу вільної науки, коли усі ідеї та відкриття науковців є загальнодоступними. Технології не можуть розвиватися у закритому режимі. До 20 століття наука розвивалася дуже повільно саме через те, що була доступна лише вузькому колу людей. Знання мають бути доступними для всіх.
Ще джуном я часто чув від спікерів на конференціях про їхній досвід роботи в опенсорс проєктах, і мені було цікаво дослідити, як працюють під капотом інструменти, проте коли я заходив у проєкт, було важко розібратися з кодовою базою та зрозуміти контекст.
Зараз я намагаюся контрибʼютити, наскільки це можливо. Хотілося б бути активнішим, проте навіть коли є час і натхнення, зʼявляється челендж знайти цікавий проєкт та відповідну таску. У популярних проєктах зазвичай висока конкуренція: іноді заходиш, а там обрану задачу вже вирішують декілька людей. Усім хочеться потім відзначитись на співбесіді як постійний контрибʼютор топової технології. Виходить, що безоплатно попрацювати виходить не завжди.
Зазвичай я обираю проєкти за релевантним напрямом: бази даних та проєкти, що працюють з чергами повідомлень, щоби зануритися в них та поглибити знання. Загалом це займає близько 1 робочого дня на місяць. Найближчим часом хотілося б долучитися до проєктів etcd та nats-server.
Перший досвід контрибʼюшена трапився у популярному продукті Vault — це менеджер секретів у проєктах. Я знайшов невелику таску, зайшов в issues і побачив суперечку, чи варто її вирішувати, адже це мінорний баг, з яким мало хто стикався. І хоч я сам цю проблему в очі не бачив, я сказав, що теж з нею стикнувся і взявся її пофіксити. Так я долучився до спільноти контрибʼютерів Vault.
Зазвичай опенсорс-ком'юніті добре налаштоване для всіх контриб'ютерів, тому фідбек щоразу максимально коректний, навіть якщо потрібно щось переробити. Це одна з причин, чому я долучаюся до цього руху. Отримання відгуку від опенсорс спільноти — це один із способів розвивати себе як розробник. Коли ти працюєш в одній компанії довгий час, тобі корисно також отримувати досвід із зовнішніх проєктів, зростати та розвивати свою команду. Крім того, в Discord-чатах, створених навколо проєктів, люди обмінюються інформацією, інсайтами, що теж буває корисним.
Зазвичай чим більший проєкт та кількість контриб'ютерів, тим складніші правила участі, які описані в Contribution Guide. Наприклад, перш ніж зробити мердж-реквест, крім тестів та лінтерів потрібно також написати детальний Change Log.
Опенсорс, звичайно, підходить не всім компаніям. Наприклад, Solidgate, який розвиває процесингові сервіси не може викласти код у відкритий доступ з питань безпеки. Здебільшого у відкритий доступ викладаються інструменти, якими користується компанія. Наприклад, LinkedIn виклав в опенсорс свою чергу повідомлень Kafka, і вона стала в пригоді іншим бізнесам.
Компаній, що розвивають інструменти, наприклад, MongoDB, відкривають свій код в певних маркетингових цілях. Такі технології викликають більше довіри, адже кожен розробник може піти і подивитись, як це працює під капотом. У відкритому доступі перебувають лише версії для комʼюніті, а більшість платних фічей залишаються для комерційного використання. За таким принципом працює, наприклад, Aerospike, яка займається key-value базою даних: є версія для комʼюніті, а за різні додаткові модулі, моніторинг або підтримку від спеціалістів з компанії, потрібно платити.
І хоча Річард Столмен не так уявляв розвиток своєї концепції, думаю, вся сила ідеї полягає в тому, що вона може лягти в основу іншої. Навіть якщо проєкт MongoDB знайшов спосіб монетизуватися через опенсорс, участь комʼюніті сприяє розвитку технології, тож це іде усім на користь. Тому ця прекрасна ідея відкритого коду продовжує жити, і комерціалізація не заважає їй. Більш того, своє відображення вона знайшла в інструменті GitHub Copilot, який був навчений на відкритих репозиторіях і фактично перевикористовує весь відкритий код.
Більшість людей сприймають контриб'юшн, як написання коду для core-проєкту. Проте участь в обговоренні, пошук проблеми та написання детального баг-репорту — це теж контриб'юшн. Адже потрібно добре дослідити проблему, описати її, а потім донести мейнтейнерам, що це важливо, і це забирає час. Зазвичай я пишу баг-репорти у проєкти, якими сам користуюся, та іноді виправляю помилки самостійно.
За моїми спостереженнями, у проєктах часто відбувається конфронтація між мейнтейнерами (тих, хто відповідає за зміни кодової бази) та контрибʼюторами, які повідомляють про баги. Архітектори проєктів прагнуть підтримувати проєкти у належному стані, але не змінювати їх кардинально, тому мають суперечки з контрибʼюторами, які прагнуть змін у своїх інтересах. Тому часом таке спілкування є доволі токсичним.
Коли я вирішив заглибитися в опенсорс, мене цікавила не стільки прокачка профілю на GitHub, скільки внутрішні процеси роботи комʼюніті над проєктом. Опенсорс вважається найбільш якісним і швидким способом розробки. В таких проєктах також є певна бюрократія, але тільки в критично важливих місцях — коли відбувається з'єднання коду, баг-репорти. Коли проєкти не приділяють цьому уваги, вони можуть скотитися у форк та перестати підтримуватися. Будуючи процеси у своїй команді, я прагнув дослідити ці точки та інтегрувати в роботу своєї команди, щоби зробити розробку якіснішою та швидшою.
Зокрема ми вже додали такі практики:
1. Якісні шаблони для баг-репортів. На кожному етапі у великих опенсорс проєктах стоять Quality Gates — щойно ти намагаєшся створити баг-репорт, мусиш зробити це за шаблоном, який містить чимало полів. Таким чином ти заповнюєш його вдумливо і детально, а не просто повідомляєш, що щось не працює.
2. Triage — на проєктах є окрема людина, яка розбирає тікети, закриває дублікати, уточнює вимоги. Ми перебудували процеси в компанії так, щоби кожна людина могла створити тікет до технічної команди. Далі ми проводимо їх через систему фільтрації, уточнюємо та працюємо з ними.
3. Якісно налаштований код-рев’ю. Ми додали низку автоперевірок та валідацій, завдяки яким відбувся стрибок у якості коду. Зараз якщо розробник робить пул-реквест, і я бачу, що мені щось не подобається в коді, замість того, щоб писати зауваження, я роблю автоматичну перевірку, яка наступного разу заблокує цей фрагмент.
З погляду моралі, опенсорс-проєкти важливі. Якби всі технології патентувалися б, зокрема сама ідея інтернету, ми б зараз жили взагалі в іншому світі. З іншого боку, опенсорс тримається на альтруїстах. Коли ти викладаєш у відкритий доступ свою технологію, а великі корпорації починають користуватися нею та заробляти, це демотивує. Нещодавня гучна історія трапилася з Redis. Тривалий час Google і Microsoft використовували Redis як сервіс. Тобто, користувач платив Google за користування цією базою даних, а сам Redis за це нічого не отримував. Щоби продовжувати розвивати проєкт, вони змінили ліцензію на платну, що викликало багато критики у користувачів.
Інший приклад — фреймворк NestJS, яким користуються сотні тисяч розробників. У нього всього один мейнтейнер, який контрибʼютить весь код. Якщо він раптом припинить це робити, хтось має взяти проєкт під своє крило та продовжити розвивати його. Тому авторам важливо вміти правильно побудувати комʼюніті навколо проєкту, яке буде його підтримувати надалі, щоби важливі проєкти, якими користуються усі не перетворювалися на закинуті репозиторії.