Саймон Фиппс (Simon Phipps), ранее руководивший OpenSource-направлением в компании Sun Microsystem, а ныне входящий в управляющий совет организации Open Source Initiative (OSI), попытался сформулировать критерии оценки степени открытости проектов. Фиппс пишет, что признаком конструктивной, прагматичной борьбы за свободу программного обеспечения - является наличие равенства в сообществе, которое гарантировано справедливым управлением. Такое сообщество можно назвать открытым по правилам (open-by-rule). Конечно, нет стопроцентной гарантии, что всё будет работать как надо, так как любая достаточно сложная система подвержена сбоям. Однако целью любого открытого проекта должна быть свобода людей в реальном Мире.

В свободе программного обеспечения есть нечто большее, чем просто лицензия. Ключевой вопрос, ответ на который интересует любого потенциального разработчика, это - "какова система управления?", и "на каких условиях люди участвуют в открытых проектах"?

По мнению Фиппса, основным принципом управления в открытых проектах должна быть так называемая открытая меритократическая олигархия. Именно такая стратегия характерна при организации управления в наиболее эффективных и успешных сообществах, включая Apache Software Foundation и GNOME Foundation. Такая олигархия подразумевает осуществление управления некой элитой, а не большинством - демократия с её одним голосом для каждого не является для неё приоритетом.

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

Правила, которым необходимо следовать, при создании подлинно открытого сообщества:

  • Современная лицензия.

    Проект должен иметь современную, одобренную организацией OSI лицензию, которая обеспечивает патентную защиту всех ото всех (Apache, Mozilla/CDDL и GPLv3 позволяют это сделать) и действует одинаково в отношении всех участников. Дополнительным преимуществом является совместимость лицензии с широким кругом соответствующего кода в других проектах.

  • Отсутствие практики отчуждения имущественных прав.

    Открытое сообщество не будет требовать от всех участников передачи имущественных прав на код в руки одного лица. Если это и будет сделано, то держателем всех авторских прав станет некоммерческая организация, контролируемая сообществом, например, SPI или FSF.

  • Грамотная политика управления торговыми марками.

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

  • Наличие графика выпуска релизов и чёткого плана развития

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

  • Множество разработчиков.

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

  • Возможность создания форка проекта.

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

  • Обеспечение принципа прозрачности.

    Необходимо дать положительный ответ на следующие вопросы, чтобы понять, насколько прозрачен открытый проект: Можно ли знать всё о сообществе, в том числе что происходит и почему происходит ? Все ли обсуждения видимы общественности (кроме случаев, когда дело касается личной информации) ? Можно ли отслеживать все коммиты и патчи, а также знать причину включения каждого из них в проект ?

В качестве наглядной демонстрации применимости данных правил к оценке реальных проектов, Саймон Фиппс попытался проанализировать степень открытости сообщества разработчиков OpenJDK. По разным причинам методы управления в проекте OpenJDK никогда не были полностью определены и вот уже более года все хранят молчание. Тем не менее, Марк Рейнхольд, занимающий должность старшего архитектора платформы Java в Oracle, опубликовал на днях черновик новых правил организации управления в проекте OpenJDK, в подготовке которого принимали участие представители Oracle и IBM.

  • Подавляющее большинство работ по OpenJDK проводятся сотрудниками Oracle;
  • Сообщество OpenJDK реализует функции на основе спецификаций JCP и не изобретает никаких новых возможностей;
  • OpenJDK выпускается под лицензией GPLv2 с некоторыми лицензионными исключениями (в частности, разрешающее динамическое связывание лицензионное исключение Classpath), направленными на предотвращение определенных нежелательных последствий использования GPL, таких как проблемы связывания библиотек с коммерческими проектами;
  • Для соответствия условиям на использование бренда Java, пользователи обязаны использовать наборы тестов TCK;
  • Значительный вклад в успех проекта OpenJDK, после открытия кода, внесли сотрудники Red Hat, Google, Apple и IBM. Вклад отдельных разработчиков из проекта GNU Classpath, предшественника OpenJDK, также сыграл значительную роль в становлении OpenJDK как жизнеспособного проекта, в особенности на GNU/Linux.
  • Широко распространено мнение, что решение IBM присоединиться к OpenJDK, после которого проект Apache Harmony был заброшен, стало результатом неафишируемой сделки с Oracle, в обмен на расширенные полномочия в управлении проектом.

Новые правила управления OpenJDK обсуждались на конференции FOSDEM 2011, но до этого обсуждения было также проведено небольшое тестирование черновика правил, которое принесло им минус 3 балла по шкале от -10 до +10. "Это говорит о том, что в моих глазах новые правила управления OpenJDK не могут считаться правилами открытого сообщества, заявил Саймон Фиппс.

Источник: http://www.opennet.ru/opennews/art.shtml?num=29474