Сообщество свободного программного обеспечения

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

Совместная разработка

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

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

Более того, если какая-то компания вносит в продукт улучшения из коммерческих соображений, то для нее часто проще делать это сразу открыто, используя доступ к первоначальному исходному коду, потому что согласно лицензии ей все равно необходимо будет опубликовать исходный код, если она намеревается распространять этот продукт. Такая ситуация имеет место не совсеми открытыми программными продуктами, в ряде случаев измененная версия разрабатывается и ее исходный код распространяется отдельной фирмой. Тем не менее, подход, основанный на непосредственной совместной разработке, делает распространение и улучшение программ более быстрым и простым. Сейчас так происходит далеко не везде, но, например, в случае с IBM и Samba, или с ядром Linux ситуация именно такова: разработчики из различных и часто конкурирующих коммерческих фирм работают с одной и той же системой контроля исходного кода свободной программы.

GNU/Linux -- пример совместной разработки

Мы подобрались к вопросу о том, что такое операционная система GNU/Linux, как она разрабатывается и кто и как ее использует. Все элементы этой огромной системы, будь то прикладное приложение, ядро операционной системы, или документация, разрабатываются отдельным человеком или отдельной командой разработчиков, и это фактически единственная возможность для подобных разработок, общая трудоемкость которых исчисляется десятками тысяч человеко-лет. Таким образом, у каждого элемента системы есть некий основной автор, но этим круг людей, причастных к разработке этого элеента, не ограничивается.

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

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

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

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

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

Дистрибутив GNU/Linux

Может сложиться впечатление, что дистрибутив --- это набор разрозненных программных продуктов, непонятным образом собранных вместе. То есть, какие-то люди разрабатывают собственно GNU/Linux, и совсем другие люди занимаются разработкой программ. На самом деле, дистрибутив можно рассматривать как метапродукт, который подчиняется тем же законам сообщества, которым подчиняется отдельный продукт.

Дистрибутив --- это тоже программный продукт, только очень большой. Он собирается из частей, которые находятся в интернете под свободными лицензиями. Специфика дистрибутива в том, что он многокомпонентен. Если мы пишем программу совместно, там может быть 30 мегабайт исходного кода, там может быть много модулей, но если мы возьмём программу поменьше, то это всё равно единое целое, с единым представлением, как следует программировать, документировать и т.д. Дистрибутив GNU/Linux --- это набор программных продуктов, (их там несколько тысяч) сделанных, как минимум, сотнями групп разработчиков, никак не связанных друг с другом. Поэтому функции разработчика дистрибутива можно сформулировать следующим образом: определение политики развития и целевая разработка программных продуктов, которые сообществу не очень нужны. Кстати, здесь и ответ на вопрос, откуда берутся деньги. Один из неплохих источников --- заказная доработка.

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

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

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

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

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


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

52

1

1

1

1

ConstantinYershow, ОльгаТочилкина, VsevolodKrishchenko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex