The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Критерии оценки открытости проектов и попытка их применения к проекту OpenJDK

09.02.2011 16:00

Саймон Фиппс (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 не могут считаться правилами открытого сообщества, заявил Саймон Фиппс.

  1. Главная ссылка к новости (http://blogs.computerworlduk.c...)
  2. OpenNews: Смена лицензии на код RPC решила проблемы со свободностью кода NFS и Glibc
  3. OpenNews: Критерии присуждения компаниям статуса Open Source
  4. OpenNews: Oracle покинул бывший глава OpenSource-направления Sun
  5. OpenNews: Революционное свержение власти в проекте FFmpeg
Автор новости: timurkin
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/29474-osi
Ключевые слова: osi, rules, opensource, java, free, software
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (14) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 17:42, 09/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Java никогда не была полностью свободной. И не будет.
     
     
  • 2.15, Tav (ok), 21:50, 09/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Под словом "Java" можно много чего понимать (VM, JDK, спецификации, язык программирования, бренд).

    Речь об OpenJDK.

    Основные свободы ПО (http://www.gnu.org/philosophy/free-sw.ru.html):
    - Свобода выполнять программу в любых целях (свобода 0).
    - Свобода изучать работу программы и модифицировать программу под свои нужды (свобода 1). Это предполагает доступ к исходному тексту.
    - Свобода передавать копии, чтобы помочь своему ближнему (свобода 2).
    - Свобода передавать копии своих измененных версий другим (свобода 3). Этим вы можете дать всему сообществу возможность получать выгоду от ваших изменений. Это предполагает доступ к исходному тексту.

    Пользователи OpenJDK лишены какой-нибудь из этих свобод?

     
     
  • 3.16, Аноним (-), 23:12, 09/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    И что же, я могу портировать OpenJDK на на мобильный телефон?
     
     
  • 4.17, Tav (ok), 23:48, 09/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Да.

    Apache Harmony, с которым были проблемы, — не порт и не форк OpenJDK, а альтернативная реализация под другой лицензией. С OpenJDK предоставляется лицензия на соответствующие патенты. На модификации это тоже распространяется. Если я не ошибаюсь, это обеспечивается даже просто лицензией GPL2 (в GPL3 оговаривается более сложная ситуация, когда владелец кода и владелец патентов разные).

     
     
  • 5.19, Аноним (-), 20:17, 15/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Вот тут вы путаете слово реализация (которое вы упомянули к месту) и "форк". Harmony - не есть форк, а просто другая /реализация/ JLS.
     
     
  • 6.20, Tav (ok), 20:40, 15/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Harmony - не есть форк, а просто другая /реализация/ JLS.

    Именно это я выше и написал.

     

  • 1.2, lucentcode (ok), 18:08, 09/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Дело мужик пишет. Я за разумную меритократическую систему управления. Самые способные в команде разработчиков должны прислушиваться к пожеланиям сообщества, и контролировать внесение патчей в исходный код. Не каждый программист имеет нужную квалификацию, и не каждый способен просчитать все выгоды и проблемы от того, или иного патча. Добавьте ещё редкость хороших коммуникативных навыков и управленческих качеств среди IT-сообщества-и мы приходим к пониманию того, насколько ценны эти способности среди участников Open Source проектов.
     
  • 1.3, lucentcode (ok), 18:10, 09/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А великодушным диктаторам я не доверяю. Сегодня они двигатель прогресса, а завтра главный тормоз. И место им тогда не в проекте, а где-то ещё.
     
  • 1.4, t0ly (?), 18:31, 09/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    я вот только не пойму
    мне как разработчки или пользователю какая разница в том открыт jdk или закрыт и какая у него лицензия?

    и ещё не понятно как Oracle зарабатывает на том что владеет jdk и как на этом зарабатывал прошлый владелец?

     
     
  • 2.6, Анон (?), 18:57, 09/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >мне как разработчки или пользователю какая разница в том открыт jdk или закрыт и какая у него лицензия?

    RMS негодует!

     
  • 2.7, xxx (??), 19:16, 09/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >мне как разработчки или пользователю какая разница в том открыт jdk или закрыт и какая у него лицензия?

    Я прям со стула чуть не шлёпнулся прочитав это.

     
  • 2.8, QuAzI (ok), 19:17, 09/02/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты как "разработчик" не знаешь, сколько закладок в твоём слинкованном в Delphi приложений и не сработает ли открытый этим приложением сокет после посылки хитрого набора байт как большая троянская дырень. Ты как "разработчик" не поймёшь, почему на разных версиях один и тот же код ведёт себя по разному. Ну и ещё валом более мелких причин, начиная от переделки конкретной функции под свои нужды, заканчивая уверенностью, что это будет работать после того как оракль загнётся.
     
  • 2.10, VoDA (ok), 19:32, 09/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > мне как разработчки или пользователю какая разница в том открыт jdk или закрыт и какая у него лицензия?

    тебе как фирме-разработчику - есть разница. чем больше фирма тем больше внимания к лицензиям. А для ИП Вася Пупкин разницы нет - он продолжает торговать китайским Abibas =)

    > и ещё не понятно как Oracle зарабатывает на том что владеет jdk и как на этом зарабатывал прошлый владелец?

    денег оно приносит за счет выдачи лицензий на разработку собственных ответвления JDK к примеру для самопальных ОС или высокопроизводительных серверов. К примеру все JDK (кроме Apache Harmony) это потомки Sun JDK.

    Дальше обучение и выдача сертификатов на Java (tm) технологии тоже приносит $.

    А в сумме деньги с JDK не покрывают расходы на его развитие. Так что прибыль с этого идет за счет сопутствующих вещей.

     

  • 1.18, nuclight (ok), 20:02, 11/02/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    BSD забыли. Вот где действительно лицензия для свободных людей. Да и меритократическиая модель управления отсюда же растет.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру