You are here: Foswiki>Gnumed Web>OpenSourceSuccessRu (11 Mar 2013, IvanLykov)EditAttach

Характеристики успешного проекта OSS

Что характеризует "успешный" проект OSS?

Стефано Пьяцца считал полезным использовать только на стадии разработки Gnumed (2007) поиск характеристик каких-либо проектов, широко признаваемых как "успешные", и применять их к Gnumed. Он сделал краткий (3 ч) поиск Google по успешным проектам с открытым кодом

Он предложил некоторые краткие выводы:

(1) Большинство проектов OSS дают сбой

90-95% всех стартапов проваливаются

(2) Для всех учебных проектов понадобилось улучшение текущей программы

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

(3) Литературы по традиционным методам дизайна мало

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

(4) Большинство разработчиков OSS является пользователями

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

(5) "Управление" проектом разнообразно

Считается, из трех проектов один был параллельным от коммерческого предприятия (Mozilla), и Netscape сохраняет контроль и тратит значительные ресурсы на управление и тестирование кодовых страниц (6 команд). Apache был, вероятно, наиболее близок к Gnumed. Он имел гораздо меньше кода, чем Mozilla. Там было 8-25 разработчиков "ядра", с 4-8 активными в любое время. Большинство кодовых страниц (> 85%) было внесено 15 основными разработчиками. Они имели "кворум" для голосования по основным вопросам. Большая часть связи была через списки электронной почты. Отправка почты координируется одним разработчиком.

(6) Осведомленные пользователи способствовали выявлению и исправлению ошибок

Примерно в 10 раз больше пользователей, чем разработчиков "ядра", поставляли исправления, и многие также выявляли ошибки и тестировали программное обеспечение

Что такое "успех"? Широкое качество поглощения при использовании Сопровождаемости сообщества по "плотности" ошибок у разработчиков

Что такое "провал"?

Ниже следуют различные цитаты и резюме - "я не уверен, как они могут быть использованы, но могут стимулировать обсуждение

(из http://aseigo.blogspot.com/2005/11/writing-successful-open-source.html)

Написание успешного ПО с открытым исходным кодом

я считаю кикер провалом для программного обеспечения.

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

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

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

в открытом исходном коде мы работаем с очень небольшими группами разработчиков с более высоким оборотом. эти люди делают это, потому что они пользуются им. затем эксплуатация нашего программного обеспечения должна поддерживать это. как?

ясность:

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

простота:

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

расширяемость:

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

документация:

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

изобретение против повторного использования:

если написан хороший код, делающий так, что ваши потребности программного обеспечения используют его. если он не точно то, что нужно, но достаточно близок, оставьте перфекционизм и не изобретайте колесо. и ради богини красоты не раздваивайте код, если его вам нужно настроить чуть-чуть; исправьте его вверх по течению, так чтобы не завершать с N немного разным на вкус тем же компонентом. однако, если лучшая вещь там не очень хорошо подходит, не пытайтесь и подправьте его (использование kioslaves для imap в kmail является хорошим примером этого IMHO).

сделайте его легким для внесения изменений:

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

Вот мои наработки (RH) на http://www.research.avayalabs.com/techreport/ALR-2002-003-paper.pdf

Apache

"Программа NCSA httpd program 1995" выросла из предыдущего проекта, координирующего исправления для него

Сначала были изучены проблемы процесса, "как будет работать команда разработчиков? Связь по электронной почте Минимальный кворум для разрешения конфликтов " новые члены "ядра" были приглашены после периода участия (~6 месяцев) 8-25 членов "ядра" активных 4-8 в любое время

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

Основные релизы управляются через силовое решение "старшего" разработчика ядра по основным вопросам, например, "встряхнуть дерево и сгрести листья наверх"

Количество участвующих - 249 в коде для исправления ошибок 182 сообщений об ошибках 591, приведшие к изменению кода, от большинства индивидуальных 458 сообщений по проблемам, предоставленные неосновными разработчиками, " т.е. сообщества, имели значительную роль в тестировании программного обеспечения Активные 15 разработчиков внесли >85% изменений кода

Плотность дефектов было трудно сравнить с коммерческими проектами, но примерно сопоставима

Некоторые выводы/гипотезы команды ядра макс 10-15, если проект больше, она должна быть разбита на подпроекты с большей пользовательской базой, участники будут находить дефекты и исправлять, освобождая основную группу для продолжения кодирования новых компонентов, " иначе кодировщики увязнут в исправлении ошибок. Кодеры, как правило, будут пользователями программного обеспечения, поэтому имеют четкое представление о "потребностях пользователей"

Mozilla

Код был выпущен в "среду" OSS фирмой Netscape в 1998. Netscape оставался "доброжелательным диктатором" для наблюдения за разработкой. Это было гораздо более крупный проект, но снова начал на основе предыдущего ПО " разработчик был для его выполнения

12 основных кодировщиков/членов " частично коммерческих 6 тестовых команд, кодировали проверки до релиза, официальных тестовых случаев

Это цитировано из http://www.cmcrossroads.com/ubbthreads/showflat.php?Cat=&Number=53266

Большие проекты живут и умирают в силу их лидеров, которых невозможно заменить никаким количеством управленцев. Лидеры успешного проекта сосредотачивают свои команды на "нужных" возможностях, а не "приятных."

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

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

Разработчики открытого исходного кода, работающие на сайтах, подобных SourceForge?.net могут также задействовать ресурсы за пределами их проекта, в других местах в сообществе. Централизованное приложение, на котором работают все, поддерживает быструю идентификацию разработчиков с конкретными знаниями, которые вы можете использовать " либо для кратких вопросов, либо для присоединения к вашему проекту в качестве значимого участника (и, кто знает, возможно также найдете, что планируемый вами проект уже сделан!).

"Agile", eXtreme Programming (XP) и другие формализованные методы все большего количества компаний эволюционировали из опыта развития с открытым исходным кодом. Перемещение организации к этим новым методам работы может быть сложной задачей. Однако, я могу почти гарантировать, что некоторые из сотрудников вашей компании уже имеют многие из этих навыков, отточенных в проектах с открытым кодом, в которые они так или иначе внесли

Вот отдельные цитаты из оригинального документа в "The Cathedral and the Bazaar" на

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

Бросали код и снова начинали

Но я имею более теоретическое основание думать, что переход может быть такой хорошей идеей, как что-то, что я знал задолго до Linux. 3. ``Планируете бросить один способ; будете, так или иначе.'' (Фред Брукс, Мифический человек-месяц, глава 11) Или назначаете его другим способом, вы часто не понимаете действительной проблемы до тех пор, пока после первого раза не реализуете решение. В следующий раз, возможно, вы знаете достаточно, чтобы сделать правильно. Если хотите получить эту привилегию, будьте готовы начать, по крайней мере, один раз [JB].

Значение обладающих пользователей

И поэтому я унаследовал popclient. Так же, как важно то, что я унаследовал базу пользователей в popclient. Пользователи замечательны для обладания, и не только потому, что они демонстрируют, что вы удовлетворяете потребность, которую сделали правильно. Подготовленные должным образом, они могут стать со-разработчиками. Другой силой традиции Unix, толкающей Linux к счастливой крайности, является то, что многие пользователи являются также и хакерами. Поскольку исходный код доступен, они могут быть эффективными хакерами. Это может быть чрезвычайно полезно для сокращения времени отладки. Получая немного поощрения, ваши пользователи будут диагностировать проблемы, предлагать исправления и помогать улучшить код гораздо быстрее, чем вы смогли бы без посторонней помощи. 6. Восприятие пользователей как со-разработчиков является наименее хлопотным способом для быстрого совершенствования кода и эффективной отладки. Сила этого эффекта просто недооценина. В самом деле, очень хорошее в мире с открытым исходным кодом все мы значительно недооцениваем, насколько оно будет наращиваться с ростом пользователей и вопреки сложности системы, с тех пор, как Линус Торвальдс показал нам разницу. Может быть при этом и не было такого сюрприза. Социологи несколько лет назад обнаружили, что усредненное мнение массы одинаковое экспертному (или одинаково невежественно) совсем ненамного более надежный показатель, чем мнение случайно выбранного одиночки. Они назвали это эффектом Delphi. Похоже, показанное Линусом относится также к отладке операционной системы", в которой эффект Delphi может приручить сложность развития даже на уровне сложности ядра ОС. [CV] Одной особенностью ситуации Linux, которая четко помогает наряду с эффектом Delphi, является тот факт, что участники для любого предоставленного проекта самоотбираются. Ранний респондент указал, что участие идет не из случайной выборки, а от людей, которые достаточно заинтересованы использовать ПО, узнать, как оно работает, пытаются найти решения для проблем, с которыми они сталкиваются и на самом деле, по-видимому, получают разумные исправления. Тот, кто передает все эти фильтры, весьма вероятно, имеет что-то полезное для содействия. Закон Линуса можно перефразировать как ``Отладка распараллеливается''. Хотя, отладка требует, чтобы отладчики общались с некоторым координирующим разработчиком, это не требует значительной координации между отладчиками. Таким образом, не становится жертвой той же квадратичной сложности и управленческих расходов, которые делают проблематичным добавление разработчиков.

Потратьте время на ваши структуры данных " в нашем случае таблицы SQL

9. Структуры smart-данных и немой код работают гораздо лучше, чем другие способы. Брукс, глава 9: ``Покажите мне ваш блок и скройте ваши таблицы, и я буду продолжать удивляться. Покажите мне ваши таблицы, а ваш блок мне, обычно, не нужен; это будет очевидно.'' Разрешение для тридцать лет терминологического/культурного сдвига, это та же точка.

Рефрейминг проблемы

Но здесь есть два более фундаментальных неполитических урока, которые являются общими для всех видов дизайна. 12. Часто наиболее яркие и инновационные решения приходят от понимания, что ваша концепция проблемы была неправильна. Я пытался решить проблему неправильно, продолжая развивать popclient, как комбинированные MTA/MDA со всеми видами режимов фанки локальной доставки. Дизайн fetchmail необходимо переосмыслить от основания, как чисто MTA, часть обычного пути SMTP-говорящей почты Интернета. Когда вы упираетесь в стену при разработке"когда находите для себя трудным заставить думать кроме следующего патча"это время спросить, нет ли у вас правильного ответа, но задавали ли вы правильный вопрос. Возможно нужно переформулировать проблемы. Есть более общий урок в этой истории о том, как доставлять SMTP в fetchmail. Это не только распараллеленная отладка; развитие и (возможно, удивительного масштаба) исследование дизайна пространства тоже. Когда ваш режим развития сильно итеративен, разработка и совершенствование могут стать особыми случаями отладки"исправления `ошибок бездействия' в оригинальных возможностях или концепции программного обеспечения.

Потребность для рабочего прототипа для начала

Довольно ясно, что одиночка не сможет кодировать от основ в стиле bazaar [IN]. Одиночка может проверить, отладить и улучшить в стиле базар, но было бы очень трудно создать оригинальный проект в стиле базар. Линус не пробовал его. Я тоже не замечен. Нарождающийся разработчик должен иметь что-то к запуску и тестированию для воспроизведения. Когда начинаете сборку в сообществе, вы должны быть в состоянии представить правдоподобное обещание. Ваша программа не особенно хорошо работает. Она может быть грубой, с дефектами, неполной и плохо документированной. То, чего нельзя делать, это (a) запускать и (b) убеждать потенциальных со-разработчиков, что она может превратиться в нечто очень аккуратное в обозримом будущем.

Коммерческий дизайн не всегда получает лучшие результаты!

Одной из наиболее известных народных примет инжениринга ПО является то, что от 60% до 75% обычных программных проектов либо никогда не завершаются, либо отвергаются их предполагаемыми пользователями. Если этот диапазон близок к действительности (я никогда не встречал менеджера любого опыта, оспаривающего его), чем больше проектов, тем меньше направленных на достижение целей, которые либо (a) реально недостижимы, либо (b) непосредственно просто неверны.
Topic revision: 11 Mar 2013, IvanLykov
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark