Где победил Open Source, что с ним не так и кому он нужен

Я работаю в DaData — это облачный сервис, который помогает бизнесу получать информацию о клиентах, например, по ИНН или адресу. Услугой часто пользуются интернет-магазины, чтобы запрашивать меньше данных у покупателей: пользователь только вводит адрес доставки, а у магазина уже есть координаты, район города и ближайшее метро. Особенно это полезно при работе с юрлицами, потому что клиенту вместо 20 полей с реквизитами достаточно заполнить название компании или ИНН.

В работе я использую опенсорсные библиотеки, в том числе собственного авторства. Моему аккаунту на GitHub уже много лет, и там есть несколько проектов, один из которых даже собрал 1000 звёзд. Поделюсь своим опытом и расскажу о главных проблемах Open Source.

Большинство популярных библиотек — опенсорсные

Сегодня Open Source — это доминирующий способ распространения библиотек. Популярных коммерческих библиотек довольно мало, за исключением сложных узкоспециализированных направлений.

С одной стороны, делать библиотеку опенсорсной выгодно: другие разработчики могут её дополнить, найти и исправить баги. С другой — приятно осознавать, что вы причиняете людям добро. Ведь пользователи могут адаптировать библиотеку с открытым кодом под свои задачи, а не только использовать так, как задумал автор. Тем не менее я не считаю, что весь софт должен быть открытым. Это удобный способ распространения библиотек и некоторого другого софта — не более.

Первый крупный проект на GitHub я создал в прошлом году. Тогда я занимался транслитерацией — это когда русские слова пишутся латиницей, как имя и фамилия в загранпаспорте. Например, если вам захотят отправить письмо из США, то напишут адрес не кириллическими, а латинскими буквами.

Я написал библиотеку, которая умеет транслитерировать слова по любой из 15 схем и назвал её iuliia в честь того самого имени. Помимо версии для Python, я написал вариант для JavaSсript и параллельно сделал сайт с описанием либы и демками. Сами схемы транслитерации собрал в виде JSON-файлов, поэтому библиотеку легко адаптировать под другой язык, например Java.

У iuliia немного скачиваний: версию на JavaScript за последнюю неделю скачали 111 раз. Наверное, потому, что транслитерация — не самая популярная задача в программировании. Тем не менее пару раз пользователи писали о багах. Пул-реквестов не было, но они, по большому счёту, и не нужны: в транслитерации новых фич не придумаешь.

Позже я написал статью на «Хабре» с кровавыми подробностями о том, как тяжело приходилось кириллице в XX веке и что с ней сделала транслитерация. Читатели активно делились своей болью в комментариях и рассказывали о своих проблемах с ФИО. С той статьи на библиотеку перешло много разработчиков, которые уже сделали больше 10 вариантов для разных языков программирования.

О самом звёздном проекте на GitHub

Помимо iuliia у меня есть проект sqlean с 1000 звёзд — это больше, чем у всех остальных моих проектов, вместе взятых. Но перед тем, как рассказать о нём, позволю себе небольшое лирическое отступление.

Я обожаю язык SQL — это золотая середина для анализа данных: он мощнее Excel, но проще, чем Python. Он декларативный и отлично справляется с выборкой данных. Вы не пишете, как именно СУБД должна выбирать данные, а говорите, что хотите от неё получить.

Среди реляционных СУБД больше всех мне нравится SQLite. Это компактная база, которая легко встраивается в код, её удобно использовать в анализе данных, а также в качестве хранилища для небольшого приложения. Поэтому я пишу о ней статьи и стараюсь всячески популяризировать.

У SQLite есть проблема: в её стандартную поставку входит мало функций для работы с текстом, числами, математической статистикой и так далее. Их потихоньку добавляют, но в сравнении с PostgreSQL — всё равно маловато.

Поэтому сторонние разработчики пишут расширения для недостающих функций, например чтобы работать с регулярными выражениями. Регулярки позволяют искать и заменять текст не по точным совпадениям, а по довольно хитрым шаблонам. Они есть во всех популярных СУБД, кроме SQLite — чтобы добавить туда регулярные выражения, нужно найти расширение, скомпилировать и правильно подключить.

Для большинства пользователей компиляция — невыполнимая задача. Люди приходят на форум поддержки SQLite и спрашивают, как добавить ту или иную фичу. А им предлагают скачать и скомпилировать сишное расширение. Пользователи в недоумении спрашивают: «Что ещё за компиляция?» — а их отсылают к документации. Уверен, до победной компиляции доходят единицы.

Расширения для SQLite размазаны по GitHub мелким слоем, без структуры и логики. Я собрал их в блоки по решаемым задачам, написал доку и скомпилировал, чтобы пользователи могли сразу качать под Windows, Mac, iOS или Linux. Иногда пользователи предлагают фичи. У меня даже был контрибьютор — он принёс готовый модуль, который добавляет функции для работы с IP-адресами. При этом он не просто скопипастил его, а написал с нуля.

Моя работа оказалась востребованной, потому что пользователи не хотели заморачиваться с компиляцией. Да, можно покопаться в доках и понять, как что делать. Но в эти дебри совсем не хочется погружаться — а ведь на самом деле всё довольно просто.

Позже я написал статью о либе и отправил на Hacker News. Она попала на первое место на главной странице и даже побывала статьёй #1 об SQLite за всю историю сайта. Hacker News — это как «Хабр», только для англоязычной аудитории, и там публикуют ссылки на статьи, а не тексты. При этом ресурс мегапопулярен, на нём постоянно проходят бурные обсуждения и его читают во всём мире.

Под какой лицензией размещать проекты на GitHub

Для проектов на GitHub я использую разрешительную лицензию MIT License, потому что она весьма простая и понятная. В ней лишь написано, чтобы пользователи софта давали ссылку на авторов и не затирали их имён. В остальном она предоставляет полную свободу. Код можно модифицировать и использовать в коммерческих проектах.

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

Я смотрю на лицензии и Open Source с практической точки зрения, поэтому «религиозные войны» между FSF и OSI мне неинтересны. Иногда проприетарный софт тоже нужен. Не зря разработчики придумали Open Core и задержанную публикацию, когда софт выпускается как проприетарный, но со временем открывается по частям. Всё это нужно в конкретных случаях, и нельзя делить лицензии на хорошие и плохие. Хотя, если показать Ричарду Столлману проект под Open Core, — он наверняка придёт в бешенство.

Сколько сил и времени уходит на поддержку open-source-проектов

Я вкладываю немного сил в саппорт своих проектов. Отчасти потому, что строю их без внешних зависимостей. Работоспособность моих программ зависит только от стандартной библиотеки — а она довольно стабильная. Поэтому меня не беспокоят обновления и свеженайденные уязвимости в сторонних библиотеках.

Именно из-за огромного количества внешних зависимостей я не люблю мир JavaScript. Стоит только создать проект, как через полгода он «протухнет». Поэтому авторам приходится регулярно обновлять библиотеки, которые часто конфликтуют между собой.

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

Я работаю над проектами небольшими набегами. Обычный саппорт занимает у меня несколько часов в месяц, а добавление нового расширения для SQLite — от одного до нескольких дней. Над новыми проектами могу работать неделями.

На GitHub можно посмотреть статистику активности контрибьютора — Contribution activity. Каждому году там соответствует квадратик — чем больше кода написал разработчик, тем ярче он окрашен. Я работаю над проектами нерегулярно, поэтому у меня цветные квадраты чередуются с серыми.

Что не так с Open Source и почему с ним заигрывают корпорации

Как я уже сказал, Open Source отлично подходит для библиотек, поэтому большая их часть — опенсорсная. Так легче находить и исправлять баги в проектах, да и выбор у пользователей большой: можно найти что угодно и адаптировать под свои задачи.

Но у такой модели распространения кода есть две большие проблемы — обе касаются справедливого распределения прибыли.

Авторы открытых библиотек незаслуженно мало зарабатывают

Некоторыми библиотеками пользуются буквально все, включая Google, Facebook* и так далее. Но их авторы за это ничего не получают. Когда на тебе держатся горы корпоративного софта, который продают за 1 млн баксов, а ты сидишь в маленькой квартире и грызёшь сухарь — это как минимум несправедливо.

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

С другой стороны — многое зависит от ваших ожиданий. Если вы идёте в Open Source делать библиотеки и зарабатывать на этом бабло, скорее всего, вас ждёт разочарование. Поэтому, как я говорил ранее, отбросьте все ожидания.

К Open Source много вопросов с точки зрения социальной справедливости. Условный Google может платить более щедро авторам популярных библиотек, которые он использует.

Облачные сервисы продают открытое ПО как своё собственное

Такие популярные программы, как PostgreSQL или Sentry изначально распространялись на открытых разрешительных лицензиях. Поэтому корпорации могут продавать опенсорсные продукты как свои — в виде облачных сервисов. За их счёт Amazon наращивает свой капитал, а от независимых разработчиков уходят пользователи. Зачем им маленькая компания, когда есть большой и надёжный Amazon, который ещё и условия повыгоднее предложит?

Некоторые компании переходят на модель Open Core, а другие приняли новые лицензии — как это недавно сделала Elastic. Их Elasticsearch — один из лучших инструментов для поиска по любым видам и формам данных. Однажды Elastic отказалась от разрешительной лицензии и запретила облачным сервисам перепродавать Elasticsearch. Тогда на компанию вылили ушат помоев, а Amazon форкнул последнюю открытую версию программы и пообещал развивать форк. У Amazon намного больше ресурсов, чем у любого независимого разработчика, поэтому они могут разорить Elastic.

С такой проблемой столкнулись и другие разработчики. MongoDB сразу прописала в лицензии, что их софт нельзя свободно перепродавать в облаке. Поэтому Amazon пришлось договариваться с компанией об отчислениях, чтобы предоставлять сервис своим пользователям.

В остальных случаях сотрудничество корпораций и Open Source даёт результат win-win. Google донатит в открытые проекты по вполне прагматичным соображениям: он использует эти программы и библиотеки в своих сервисах и хочет развивать под свои задачи. Поэтому крупному бизнесу нужно влиять на разработку открытого ПО. С другой стороны, авторы open-source-проектов получают деньги от контрибьюторов. Здесь нет альтруизма — только взаимовыгодное сотрудничество.

Как стать мейнтейнером и с чего начать контрибьютить в Open Source

Статистика говорит, что собрать 1000 звёзд на GitHub крайне сложно. Поэтому, чтобы в случае неудачи не разочароваться в Open Source, отбросьте все ожидания.

Не ищите идею специально. Если есть боль, которую у вас получится решить с помощью кода — пишите библиотеку или утилиту. Потом уже можно задуматься: оставить проект для себя или причесать его, написать минимальный readme и выложить на GitHub? На это уйдёт немного времени, но зато вы создадите нечто ценное для людей, а это уже другой уровень отношений с Open Source. Вы не только решите свою проблему, но и поможете другим разработчикам.

Начать контрибьютить проще всего с библиотек, которые вы используете в работе.

Первый способ. Зайдите в репозиторий проекта на GitHub и посмотрите, какие ишью там открыты. Если можете что-нибудь решить, присылайте пул-реквест с исправлением. Но контрибьютить — это не только исправлять баги и предлагать фичи. Можно написать документацию к проекту, ведь в Open Source её всегда не хватает.

Второй способ. Найдите проблему в проекте самостоятельно и откройте ишью. Одни мейнтейнеры скажут вам за это спасибо, а другие — в гробу видали ваши ишью. У них и так уже 400 открыто, и они пребывают в перманентной печали. Поэтому лучше сразу прикладывайте к ишью пул-реквест с исправлением.

В общем, мелкие изменения можно присылать сразу, а крупные лучше обсудить с мейнтейнером. Это займёт у вас немного времени, зато вы не проделаете работу впустую и не разочаруетесь в мейнтейнере, который отклонит ваш пул-реквест.

Подведём итоги:

• Модель Open Source отлично подходит для лицензирования библиотек, но далеко не весь софт должен быть открытым.
• Как правило, для open-source-проектов подходит MIT License или другая разрешительная лицензия. Она обязывает пользователя указывать или не скрывать имя автора программы, а в остальном предоставляет свободу действий.
• Проблема Open Source — в несправедливом распределении доходов от программ. Большинство авторов популярных библиотек, на которых держится весь интернет, получают копейки за свою работу.
• Чтобы стать мейнтейнером, не нужно специально искать идею для проекта. Попробуйте написать программу, которая решит вашу проблему, — в будущем из неё может получиться отличный open-source-проект.
• Контрибьютят двумя способами: решают ишью из списка или находят новую проблему и предлагают решение. Вы можете исправлять баги, предлагать решение и писать документацию к проекту.