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

37

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

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

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

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

open-source

— Томас Стрингер
источник

10

Добавьте отказ от ответственности, если вы обеспокоены. :)

— Vaughan Hilts

18

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

— Davidmh

@ VaughanHilts Меня не беспокоит, что кто-то рассердится, проблема заключается только в стремлении улучшить распространение и потребление программного обеспечения. Это последнее, от чего я не хотел бы страдать из-за слишком нетерпеливого релиза.

— Томас Стрингер

@Davidmh: Это было бы моей главной заботой, "однажды сгорел, дважды стеснялся".

— Матье М.

8

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

— Восстановите Монику

56

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

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

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

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

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

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

— Василий Старынкевич
источник

33

TL; DR:

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

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

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

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

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

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

— Резиновая утка
источник

9

Похоже, ваша единственная большая ошибка - называть это «v1.0». Обычно пользователи ожидают, что для обозначения «готового» продукта в том смысле, что его можно использовать по назначению, без явных ошибок и т. Д. «Выпуск рано» - это хорошо, но пользователи должны быть проинформированы, что они морские свинки.

— R ..

3

Да. Я бы согласился с этим задним числом. Честно говоря, я думал, что тщательно проверил это. Я думал, что это было 1,0 в то время @R ... я был не прав.

— RubberDuck

12

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

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

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

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

— Питер
источник

3

Должны ли мы сделать вывод, что «бета» не должна быть достаточно твердой? Я предполагаю, что «крупные софтверные компании» называют это «бета», когда он собирается быть готовым к производству, чтобы сопоставить программное обеспечение с реальными данными. Может быть, назвать это прототипом ?

— Пьер Арло

2

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

— Питер

3

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

— RubberDuck

2

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

— el.pescado

3

@ SteveJessop до того, как игровая индустрия изменила то, что мы подразумевали под «бета», я бы с вами согласился. =)

— RubberDuck

7

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

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

— как зовут
источник

2

без объяснения этот ответ может стать бесполезным в случае, если кто-то постит противоположное мнение. Например, если кто-то публикует претензию типа «Есть моральная ответственность. У кого-то может возникнуть соблазн использовать ваше недоделанное программное обеспечение. Ваш авторитет не был бы единственным, о чем нужно беспокоиться». Как этот ответ поможет читателю выбрать два противоположных мнения? Попробуйте отредактировать его в лучшую форму, чтобы соответствовать рекомендациям « Как ответить» .

— комнат

6

@gnat: Это неправда, что этот ответ без объяснения - объяснение - самое следующее предложение: «Никого не принуждают использовать ваше недоделанное программное обеспечение». Это краткое объяснение, да, но оно все еще является ПРИЧИНОЙ для высказывания «нет никакой моральной ответственности»

— slebetman

@gnat: то же самое можно сказать о большинстве ответов. «Я не верю, что вы должны освободить […] Не очень важно пометить его […]». Ожидаете ли вы больше внешних источников для этого ответа?

— Пьер Арло

2

Там с хорошим мнением и с плохим мнением. Я согласен с вами, но было бы приятно, если бы вы подкрепили это более убедительным аргументом.

— RubberDuck

6

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

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

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

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

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

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

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

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

— Р..
источник

1

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

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

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

— Дамиан Йеррик
источник

2

Это важно только в том случае, если вы хотите создать реализацию JRE / JDK, а не какие-либо Java-программы, которые на нем работают, AFAIK.

— Sjas

@sjas Вы пытаетесь подразумевать, что JLS - единственная спецификация, с которой вы, вероятно, столкнетесь, с этим ограничением «завершить или оставить это при себе»?

— Дамиан Йеррик

Вы пытаетесь подразумевать, что я намекаю на это. ;)

— sjas

@sjas Спасибо. Есть ли другой способ сделать этот ответ полезным?

— Дамиан Йеррик

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

— Sjas