Различия между версиями 1 и 5 (по 4 версиям)
Версия 1 от 2008-07-17 03:28:02
Размер: 11995
Редактор: eSyr
Комментарий:
Версия 5 от 2008-07-18 11:44:43
Размер: 22850
Редактор: ConstantinYershow
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 3: Строка 3:
Про досбокс: ... Структура сообщества - очень важная тема, поскольку в ней заключается начало ответа на вопрос "как думать?". Открытый спсоб разработки - это то, чем отличаются открытые продукты от закрытых с самого начала. Всё остальное - технология, которая наверчена поверх. Открытый способ разработки плюс копилефтный способ лицензирования - это основание для бизнеса. То есть, мы говорим, что никакой человек, который воспользовался нашей разработкой и привнёс туда какие-то свои инструменты, который хочет достичь чего-то на рынке, должен (поскольку изначально разработка копилефтная) организовать свой бизнес также на основе свободного софта. Копилефт - это гарантия, что любые успешные модификации нашего програмного обеспечения будут опубликованы, и ими сможет воспользоваться каждый, и развитие програмного продукта не прекратится, даже если человек модифицировал что-то исключительно чтобы заработать. Введение копилефта в лицензию приведёт к тому, что, распространяя свой продукт, человек должен будет давать свободный доступ исходным текстам, и, стало быть, эти улучшения окажутся в свободном доступе. Поэтому я, как автор програмного продукта, могу смело выкладывать его под свободной лицензией с копилефтом, зная, что, какие бы улучшения к нему не прибавили, я могу инкорпорировать их в исходный код. По уму, это приводит к тому, что все возвращаются к совместной разрабтке. Если какая-то компания вносит в продукт улучшения из чисто коммерческих соображений, она делает это не у себя в загашнике, а прямо у меня, потому что ей всё равно публиковаться. Так быстрее, один хозяин, в общем, так проще. Сейчас так происходит не везде, но например с IBM и самбой это так.
Строка 5: Строка 5:
Одна тема --- тема очень важная, структура собщества. Ответ на один из вопросов --- как думать. Это откр. спсоб разраб --- то, чем отл. откр. продукты от закрытых с самого начала. Кпилефтный способ лицензирование --- осн. для бизнеса. П уму, эт приводит к тому, что все возвр. к совместной разрабтке. Мы подобрались к вопросу, что такое Linux и как его исопльзуют. Каждый кусок, будь то прилоение, ядро... разрабатывает отдельный человек или даже отдельная команда разработчиков, и это фактически единственный способ такое разрабатывать. У каждого такого кусочка есть некий автор. Создаётся впечатление, что это такая сборная солянка непонятно чего, непонятным образом сложившаяся в дистрибутив. То есть, какие-то люди разрабатывают линукс, и совсем другие люди занимаются разработкой программ. На самом деле, дистрибутив линукс можно рассматривать как метапродукт, который подчиняется тем же законам сообщества, которым подчиняется отдельный продукт.
Строка 7: Строка 7:
Мы подобрались к тому, чт такое Linux и как его исопльзуют. У нас есть такй цветочек, и каждую часть разрабатывает своя команда разработчиков, и это факт. единственный способ такое разрабатывать. У каждого такого кусчка есть некий автр. Создаётся впечатление, чт это такая сборная солянка непонятно чего, сложившаяся в дистрибутив. Т есть, какие-то люди предлагают линукс, и совсем другие люди занимаются разработкой программ. На самом деле, линукс можно рассм. как метапродукт, который подчиняется тем законам сообщества, кторым подчиняется отдельный продукт. Вот есть некая группа товарищей, иногда даже только один, core team. Это,как правило, те люди, которые большую часть времени тратят на то, чтобы разрабатывать этот продукт. Кстати, часто члены core team бывают распределены по всему миру. Иногда они этим работают, иногда это дело жизни, по-разному бывает. Если бы этим всё и заканчивалось, то мы бы имели картинку ту, что была в правовладельческом продукте. Ибо любой правовладельческий продукт разрабатывается тлько таким ядром. Кстати сказать, функция core team шире, чем функция разработчиков правовладельческого продукта, поскольку ядро занимается ещё и стратегическим планированием. Иногда решения ядра очень жёсткие.
Строка 9: Строка 9:
Вот есть некая группа товарищей, core. Это, в некторых случаях, те люди, которые большую часть времени тратят на то, чтобы разрабатывать этот продукт. Иногда они этим работают, иногда это дело жизни, по-разному бывает. Если бы этим всё и заканчивалось, то мы бы имели картинку ту, что была в правовлад. пордукте. Ибо любой правовл. продукт ращрабатывается тлько таким ядром. Кстати сказать, функция core team шире, чем функция обычных разр.. Иногда решения ядра очень жёсткие. В отличие от разработчиков правовладельческого продукта мы рассчитываем на совместную разработку, на привлечение к сообществу любых людей, в том числе таких, кторые не могут уделять разработке этого кокретного продукта всё своё время. Тем не менее, это профессиональные програмисты, перед ними периодически возникает задача внести в наш продукт какие-то изменения, допустим, исправление ошибок или внедрение новых возможностей. Тогда к проекту подключаются добровольцы, которых может быть достаточно много (это зависит от популярности проекта). В конце концов, если ты исправил ошибку, и в core team это приняли, ты уже разработчик. Эти люди заинтересованы в програмном продукте, имеют пользовательскую квалификацию и квалификацию разработчика, имеют ресурс на участие в собществе. Откуда у вас ресурс, что вами двигало - это важно для исследователя, но не регламентировано. Если вы включили свои модификации в upstream, т.е. в общий исходный код, то вам огромное спасибо. Этих людей больше на порядок, но никаких допобязательств перед ними не стоит. С другой стороны, это люди достаточно мотивированные, и если он один раз где-то принял участие, то вероятно, что и ещё раз примет участие, а дальше его и в core team примут.
Строка 11: Строка 11:
Иногда встречаются различные задачи, на кторых core team не хватает, и тогда подключаются сторонние разрабтчики, кторые не уделяю всё своё время, но они имеют свой интерес, имеют польз. квалиф., имеют квалиф. разраб, имеют ресурс на участие в собществе. откуда у вас ресурс, что вами двигал --- это важно для иссл., но не регламентировано. Если вы включили свои модиф. в upstream, то вам огромное спасибо. Этих людей больше на порядок, но никаких допобязательств перед ними не стоит. В этом супе не хватает главнго - пользователей. Обратите внимание, что их ещё больше, чем разработчиков. Это нужн по понятным причинам. Любой разработчик - в танке, он имеет опыт и как пльзователь, и как разработчик, и он знает как работает та или иная часть прграмного продукта, даже если она никак не документирована. В такой форме продукт очень плохо функционирует. На пользователей никаких обязанностей не накладывается, единственная вещь, которую надо иметь в виду - пользователь хорош тогда, когда он активен. Например, если несколько пользователей заявляет разработчику, что им-де неудобно пользоваться програмным продуктом, то социальное чувство заставит разработчика задуматься над тем, а как сделать, чтобы им было тоже удобно. Далее, часто документация бывает неполной, и пользователю нужен совет разработчика. Наконец, при нахождении ошибок хорошо бы о ней сообщить, чтобы её исправить.
Строка 13: Строка 13:
В этом супе не хватает главнго --- пользователей. Обратите внимание, чт изх ещё больше. Это нужн по понятным причинам. Любой разраб --- в танке, он имеет опыт и как пльз., и как разраб., и он знает как польз. пргр. продуктом. В такой фрме продукт очень плохо функц. На польз. никакго усл. не накл., единств. вещь, которую надо иметь в виду --- пользователь хорош тгда, когда он активен. В частности, при нахождении ошибок хорошо бы о ней сообщить, чтобы её исправить. ##Где-то здесь было бы невредно вставить соответствующую картинку. Когда она будет подобающим образом нарисована.
Строка 15: Строка 15:
У всего есть братная сторона. Разработчики должны что-то делать. В случае свободного софта все взм. у вас в руках. Если активности не будет, то ничего не будет. У всего этого есть обратная сторона. Разработчики должны что-то делать. То есть, если у вас есть идея, как модифицировать програмный продукт, будьте любезны, модифицируйте. В случае свободного софта все возможности у вас в руках. Если активности не будет, то ничего не будет. Причём, это касается как разработчика, так и пользователя. Типичный случай продукта, не соответствующего этой схеме, это продукт где очень мало пользователей. То есть, есть ядро, которому за этот продукт заплатили, и есть три пользователя. Вот так работать не будет, потому что нет механизма привлечения к делу.
Строка 17: Строка 17:
Если уьрать слово разрабтчик, то получим свободную схему для чего угодно. И без активности какй-либо части оно работать не будет. === Дистрибутив ===
Строка 19: Строка 19:
Дистрибутив --- эт такой прогр. продукт, тодлько очень большой, он сбирается из кусков, которые в интернете там и сям. Какая специфика --- он многокмпонентен. Если мы пишем программу свместно, то да, там мжет быть 30 мегабайт исх. кода, да, там может быть много модулей, но если мы возьмём пменьше программу, то это всё равно едине целое, с единым предст. по многим вещам. В случае с линуксом это набор ПО, причём неск. тысяч, сделанные стнями групп разрабтчиков, кторые друг с другом не связаны. Поэтому функции ядра в двух вещах --- определять политику развития и целевая разраб. прогр. продуктов, которые сообщ. не особо нужны. И кстати говоря, эт твет н вопрос, откуда берутся деньги. Вокруг core существует команда, где будет мнго разных людей --- дизайнеры, секретари.... Уровень разрабтчиков довольно странный. Дистрибутив - это такой програмный продукт, только очень большой. Он сбирается из кусков, которые в интернете находятся там и сям под свободными лицензиями. Специфика дистрибутива в том, что он многокмпонентен. Если мы пишем программу совместно, там может быть 30 мегабайт исходного кода, да, там может быть много модулей, но если мы возьмём программу поменьше, то это всё равно едине целое, с единым представлением, как следует программировать, документировать и т.д. Дистрибутив же линукса - это набор програмных продуктов, коих там несколько тысяч, сделанные (как минимум) сотнями групп разрабтчиков, никак не связаных друг с другом. Поэтому функции ядра в двух вещах: определять политику развития и целевая разработка програмных продуктов, которые сообществу не особо нужны. И кстати говоря, это ответ н вопрос, откуда берутся деньги. Один из неполохих источников - заказная доработка. Вокруг core существует команда, где будет мнго разных людей - дизайнеры, секретари....
Строка 21: Строка 21:
Можно качать бинарники (и это прихдится делать в двух случаях), но есть три проблемы. ... Уровень разработчиков довольно странный. В принципе, програмные продукты и без нас разрабатываются, и мы можем зайти на сайт и их скачать. Проблема в том, что я не стану качать бинарники (это прихдится делать в двух случаях: если вы совсем не разбираетесь в линуксе, а вам сказали, что нужно запустить такую программу, или если этот продукт распростроняется вообще без исходников). Качать бинарники не стоит по трём причинам:
 * технологическая несовместимость. Эта программа может просто не заработать под этим линуксом.
 * А в чём бонус-то? Так мы берём программу, и так мы её берём (правда, в одном случае платим в другом нет). А если нашлась ошибка, что мы будем делать? Она же бинарная.
 * Программа может работать нормально, но нарушать какую-то дисциплину, установленную core team. Вы её установите, и всё у вас посыпется.
Строка 23: Строка 26:
Кто будет заниматься тестированием? Ментейнер. Он берёт рпограмму из интернета (причём в исх. текстах), чтобы прверить на предмет тсут. гадостей, чтбы проверить на предмет соотв. политике дистр., изг. из него бин. версию и он взаимд. с польз.. Он отлич. от разраб. тем, что он разобрался и сбрал его в дистрибутив. Кто будет заниматься всем этим, то есть отслеживанием новых версий, сборкой програмных продуктов из исходных версий в соответствии с политикой дистрибутива, адаптацией (в случае, если есть какие-то ошибки)? Ментейнер, то есть человек, который играет роль разработчика по отношению к дистрибутиву. Он берёт программу из интернета (причём в исходных текстах), чтобы прверить на предмет отсутствия гадостей, чтобы проверить на предмет соответствия политике дистрибутива, изготовляет из него бинарную версию и он взаимдействует с пользователем. Он отличается от разработчика тем, что он хорошо рабирается в данном програмном продукте, который он собрал и адаптировал к использованию в дистрибутиве.
Строка 25: Строка 28:
Польз. дистр --- системные администраторы, которым важно, какой дистр., важна функц. Так что структура копирует структуру сообщества, нарастающую вокруг обычного програмного продукта. Разработчик в данном случае - это тот, кто сам программу не пишет, а адаптирует для работы с дистрибутивом. Пользователи - это в превую очередь пользователи дистрибутива как такового - то есть системные администраторы, которым важно, какой дистрибутив, важна функциональность.
Строка 27: Строка 30:
Тем не менее, никто от моральных обяз. не свобждал. Точно также к ментейнеру --- квалификация и слежение за прдуктом. Тем не менее, никто от моральных обязательств не свобждал. Ядро должно принимать стратегически верные решения. Точно также дело ментейнера - квалификация и слежение за продуктом. От пользователя, как и в предыдущем случае, требуется активнсть.
Строка 29: Строка 32:
От польз, как и в пред. картинке, требуется активнсть. В случае прямого обращения к ментейнеру некторые задачи решаются в течение часов.
Строка 31: Строка 34:
В случае обращения к ментейнеру прямого некторые задачи решаются в течение часов.

Чего не хватает, точнее, чт является услоовием для комф. сущ. собщества. Есть мральные обяз. у участников (активность). Ккие усл. длжны быть собл.:
 * Инф. связность (интернет). Не должно быть никаких препятствий на пути расп. информации, как расп. самого прогр. продукта, так и инф. о нём. (рассказ про китай)
 * Информационная струтктурирваннсть. Речь о том, что инф. должно быть не просто много, но она должна быть структ. так, чтобы человек мог подкл. без особых затрат. При этом надо понимать, что в инф. структ. вкл. как чи ст тех. инф. для разработчиков, так и польз. док.. Другое дело, что структ. тоже не самоцель и не всегда её удаётся пддержать. При этом, когда про неё говориться, говорится и пр ресурсы интераткивные
 * Техн. преимущества. Идея в том, чтобы человеку из команды был удбно не просто компиировать, а компилировать в сотв. с дисциплиной. То есть, предст. сбор. сервера, механизм сборки, версионирование... Предположим, скачали какую-то программу на языке С, 100 файлов. Ребята разраб. у себя под солярисом, у них всё замечательн рабтает. В какой-то момент она вообще не запускается, нужны библитеки, компиляторы... В итоге собрали, но в солярисе программы кладутся в /opt/progname/, и дальше уже начинаете вносить изм., чтбы она раскладывала файлы в праильные места и их там искала. Потом оказывается, что есть какая-то ошибка, которая в солярис ене проялвяется. Наконец, наступило счастье, программа теперь работает нормально, а через 2 недели вышла новая версия... Что нужно было елать на самм деле --- любые изменения протоколировать (diff и patch), кроме того, недурно указать что нужно для сброчного окр. и запротоколировать. И только после этого можете с более-менее лёгким сердцем это собирать. При нвой версии ставите это изменение, накатите патчи и стало уже лучше. Осталось сказать, что делать это лучше на отдельном компьютере. И то, что в альте всё это предоставляется, и вы начнёте понимать, что такое тех. преимущества.
Чего тут не хватает, точнее, что является услоовием для комфортного существования собщества. Есть, как сакзано выше, моральные обязательства у участников (активность). Какие ещё условия должны быть соблюдены:
 * Инф. связность. Условно говоря, интернет. Не должно быть никаких препятствий на пути распространении информации, причём как самого програмного продукта, так и информации о нём.
 * Информационная струтктурирваннсть. Речь о том, что информации должно быть не просто много, но она должна быть хорошо структурированна, чтобы человек мог подключиться к проекту с миимальными затратами. При этом надо понимать, что в информационную структурированность включаестя как чисто техническая информация для разработчиков, так и пользовательская документация. Другое дело, что структурированность тоже не самоцель и не всегда её удаётся поддержать на должном уровне. В эту же категорию включаются интерактивные ресурсы - обратная связь по ошибкам, списки рассылки, форумы. Чтобы пользователь, у которого есть вопрос, знал куда его задать.
 * Технологические преимущества. Идея в том, чтобы человеку из команды был удобно не просто компилировать, а компилировать в сотвестсвии с принятой дисциплиной. То есть, представить сборочные сервера, механизмы сборки, ведения учёта изменений, версионирование... То есть, предоставить то, что облегчит ему жизнь в сооществе. Предположим, скачали какую-то программу на языке С, 100 файлов. Ребята разработали её у себя под солярисом, у них всё замечательно работает. А вы хотите скомпилировать её под линуксом, поскольку других таких нет. В какой-то момент она вообще не запускается, вы выясняете, какие нужны библитеки, компиляторы... В итоге собрали, сказали makeinstall, но в солярисе программы кладутся в /opt/progname/, вы всё поудаляли, и дальше уже начинаете вносить изменения, чтбы она раскладывала файлы в праильные места и их там искала. Потом оказывается, что есть какая-то ошибка, которая в солярисе не проялвяется. Наконец, наступило счастье, программа теперь работает нормально, а через 2 недели вышла новая версия... Что нужно было делать на самом деле - любые изменения протоколировать (для этого существуют специальные программы diff и patch, первая показывает различия между старым и новым файлом, вторая заменяет содержание старого файла на содержание нового), кроме того, недурно указать, что нужно для сброчного окружения. И только после этого можете с более-менее лёгким сердцем это собирать. При новой версии применяете к тексту программы старые изменения, если они применятся, автор не подумал, что там была ошибка, если они не применятся, вам нужно посмотреть, что там изменилось, это называется "накатить патчи", и стало уже лучше. Осталось сказать, что делать это лучше на отдельном компьютере. А то мало ли что вы сделаете с библиотеками на старом компьютере. И то, что в альте всё это предоставляется, и вы начнёте понимать, что такое технические преимущества.
Строка 43: Строка 44:
|| Готовность (%) || Продолжительность (ак. ч.) || Подготовка (календ. ч.) || Полный текст (раб. д.) || Предварительные знания || Level || Maintainer || Start date || End date ||
|| 0 || 1 || 1 || 1 || || 1 || ConstantinYershow, ОльгаТочилкина || || ||
|| Готовность (%) || Продолжительность (ак. ч.) || Подготовка (календ. ч.) || Полный текст (раб. д.) || Предварительные знания || Level || Maintainer                      || Start date || End date ||
|| 20 || 1 || 1 || 1 || || 1 || ConstantinYershow, ОльгаТочилкина, VsevolodKrishchenko || || ||

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

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

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

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

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

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

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

Дистрибутив

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

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

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

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

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

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

В случае прямого обращения к ментейнеру некторые задачи решаются в течение часов.

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

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


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

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

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

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

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

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

Level

Maintainer

Start date

End date

20

1

1

1

1

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


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080716/04CommunityStructure (последним исправлял пользователь VsevolodKrishchenko 2008-10-04 11:01:04)