Випуск програмного забезпечення з відкритим кодом занадто рано [закрито]

Яка моральна відповідальність випускати програмне забезпечення з відкритим кодом занадто рано? Наприклад, наближений до повного продукту, який не пройшов повну перевірку.

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

Побоювання полягає в тому, що програмне забезпечення є відкритим джерелом і може призвести до проблем для споживачів.

Це безпідставний страх?

Я вважаю навпаки, що ви повинні якомога швидше випустити програмне забезпечення з відкритим кодом. Для цього немає "занадто скоро" (але це слід скласти).

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

Однак, дуже важливо позначити це як альфа-або бета-стадію, і якщо можливо, сказати (наприклад, у файлі READMEабо TODOфайлі, а також у блозі тощо), що не вистачає, не перевірено, або в поганій формі. Ви також повинні використовувати номер версії для передачі такої інформації.

Що стосується безкоштовного програмного забезпечення , найкраще, що має трапитися, - це те, що хтось зазирне у вихідний код і запропонує вам невеликий виправлення, вдосконалюючи його. Ось чому ви робите своє програмне забезпечення безкоштовним!

^{Отже, вам потрібно зробити вашу щоденну роботу видимим на вашому вільному програмному забезпеченні! Зовнішні дописувачі будуть злісні, якщо їх патч не працюватиме або є копією вашого недавнього вихідного коду програмного забезпечення.}

Те, чого ви повинні боятися, нікого не цікавить ваше програмне забезпечення (і сприяти йому). Залучення зовнішнього інтересу до вільного програмного забезпечення (зокрема, залучення зовнішніх учасників) - довга дорога.

TL; DR:

Відпустіть достроково. Випускайте часто.

Особистий анекдот:

Я був дуже радий проекту, над яким працював. Мовляв, по-справжньому схвильований. Я не міг спати вночі схвильований. Отже, я підштовхнув свого співавтора до випуску v1.0 швидше, ніж він хотів.

Це було жахливо. Ніщо не працювало так, як слід було. Були помилки на кожному кроці, але ми реєстрували їх та виправляли. У нас навіть було декілька ранніх усиновлювачів, які подавали помилки, яких ми, можливо, не знайшли. Через тиждень-два ми випустили новий випуск, який вирішив багато питань, а потім повернувся до створення нових функцій.

Звільнитись достроково було найкращим, що ми могли зробити. Це ставить наш продукт перед реальними користувачами. Роблячи ці виявлені помилки, ми, можливо, не знайшли і покращили наш проект. Це також дає зрозуміти тим, хто рано приймає, що ми серйозно ставимося до цього проекту. Буде більше випусків та активного розвитку.

Це теж могло легко піти іншим шляхом. Ми могли ігнорувати ці повідомлення про помилки. Або ми не могли швидко відреагувати. Це може бути інша історія, якби нам знадобилося 3 місяці, щоб випустити v1.1 замість кількох тижнів.

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

Повідомте користувачів про стан програмного забезпечення та чому воно доступне для завантаження.

Програмне забезпечення завжди призведе до проблем із клієнтами, незалежно від того, повністю перевірено чи ні. Більшість клієнтів погоджуються з цим фактом, а деякі - ніколи. Але якщо програмне забезпечення призведе до більшої кількості проблем, ніж можна було б розумно очікувати, існує моральний обов'язок повідомити клієнта про ризик, який він несе. Інформація повинна бути як у короткій формі (мітки "Альфа / Бета / EarlyAccess") *, так і детально: Перелік відомих проблем, обхідних шляхів та особливі міркування, наприклад, якщо є ймовірність, що дані можуть бути пошкоджені.

* Майте на увазі, що деякі великі програмні компанії користувачі навчали думати про "бета-версію" як про стан, де програмне забезпечення досить міцне, тому говорити користувачеві, що програмне забезпечення є "бета-версією", часто не вистачає інформації.

Ніякої моральної відповідальності немає. Ніхто не змушений використовувати ваше напівфабрикатне програмне забезпечення.

Єдине, про що слід потурбувати, - це ваша довіра.

Мій досвід полягає в тому, що потрібно досягти балансу.

Зараз я працюю (в сенсі відповіді на запитання та надання пропозицій щодо розробки, не бачачи жодного коду) з розробником, який виробляє, як виглядає, дуже захоплюючий проект FOSS, який використовує написаний мною код. Публічний випуск неодноразово затримувався реалізацією змін дизайну, які дозволять зробити проект набагато кращим у довгостроковій перспективі, але які потребують значних перезаписів коду, який вже був написаний і який вже "працював". На мою думку, якщо робочий, але недосконалий реліз був зроблений, як тільки щось було показано, ідеї щодо змін (і фактичні виправлення) могли прийти від широкої спільноти, яка зацікавлена ​​в цьому проекті, пришвидшити його вперед, а не мати проблеми виникають повільно, поодинці, як розробник думає про них і просить відгуки про дизайн у мене та інших зацікавлених членів спільноти. Тож з цієї точки зору я дуже прихильник "звільнення достроково, звільняй часто".

З іншого боку, низькоякісні випуски можуть зробити новий проект поганим виглядом, перш ніж він навіть зійде з місця. Деякі підводні камені, які я бачив, включають:

• Дерево скелету з визначеннями інтерфейсу, але без коду.
• Код, який не вдало компілюється для когось, крім розробника.
• Немає інструкцій щодо створення / запуску програми.
• Жодна документація про те, які аспекти можна очікувати на роботу.
• Незрозумілий опис того, що програма навіть робить чи буде робити.
• Відсутність будь-якої демонстрації корисності.

Для останнього моменту я думаю про такі речі, як:

• Компілятор / перекладач, який навіть не може компілювати / запустити програму типу «привіт-світ».
• Емулятор, який не може принаймні запустити зразок якоїсь програми або іншим чином продемонструвати, що він щось робить.
• Інструмент обробки зображень, який не може нічого, крім завантаження та збереження немодифікованого зображення.
• Гра, окрім титульного екрана.

Такі проблеми надають образу "парового програмного забезпечення", який важко похитнути, якщо ви не дуже відкриті щодо відсутності робочого коду.

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

Є один випадок, коли випуск вільного програмного забезпечення може мати негативні наслідки. Деякі технічні характеристики ліцензуються для загального користування за умови, що всі реалізації, що розповсюджуються для загального користування, повинні повністю відповідати специфікації при першому опублікуванні. Видавець юридично забороняє вам розповсюджувати незавершене виконання специфікації. Без конкретної ліцензійної угоди від видавця специфікації ви повинні ділитися нею ні з ким, поки він не пройде всі тести. Це змушує "модель собору" (як називав Ерік С. Реймонд) щодо реалізації специфікації.

Одна специфікація за такою ліцензією - специфікація мови Java . Це обмеження стосується розробників віртуальних машин, сумісних з JVM, але, на щастя, не для розробників додатків, що працюють в JVM.

У статті " 4 Shifty Details про Microsoft" Open Source ".NET " від Liu Qihao & Ciaran O'Riordan згадується можливість інтерпретації патентної обіцянки Microsoft на .NET Бібліотеки та компоненти часу виконання аналогічним чином. . Але знову ж таки, це не стосується програм, що працюють у CLR.