Qual è la responsabilità morale di rilasciare il software open source troppo presto? Ad esempio, un prodotto quasi completo che non è stato completamente testato.
Quali sono le aspettative del programmatore? Attendi fino a quando non è stato completamente testato o rilasciato per l'open source, quindi prosegui lo sviluppo, i test e gli avanzamenti futuri?
Il timore è che il software sia open source e potrebbe potenzialmente portare a problemi per i consumatori.
È una paura infondata?
Credo invece che dovresti rilasciare un software open source il prima possibile. Non c'è "troppo presto" per quello (ma dovrebbe essere compilato).
O almeno pubblichi il codice sorgente molto presto e continuamente (ad esempio con frequenti spinte su github ), senza rendere versioni formali
Tuttavia, è molto importante contrassegnarlo come alpha o beta stage e, se possibile, dire (ad esempio in un README o TODO file, e in alcuni blog, ecc ...) cosa manca, non testato, o in cattive condizioni. Dovresti anche utilizzare il numero di versione per trasmettere tali informazioni.
Con il software gratuito , il meglio che dovrebbe succedere è che qualcuno guardi il codice sorgente e ti proponga una piccola patch migliorandolo Ecco perché rendi il tuo software gratuito!
Quindi, è necessario rendere visibile il tuo lavoro quotidiano sul tuo software gratuito! I contributori esterni sarebbero incazzati se la loro patch non funzionasse, o fosse un duplicato del tuo recente codice sorgente del software.
Ciò di cui dovresti aver paura è che nessuno si interessi al tuo software (e contribuisca a farlo). Attrarre l'interesse esterno per un software libero (in particolare, attrarre collaboratori esterni) è un lungo viaggio.
TL; DR:
Rilascia in anticipo. Rilascio spesso.
Aneddoto personale:
Ero davvero entusiasta del progetto a cui stavo lavorando. Mi piace, davvero eccitato. Non potevo dormire di notte eccitato. Così, ho spinto il mio co-dev a rilasciare v1.0 più velocemente di quanto avrebbe voluto.
È stato terribile. Niente ha funzionato come doveva. C'erano bug ad ogni turno, ma li abbiamo registrati e risolti. Abbiamo persino avuto alcuni utenti che hanno adottato bug che potremmo non aver trovato. Una o due settimane dopo abbiamo rilasciato una nuova versione che affrontava molti problemi e poi tornava a creare nuove funzionalità.
Il rilascio anticipato era la cosa migliore che avremmo potuto fare. Mette il nostro prodotto di fronte a utenti reali. Facendo questo bug esposto potremmo o non aver trovato e reso migliore il nostro progetto. Permette anche a quei primi utenti di sapere che siamo seri su questo progetto. Ci saranno più versioni e sviluppo attivo.
Avrebbe potuto facilmente andare anche nell'altro modo. Potremmo aver ignorato quelle segnalazioni di bug. Oppure non avremmo potuto reagire rapidamente. Potrebbe essere stata una storia diversa se ci fossero voluti 3 mesi per rilasciare v1.1 invece di poche settimane.
È lo stesso del software closed source. La comunicazione è importante.
Informa gli utenti qual è 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 quanti potrebbero essere ragionevolmente prevedibili, c'è un obbligo morale di informare il cliente del rischio che sta assumendo. Le informazioni dovrebbero essere sia in forma abbreviata (etichette "Alpha / Beta / EarlyAccess"), sia nei dettagli: un elenco di problemi noti, soluzioni alternative e considerazioni speciali, ad es. se è probabile che i dati possano essere danneggiati.
* Sappi che gli utenti sono stati addestrati da alcune grandi società di software a pensare a "Beta" come a uno stato in cui il software è piuttosto solido, quindi dire all'utente che il software è "Beta" spesso non è sufficiente.
Non c'è alcuna responsabilità morale. Nessuno è costretto a usare il tuo software mezzo cotto.
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. La versione pubblica è stata ripetutamente ritardata dalle realizzazioni di modifiche del design che renderanno il progetto molto migliore a lungo termine, ma che richiedono riscritture significative del codice che è già stato scritto e che stava già "funzionando". Il mio punto di vista è che, una volta realizzata una versione funzionante ma imperfetta non appena c'era qualcosa da mostrare, le idee per i cambiamenti (e le patch attuali) potevano provenire dalla più ampia comunità interessata a questo progetto, che avrebbe accelerato piuttosto che avere i problemi emergono lentamente, uno alla volta, come lo sviluppatore pensa a loro e chiede il feedback del design da me stesso e da altri membri interessati della comunità. Quindi, da questo punto di vista, sono un sostenitore del "rilascio anticipato, rilascio frequente".
D'altra parte, rilasci di bassa qualità possono far sembrare un nuovo progetto un brutto aspetto prima ancora di decollare. Alcuni trabocchetti che ho visto includono:
Per l'ultimo punto, sto pensando a cose come:
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 di lavoro per cominciare.
Infine, fai in modo che i tuoi numeri di versione abbiano un senso. Non chiamare il tuo progetto "1.0" finché non fa ciò che gli utenti si aspettano che faccia senza arresti anomali. Ho sempre avuto fortuna nell'usare numeri di versione intorno a "0.5" per la versione pubblica iniziale e andare 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 conformi alla specifica completamente al momento della prima pubblicazione. L'editore vieta legalmente di distribuire un'implementazione work-in-progress delle specifiche. Senza una specifica licenza negoziata dall'editore della specifica, è necessario condividerlo con nessuno fino a quando non passa tutti i test. Ciò costringe un "modello di cattedrale" (come lo chiamava Eric S. Raymond) sulle implementazioni delle specifiche.
Una specifica 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 dettagli Shifty sull'open source di Microsoft". NET "di Liu Qihao & Ciaran O'Riordan cita la possibilità di interpretare la promessa di brevetto Microsoft per le librerie .NET e i componenti di runtime escludere implementazioni incomplete del CLR in modo simile. Ma ancora una volta, questo non si applica alle applicazioni eseguite nel CLR.
Leggi altre domande sui tag open-source