О свободном ПО

В чудесном и веселом руководстве по ØMQ внезапно наткнулся на главу, посвященную сообществу разработчиков ØMQ. Глава посвящена описанию процесса разработки, которому дали название C4 — Collective Code Construction Contract (да, почти как взрывчатка). Автор — Питер Хинтженс (Pieter Hintjens) — тот самый основатель и CEO iMatix, один из создателей протокола AMQP, который отказался от своего детища в пользу ØMQ.

В извечном выборе между GPL и BSD (под последним понимаются все не вирусные свободные лицензии вроде MIT или Apache) Питер однозначно требует GPL (в любой форме: GPL, LGPL или AGPL). Не только потому, что BSD лицензия как бы сообщает: «Укради меня» (Как вы знаете, код под этой лицензией можно спокойно форкнуть, изменить, адаптировать и т.д. и т.п. и перевыпустить результат под совершено другой лицензией, включая проприетарные), но и потому, что GPL код обладает одним чудесным свойством. Любой форк GPL кода может быть вмержен (с точки зрения лицензии) обратно в родительский проект. А вот BSD код может быть не только спрятан под проприетарной лицензией, но даже его свободный форк (например, под GPL), будет уже несовместим с родителем. Это (вирусное) свойство GPL жизненно необходимо для формирования большого сообщества вокруг свободного проекта.

Собственно, формирование сообщества, создание продукта сообществом, увеличение размера этого сообщества и является основной целью C4. Нет никакого первоначального Автора, нет никакой Компании, которая стоит за продуктом (они конечно есть, но они лишь запускают процесс создания сообщества). Есть Сообщество. Удивительно, но это ведь именно та столманновая свобода.

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

В C4 определены только две роли: Мейнтейнер и Контрибутор. Контрибутор создает патчи и формирует пул реквесты. Мейнтейнер имеет права на коммит в официальный репозиторий проекта, ревьюит и мержит пул реквесты. Естественно, если какому-то контрибутору не понравятся действия какого-то Мейнтейнера, он форкнет репозиторий и станет сам Мейнтейнером. Это нормальная жизнь сообщества. Ну а для пущей справедливости любому Контрибьютору предлагается стать Мейнтейнером как только будет принят его первый патч.

Собственно, C4, это развитие (я бы сказал, апофеоз) GitHub flow. Питер категорически не рекомендует пользоваться ветками. В официальном репозитории веток нет. Есть только мастер, и притом весьма стабильный мастер. Фичи, багофиксы, любые изменения кода пилятся в форках, а затем вливаются в мастер официального репозитория через пул реквесты. Там, в форках, можно делать ветки сколько угодно, в официальном репозитории — не надо. Ветки плохи, потому что с ними сложно работать, сложно даже прийти к соглашению о том, как с ними работать. Нельзя ограничить права доступа по веткам, а значит, легко закоммитить изменения не в ту ветку. В общем, ветки — не нужны.

Да, релизы — это такие же форки, только для стабилизации.

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

В C4 используется встроенный трекер Гитхаба. И исключительно для трекания пул реквестов. Не используется тип тикета: баг или фича. Любая работа — это работа, которая сейчас делается. Нет роадмапа, нет планов, нет хотелок на будущее. Есть только текущие дела, которые завершаются пул реквестом, который будет принят или будет отвергнут. Или будет принят, а потом будет откачен назад другим пул реквестом.

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

Вот такая вот свобода в лучшем, имхо, виде. И чертовски четко и кратко формализована. И, ведь, работает, как минимум на примере ØMQ и связаных с ним проектов.

З.Ы. А следующая глава руководства весьма неплохо описывает процесс построения архитектуры (на основе ØMQ, конечно).