Rilascio del software open source troppo presto [chiuso]

Qual è la responsabilità morale di rilasciare software open source troppo presto? Ad esempio, un prodotto quasi completo che non è stato completamente testato.

Qual è l'aspettativa del programmatore? Attendere fino a quando non è completamente testato o rilasciare su open source e quindi continuare ulteriori sviluppi, test e progressi?

Il timore è che il software sia open source e potrebbe potenzialmente causare problemi ai consumatori.

È una paura infondata?

Credo al contrario che dovresti rilasciare un software open source il prima possibile. Non c'è "troppo presto" per quello (ma dovrebbe compilare).

^{O almeno pubblicare il codice sorgente molto presto e continuamente (ad es. Con frequenti spinte su github ), senza rilasciare formali .}

Tuttavia, è molto importante contrassegnarlo come fase alfa o beta e, se possibile, dire (ad esempio in un file READMEo TODO, su alcuni blog, ecc ...) cosa manca, non testato o in cattiva forma. È inoltre necessario utilizzare il numero di versione per trasmettere tali informazioni.

Con il software libero , il meglio che dovrebbe accadere è che qualcuno dia un'occhiata al codice sorgente e ti proponga una piccola patch per migliorarlo. Ecco perché rendi il tuo software gratuito!

^{Quindi, devi rendere visibile il tuo lavoro quotidiano sul tuo software gratuito! I collaboratori esterni sarebbero incazzati se la loro patch non funzionasse o è un duplicato del tuo recente codice sorgente del software.}

Ciò di cui dovresti aver paura è che nessuno si interessi al tuo software (e contribuisca ad esso). Attrarre l'interesse esterno verso un software libero (in particolare, attirare collaboratori esterni) è un lungo viaggio.

TL; DR:

Rilascio anticipato. Rilascio spesso.

Aneddoto personale:

Ero davvero entusiasta del progetto a cui stavo lavorando. Mi piace davvero. Non riuscivo a dormire la notte eccitato. Quindi, ho spinto il mio co-sviluppatore a rilasciare v1.0 più velocemente di quanto volesse.

È stato terribile. Niente ha funzionato come doveva. Ci sono stati bug ad ogni turno, ma li abbiamo registrati e risolti. Abbiamo anche avuto alcuni dei primi ad adottare bug che potremmo non aver trovato. Una o due settimane dopo abbiamo rilasciato una nuova versione che risolveva molti problemi e poi è tornata alla creazione di nuove funzionalità.

Rilasciare presto è stata la cosa migliore che avremmo potuto fare. Mette il nostro prodotto di fronte a utenti reali. Facendo questo bug esposti potremmo aver trovato o meno e reso migliore il nostro progetto. Inoltre ha fatto sapere ai primi utenti che siamo seri riguardo a questo progetto. Ci saranno più rilasci e sviluppo attivo.

Tuttavia, avrebbe potuto facilmente andare nell'altra direzione. Avremmo potuto ignorare quelle segnalazioni di bug. O non avremmo potuto reagire rapidamente. Potrebbe essere stata una storia diversa se ci volessero 3 mesi per rilasciare v1.1 invece di alcune settimane.

È lo stesso del software a sorgente chiuso. La comunicazione è importante

Informare gli utenti su quale sia lo stato del software e perché è disponibile per il download.

Il software porterà sempre a problemi dei clienti, indipendentemente dal fatto che sia completamente testato o meno. La maggior parte dei clienti accetta questo fatto e alcuni clienti non lo fanno mai. Ma se il software porterà a più problemi di quanto ci si possa ragionevolmente aspettare, c'è un obbligo morale di informare il cliente del rischio che stanno correndo. Le informazioni dovrebbero essere sia in forma abbreviata (etichette "Alpha / Beta / EarlyAccess") * sia in dettaglio: un elenco di problemi noti, soluzioni alternative e considerazioni speciali, ad esempio se è probabile che i dati possano essere danneggiati.

* Essere consapevoli del fatto che gli utenti sono stati addestrati da alcune grandi società di software a pensare a "Beta" come uno stato in cui il software è piuttosto solido, quindi dire all'utente che il software è "Beta" spesso non è sufficiente informazione.

Non esiste alcuna responsabilità morale. Nessuno è costretto a usare il tuo software cotto a metà.

L'unica cosa di cui preoccuparsi sarebbe la tua credibilità.

La mia esperienza è che c'è un equilibrio da raggiungere.

In questo momento, sto lavorando (nel senso di rispondere alle domande e fornire suggerimenti di sviluppo, senza vedere alcun codice) con uno sviluppatore che sta producendo quello che sembra essere un progetto FOSS molto eccitante che utilizza il codice che ho scritto. Il rilascio pubblico è stato ripetutamente ritardato dalla realizzazione di modifiche alla progettazione che renderanno il progetto molto migliore a lungo termine, ma che richiedono significative riscritture di codice che è già stato scritto e che già "funzionava". La mia opinione è che, se fosse stata rilasciata una versione funzionante ma imperfetta non appena ci fosse stato qualcosa da mostrare, le idee per i cambiamenti (e le patch effettive) sarebbero potute venire dalla più ampia comunità interessata a questo progetto e accelerarla invece di avere i problemi affiorano lentamente, uno alla volta, mentre lo sviluppatore ci pensa e chiede feedback sul design da me stesso e da altri membri interessati della comunità. Quindi, da questo punto di vista, sono un sostenitore di "rilascio anticipato, rilascio frequente".

D'altra parte, rilasci di bassa qualità possono far sembrare un nuovo progetto prima che decida di decollare. Alcune insidie ​​che ho visto includono:

• Alberi scheletro con definizioni di interfaccia ma nessun codice.
• Codice che non viene compilato correttamente per nessuno, tranne lo sviluppatore.
• Nessuna istruzione su come compilare / eseguire il programma.
• Nessuna documentazione su quali aspetti ci si può aspettare che funzionino.
• Descrizione poco chiara di ciò che il programma fa o farà.
• Mancanza di qualsiasi dimostrazione di utilità.

Per l'ultimo punto, sto pensando a cose come:

• Compilatore / interprete che non può nemmeno compilare / eseguire un programma di tipo ciao-mondo.
• Emulatore che non può almeno eseguire un programma di esempio di qualche tipo o dimostrare in altro modo che sta facendo qualcosa.
• Strumento di elaborazione delle immagini che non può fare altro che caricare e salvare nuovamente l'immagine non modificata.
• Gioco con nient'altro che una schermata del titolo.

Questi tipi di problemi si prestano a un'immagine "vaporware" che può essere difficile da scuotere a meno che tu non sia molto aperto sulla mancanza di codice funzionante all'inizio.

Infine, fai in modo che i tuoi numeri di versione abbiano un senso. Non chiamare il tuo progetto "1.0" fino a quando non fa ciò che gli utenti si aspettano che faccia senza crash. Ho sempre avuto fortuna con l'uso dei numeri di versione intorno a "0,5" per la versione pubblica iniziale e andando da lì, ma ho anche visto cose come "0.1" o "0.10" che hanno senso.

C'è un caso in cui il rilascio di software libero può avere conseguenze negative. Alcune specifiche sono concesse in licenza al pubblico a condizione che tutte le implementazioni distribuite al pubblico siano completamente conformi alle specifiche alla prima pubblicazione. L'editore ti proibisce legalmente di distribuire un'implementazione work-in-progress della specifica. Senza una specifica licenza negoziata dall'editore della specifica, è necessario condividerlo con nessuno fino a quando non ha superato tutti i test. Ciò impone un "modello di cattedrale" (come lo chiamava Eric S. Raymond) sulle implementazioni della specifica.

Una specifica in virtù di tale licenza è la specifica del linguaggio Java . Questa restrizione si applica agli sviluppatori di macchine virtuali compatibili con la JVM, ma fortunatamente non agli sviluppatori di applicazioni eseguite in una JVM.

L'articolo " 4 Shifty Details About" Open Source ".NET di Microsoft " di Liu Qihao e Ciaran O'Riordan menziona la possibilità di interpretare la promessa di brevetto Microsoft per le librerie .NET e i componenti di runtime per escludere implementazioni incomplete del CLR in modo simile . Ma ancora una volta, questo non si applica alle applicazioni eseguite nel CLR.