Некоторые скептически высказываются насчет ГитЛаба — мол вот вы перестанете поддерживать бесплатный Community Edition(CE), и что мы будем делать? Не перестанем. Публикуем для вас перевод статьи на эту тему.

Недавно мы зафиксировали нашу политику в отношении поддержки ПО с открытым кодом (open source) и нашу преданность этому методу разработки. Коротко нашу политику можно описать так: нужно принимать решения в интересах проекта, при этом не забывая о бизнесе, который этот проект поддерживает. В этой статье я хочу поделиться с вами соображениями о некоторых правилах в нашей политике.

Сложности управления open source проектом

Маттиас Штюрмер (Matthias Sturmer) с сайта Opensource.com определил четыре типа open source сообществ:

1. Проекты с единым куратором (single-vendor projects)
2. Сообщества разработчиков (development communities)
3. Сообщества пользователей (user communities)
4. Центры взаимодействия (open source competence centers)

Последние три типа характеризуются распределенными процессами разработки. В некоторых случаях разработка координируется некоммерческими организациями, возникшими на базе сообщества, но, в любом случае, у сообщества такого типа нет какого-то одного источника финансирования. Примерами таких сообществ являются Apache, Rails и Linux.

Напротив, первый тип, «проекты с единым куратором» характеризуется финансовой поддержкой конкретной коммерческой организации, которая контролирует направление развития проекта и финансирует большинство основных разработчиков. Примерами сообществ такого типа являются Wordpress и Automattic; Hadoop и Cloudera; Elasticsearch и Elastic.

Всякий раз, когда развитием open source проекта занимается компания-куратор, возникает вопрос — какую модель развития она выберет? Компания должна балансировать между нуждами бизнеса, поддержкой разработки и тем, чтобы проект оставался на плаву. Более того, компания должна получать прибыль с проекта, ведь сам проект и его сообщество финансируются именно на ее деньги. Однако, в отличие от ПО с закрытым исходным кодом, open source проекты могут быть форкнуты и продолжать свое развитие за пределами компании-куратора.

Для нас open source — это набор этических обязательств, а не просто лицензия

Open source появился как следствие движения Free Software. Когда термин ‘open source’ зародился в конце 90х, с его помощью подчеркивался тот факт, что исходный код можно было просмотреть и даже модифицировать. Также с помощью этого термина удалось избавиться от сравнений с пивом (“free as in beer”), которые намекали на низкое качество продукта. В то же время, введение термина open source заложило фундамент для финансирования таких проектов коммерческими организациями. С 1998 года open source стал стандартом де-факто, показателем качества и гарантией того, что проект не будет монополизирован куратором (vendor lock-in).

Однако у введения термина ‘open source’ был и обратный эффект — утратили силу активистские корни движения Free Software (“free as in freedom”). В основе движения open source лежит коллаборация, для которой требуется взаимное доверие. Когда коммерческие компании, осуществляющие поддержку open source проектов, пренебрегают этими принципами, взаимное доверие теряется, а без него вся концепция open source перестает работать.

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

Что значит быть хорошим управляющим open source проекта?

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

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

• Прозрачный процесс принятия решений по направлению развития проекта.
• Участие компании в открытых каналах коммуникации.
• Забота об интересах компании в ущерб интересам проекта.

Все эти пункты должны быть приняты во внимание, если мы хотим добиться полной поддержки проекта, кода, сообщества и пользователей.

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

К примеру, наша опытная команда продажников поделилась с нами своими бедами: «Почему ПО должно быть бесплатным для абсолютно всех пользователей? Почему пользователи, которые работают с командами из более чем 10000 разработчиков, не платят нам ни копейки?» Ведь при продаже интеллектуальной собственности можно устанавливать лимит на бесплатное использование. Продажники спрашивают: «Почему бы не установить лимит на количество пользователей в бесплатной версии? Пока у вас меньше 1000 разработчиков, вы можете пользоваться Community Edition, но для более крупной команды вам придется купить enterprise edition.» С экономической точки зрения такое решение оправдано, но в контексте open source оно теряет всякий смысл.

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

Мы не единственная компания, столкнувшаяся с такими проблемами. Год назад Адам Джейкоб (Adam Jacob) из Chef сказал: «Мы пытаемся понять, какую функциональность нужно включать в различные пакеты услуг, и как найти баланс между нашим стремлением к ведению успешного бизнеса и нашей искреннюю верой в то, что open source является будущим инфраструктуры.» Это было год назад, с тех пор Chef заметно продвинулись как управляющие своего проекта.

Нейтен Харви (Nathen Harvey), ныне вице-президент по развитию сообщества (VP of Community Development) Chef в своем интервью на эту тему сказал следующее: «На пересечении open source и коммерческих интересов поднимаются вопросы полномочий, аутентичности и культуры.» Что окажется важнее — коммерческие интересы или развитие проекта? Это очень важный вопрос, над ответом на который должны задуматься в любом open source проекте с единым куратором. Нейтен приводит свой главный принцип по этому вопросу: «прозрачность важнее всего» — мы с ним полностью в этом согласны.

В чем заключается наша политика?

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

• Открытая разработка. Вы можете отправлять тикеты в публичный трекер, это не read-only интерфейс.
• Открытое ведение бизнеса. Политики и основные правила по ведению нашего бизнеса открыты для всех желающих.
• Четкая стратегия развития. В нашем документе «Стратегия» (Direction) содержатся текущие приоритеты развития проекта, а также приблизительное содержание будущих релизов.

Такой уровень прозрачности является небывалым для ПО с закрытым кодом, редким для open source проектов с единым куратором и нетипичным даже среди других платформ управления репозиториями (неважно, open source или нет). По правде говоря, история управления исходным кодом и работы с сообществом полна намеренного запутывания и историй нарушенного доверия. Мы не хотим повторять этих ошибок и считаем, что для того, чтобы GitLab стал местом для безопасной и открытой совместной разработки, он сам обязан быть open source платформой.

В нашей политике мы обращаем внимание на все те вещи, которые мы обещали не делать. Мы четко обрисовали разницу между GitLab CE (Community Edition) и EE (Enterprise Edition), и мы учитываем требования сообщества четко указывая все наши обязательства.

Мы призываем вас ознакомиться с нашей политикой. Теперь, когда она опубликована, вы можете требовать от нас ее выполнения.

Пожалуйста, прочитайте «Принципы управления GitLab CE».

Перевод с английского выполнен переводческой артелью «Надмозг и партнеры», http://nadmosq.ru, главный переводчик — sgnl_05