Differences between revisions 6 and 7
Revision 6 as of 2008-07-22 14:07:12
Size: 23199
Comment:
Revision 7 as of 2008-07-22 14:41:39
Size: 23459
Comment:
Deletions are marked like this. Additions are marked like this.
Line 20: Line 20:
Дистрибутив - это такой програмный продукт, только очень большой. Он сбирается из кусков, которые в интернете находятся там и сям под свободными лицензиями. Специфика дистрибутива в том, что он многокмпонентен. Если мы пишем программу совместно, там может быть 30 мегабайт исходного кода, да, там может быть много модулей, но если мы возьмём программу поменьше, то это всё равно едине целое, с единым представлением, как следует программировать, документировать и т.д. Дистрибутив же линукса - это набор програмных продуктов, коих там несколько тысяч, сделанные (как минимум) сотнями групп разрабтчиков, никак не связаных друг с другом. Поэтому функции ядра в двух вещах: определять политику развития и целевая разработка програмных продуктов, которые сообществу не особо нужны. И кстати говоря, это ответ н вопрос, откуда берутся деньги. Один из неполохих источников - заказная доработка. Вокруг core существует команда, где будет мнго разных людей - дизайнеры, секретари.... Дистрибутив - это такой программный продукт, только очень большой. Он собирается из частей, которые в интернете находятся под свободными лицензиями. Специфика дистрибутива в том, что он многокмпонентен. Если мы пишем программу совместно, там может быть 30 мегабайт исходного кода, там может быть много модулей, но если мы возьмём программу поменьше, то это всё равно единое целое, с единым представлением, как следует программировать, документировать и т.д. Дистрибутив же линукса --- это набор программных продуктов, коих там несколько тысяч, сделанных, как минимум, сотнями групп разработчиков, никак не связанных друг с другом. Поэтому функции можно сформулировать следующим образом: определение политики развития и целевая разработка программных продуктов, которые сообществу не очень нужны. Кстати, здесь и ответ на вопрос, откуда берутся деньги. Один из неплохих источников - заказная доработка. Вокруг core существует команда, где будет много разных людей - дизайнеры, секретари....
Line 22: Line 22:
Уровень разработчиков довольно странный. В принципе, програмные продукты и без нас разрабатываются, и мы можем зайти на сайт и их скачать. Проблема в том, что я не стану качать бинарники (это прихдится делать в двух случаях: если вы совсем не разбираетесь в линуксе, а вам сказали, что нужно запустить такую программу, или если этот продукт распростроняется вообще без исходников). Качать бинарники не стоит по трём причинам: Уровень разработчиков довольно странный. В принципе, программные продукты и без нас разрабатываются, и мы можем зайти на сайт и их скачать. Проблема в том, что я не стану качать бинарники (это прихдится делать в двух случаях: если вы совсем не разбираетесь в линуксе, а вам сказали, что нужно запустить такую программу, или если этот продукт распростроняется вообще без исходников). Качать бинарники не стоит по трём причинам:
Line 27: Line 27:
Кто будет заниматься всем этим, то есть отслеживанием новых версий, сборкой програмных продуктов из исходных версий в соответствии с политикой дистрибутива, адаптацией (в случае, если есть какие-то ошибки)? Ментейнер, то есть человек, который играет роль разработчика по отношению к дистрибутиву. Он берёт программу из интернета (причём в исходных текстах), чтобы прверить на предмет отсутствия гадостей, чтобы проверить на предмет соответствия политике дистрибутива, изготовляет из него бинарную версию и он взаимдействует с пользователем. Он отличается от разработчика тем, что он хорошо рабирается в данном програмном продукте, который он собрал и адаптировал к использованию в дистрибутиве. Кто будет заниматься всем этим, то есть отслеживанием новых версий, сборкой программных продуктов из исходных версий в соответствии с политикой дистрибутива, адаптацией (в случае, если есть какие-то ошибки)? Ментейнер, то есть человек, который играет роль разработчика по отношению к дистрибутиву. Он берёт программу из интернета (причём в исходных текстах), чтобы проверить на предмет отсутствия ошибок, на предмет соответствия политике дистрибутива, изготовляет из него бинарную версию и взаимодействует с пользователем. Он отличается от разработчика тем, что он хорошо разбирается в данном программном продукте, который он собрал и адаптировал к использованию в дистрибутиве.
Line 29: Line 29:
Так что структура копирует структуру сообщества, нарастающую вокруг обычного програмного продукта. Разработчик в данном случае - это тот, кто сам программу не пишет, а адаптирует для работы с дистрибутивом. Пользователи - это в превую очередь пользователи дистрибутива как такового - то есть системные администраторы, которым важно, какой дистрибутив, важна функциональность. Так что структура копирует структуру сообщества, нарастающую вокруг обычного програмного продукта. Разработчик в данном случае --- это тот, кто сам программу не пишет, а адаптирует её для работы с дистрибутивом. Пользователи --- а это в первую очередь пользователи дистрибутива как такового --- то есть системные администраторы, которым важно, какой дистрибутив, важна функциональность.
Line 31: Line 31:
Тем не менее, никто от моральных обязательств не свобждал. Ядро должно принимать стратегически верные решения. Точно также дело ментейнера - квалификация и слежение за продуктом. От пользователя, как и в предыдущем случае, требуется активнсть. Тем не менее, никто от моральных обязательств не освобожден. Ядро должно принимать стратегически верные решения. Точно также дело ментейнера --- квалификация и слежение за продуктом. От пользователя, как и в предыдущем случае, требуется активность. Так, в случае прямого обращения к ментейнеру некторые задачи решаются в течение часов.
Line 33: Line 33:
В случае прямого обращения к ментейнеру некторые задачи решаются в течение часов.

Чего тут не хватает, точнее, что является услоовием для комфортного су
ществования собщества. Есть, как сакзано выше, моральные обязательства у участников (активность). Какие ещё условия должны быть соблюдены:
 * Инф. связность. Условно говоря, интернет. Не должно быть никаких препятствий на пути распространении информации, причём как самого програмного продукта, так и информации о нём.
 * Информационная струтктурирваннсть. Речь о том, что информации должно быть не просто много, но она должна быть хорошо структурированна, чтобы человек мог подключиться к проекту с миимальными затратами. При этом надо понимать, что в информационную структурированность включаестя как чисто техническая информация для разработчиков, так и пользовательская документация. Другое дело, что структурированность тоже не самоцель и не всегда её удаётся поддержать на должном уровне. В эту же категорию включаются интерактивные ресурсы - обратная связь по ошибкам, списки рассылки, форумы. Чтобы пользователь, у которого есть вопрос, знал куда его задать.
 * Технологические преимущества. Идея в том, чтобы человеку из команды был удобно не просто компилировать, а компилировать в сотвестсвии с принятой дисциплиной. То есть, представить сборочные сервера, механизмы сборки, ведения учёта изменений, версионирование... То есть, предоставить то, что облегчит ему жизнь в сооществе. Предположим,
скачали какую-то программу на языке С, 100 файлов. Ребята разработали её у себя под солярисом, у них всё замечательно работает. А вы хотите скомпилировать её под линуксом, поскольку других таких нет. В какой-то момент она вообще не запускается, вы выясняете, какие нужны библитеки, компиляторы... В итоге собрали, сказали makeinstall, но в солярисе программы кладутся в /opt/progname/, вы всё поудаляли, и дальше уже начинаете вносить изменения, чтбы она раскладывала файлы в праильные места и их там искала. Потом оказывается, что есть какая-то ошибка, которая в солярисе не проялвяется. Наконец, наступило счастье, программа теперь работает нормально, а через 2 недели вышла новая версия... Что нужно было делать на самом деле - любые изменения протоколировать (для этого существуют специальные программы diff и patch, первая показывает различия между старым и новым файлом, вторая заменяет содержание старого файла на содержание нового), кроме того, недурно указать, что нужно для сброчного окружения. И только после этого можете с более-менее лёгким сердцем это собирать. При новой версии применяете к тексту программы старые изменения, если они применятся, автор не подумал, что там была ошибка, если они не применятся, вам нужно посмотреть, что там изменилось, это называется "накатить патчи", и стало уже лучше. Осталось сказать, что делать это лучше на отдельном компьютере. А то мало ли что вы сделаете с библиотеками на старом компьютере. И то, что в альте всё это предоставляется, и вы начнёте понимать, что такое технические преимущества.
Чего тут не хватает, точнее, что является условием для комфортного существования собщества. Есть, как сказано выше, моральные обязательства у участников (активность). Какие ещё условия должны быть соблюдены:
 * Информационная связность. Условно говоря, интернет. Не должно быть никаких препятствий на пути распространении информации, причём как самого програмного продукта, так и информации о нём.
 * Информационная структурирванность. Речь о том, что информации должно быть не просто много, но она должна быть хорошо структурирована, чтобы человек мог подключиться к проекту с минимальными затратами. При этом необходимо понимать, что в понятие информационной структурированности включается как чисто техническая информация для разработчиков, так и пользовательская документация. Другое дело, что структурированность тоже не самоцель и не всегда её удаётся поддержать на должном уровне. В эту же категорию включаются интерактивные ресурсы --- обратная связь по ошибкам, списки рассылки, форумы. Это необходимо для того, чтобы пользователь, у которого есть вопрос, знал, кому и как его задать.
 * Технологические преимущества. Смысл в том, чтобы человеку из команды был удобно не просто компилировать, а компилировать в соответствии с принятой дис
циплиной. То есть, необходимо предоставить сборочные сервера, механизмы сборки, ведение учёта изменений, версионирование... Иными словами, предоставить то, что облегчит ему жизнь в сообществе. Предположим, мы скачали какую-то программу на языке С, в ней 100 файлов. Она была разработана, скажем, под Solaris'ом, там всё замечательно работает. А мы хотим скомпилировать её под линуксом, поскольку других подобных программ нет. В какой-то момент она вообще не запускается, вы выясняете, какие нужны библитеки, компиляторы... В итоге собрали, сказали {{{makeinstall}}}, но в Solaris'e программы кладутся в /opt/progname/, мы всё удалили, и дальше уже начинаем вносить изменения, чтобы она направляла файлы в правильные места и их там искала. Потом оказывается, что есть какая-то ошибка, которая в Solaris'е не проявляется. Наконец, наступил момент, когда программа работает нормально, а через 2 недели выходит новая версия... Чтобы избежать подобной ситуации, необходимо помнить следующее: любые изменения необходимо протоколировать (для этого существуют специальные программы diff и patch: первая показывает различия между старым и новым файлом, вторая заменяет содержание старого файла на содержание нового), кроме того, недурно указать, что нужно для сброчного окружения. И только после этого можете с более-менее лёгким сердцем это собирать. При новой версии применяете к тексту программы старые изменения, если они применятся, автор не подумал, что там была ошибка, если они не применятся, вам нужно посмотреть, что там изменилось, это называется "накатить патчи", и стало уже лучше. Осталось сказать, что делать это лучше на отдельном компьютере. А то мало ли что вы сделаете с библиотеками на старом компьютере. И то, что в альте всё это предоставляется, и вы начнёте понимать, что такое технические преимущества.
Line 46: Line 44:
|| 27 || 1 || 1 || 1 || || 1 || ConstantinYershow, ОльгаТочилкина, VsevolodKrishchenko || || || || 30 || 1 || 1 || 1 || || 1 || ConstantinYershow, ОльгаТочилкина, VsevolodKrishchenko || || ||

Структура сообщества

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

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

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

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

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

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

Дистрибутив

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

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

  • технологическая несовместимость. Эта программа может просто не заработать под этим линуксом.
  • А в чём бонус-то? Так мы берём программу, и так мы её берём (правда, в одном случае платим в другом нет). А если нашлась ошибка, что мы будем делать? Она же бинарная.
  • Программа может работать нормально, но нарушать какую-то дисциплину, установленную core team. Вы её установите, и всё у вас посыпется.

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

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

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

Чего тут не хватает, точнее, что является условием для комфортного существования собщества. Есть, как сказано выше, моральные обязательства у участников (активность). Какие ещё условия должны быть соблюдены:

  • Информационная связность. Условно говоря, интернет. Не должно быть никаких препятствий на пути распространении информации, причём как самого програмного продукта, так и информации о нём.
  • Информационная структурирванность. Речь о том, что информации должно быть не просто много, но она должна быть хорошо структурирована, чтобы человек мог подключиться к проекту с минимальными затратами. При этом необходимо понимать, что в понятие информационной структурированности включается как чисто техническая информация для разработчиков, так и пользовательская документация. Другое дело, что структурированность тоже не самоцель и не всегда её удаётся поддержать на должном уровне. В эту же категорию включаются интерактивные ресурсы --- обратная связь по ошибкам, списки рассылки, форумы. Это необходимо для того, чтобы пользователь, у которого есть вопрос, знал, кому и как его задать.
  • Технологические преимущества. Смысл в том, чтобы человеку из команды был удобно не просто компилировать, а компилировать в соответствии с принятой дисциплиной. То есть, необходимо предоставить сборочные сервера, механизмы сборки, ведение учёта изменений, версионирование... Иными словами, предоставить то, что облегчит ему жизнь в сообществе. Предположим, мы скачали какую-то программу на языке С, в ней 100 файлов. Она была разработана, скажем, под Solaris'ом, там всё замечательно работает. А мы хотим скомпилировать её под линуксом, поскольку других подобных программ нет. В какой-то момент она вообще не запускается, вы выясняете, какие нужны библитеки, компиляторы... В итоге собрали, сказали makeinstall, но в Solaris'e программы кладутся в /opt/progname/, мы всё удалили, и дальше уже начинаем вносить изменения, чтобы она направляла файлы в правильные места и их там искала. Потом оказывается, что есть какая-то ошибка, которая в Solaris'е не проявляется. Наконец, наступил момент, когда программа работает нормально, а через 2 недели выходит новая версия... Чтобы избежать подобной ситуации, необходимо помнить следующее: любые изменения необходимо протоколировать (для этого существуют специальные программы diff и patch: первая показывает различия между старым и новым файлом, вторая заменяет содержание старого файла на содержание нового), кроме того, недурно указать, что нужно для сброчного окружения. И только после этого можете с более-менее лёгким сердцем это собирать. При новой версии применяете к тексту программы старые изменения, если они применятся, автор не подумал, что там была ошибка, если они не применятся, вам нужно посмотреть, что там изменилось, это называется "накатить патчи", и стало уже лучше. Осталось сказать, что делать это лучше на отдельном компьютере. А то мало ли что вы сделаете с библиотеками на старом компьютере. И то, что в альте всё это предоставляется, и вы начнёте понимать, что такое технические преимущества.


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

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

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

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

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

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

Level

Maintainer

Start date

End date

30

1

1

1

1

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


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

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