Differences between revisions 10 and 29 (spanning 19 versions)
Revision 10 as of 2008-07-23 10:19:50
Size: 23626
Comment:
Revision 29 as of 2008-10-04 08:01:04
Size: 31551
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
== Структура сообщества == == Сообщество свободного программного обеспечения ==
Line 3: Line 3:
Структура сообщества - очень важная тема, поскольку в ней можно найти ответы на многих концептуально важные вопросы. Итак, открытый способ разработки --- это то, чем отличаются открытые продукты от закрытых с самого начала. Всё остальное --- это технология, которая ''наверчена поверх''. Открытый способ разработки плюс copyleft как способ лицензирования --- это основание для бизнеса. Иными словами, этим мы говорим, что всякий человек, который воспользовался нашей разработкой и привнёс туда какие-то свои инструменты и который хочет достичь чего-то на рынке, должен (поскольку изначально разработка ведется под копилефт-лицензией) организовать свой бизнес также на основе свободного софта. Лицензирование методом copyleft --- это гарантия, что любые успешные модификации нашего программного обеспечения будут опубликованы, и ими сможет воспользоваться каждый, а развитие программного продукта не прекратится, даже если человек модифицировал что-то исключительно ради заработка. Введение copyleft'a в лицензию приведёт к тому, что, распространяя свой продукт, человек должен будет давать свободный доступ к исходным текстам, и, стало быть, все эти улучшения окажутся в свободном доступе. Поэтому любой автор програмного продукта может смело опублиовать его под свободной лицензией с copyleft, зная, что, какие бы улучшения не были в него привнесены, он может включить их в исходный код. В принципе, это приводит к возвращению к совместной разработке. Если какая-то компания вносит в продукт улучшения из чисто коммерческих соображений, она делает это не внутри своих структур, а открыто, потому что согласно лицензии ей необходимо опубликовать их. Такой подход делает распространение и улучшение программ быстрее и проще. Сейчас так происходит не везде, но, например, с IBM и SAMBA это так. Структура сообщества вокруг свободного программного обеспечения --- очень важная тема, ведь именно рассматривая ее можно найти ответы на многие вопросы, касающиеся открытого процесса разработки. Итак, открытый способ разработки --- это то, чем изначально отличаются открытые (или свободные) программные продукты от закрытых, называемых также правовладельческими, собственническими или "проприетарными" (от англ. ''proprietary'' --- собственник). Все используемые при разработке технологии напрямую зависят от выбора способа разработки.
Line 5: Line 5:
Мы подобрались к вопросам о том, что такое Linux и как его используют. Все элементы системы, будь то приложение, ядро или что-то другое, разрабатываются отдельным человеком или даже отдельной командой разработчиков, и это фактически единственная возможность для подобных разработок. Таким образом, у каждого такого элемента есть некий автор. Может сложиться впечатление, что дистрибутив --- это разрозненный набор программных продуктов, непонятным образом собранных вместе. То есть, какие-то люди разрабатывают собственно Linux, и совсем другие люди занимаются разработкой программ. На самом деле, дистрибутив можно рассматривать как метапродукт, который подчиняется тем же законам сообщества, которым подчиняется отдельный продукт. === Совместная разработка ===
Line 7: Line 7:
Итак, существуют несколько человек (иногда даже только один), образующие core team. Это,как правило, те люди, которые большую часть времени тратят на то, чтобы разрабатывать этот продукт. Кстати, часто члены core team живут в разных странах. Иногда они зарабатывают этими разработками деньги, иногда это --- дело жизни. Если бы этим всё и ограничивалось, то ситуация бы ничем не отличалась от той, что имела место в связи с правовладельческими продуктами, потому что любой такой продукт разрабатывается только такой командой. Кстати, функция core team шире, чем функция разработчиков правовладельческого продукта, поскольку core team занимается ещё и стратегическим планированием. Открытый способ разработки плюс "копилефт" как способ лицензирования --- это основание для бизнеса, основанного на открытом программном обеспечении. Всякий человек, который воспользовался нашей разработкой и привнёс туда какие-то свои инструменты и который хочет достичь чего-то на рынке, обязан организовать этот бизнес также на основе свободного программного обеспечения, поскольку изначально разработка ведется под "копилефт"-лицензией. Таким образом, лицензирование методом copyleft --- это гарантия, что любые успешные модификации нашего программного обеспечения будут опубликованы, и ими сможет воспользоваться каждый, а развитие программного продукта не прекратится, даже если человек модифицировал что-то исключительно ради своего заработка.
Line 9: Line 9:
В отличие от разработчиков правовладельческого продукта мы рассчитываем на совместную разработку, на привлечение к сообществу любых людей, в том числе тех, которые не могут уделять разработке нашего продукта всё своё время. Тем не менее, в сообщество входят и профессиональные программисты, перед ними периодически возникает задача внести в наш продукт какие-то изменения, допустим, исправление ошибок или внедрение новых возможностей. Тогда к проекту подключаются добровольцы, которых может быть достаточно много (это зависит от популярности проекта). Если Вы исправили ошибку, и core team это приняли, Вы уже разработчик. Эти люди заинтересованы в программном продукте, имеют пользовательскую квалификацию и квалификацию разработчика, имеют ресурс на участие в сообществе. Откуда у вас ресурс, что вами двигало --- это важно для исследователя, но не регламентировано. Если вы включили свои модификации в upstream, т.е. в общий исходный код, то Вам огромное спасибо от разработчиков и пользователей. Таких людей больше, но никаких дополнительных обязательств перед ними не стоит. С другой стороны, они достаточно мотивированны, и если кто-то однажды принял участие в модификации продукта, вполне вероятно, что он сделает это снова, а дальше его и в core team могут принять. Введение такой "заразной" свободной составляющей в лицензию приводит к тому, что, любой распространяющий свободный продукт производитель должен будет обеспечить свободный доступ к исходным текстам, и, стало быть, все сделанные им улучшения окажутся в свободном доступе. Поэтому любой автор программного продукта может смело опубликовать его под свободной лицензией с copyleft, зная, что, какие бы улучшения не были в него привнесены другими людьми, он может включить их обратно в исходный код. В принципе, это является одной из форм совместной разработки.
Line 11: Line 11:
В этом супе не хватает главного - пользователей. Обратите внимание, что их ещё больше, чем разработчиков. Это необходимо по нескольким причинам. Так, любой разработчик имеет опыт и как пользователь, и как разработчик, и он знает, как работает та или иная часть программного продукта, даже если она никак не документирована. Однако в такой форме продукт очень плохо функционирует. На пользователей никаких обязанностей не накладывается, единственная вещь, которую надо иметь в виду - пользователь хорош тогда, когда он активен. Например, если несколько пользователей заявляют разработчику, что им неудобно пользоваться программным продуктом, то социальное чувство заставит разработчика задуматься над тем, как сделать, чтобы им было тоже удобно. Далее, часто документация бывает неполной, и пользователю нужен совет разработчика. Наконец, при нахождении ошибок хорошо было бы о них сообщить, чтобы их могли исправить. Более того, если какая-то компания вносит в продукт улучшения из коммерческих соображений, то для нее часто проще делать это сразу открыто, используя доступ к первоначальному исходному коду, потому что согласно лицензии ей все равно необходимо будет опубликовать исходный код, если она намеревается распространять этот продукт. Такая ситуация имеет место не со всеми открытыми программными продуктами, в ряде случаев измененная версия разрабатывается и ее исходный код распространяется отдельной фирмой. Тем не менее, подход, основанный на непосредственной совместной разработке, делает распространение и улучшение программ более быстрым и простым. Сейчас так происходит далеко не везде, но, например, в случае с IBM и Samba, или с ядром Linux ситуация именно такова: разработчики из различных и часто конкурирующих коммерческих фирм работают с одной и той же системой контроля исходного кода свободной программы.


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

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

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

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

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

Рассмотрим теперь роль пользователей в сообществе. Обратите внимание, что их должно быть ещё больше, чем разработчиков. Это необходимо по нескольким причинам. Так, любой разработчик имеет опыт и как пользователь, и как разработчик, и он знает, как работает та или иная часть программного продукта, даже если она никак не документирована. Однако при таком подходе продукт очень плохо функционирует с точки зрения конечного пользователя, не являющегося программистом. На пользователей никаких обязанностей не накладывается, единственное, что надо иметь в виду --- пользователь хорош тогда, когда он активен. Активность проявляется в том, что пользователи заявляют разработчику, что им неудобно пользоваться программным продуктом. В этом случае социальное чувство (или опасения лишиться дохода) заставит разработчика задуматься над тем, как сделать, чтобы менее квалифицированным пользователям было тоже удобно. Далее, часто документация бывает неполной, и пользователю нужен совет разработчика, что является причиной задуматься о полноте документации. Наконец, при нахождении любых ошибок пользователю хорошо было бы о них сообщать разработчикам, чтобы они могли внести исправления. Наконец, наиболее активные пользователи могут сами участвовать в создании документации или в ответах на вопросы менее квалифицированных пользователей. Таким образом, сообщество состоит из разработчиков программного продукта и его активных пользователей.
Line 15: Line 28:
У всего этого есть обратная сторона. Разработчики должны что-то делать. То есть, если у вас есть идея, как модифицировать программный продукт, будьте любезны, модифицируйте. В случае свободного программного обеспечения все возможности в ваших руках. Если активности не будет, то и развития не будет, причём это касается как разработчика, так и пользователя. Типичный случай продукта, не соответствующего этой схеме, это продукт, у которого очень мало пользователей. То есть, есть core team --- разработчики, которым за этот продукт заплатили --- и есть, скажем, три пользователя. В такой ситуации развития не будет, потому что нет ни механизма привлечения к делу, ни мотивации. У описанного процесса свободной разработки есть обратная сторона. Разработчики должны что-то делать. То есть, если у вас есть идея, как модифицировать программный продукт, будьте любезны, модифицируйте. В случае свободного программного обеспечения все возможности в руках пользователей и разработчиков. Если активности участников процесса разработки не будет, то и развития не будет, причём это касается как разработчика-программиста, так и пользователя. Типичный случай продукта, не соответствующего этой схеме, это продукт, у которого очень мало активных пользователей. То есть, есть основная группа разработчиков --- разработчики, которым за этот продукт заплатили, --- и есть, скажем, три пользователя. В такой ситуации развития не будет, потому что нет привлечения широких слоев пользователей к процессу, и не будет мотивации у разработчиков для улучшения программного продукта.
Line 17: Line 30:
=== Дистрибутив ===
Line 19: Line 31:
Дистрибутив --- это тоже программный продукт, только очень большой. Он собирается из частей, которые находятся в интернете под свободными лицензиями. Специфика дистрибутива в том, что он многокомпонентен. Если мы пишем программу совместно, там может быть 30 мегабайт исходного кода, там может быть много модулей, но если мы возьмём программу поменьше, то это всё равно единое целое, с единым представлением, как следует программировать, документировать и т.д. Дистрибутив Linux --- это набор программных продуктов, (их там несколько тысяч) сделанных, как минимум, сотнями групп разработчиков, никак не связанных друг с другом. Поэтому функции разработчика дистрибутива можно сформулировать следующим образом: определение политики развития и целевая разработка программных продуктов, которые сообществу не очень нужны. Кстати, здесь и ответ на вопрос, откуда берутся деньги. Один из неплохих источников --- заказная доработка. === Разработка дистрибутива GNU/Linux ===
Line 21: Line 33:
Уровень разработчиков довольно странный. В принципе, программные продукты и без нас разрабатываются, и мы можем зайти на сайт и их скачать. Проблема в том, что я не стану качать бинарники (это прихдится делать в двух случаях: если вы совсем не разбираетесь в линуксе, а вам сказали, что нужно запустить такую программу, или если этот продукт распространяется вообще без исходного кода). Качать бинарники не стоит по трём причинам:
 * технологическая несовместимость. Эта программа может просто не заработать в этой системе.
 * В обоих случаях у нас в результате скачана программа (правда, в одном случае платим в другом нет). А если нашлась ошибка, что мы будем делать? Она же бинарная.
 * Программа может работать нормально, но нарушать какую-то дисциплину, установленную core team. Вы её установите, и всё у вас посыпется.
Из описанного процесса разработки отдельных элементов системы GNU/Linux может сложиться впечатление, что дистрибутив --- это набор разрозненных программных продуктов, непонятным образом собранных вместе. То есть, какие-то люди разрабатывают собственно GNU/Linux, и совсем другие люди занимаются разработкой программ. На самом деле, дистрибутив можно рассматривать как метапродукт, который подчиняется тем же законам сообщества, которым подчиняется отдельный продукт.
Line 26: Line 35:
Кто будет заниматься всем этим, то есть отслеживанием новых версий, сборкой программных продуктов из исходных версий в соответствии с политикой дистрибутива, адаптацией (в случае, если есть какие-то ошибки)? Ментейнер, то есть человек, который играет роль разработчика по отношению к дистрибутиву. Он берёт программу из интернета (причём в исходных текстах), чтобы проверить на предмет отсутствия ошибок, на предмет соответствия политике дистрибутива, изготовляет из него бинарную версию и взаимодействует с пользователем. Он отличается от разработчика тем, что он хорошо разбирается в данном программном продукте, который он собрал и адаптировал к использованию в дистрибутиве. Дистрибутив --- это тоже программный продукт, только очень и очень большой. Он собирается из частей, которые находятся в интернете под свободными лицензиями. Специфика дистрибутива в том, что он многокомпонентен, причем компоненты его разного размера и сложности. Если мы пишем программу совместно, там может быть 30 мегабайт исходного кода, множество отдельных модулей, но даже если мы возьмём программу небольшого размера, то это всё равно некоторое единое целое, с единым представлением, как следует программировать, документировать и т.д. Дистрибутив GNU/Linux --- это набор нескольких тысяч программных продуктов, сделанных, как минимум, сотнями групп разработчиков, часто никак не связанных друг с другом. Поэтому функции разработчика дистрибутива можно сформулировать следующим образом: определение политики развития дистрибутива, а также целевая разработка программных продуктов, которые сообществу в целом не очень нужны. Кстати, здесь и один из ответов на вопрос, откуда берутся деньги при открытом способе производства: один из неплохих источников --- заказная доработка для нужд конкретного заказчика.
Line 28: Line 37:
Так что структура копирует структуру сообщества, нарастающую вокруг обычного програмного продукта. Разработчик в данном случае --- это тот, кто сам программу не пишет, а адаптирует её для работы с дистрибутивом. Пользователи --- а это в первую очередь пользователи дистрибутива как такового --- то есть системные администраторы, которым важно, какой дистрибутив, важна функциональность. Рассмотрим сообщество разработчиков с позиции разработчика дистрибутива. В принципе, включаемые в дистрибутив программные продукты разрабатываются и без его участия, и он может просто зайти на сайт и их скачать. Проблема в том, что нежелательно скачивать бинарные файлы (это приходится делать в двух случаях: если вы совсем не разбираетесь в GNU/Linux, а вам необходимо запустить такую программу, или если этот очень нужный вам продукт распространяется вообще без исходного кода). Скачивать бинарные файлы не стоит по трём следующим причинам:
 * Технологическая несовместимость. Эта программа может просто не заработать в этой системе (например, у нас может быть другая архитектура процессора --- x86-64, а на x86).
 * Если в бинарном файле нашлась некоторая ошибка или уязвимость с точки зрения безопасности, с бинарным файлом мы сделать ничего не сможем.
 * Программа может работать нормально, но нарушать какую-то дисциплину, установленную разработчиками дистрибутива. В случае ее включения в дистрибутив в неизменном виде всё остальное может начать работать некорректно.
Line 30: Line 42:
Тем не менее, никто от моральных обязательств не освобожден. Ядро должно принимать стратегически верные решения. Точно также дело ментейнера --- квалификация и слежение за продуктом. От пользователя, как и в предыдущем случае, требуется активность. Так, в случае прямого обращения к ментейнеру некторые задачи решаются в течение часов. Кто будет заниматься всеми этими проблемами, то есть отслеживанием новых версий, сборкой программных продуктов из исходных версий в соответствии с политикой дистрибутива, адаптацией (в случае, если есть какие-то ошибки), оперативным исправлением уязвимостей? Это ментейнер --- человек, который играет роль разработчика по отношению к дистрибутиву. Он берёт у разработчиков программу в исходных текстах, чтобы проверить на предмет отсутствия ошибок и на предмет соответствия политике дистрибутива, затем изготовляет из нее бинарные версии для всех поддерживаемых дистрибутивом аппаратных архитектур, а затем и взаимодействует с пользователями дистрибутива. Он отличается от разработчика исходной версии тем, что он хорошо разбирается в данном программном продукте, который он собрал и адаптировал к использованию в дистрибутиве. Ряд изменений, сделанных ментейнером, может быть включен в дальнейшем в исходный код продукта (в "апстрим").
Line 32: Line 44:
Чего тут не хватает, точнее, что является условием для комфортного существования собщества. Есть, как сказано выше, моральные обязательства у участников (активность). Какие ещё условия должны быть соблюдены:
 * Информационная связность. Условно говоря, интернет. Не должно быть никаких препятствий на пути распространении информации, причём как самого програмного продукта, так и информации о нём.
 * Информационная структурирванность. Речь о том, что информации должно быть не просто много, но она должна быть хорошо структурирована, чтобы человек мог подключиться к проекту с минимальными затратами. При этом необходимо понимать, что в понятие информационной структурированности включается как чисто техническая информация для разработчиков, так и пользовательская документация. Другое дело, что структурированность тоже не самоцель и не всегда её удаётся поддержать на должном уровне. В эту же категорию включаются интерактивные ресурсы --- обратная связь по ошибкам, списки рассылки, форумы. Это необходимо для того, чтобы пользователь, у которого есть вопрос, знал, кому и как его задать.
 * Технологические преимущества. Смысл в том, чтобы человеку из команды был удобно не просто компилировать, а компилировать в соответствии с принятой дисциплиной. То есть, необходимо предоставить сборочные сервера, механизмы сборки, ведение учёта изменений, версионирование... Иными словами, предоставить то, что облегчит ему жизнь в сообществе. Предположим, мы скачали какую-то программу на языке С, в ней 100 файлов. Она была разработана, скажем, под Solaris'ом, там всё замечательно работает. А мы хотим скомпилировать её под линуксом, поскольку других подобных программ нет. В какой-то момент она вообще не запускается, вы выясняете, какие нужны библитеки, компиляторы... В итоге собрали, сказали {{{makeinstall}}}, но в Solaris'e программы кладутся в /opt/progname/, мы всё удалили, и дальше уже начинаем вносить изменения, чтобы она направляла файлы в правильные места и их там искала. Потом оказывается, что есть какая-то ошибка, которая в Solaris'е не проявляется. Наконец, наступил момент, когда программа работает нормально, а через 2 недели выходит новая версия... Чтобы избежать подобной ситуации, необходимо помнить следующее: любые изменения необходимо протоколировать (для этого существуют специальные программы diff и patch: первая показывает различия между старым и новым файлом, вторая заменяет содержание старого файла на содержание нового), кроме того, недурно указать, что нужно для сброчного окружения. И только после этого можете с более-менее лёгким сердцем это собирать. При новой версии применяете к тексту программы старые изменения, если они применятся, автор не подумал, что там была ошибка, если они не применятся, вам нужно посмотреть, что там изменилось, это называется "накатить патчи", и стало уже лучше. Осталось сказать, что делать это лучше на отдельном компьютере. А то мало ли что вы сделаете с библиотеками на старом компьютере. И то, что в альте всё это предоставляется, и вы начнёте понимать, что такое технические преимущества.
Таким образом, структура сообщества дистрибутива копирует структуру сообщества, нарастающего вокруг обычного программного продукта. Основная группа разработчиков принимает стратегические решения и определяет политику дистрибутива и требования к составляющем его программам. Разработчик в данном случае --- это тот, кто программу не пишет, а адаптирует её для работы в дистрибутиве, это могут быть как разработчики-добровольцы, так и члены основной группы разработчиков. Пользователи --- это в первую очередь пользователи дистрибутива как такового --- могут быть и системными администраторами, внедряющими и поддерживающими дистрибутив на предприятии, и обычными домашними пользователи.

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

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

Последний пункт можно пояснить на прмере. Предположим, мы скачали какую-то программу на языке Си, в ней около ста файлов. Она была разработана, скажем, под ОС Sun Solaris и архитектурой Sparc64, и там у автора всё замечательно работает. А мы хотим скомпилировать её под GNU/Linux и архитектуру x86, поскольку других подобных программ нет. Сначала мы определяем, какие библиотеки и каких версий требуются для ее компиляции и работы. В итоге ментейнер собирает ее, дает команду {{{make install}}}, но в Solaris'e программы находятся в каталоге {{{/opt/progname/}}}, и ментейнер вынужден всё удалить, и дальше уже вносить изменения, чтобы она помещала свои файлы в правильные каталоги в соответствии с политикой дистрибутива, и там их и искала. Затем оказывается, что есть какая-то ошибка, которая у автора не проявляется в силу иной архитектуры и операционной системы. После ее исправления, наконец, наступает момент, когда программа работает нормально, но через 2 недели выходит ее новая версия... Чтобы избежать ситуации, когда этот процесс придется повторять каждый раз с нуля при выходе новой версии, необходимо помнить следующее: любые изменения необходимо протоколировать , кроме того, нужно указывать, что нужно для сброчного окружения. И только после этого можете спокойно это собирать.

Для определения различий между исходной и измененной версиями этого существуют специальные программы diff и patch: первая показывает различия между старым и новым файлом (эти различия называются "патчем"), а вторая изменяет содержание старого файла на содержание нового. При выходе новой версии созданный ранее патч применяется к тексту программы. Если патч не накладывается, то, вероятно, автор либо исправил ошибку сам, либо внес крупные изменения в тот фрагмент кода, где была ошибка. Ментейнеру нужно выяснить, что же там изменилось, возможно, ошибка уже исправлена, или нужно создавать новый патч. На жаргоне весь этот процесс называется "накатить патчи". Осталось сказать, что делать это лучше на отдельном сборочном компьютере, чтобы избежать возможных нежелательных изменений библиотек на своем компьютере.

##Отметим, что ALTLinux всё это предоставляет.
Line 43: Line 65:
|| 42 || 1 || 1 || 1 || || 1 || ConstantinYershow, ОльгаТочилкина, VsevolodKrishchenko || || || || 90 || 1 || 1 || 1 || || 1 || ConstantinYershow, ОльгаТочилкина, VsevolodKrishchenko || || ||

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработка дистрибутива GNU/Linux

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

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

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

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

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

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

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

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

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

Последний пункт можно пояснить на прмере. Предположим, мы скачали какую-то программу на языке Си, в ней около ста файлов. Она была разработана, скажем, под ОС Sun Solaris и архитектурой Sparc64, и там у автора всё замечательно работает. А мы хотим скомпилировать её под GNU/Linux и архитектуру x86, поскольку других подобных программ нет. Сначала мы определяем, какие библиотеки и каких версий требуются для ее компиляции и работы. В итоге ментейнер собирает ее, дает команду make install, но в Solaris'e программы находятся в каталоге /opt/progname/, и ментейнер вынужден всё удалить, и дальше уже вносить изменения, чтобы она помещала свои файлы в правильные каталоги в соответствии с политикой дистрибутива, и там их и искала. Затем оказывается, что есть какая-то ошибка, которая у автора не проявляется в силу иной архитектуры и операционной системы. После ее исправления, наконец, наступает момент, когда программа работает нормально, но через 2 недели выходит ее новая версия... Чтобы избежать ситуации, когда этот процесс придется повторять каждый раз с нуля при выходе новой версии, необходимо помнить следующее: любые изменения необходимо протоколировать , кроме того, нужно указывать, что нужно для сброчного окружения. И только после этого можете спокойно это собирать.

Для определения различий между исходной и измененной версиями этого существуют специальные программы diff и patch: первая показывает различия между старым и новым файлом (эти различия называются "патчем"), а вторая изменяет содержание старого файла на содержание нового. При выходе новой версии созданный ранее патч применяется к тексту программы. Если патч не накладывается, то, вероятно, автор либо исправил ошибку сам, либо внес крупные изменения в тот фрагмент кода, где была ошибка. Ментейнеру нужно выяснить, что же там изменилось, возможно, ошибка уже исправлена, или нужно создавать новый патч. На жаргоне весь этот процесс называется "накатить патчи". Осталось сказать, что делать это лучше на отдельном сборочном компьютере, чтобы избежать возможных нежелательных изменений библиотек на своем компьютере.


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

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

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

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

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

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

Level

Maintainer

Start date

End date

90

1

1

1

1

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


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080716/04CommunityStructure (last edited 2008-10-04 08:01:04 by VsevolodKrishchenko)