Выпуск программного обеспечения с открытым исходным кодом слишком рано [закрыто]

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

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

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

Это необоснованный страх?

Напротив, я считаю, что вы должны выпустить программное обеспечение с открытым исходным кодом как можно скорее. Для этого нет «слишком рано» (но оно должно компилироваться).

^{Или, по крайней мере, публиковать исходный код очень рано и постоянно (например, частыми нажатиями на github ), не делая официальных релизов.}

Тем не менее, очень важно пометить его как альфа или бета стадию и, если возможно, сказать (например, в файле READMEили в TODOфайле, в каком-то блоге и т. Д.), Что отсутствует, не проверено или находится в плохом состоянии. Вы также должны использовать номер версии для передачи такой информации.

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

^{Следовательно, вы должны сделать свою повседневную работу видимой на бесплатном программном обеспечении! Внешние участники будут разозлены, если их патч не будет работать или является копией вашего недавнего исходного кода программного обеспечения.}

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

TL; DR:

Выпуск рано. Выпуск Часто.

Личный анекдот:

Я был действительно взволнован проектом, над которым я работал. Мол, очень взволнован. Я не мог спать по ночам взволнован. Итак, я подтолкнул моего соавтора к выпуску версии 1.0 быстрее, чем он хотел.

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

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

Это могло легко пойти и другим путем, хотя. Мы могли бы проигнорировать эти сообщения об ошибках. Или мы могли бы не отреагировать быстро. Это могла бы быть другая история, если бы нам потребовалось 3 месяца, чтобы выпустить v1.1 вместо нескольких недель.

Это так же, как с закрытым исходным кодом. Общение важно.

Сообщите пользователям, каково состояние программного обеспечения и почему оно доступно для загрузки.

Программное обеспечение всегда приводит к проблемам клиентов, независимо от того, полностью ли оно протестировано или нет. Большинство клиентов принимают этот факт, а некоторые - нет. Но если программное обеспечение приведет к большему количеству проблем, чем можно было бы разумно ожидать, существует моральное обязательство информировать клиента о риске, который он принимает. Информация должна быть как в краткой форме (метки «Alpha / Beta / EarlyAccess») *, так и в деталях: список известных проблем, обходных путей и особых соображений, например, если существует вероятность повреждения данных.

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

Там нет моральной ответственности вообще. Никто не будет вынужден использовать ваше недоделанное программное обеспечение.

Единственное, о чем нужно беспокоиться, это ваш авторитет.

Мой опыт показывает, что нужно достичь баланса.

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

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

• Скелетные деревья с определениями интерфейса, но без кода.
• Код, который не компилируется ни для кого, кроме разработчика.
• Нет инструкций по сборке / запуску программы.
• Нет документации о том, какие аспекты могут работать.
• Непонятное описание того, что программа даже делает или будет делать.
• Отсутствие какой-либо демонстрации полезности.

В заключение я думаю о таких вещах, как:

• Компилятор / интерпретатор, который не может даже скомпилировать / запустить программу типа hello-world.
• Эмулятор, который по крайней мере не может запустить какую-либо программу-пример или иным образом продемонстрировать, что он что-то делает.
• Инструмент обработки изображений, который ничего не может сделать, кроме как загрузить и сохранить неизмененное изображение.
• Игра только с титульным экраном.

Такого рода проблемы создают «испорченное» изображение, которое может быть трудно поколебать, если вы не очень уверены в отсутствии рабочего кода с самого начала.

Наконец, сделайте ваши номера версий понятными. Не называйте ваш проект «1.0», пока он не сделает то, что пользователи ожидают от него без сбоев. Мне всегда везло с использованием номеров версий около 0,5 для первоначального публичного релиза и оттуда, но я также видел такие вещи, как «0,1» или «0,10», которые имеют смысл.

Существует один случай, когда выпуск свободного программного обеспечения может иметь негативные последствия. Некоторые спецификации лицензируются для общественности при условии, что все реализации, распространяемые для общественности, должны полностью соответствовать спецификации при первой публикации. Издатель юридически запрещает вам распространять текущую реализацию спецификации. Без специальной согласованной лицензии от издателя спецификации вы должны предоставить ее никому, пока она не пройдет все тесты. Это навязывает «модель собора» (как назвал ее Эрик С. Рэймонд) в реализации спецификации.

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

В статье « 4 изящных подробности о« открытом исходном коде » Microsoft .NET » Лю Цихао и Сиаран О'Риордан упоминается возможность интерпретации обещания Microsoft о патентах для библиотек .NET и компонентов времени выполнения для исключения неполных реализаций CLR аналогичным образом. , Но опять же, это не относится к приложениям, которые запускаются в CLR.