Бізнес на відкритому коді: скільки він протримається? Розбираємося в економіці open-source

На програми з відкритим кодом щодня розраховують мільйони людей: під час перегляду веб-сторінок, потокового відео, голосових вказівок смартфону — постійно. Кожен з цих проектів має відкритий вихідний код, тож кожен охочий може знайти його, подивитись і використати, як і коли завгодно. Одна з причин, чому код взагалі почали робити відкритими — швидкий пошук помилок. Здається, усе логічно: чим більше програмістів подивляться і скористаються розробкою, тим швидше будуть знайдені і виправлені всі баги. Та на практиці так відбувається не завжди. Згадаймо про OpenSSL, протокол шифрування, що захищає левову частину інтернету. Це проект з відкритим вихідним кодом, який понад десять років створював Стівен Генсон з невеликою командою. Наприкінці 2011 року вони відповідали за підтримку кодової бази, що містила півтора мільйона рядків коду, більшість з яких написав або затвердив сам Генсон. Колосальна відповідальність для однієї людини, якщо згадати, що OpenSSL захищав сервери двох третин усіх активних сайтів, чат-, імейл-сервери, VPN й інфраструктуру урядових та фінансових інституцій. Кілька тижнів Стівен Генсон та його колега Робін Сегельман працювали над кодом OpenSSL, зрештою затвердили його, але пропустили одну помилку. Баг, що з часом став відомий як Heartbleed, дозволяв зловмисникам перехоплювати інформацію, що передавалась на будь-який сайт під захистом OpenSSL (а це, нагадаємо, дві третини сайтів взагалі). Сегельман визнав, що ця помилка була доволі звичайною і помітити її було б нескладно, просто він не помітив. Баг Heartbleed був у коді OpenSSL два з половиною роки, допоки його не знайшли і не усунули в 2014-му. Та він і досі живе на тисячах пристроїв, де його навряд колись виправлять. Тож, як бачимо, відкритий доступ до коду не убезпечує його від помилок. Те, що безліч людей можуть доопрацювати чи виправити продукт, не означає, що вони це зроблять. І на цьому прикладі стають помітними усі проблеми й суперечки, пов'язані із самим явищем відкритого коду.

ДЖЕРЕЛО ВСІХ ПРОБЛЕМ

Як зазначив у своєму блозі Стів Маркес, колишній генеральний директор OpenSSL Foundation, причина Heartbleed була у виснаженні розробників і відсутності фінансування. За словами Маркеса, фонд працював із бюджетом, що складався з менше ніж 2000 доларів пожертвувань й менше мільйона доларів на рік від контрактів. Фонд не міг укладати більше контрактів, тому що розробники і без того працювали на повну ставку та мали сім'ї, у них просто не було часу. Очевидно, що OpenSSL — надто серйозний і великий проект, однієї крихітної і перевтомленої команди для нього було замало.

Розробники працюють над OpenSSL не за гроші і не за славу. Вони роблять це через гордість, майстерність і відповідальність за справу, у яку вони вірять ... знаючи, що будуть проігноровані, допоки щось не піде не так.

То все в порядку і можна не хвилюватися?

Ні. Оскільки відкритий код використовує так багато компаній, розробники популярного ПЗ мусять розгрібати безліч проблем. Вони обробляють дедалі більше звітів про помилки, feature-запитів, рев'ю і комітів коду тощо, кінця цьому немає. У той же ж час програмісти, які займаються відкритим кодом, теж мусять мати справу з корпоративними користувачами. Останні не завжди розуміють норми спільноти, умови і обов'язки працівників, якщо йдеться, наприклад, про збої у роботі програми. Користувачі придбали ПЗ, яке не працює, тож байдуже, хто там винен. Зрештою і покупці, і корпоративні працівники, і розробники відкритого коду — усі незадоволені. Багато девелоперів вважають, що проблемам можна зарадити грошима. Якби гігантські технологічні компанії вкладали більше ресурсів у продукти, від яких самі ж і залежать, все було би добре. Розробники могли б більше часу працювати над відкритим кодом і це стимулювало б спільноту програмістів загалом. Однак недостатньо просто кинути більше грошей. Збільшення фінансування створює свої проблеми: як ці гроші розподіляються і що спонсори хочуть у відповідь за них. Є ризик того, що приплив капіталу зруйнує ідейну основу спільноти, на якій відкритий код тримався майже півстоліття.

БЕЗКОШТОВНЕ, ЯК ПИВО: ОСНОВИ ЕКОНОМІКИ OPEN-SOURCE ПРОЕКТІВ

Все почалось з лабораторії штучного інтелекту MIT на початку 80-х років. Тоді піонери комп'ютерних наук, як от Марвін Мінскі, спілкувались та навчали нове покоління хакерів, таких як Річард Столлман і Гай Стіл, котрі згодом докорінно змінять світ програмування. Стіл зіграв важливу роль в документуванні та створенні мов Lisp і Scheme. Столлман заклав фундамент усього руху open-source . Нещодавно Річард Столлман розповів New Left Review, як лабораторія штучного інтелекту сприяла культурі співпраці та радикальної відкритості. Тоді гігантський комп'ютер лабораторії ще не був захищений паролями, а двері завжди були відчинені. У 1983 році він опублікував повідомлення в групі Usenet — такому собі протофорумі — і сказав, що створить операційну систему та віддасть безкоштовно кожному, хто зможе її використовувати. ОС він назвав GNU — це абревіатура для Gnus Not Unix. Своєрідний виклик домінуючій ОС того часу Unix. GNU був першою ластівкою у русі вільного програмного забезпечення, принципи якого Столлман висловив у Маніфесті GNU 1985 року:

Золоте правило вимагає: якщо програма мені подобається, я маю вільно поділитися нею з іншими. Продавці програмного забезпечення хочуть розділяти користувачів, щоб володарювати; вони нав'язують думку, що користувачам не варто ділитися з іншими. Я відмовляюсь діяти у такий спосіб.

Було тільки одне «але».

В основі руху за вільне програмне забезпечення була етика, а вона, як відомо, шкодить бізнесу. Тому в 1998 році група прибічників open-source зібралася, щоб з'ясувати, як зробити вільне ПЗ привабливим для промисловості. Розробники хотіли змінити репутацію й імідж продукту, аби його захотіли купити корпорації. «Ретроспективно нам здавалося зрозумілим, що термін "вільне програмне забезпечення" завдав неабиякої шкоди за ці роки», — написав Реймонд в есе Open Sources: Voices from the Open Source Revolution. Він зазначив, що словосполучення free software занадто асоціювалось з комунізмом і порушенням прав інтелектуальної власності. Так виникло поняття open source. Ця маркетингова кампанія зі зміною іміджу мала феноменальний успіх. Програмне забезпечення з відкритим вихідним кодом дотепер лежить в основі технологічних платформ та послуг, які більшість з нас використовує щодня. Візьмемо хоч Microsoft, чий колишній генеральний директор Стів Балмер якось назвав Linux та інші проекти з відкритим кодом «раком». Зараз Microsoft позиціонує себе чемпіоном і фанатом open-source. Не пасуть задніх і Google, Facebook, Amazon, IBM та навіть уряд США. Вільне (free) програмне забезпечення, якщо й згадується взагалі, зазвичай ховається під загальним терміном «вільне та відкрите програмне забезпечення» або «FOSS» (Free and Open Source Software).

ЕКОНОМІКА OPEN SOURCE

Більшість компаній з Кремнієвої долини швидко прийняла відкрите програмне забезпечення. Економісти ще довго намагалися пояснити, як ці проекти, що порушили всі правила ринку, могли бути настільки успішними. Попереднє пояснення (про етику, свободу і альтруїзм) не здавалося адекватним, коли мова йшла про розвиток грандіозних та успішних проектів, як от Linux. Ще не відбувалось нічого подібного лише завдяки доброзичливості й альтруїзму. Ця аномалія спричинила шквал досліджень на початку 2000-х років. Економісти шукали, де ж розробники мали вигоду, та прагнули пояснити розвиток відкритих проектів так, щоб не порушилась традиційна система: раціональний виробник + споживач. У 2000 році економісти Джош Лернер і Жан Тироль (Josh Lerner & Jean Tirole) опублікували найвідоміше економічне пояснення розвитку відкритих проектів. У праці The Simple Economics of Open Source Лернер і Тірол перелічили переваги, які отримували розробники від проектів open-source. Економісти залишались економістами, з їхнього погляду головним мотивуючим фактором не могло бути просто бажання дати світові вільне програмне забезпечення. Вигодами, що їх отримували розробники, вважались або гроші, або користь від готового продукту для себе (тобто гроші), або просування у кар'єрі (яка принесе гроші), або визнання з боку колег. Праця Лернера й Тіроля стала своєрідним Євангелієм у галузі. Сьогодні це найбільш цитована стаття з економіки відкритого коду. Уся ця історія з економістами і відкритим кодом характерна для початку нульових, але екосистема FOSS дуже змінилася за останні 15–20 років. Ці зміни значною мірою зумовлені створенням Git у 2005 році. Сервіси на Git (передовсім створений через 3 роки GitHub) значно прискорили темпи розробки відкритих проектів та різко знизили бар'єр для входу нових учасників. Це була нова проблема, що її Лернер і Тірол передбачили майже за десять років до появи GitHub. Вони ставили під сумнів, чи зможе керування open-source проектами пристосуватись до ще більшої кількості учасників. Швидке зростання кількості учасників руху часто називають підтвердженням його розвитку. Однак все більше розробників FOSS стали говорити про вигорання через підтримку репозиторіїв з відкритим вихідним кодом. Зростав потік компаній, що залежать від відкритих проектів, і зростав потік звернень та запитів від цих компаній до розробників. І кожна вважає свої справи пріоритетними, тож перенавантаження програмістів стало серйозною проблемою. Багато розробників FOSS почали замислюватись: чи є стійкою в масштабі модель розробки програмного забезпечення, яка спирається на доброзичливість окремих волонтерів? Деякі розглядали це як культурну проблему, що зникне, якщо вчити учасників бути хорошими,терплячими і відмовлятись від грошових внесків. Інші говорили про недостатнє фінансування як джерело всіх бід. Треті заперечували, що системна проблема існує взагалі.

ТРАГЕДІЯ ВІДКРИТИХ ПРОЕКТІВ

У 2015 році Надя Егбаль (Nadia Eghbal) полишила роботу венчурного капіталіста і вирішила з'ясувати, чому для багатьох проектів з відкритим кодом було так важко монетизувати свою роботу. Егбаль зацікавилася економікою open-source після численних розповідей про те, що хороші проекти є, їх використовують, а от як фінансувати — незрозуміло. Багато популярних проектів з відкритим кодом мали всі ознаки успішного запуску: швидке прийняття, велика база користувачів і низькі витрати на розробку. Але проблема в тому, що залучити інвесторів можна тільки перспективою великих прибутків. Для сталого фінансування відкритих джерел потрібні альтернативні механізми використання, одним успішним запуском не обійдешся. Після року опитування сотні розробників Егбаль публікує «Roads and Bridges» — напевно, найбільше дослідження з економіки відкритого програмного забезпечення. Ця доповідь показує open-source як невиключне суспільне благо. Тобто ресурс, який може використовувати будь-хто, як от дороги чи мости. Невиключні суспільні блага є наріжним каменем здорової спільноти, але вони підпорядковуються тому, що економісти називають «Проблемою безкоштовного проїзду» і «Трагедією спільного». Проблема безкоштовного проїзду описує ситуацію, в якій товар або надмірно споживається, або недостатньо виробляється. Не існує способу заборонити його людям, які не заплатили. Коли кожен використовує благо у своїх інтересах і нічого не віддає, воно зникає і перестає бути корисним. У випадку з FOSS енергія та увага програмістів не безкінечні, а без них проекти не зможуть функціонувати і бути корисними та безпечними. Google може витрачати значні ресурси на розробку інструменту з відкритим вихідним кодом, як от TensorFlow, платформу для машинного навчання. Але це відкритий код, ним користуються й інші. Якщо безліч компаній почне використовувати TensorFlow, але не сприятиме його підтримці, програмне забезпечення буде недостатньо продуктивним. Трагедія спільного достатньо вивчена в економіці, але Егбаль зрозуміла, що звичайні рішення (перетворити товари на приватне або регульоване благо) тут не годяться, адже тоді відкриті проекти перестануть бути відкритими. До того ж, регулювання open-source (наприклад, створення організації для розподілу державних грантів серед відкритих проектів) підриває основні переваги руху. Від такої стабільності може постраждати ефективність та швидкість процесів. Окрім того, управління і контроль підірвуть сам вільних дух проектів. Деякі розробники намагалися регулювати використання їхнього відкритого програмного забезпечення. Наприклад, хотіли заборонити свої програми для установ, що співпрацюють із міграційними та митними службами. Але реакція спільноти на такі дії була разюче негативна, тож вони не прижилися. Очевидно, що відкрите програмне забезпечення має бути доступним для всіх — так вважає спільнота.

ВІДКРИТИЙ КОД, ЗАКРИТА СПІЛЬНОТА

Є думка, що регулювання доступу до товариства вирішило б проблему вигорання і перевтоми. Модель «відкритий код, закрита спільнота» передбачає оплату за доступ до спільноти розробників, що працюють над проектом. Так учасників буде менше, але вони будуть справді зацікавлені у покращенні коду. Звісно, є ті, хто не хоче обмежувати доступ до проекту, але прагне уникнути вигорання розробників. Для них логічно було б просити користувачів підтримувати проект і наймати на ці кошти команду. Цей підхід перетворює фінансування відкритого джерела у вправу розрахунку: з'ясуйте, хто отримує вигоду від проекту з відкритим кодом, і переконайтеся, що вони вносять свій внесок у екосистему. Хоча центральної бази, яка відстежувала б усіх учасників open-source, немає, є дещо досить близьке — це називається GitHub. GitHub запрацював у 2008 році, нехай це не єдине місце, куди програмісти приходять зберігати і обговорювати відкриті проекти, все ж GitHub — головний оплот. Сьогодні там понад 100 мільйонів репозиторіїв, створених приблизно 25 мільйонами учасників зі всього світу. Мотивація, яка змусила ці 25 мільйонів зробити свій внесок у розробку з відкритим вихідним кодом, є різноманітною, але, за словами Девіда Ганссона, засновника Ruby on Rails, протягом останніх двох десятиліть учасники FOSS дуже змінились. Більшість програм фінансується компаніями, що шукають вирішення своїх проблем та платять розробникам. Не можна сказати, що програмісти, які самі пишуть код, зовсім зникли. Вони є ідейним фундаментом, основою спільноти FOSS. Але найактивніші учасники займаються проектами Google, Microsoft, Amazon, IBM, Facebook, TenCent, Baidu, Red Hat й Intel. Кожна з цих компаній комерційна і продає продукти, що базуються на відкритому коді. І, звісно ж, усі вони переконані, що роблять достатньо для проектів з відкритим кодом, а не лише заробляють на них. На свій захист представники корпорацій розповідають про пожертвування у фонди open-source проектів, заохочення працівників до роботи над відкритим кодом, власне самі відкриті і безкоштовні продукти компаній. Та питання не в тому, чи допомагають великі гравці взагалі, а чи роблять вони достатньо, чи співмірний їхній вклад з їхніми прибутками від проектів. Джейкоб Каплан-Мосс (Jacob Kaplan-Moss), співзасновник Django, переконаний, що багатомільярдні компанії повинні зробити більше. Він вказав на GitHub, який нещодавно був придбаний Microsoft за 7,5 мільярдів доларів. Якщо GitHub дійсно піклувався б про open-source, то віддав би половину прибутку учасникам і розробникам, вважає Каплан-Мосс. При цьому частина спільноти вважає, що змішувати гроші та відкриті проекти треба дуже обережно. Розподіл коштів серед учасників точно залишить когось невдоволеним і змусить усіх думати про правила ринку, винагороди, а не про проект, спільноту і творчість. Якщо підсумувати, то питання не в тому, чи потрібно краще фінансувати проекти open-source, а в тому — як це зробити правильно.

БЕЗКОШТОВНІ ПРОГРАМИ КОШТУЮТЬ ГРОШЕЙ

Девід Ганссон — один з найбільших критиків змішування грошей та проектів з відкритим кодом. Та навіть він виступає за збільшення фінансування проектів у деяких випадках. Найбільш перспективним напрямком підтримки open-source він вважає корпоративний патронат. Тобто компанії жертвують кошти фондам, що підтримують конкретні проекти з відкритим кодом. Наприклад, IBM, Intel, Google та Microsoft є «платиновими донорами» для Linux Foundation, де розробники працюють над ядром Linux, це їхня основна робота. Інший спосіб — наймати працівників для роботи над відкритим проектом на постійній основі або ж дозволяти основним працівникам компанії витрачати частину свого робочого дня на відкритий код. Однак тут є свої ризики: якщо одна компанія буде вкладати найбільше сил у розробку якогось конкретного проекту, то природно буде робити його корисним для себе. Така централізація може зашкодити продукту й обмежити його можливості. Все буде зосереджуватись на користі для компанії-спонсора. До того ж, якщо фінансування з одного джерела раптом припиниться, проект, вірогідно, теж не розвиватиметься. З одного боку, що добре для Google — найімовірніше, добре і для всіх. Але різноманітності ринку це точно нашкодить. Хорошим прикладом є розвиток ОС Android, яка працює на 86% усіх проданих у світі смартфонів. Android має відкритий код, але майже всією розробкою займається Google. Водночас Google платить за створення деяких пропрієтарних застосунків, заради яких часто і купують Android — наприклад, Google Maps і Gmail. Кожен може вільно створювати власні операційні системи Android з відкритого вихідного коду, але Google забороняє використовувати свої програми на будь-яких неофіційних «Андроїдах». А у людей виникає прямий асоціативний зв'язок між продуктами Google і Android. Компанії можуть вільно використовувати спеціальну версію Android без продуктів Google, але це не те, чого хочуть користувачі. Amazon вже намагався це зробити у 2014 році з телефоном Fire — і все скінчилося помилкою у 170 мільйонів доларів.

То Ганссон правий: треба просто запровадити корпоративний патронат і все налагодиться?

Не зовсім. Навіть якщо проект з відкритим вихідним кодом хоче перейти на корпоративне спонсорство, багатьом не вистачає організаційної структури. Принаймні, так вважає Деб Ніколсон (Deb Nicholson), директорка з комунікацій у Software Freedom Conservancy — організації, що надає інфраструктурну підтримку проектам з відкритим кодом. SFC є однією з багатьох неприбуткових організацій, що надають інституційну підтримку проектам з відкритим кодом. Є й інші: Software in the Public Interest або Free Software Foundation. Вони пропонують різні послуги, такі як юридичні консультації або фізична інфраструктура (сервери, офісні приміщення тощо), необхідні для запуску успішного проекту з відкритим кодом. Роль цих неприбуткових організацій полягає в тому, щоб допомогти проектам вирішити організаційні дилеми і дати FOSS зосередитися на створенні програмного забезпечення. Окрім цього, є ще комерційний підхід до розвитку open-source. Наприклад, компанія Tidelift, заснована чотирма колишніми співробітниками Red Hat. Вони сподіваються збільшити фінансування для проектів з відкритим вихідним кодом. Як? Генеральний директор Tidelift Дональд Фішер (Donald Fischer) сказав, що найбільшим бар'єром для відкритого проекту є невпевненість покупців у тому, що продукт буде працювати чітко і добре. Особливо це стосується ретельно регульованих галузей, як от банківська справа. У відкритих програм немає гарячої лінії підтримки, якщо щось піде не так — до кого звертатися? Розробники, може, не хочуть монетизувати свій час на розв'язання проблем клієнтів, але хтось-таки й здатен це робити. Бізнес може платити за послуги підтримки проектів, які вони використовують. Tidelift — такий собі Airbnb або Uber для галузі open-source. Компанія працює над проблемами безпеки, ліцензування або обслуговування та окремо платить розробникам відкритого проекту. Розмір виплат залежить від того, скільки компаній використовують код. Це не перша ініціатива, яка намагалася монетизувати проекти з відкритим кодом. Згадаймо Code Sponsor, що хотіла шукати компанії, які б розміщували рекламу у проектах FOSS. З часом Code Source змінила свою бізнес-модель, реорганізувалась, змінила назву на CodeFund і зараз використовує етичну цифрову рекламу для фінансування проектів з відкритим кодом. Дехто з розробників намагався фінансувати свої відкриті проекти через краудфандингові платформи, як от Patreon. У деяких випадках це працює, наприклад, Еван Ю (Evan You), автор Vue.js, збирає щомісяця на Patreon понад 17 000 доларів. Але випадки успіху поодинокі. У січні менеджерка проекту GitHub Девон Цугель (Devon Zuegel) написала пост «Let's talk about open source sustainability», де підкреслила ряд проблем у спільноті: неадекватні ресурси та управління, відсутність комунікації та перевантаження роботою. Цугель просила розповісти, як вона може допомогти хоча б із частиною цього. Такий заклик сприйняли неоднозначно. Дехто радів, що GitHub хоче зарадити розробникам, інші ж рішуче не погоджувались з тим, що проблема взагалі існує. Питання про те, чи є криза стійкості у FOSS, — суперечливе, але знайти рішення для проектів з відкритим кодом все одно потрібно. Розробники постійно витрачають сили на те, щоб знайти фінансування та волонтерів для підтримки розвитку, і продовжують працювати над проектами. Це очевидне свідчення їхньої відданості цілям проекту та етичним переконанням. Більшість розробників згодні з тим, що стале фінансування спільноти призведе до кращого програмного забезпечення. Як зазначив Генрі Чжу (розробник Babel.js) у «Hope in Source», спільнота з відкритим вихідним кодом дуже схожа на релігійну, особливо у ставленні до грошей. Організовані релігійні громади потребують фінансування для базових потреб, але їхні найважливіші активи — це люди, які збираються разом і працюють заради спільної мети. Тим більше несправедливо, що технологічні компанії та користувачі покладаються на цих розробників. Світ дедалі більше залежить від програмного забезпечення з відкритим кодом. Це стосується і споживчих товарів, і критично важливої інфраструктури інтернет-безпеки. Тому настав час корпораціям і користувачам зрозуміти: відкриті проекти варті того, аби за них платили.