[software.thoughts] Мой личный взгляд на тенденции вокруг OpenSource-библиотек

Данный пост можно рассматривать как продолжение недавнего поста про OpenSource лицензии и способы заработка на OpenSource разработках. Сегодня я попытаюсь изложить свой взгляд на то, как менялись тенденции в распространении библиотек и как это, по моему мнению, повлияло на экономику разработки этих самых библиотек. Правда, в разработке софта я не очень давно, профессионально занимаюсь этим всего 25 лет, поэтому буду делиться своими впечатлениями за этот небольшой промежуток времени. И, к сожалению, не смогу рассказать о том, что происходило в 80-е годы прошлого века и еще раньше.

Святые 90-е, рынок во все поля

Итак, насколько я помню, в 90-е годы продажа библиотек была вполне себе понятным и сложившимся бизнесом. Как мне представляется, тому способствовало несколько важных факторов:

• активное проникновение персональных компьютеров в самые разнообразные сферы и вызванная этим большая потребность в разработке самого разнообразного софта. Как системного или околосистемного, так и прикладного. Плюс наметившийся в 90-е годы переход персоналок от текстового MS-DOS-а к графическому Windows. Поскольку софта нужно было делать много и быстро, то была и потребность в готовых программных компонентах, на базе которых можно бы оперативно писать прикладное ПО. Бывшие в те годы маргинальными MacOS, OS/2 и различные варианты Unix-ов не берем в рассмотрение, т.к. на фоне тогдашнего парка IBM-совместимых персоналок это все было лишь каплей в море. Хотя и под эти маргинальные направления существовал свой рынок, на котором кто-то вполне себе зарабатывал;
• появление такого явления, как RAD (Rapid Application Development) инструментарий самым ярким примером которого в то время был, полагаю, Borland Delphi. Разработчик в IDE мог быстро собрать из готовых компонентов заготовку для своего приложения, которая затем уже тщательно дорабатывалась напильником. Вопрос был лишь в том, откуда брать эти самые готовые компоненты. И на этот вопрос ответил рынок, на котором тогда появилось множество разнообразных библиотек контролов для Delphi/Builder-а, генераторов отчетов, средств поддержки различных форматов данных и пр.;
• OpenSource явление тогда уже было более-менее известным, привлекающим к себе внимание, но еще не доминирующим. Т.е. про OpenSource можно было прочитать, можно было даже как-то прикоснуться, если у вас был более-менее нормальный доступ к Интернету, можно было прочитать мнения экспертов о том, что в будущем OpenSource будет играть все более серьезную роль (особенно много таких статей мне лично стало встречаться ближе к концу 1990-х и началу 2000-х). Но непосредственного влияния на разработчиков для ПК и пользователей софта для ПК OpenSource тогда еще не оказывало. Кроме того, инструментарий для формирования большой и открытой экосистемы OpenSource стал доступен широкой публике только в 2000-х (я сейчас про сервисы вроде SourceForge, Google Code, BitBucket и GitHub);
• из-за того, что мощность тогдашних ПК была небольшой, значительная часть софта разрабатывалась на компилируемых непосредственно в машинный код языках программирования: С, C++, Pascal/ObjectPascal/Delphi, Modula-2 и иже с ними. ЕМНИП, даже какие-то диалекты dBase-совместимых языков, типа Clipper-а, могли выдавать на выходе исполняемый .exe-файл. Кроме того, инструментальных средств разработки было не так уж много, а производители компиляторов стремились поддерживать совместимость с obj/lib-файлами от предыдущих версий своих компиляторов. Это давало возможность распространять библиотеки без исходных кодов: просто архив, в котором, в случае C/C++, были только заголовочные файлы и несколько .lib-файлов. Обычной практикой в то время было узнать какая версия компилятора от MS или Borland-а у клиента и выслать клиенту собранную библиотеку именно под эту версию.

В общем, была потребность в готовых компонентах, была возможность раздавать эти самые готовые компоненты в закрытом виде. И не было толп красноглазых борцунов за религию OpenSource со святым Столманом на знаменах :)

Правда, возможность распространять готовые компоненты в закрытом виде была хороша для производителей компонентов, но для пользователей это было не очень удобно. Т.к. ошибки есть везде, документация всегда оставляет какие-то вопросы без ответов (даже если она хорошо написана, что далеко не всегда имело место быть), то пользователь оказывался в неприятной ситуации когда ему требовалось заглянуть в потроха библиотеки. Не важно, с целью ли отладки, или же просто разобраться с тем, что и как внутри библиотеки происходит.

Поэтому достаточно быстро стало понятно, что очень здорово, когда купленная библиотека поставляется клиенту не только в виде готовых бинарников, но еще и с исходными кодами. Т.е. множество пользователей чужих библиотек на собственной шкуре прочувствовало одно из преимуществ, которые дает модель OpenSource.

Как бы то ни было, в 1990-е и самом начале 2000-х вполне себе работал рынок библиотек. Были фирмы и индивидуальные разработчики, которые на постоянной основе занимались разработкой программных библиотек и продавали результаты своего труда. И были покупатели, которые были готовы покупать сторонние библиотеки по вполне себе понятны причинам: нужно было экономить свое время и тратить собственные силы только на свою прикладную задачу, а альтернатив готовым платным и закрытым (или частично открытым) библиотекам не было.

Все течет, все изменяется...

Однако, в конце 1990-х и начале 2000-х ситуация стала меняться.

Во-первых, сформировалась такая ниша, как Web-разработка, в которой изрядная часть разработки -- это server-side, который под Unix-ами. И не просто под Unix-ами, а под разработанными в рамках модели OpenSource Unix-ами, вроде Linux и FreeBSD. И вот уже OpenSource -- это не просто что-то где-то там, а это именно то, с чем приходится иметь дело здесь и сейчас. Будь то дистрибутив Linux, компилятор GCC или Web-сервер apache.

Во-вторых, мощность компьютеров выросла настолько, что стало возможно разрабатывать большой и серьезный софт на динамически-типизированных языках, вроде Python и Ruby. В которых все распространяется в исходниках. Так что если вы делаете какую-то полезную библиотеку на Python-е, то отдать ее клиенту в закрытом виде, не показывая исходников, уже не получится.

Сюда же я бы добавил и Java с ее байт-кодом, из которого посредством декомпиляторов можно было чуть ли не полностью восстановить исходный код. Кто-то раздавал Java-библиотеки обсфуцированные специальными средствами, чтобы по восстановленном исходнику было ничего не понятно. Но многие Java-библиотеки никакими обсфукаторами не обрабатывались.

В-третьих, Интернет становился все более и более доступным. Что создало отличную почву для формирования настоящего глобального OpenSource движения. Результатом чего стало появление ресурсов вроде SourceForge, BitBucket и GitHub. Соответственно, распространять открытые библиотеки стало несравнимо проще, чем в 90-е. И формирование сообществ вокруг тех или иных открытых проектов стало обыденным делом. Даже вокруг библиотек с небольшим количество пользователей могло сформироваться жизнеспособное коммьюнити, которое сообща развивало нужные им библиотеки.

Огромную роль в этом сыграло появление таких VCS, как git и Mercurial. В отличии от централизованных VCS (типа CVS и Svn) децентрализованные VCS давали пользователям простую модель внесения изменений в чужой проект: fork-modify-pull. Я могу форкнуть чужую библиотеку, подправить в ней что-нибудь, и отослать свои правки автору в виде pull request-а. И для этого мне не нужно связываться заранее с автором чтобы он дал мне доступ к основному CVS или Svn репозиторию.

В-четвертых, т.к. OpenSource стал оказывать гораздо большее влияние на ИТ-индустрию в целом, а так же сформировалось настоящее большое OpenSource движение с большим количеством евангелистов, размахивающих флагами церкви свободного ПО, то изменилось и отношение крупных корпораций к OpenSource. Стали появляться сперва отдельные случаи открытия исходных текстов своих продуктов (типа открытия исходников браузера Netscape). Затем эти случаи переросли в устоявшуюся тенденцию. И сейчас уже считается хорошим тоном, когда какая-нибудь компания делает внутренний продукт для собственных целей, а потом открывает либо весь продукт, либо значительную его часть под открытой лицензией.

Кроме того, поскольку коммерческие компании стали сильно зависеть от OpenSource решений, то обыденной практикой стали случаи, когда внутри какой-то компании часть сотрудников в режиме full-time работают над OpenSource проектами и, соответственно, результаты их труда становятся доступны всем и бесплатно. Хорошим примером может служить работа над GCC-компилятором сотрудников RedHat.

Ну и к чему это все привело?

А привело это все к тому, что по сравнению с 1990-ми рынок программных библиотек практически схлопнулся. ИМХО.

А понятия "закрытой библиотки" как такового не стало. Отдельные частные случаи, наверное, еще можно отыскать, но это уже именно частные случаи, а не норма.

Какие-то библиотеки еще продаются. Наглядный пример -- это Qt, за которую сейчас просят вполне себе прилично (что-то вроде 5.5k USD за лицензию на одного разработчика). И, вообще-то говоря, найти примеры библиотек с коммерческими лицензиями не так уж и сложно.

Но суть в том, что:

• это именно что OpenSource библиотеки, которые можно бесплатно использовать в открытых проектах, а платить нужно только за коммерческую лицензию;
• отчетливо наблюдается тенденция на активное неприятие copyleft-ных лицензий. Вполне ожидаемо, что мало кто хочет платить за коммерческую лицензию для GPL-ной библиотеки, если где-то рядом есть что-то подобное под пермиссивной лицензией.

Соответственно, как мне представляется, сейчас есть вполне себе четкое движение к тому, что за библиотеки никто не хочет платить. На данный момент нормой считается распространение библиотек либо под полностью пермиссивными лицензиями, либо под лицензиями, которые заставляют открывать лишь код модифицированной библиотеки, но не код продукта, разработанного с помощью библиотеки.

И, как мне представляется, эта норма будет только усиливаться в ближайшие годы, т.к. я пока не вижу признаков того, что маятник вокруг OpenSource качнулся в обратную сторону. В сторону, в которой пришлось бы задуматься, а за чей счет банкет?

Так за чей счет банкет?

Главная мысль, которую я хочу донести в своих рассказах про OpenSource лицензии и OpenSource библиотеки: разработка OpenSource библиотеки -- это труд. Такой же, как и разработка прикладного софта (будь то "коробка" или заказной софт). А значит этот труд должен оплачиваться.

И если в 1990-е годы было понятно, за счет чего оплачивается разработка программных библиотек (за счет продажи копий этих самых библиотек, ваш К.О.), то с пришествием глобального OpenSource и все более усиливающимся неприятием GPL-подобных лицензий, поиск ответа на вопрос "за счет чего должна жить разработка OpenSource программной библиотеки" становится все сложнее.

Складывается ощущение, что в настоящее время развитие библиотеки возможно разве что в качестве побочного эффекта. Грубо говоря, Facebook развивает свой proxygen для того, чтобы решать свои собственные проблемы. Перейдет Facebook с proxygen-а на какой-нибудь Actix-Web и все, proxygen прикажет долго жить.

В принципе, есть еще несколько потенциальных источников финансирования, но у каждого их них есть свои недостатки:

• субсидирование в том или ином виде. Например, это могут быть гранты на разработку/доработку от какой-то крупной организации (как это было в случае разработки ACE в 90-х годах). Или же донаты пользователей. Проблема субсидирования в том, что это нестабильный и нерегулярный финансовый поток;
• продажа техподдержки для библиотеки. В этом случае источником доходов становится не сама библиотека, а ваша способность быстро решать проблемы клиента (которые могут иметь весьма косвенное отношение к библиотеке). Соответственно, значительная часть ваших сил будет расходоваться на работу с клиентом, а не на разработку библиотеки. И, в пределе, вам было бы выгодно вообще спихнуть развитие собственно библиотеки на какие-то чужие плечи, чтобы самим сконцентрироваться именно на техподдержке. И это все хорошо работает для раскрученных и известных библиотек, у которых сотни тысяч пользователей;
• продажа не самой библиотеки, а продукта на ее основе. Собственно, это вариация на уже озвученную выше тему библиотеки как побочного эффекта. Здесь есть две проблемы. Во-первых, далеко не для всех типов библиотек можно придумать продукт, который будет окупать развитие этой самой библиотеки. Ну, например, в качестве упражнения для читателя: какой платный продукт можно сделать поверх libcurl, Asio или OpenSSL (или Botan, или Crypto++), или RapidJSON? Во-вторых, если основной финансовый поток вам обеспечивает именно продукт, а не библиотека, то разработка библиотеки -- это затратная для вас статья, которую вам нужно минимизировать. Т.е., в идеале, переложить на чужие плечи.

И что же из всего этого следует?

А вот не знаю. Не хочу играть здесь в пророка.

Могу лишь предполагать, что может сложиться ситуация, когда будут доминировать библиотеки, которые:

• появились давно и успели собрать вокруг себя достаточно большое коммьюнити, способное продолжать развитие библиотеки. С какими-то устоявшимися источниками финансирования разработчиков (будь то продажа лицензий, как в случае Qt, либо же изрядное количество контрибьютеров, которые занимаются доработкой библиотеки в рамках своей основной работы);
• разработаны большими корпорациями и открытые этими корпорациями для достижения каких-то своих целей (будь то PR, следование моде или же минимизация стоимости сопровождения своей разработки). Например, proxygen и Folly от Facebook или Abseil от Google.

Соответственно, если библиотеки из этих двух категорий вас по каким-то причинам не устраивают (либо вы хотели бы увидеть там недостающий функционал), то это ваша личная проблема, которую вы сами должны решать тем или иным способом. Либо сами делайте доработки и сами продвигайте их в апстрим библиотеки. Либо же сами создавайте библиотеку под свои задачи. С нуля или перепиливая то, что уже есть.

Кстати говоря: issues и PR для открытой библиотеки -- это нифига не бесплатно

Есть мнение, что открытие библиотеки снижает издержки на ее развитие и сопровождение, т.к. ваши пользователи забесплатно находят проблемы в вашем коде, иногда даже предлагают фиксы для найденных проблем. А иногда и присылают PR-ы с новой функциональностью.

Мнение возникло не на пустом месте и, по большому счету, оно верное. Чем больше пользователей у библиотеки, чем в более разных условиях она эксплуатируется, тем лучше в итоге становится ее качество и вы сами от этого выигрываете.

Но нужно понимать, что обслуживание всех этих issues и PRs -- это так же работа, которую кто-то должен делать и которая так же должна оплачиваться. Далеко не всегда вы будете получать PR-ы, которые можно просто смержить с основной веткой разработки и все. А даже когда вы такие PR-ы будете получать, то в большинстве случаев это будут тривиальные правки, типа опечатки в комментарии или исправлении формата вывода какого-то значения.

Так что если вы в рамках какой-то своей разработки сделали библиотеку и выложили ее в OpenSource, то будьте готовы к тому, что вам и дальше придется нести некоторые расходы на обслуживание поступающих issues и PRs.

Вместо заключения: АВМЯК*

Т.к. этот и другие посты в блоге являются голимой джинсой проплаченной мной лично, то закончу совсем уж неприкрытой рекламой: есть небольшая компания, специализирующаяся на изобретении и изготовлении лисапедов (пример: раз, два, три). Людям, которые попробовали наши лиспеды, понравилось. Так что если вам нужно что-то такое-эдакое изобрести и не просто изобрести, но и заставить работать, то вы можете обратиться к мастерам лисапедостроения :)

---

* См. АВМЯК