Какие факторы определяют успех проекта с открытым исходным кодом?[закрыто]
https://stackoverflow.com/questions/80997
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
У нас есть ряд приложений и библиотек с закрытым исходным кодом, для которых, по нашему мнению, имеет смысл открыть исходный код.
Что нас до сих пор блокировало, так это усилия, необходимые для очистки базы кода и документирования исходного кода перед его открытием.
Мы хотим открыть исходный код только в том случае, если у нас есть разумная вероятность того, что проекты будут успешными, т.е.наличие вкладчиков.Мы убеждены, что код будет интересен большому числу разработчиков.
Какие факторы, исключая «интересность» и «полезность» проекта, определить успех проекта с открытым исходным кодом?
Примеры:
- Чистота кода
- Наличие комментариев к исходному коду
- Полностью или частично документированные API
- Выбор лицензии (GPL или GPL).LGPL против.БСД и т. д.)
- Выбор публичного репозитория
- Инвестиции в общедоступный веб-сайт
Решение
Есть несколько вещей, которые определяют успех кода.Всего этого необходимо добиться для малейшего шанса на усыновление.
- Рынок. Должен быть рынок для вашего проекта с открытым исходным кодом.Если ваш проект — апельсиновая соковыжималка в космосе, я сомневаюсь, что вы добьетесь большого успеха.Вы должны убедиться, что ваш проект получит широкое признание среди пользователей и разработчиков.Вероятность успеха увеличится в два раза, если вы сможете убедить другие корпорации принять его.
- Документация. Как вы уже говорили ранее, документация является ключевым моментом.Среди этой документации есть прокомментированный код, архитектурные решения и примечания к API.Даже если ваша документация содержит ошибки или ошибки в вашем программном обеспечении, это нормально.Помните, прозрачность имеет ключевое значение.
- Свобода. Вы должны сделать свой код «свободным» — под этим я подразумеваю свободу в речи, а не в пиве.Если у вас есть ощущение, что ваш рынок является библиотекой для других корпораций, лицензия BSD будет оптимальной.Если ваше программное обеспечение будет работать на настольных компьютерах, то GPL — ваш выбор.
- Прозрачность. Вы должны писать программное обеспечение в прозрачной среде.Как только вы откроете исходный код, скрытых секретов не останется.Вы должны объяснить все, что вы делаете, и что вы делаете.Это разозлит разработчиков, как никто другой.
- Сообщество разработчиков. Требуется сильное сообщество разработчиков.Это должно существовать.Лишь около 5% пользователей вносят свой вклад в проект.Если кто -то замечает, что в течение года не было никаких выпусков, они не подумают: «Вау, это программное обеспечение сделано», они подумают, что «разработчики должны его сбросить». Держите своих разработчиков работать над этим, даже если это означает, что они стоят вам денег.
- Коммуникации. Вы должны убедиться, что ваше сообщество может общаться.Они должны иметь возможность сообщать об ошибках, обсуждать обходные пути и публиковать исправления.Без обратной связи бессмысленно открывать проект.
- Доступность. Необходимо сделать ваш код простым для получения, даже если это означает разозлить юристов.Вы должны убедиться, что ваш проект легко загрузить и использовать.Вы не хотите, чтобы пользователю для этого приходилось прыгать через 18 экранов и подписывать контракт.Вы должны делать вещи простыми и понятными
Другие советы
Я думаю, что самым важным фактором является количество пользователей, использующих ваш проект.В противном случае это просто хорошо написанная, полезная и хорошо документированная куча вещей, которые сидят на сервере и не делают особо многого...
Чтобы привлечь участников, вам сначала нужны пользователи, а затем некоторая незавершенность.Вам нужно запустить «это круто, но я действительно хотел бы, чтобы это было это или было другое». Если вам не хватает очевидной функции, очень вероятно, что пользователь станет участником, чтобы добавить ее.
Самое главное, чтобы программа была хорошей.Если это нехорошо, никто не будет этим пользоваться.Вы не можете надеяться, что ситуация с курицей и яйцом изменится и что люди будут воспринимать ее как нечто само собой разумеющееся, пока она не станет хорошей.
Конечно, «хороший» просто означает «лучше, чем любой другой практический вариант для значительного числа людей», это не означает, что он строго лучший, а лишь то, что у него есть некоторые особенности, которые для многих людей делают его лучше, чем другие варианты.Иногда программа имеет нет эквивалента где-либо еще, и в этом случае почти нет никаких требований в этом отношении.
Когда программа хороша, люди будут ее использовать.Очевидно, что у нее должен быть рынок среди пользователей — хорошая программа, которая делает то, что никому не нужно, на самом деле не очень хороша, независимо от того, насколько хорошо она спроектирована.Можно было бы высказать точку зрения по поводу маркетинга, но по-настоящему хорошие продукты до определенного момента имеют тенденцию продаваться сами по себе.Гораздо сложнее продвигать что-то плохое, поэтому очевидно, что первым приоритетом должен быть сам продукт, а не его продвижение.
Тогда реальный вопрос: как сделать это хорошо?И ответом на это является преданная своему делу, квалифицированная команда разработчиков.Один человек редко может создать хороший продукт самостоятельно;даже если они намного лучше других разработчиков, множественность точек зрения оказывает невероятно полезное влияние на проект.Вот почему так полезно иметь корпоративных спонсоров — это позволяет другим разработчикам (из корпорации) задуматься над проблемой и высказать свое собственное мнение.Это особенно полезно в том случае, если разработка программы требует значительного опыта, которого обычно нет в сообществе.
Конечно, я говорю это все из опыта.Я один из основных разработчиков x264 (на данный момент самый активный), одного из самых популярных видеокодеров.У нас есть два основных разработчика, несколько второстепенных разработчиков в сообществе, которые вносят исправления, а также корпоративное спонсорство со стороны Joost (Габриэль Бувинь, который поддерживает алгоритмы контроля скорости) и Avail Media (на которых я иногда работаю по контракту и которые в настоящее время нанимают программистов по контракту). для добавления поддержки чересстрочной развертки MBAFF), а также некоторых других, которые появляются время от времени.
Не один хороший разработчик делает проект, это делают многие хорошие разработчики.И конечным результатом этого является программа, которая кодирует видео быстрее и с гораздо лучшим качеством, чем большинство коммерческих конкурентов, аппаратных и программных средств, даже тех, у кого совершенно огромные бюджеты на разработку.
При рассмотрении этих вопросов вам может быть интересно ознакомиться с онлайн-версией курс по открытому исходному коду в Калифорнийском университете в Беркли, под названием «Разработка и распространение цифровой информации с открытым исходным кодом»:Технические, экономические, социальные и юридические перспективы.Его преподают Митч Капур (основатель Lotus) и Паула Самуэльсон, профессор юридического факультета.Мне пришлось долго ездить на работу, и в прошлом году я записал аудиозапись курса на свой iPod – они много говорят о том, что работает, а что нет и почему, с очень широкой (хотя и явно академической) точки зрения.
На эту тему написаны книги.На самом деле, вы можете найти бесплатную книгу здесь: производство программного обеспечения с открытым исходным кодом
На самом деле, я думаю, что ответ заключается в том, «как вы управляете проектом».
Да, все ваши примеры имеют значение, но ключевым моментом является то, как управляется взаимодействие между разработчиками, как обрабатываются/принимаются исправления и т. д., кто «ответственный» и как они справляются с этой ответственностью, и так далее, и тому подобное.
Сравните и сопоставьте (историю нетрудно проследить!) управление разработкой Class::DBI и DBIx::Class в Perl.
Сегодня вечером я читал отличный пост об аспекте удобства использования успешных и неудачных проектов с открытым исходным кодом.
Отрывок:
Много трафика было потрачено впустую на споры об отсутствии удобства использования программного обеспечения с открытым исходным кодом/бесплатного программного обеспечения (далее «OSS»).Дебаты продолжаются в данный момент в блогах, форумах и ветках комментариев Slashdot.Некоторые люди говорят, что плохое удобство использования присуще всему миру OSS, в то время как другие говорят, что удобство использования OSS великолепно, но настоящая проблема заключается в ограниченности пользователей, которые ожидают, что каждая программа будет клонировать Microsoft.Некоторые люди утверждают, что проблемы пользовательского интерфейса — это временная проблема роста, в то время как другие говорят, что модель разработки OSS систематически приводит к плохому пользовательскому интерфейсу.Некоторые даже утверждают, что GPL косвенно вознаграждает программы, которые сложно использовать!(Кстати, я не согласен.)
Просто откройте исходный код.Скорее всего, вносить вклад пока никто не начнет.Но, по крайней мере, вы можете написать в пресс-релизах, что ваш продукт имеет лицензию GPL или что-то в этом роде.
Первый шаг заключается в том, что люди начинают его использовать...
И, возможно, тогда, когда пользователи освоятся, они начнут вносить свой вклад.
До сих пор все ответы были хорошими, но чего-то не хватает, и это хороший надзор.Ничто не убивает проект с открытым исходным кодом быстрее, чем отсутствие какого-либо управления проектом.Не столько указывать людям, что им делать, сколько просто добавить некоторую структуру и задачи для разработчиков, которых вы надеетесь привлечь.
Неорганизованные проекты быстро разваливаются.Это не птица, которую можно просто отпустить и смотреть, как она улетает.
