Quali fattori determinano il successo di un progetto open source?[Chiuso]

Question

Abbiamo una serie di applicazioni e librerie closed source, per le quali pensiamo che avrebbe senso aprire il codice sorgente.

Ciò che ci ha bloccato, finora, è lo sforzo necessario per ripulire il codice base e documentare il sorgente prima dell'apertura.

Vogliamo rendere disponibile la fonte solo se abbiamo una ragionevole possibilità che i progetti abbiano successo, ovvero seavere contributori.Siamo convinti che il codice sarebbe interessante per un'ampia base di sviluppatori.

Quali fattori, escludendo "l'interesse" e l'"utilità" del progetto, determinare il successo di un progetto open source?

Esempi:

• Pulizia del codice
• Disponibilità di commenti sul codice sorgente
• API completamente o parzialmente documentate
• Scelta della licenza (GPL vs.LGPL vs.BSD, ecc...)
• Scelta dell'archivio pubblico
• Investimento in un sito web pubblico

Answer 1

Ci sono diverse cose che dominano il successo del codice.Tutti questi devono essere raggiunti per avere la minima possibilità di adozione.

• Mercato: deve esserci un mercato per il tuo progetto open source.Se il tuo progetto è uno spremiagrumi nello spazio, dubito che avrai molto successo.Devi assicurarti che il tuo progetto ottenga un'ampia adozione tra utenti e sviluppatori.Ha il doppio delle probabilità di successo se riesci a convincere anche altre aziende ad adottarlo.
• Documentazione: come hai accennato in precedenza, la documentazione è fondamentale.Tra questa documentazione sono presenti codice commentato, decisioni sull'architettura e note API.Anche se la tua documentazione contiene bug o bug relativi al tuo software, va bene.Ricorda, la trasparenza è fondamentale.
• Libertà - Devi consentire al tuo codice di essere "libero" - con questo intendo libero come nella parola, non come nella birra.Se hai la sensazione che il tuo mercato sia una libreria per altre società, una licenza BSD è ottimale.Se il tuo software verrà eseguito su desktop, la GPL è la tua scelta.
• Trasparenza: è necessario scrivere software in un ambiente trasparente.Una volta diventato open source non ci sono segreti nascosti.Devi spiegare tutto quello che fai e cosa stai facendo.Questo farà incazzare gli sviluppatori come nessun altro
• Comunità di sviluppatori: è necessaria una forte comunità di sviluppatori.Questo deve essere esistente.Solo circa il 5% degli utenti contribuisce al progetto.Se qualcuno nota che non ci sono state versioni da un anno, non penserà "wow, questo software è fatto", penserà che "gli sviluppatori devono essere scaricati". Mantieni i tuoi sviluppatori a lavorare su di esso, anche se ciò significa che ti stanno costando denaro.
• Comunicazioni: devi assicurarti che la tua comunità sia in grado di comunicare.Devono essere in grado di segnalare bug, discutere soluzioni alternative e pubblicare patch.Senza feedback, è inutile rendere open source il progetto
• Disponibilità: è necessario rendere il codice facile da ottenere, anche se ciò significa far incazzare gli avvocati.Devi assicurarti che il tuo progetto sia facile da scaricare e utilizzare.Non vuoi che l'utente debba saltare attraverso 18 schermate fastidiose e firmare un contratto per farlo.Devi rendere le cose semplici e pulite

Answer 2

Penso che il fattore più importante sia il numero di utenti che utilizzano il tuo progetto.Altrimenti è solo un mucchio di cose davvero ben scritte, utili e ben documentate che si trovano su un server che non fa molto...

Answer 3

Per acquisire collaboratori, servono prima gli utenti, poi serve un po’ di incompletezza.Devi innescare il "questo è bello, ma vorrei davvero che avesse questo o fosse diverso in questo modo". Se ti manca una funzionalità ovvia, è estremamente probabile che un utente diventerà un contributo per aggiungerlo.

Answer 4

La cosa più importante è che il programma sia buono.Se non va bene, nessuno lo userà.Non si può sperare che il sistema dell’uovo e della gallina si inverta e che le persone lo diano per scontato finché non diventa buono.

Naturalmente, "buono" significa semplicemente "migliore di qualsiasi altra opzione pratica per un numero significativo di persone", non significa che sia strettamente il migliore, ma solo che ha alcune caratteristiche che lo rendono, per molte persone, migliore di altre opzioni.A volte il programma ha nessun equivalente da nessun'altra parte, nel qual caso non c'è quasi alcun requisito al riguardo.

Quando un programma è buono, le persone lo useranno.Ovviamente, deve avere un mercato tra gli utenti: un buon programma che fa qualcosa che nessuno vuole non è veramente buono, non importa quanto bene sia progettato.Si potrebbe fare un punto sul marketing, ma i prodotti veramente buoni, fino a un certo punto, hanno la tendenza a commercializzarsi da soli.È molto più difficile promuovere qualcosa che non è buono, quindi chiaramente la prima priorità dovrebbe essere il prodotto stesso, non la promozione del prodotto.

La vera domanda quindi è: come farlo funzionare bene?E la risposta a questa domanda è un team di sviluppo dedicato e competente.Una persona raramente riesce a creare un buon prodotto da sola;anche se sono molto migliori degli altri sviluppatori, più prospettive hanno un effetto incredibilmente utile sul progetto.Questo è il motivo per cui avere sponsor aziendali è così utile: mette le menti degli altri sviluppatori (dell'azienda) sul problema per esprimere la propria opinione.Ciò è particolarmente utile nel caso in cui lo sviluppo del programma richieda competenze significative che non sono comunemente disponibili nella comunità.

Ovviamente dico tutto per esperienza.Sono uno dei principali sviluppatori di x264 (attualmente il più attivo), uno dei codificatori video più popolari.Abbiamo due sviluppatori principali, vari sviluppatori minori nella comunità che contribuiscono con le patch e la sponsorizzazione aziendale di Joost (Gabriel Bouvigne, che mantiene gli algoritmi di controllo della velocità), di Avail Media (per cui lavoro a volte a contratto e che attualmente sta assumendo programmatori a contratto per aggiungere il supporto per l'interlacciamento MBAFF) e da alcuni altri che compaiono di tanto in tanto.

Un buon sviluppatore non realizza un progetto: molti buoni sviluppatori lo fanno.E il risultato finale è un programma che codifica video più velocemente e con una qualità di gran lunga migliore rispetto alla maggior parte dei concorrenti commerciali, hardware o software, anche quelli con budget di sviluppo assolutamente enormi.

Answer 5

Osservando questi problemi potresti essere interessato a controllare la versione online di a corso sull'open source alla UC Berkeley, denominato Sviluppo e distribuzione Open Source di informazioni digitali:Prospettive tecniche, economiche, sociali e giuridiche.È co-insegnato da Mitch Kapur (fondatore di Lotus) e Paula Samuelson, professoressa di giurisprudenza.Faccio un lungo tragitto e l’anno scorso ho messo l’audio del corso sul mio iPod: parlano molto di cosa funziona, cosa no e perché, da una prospettiva molto ampia (anche se ovviamente accademica).

Answer 6

Sono stati scritti libri sull’argomento.Infatti, puoi trovare un libro gratuito qui: produrre software open source

Answer 7

In realtà, penso che la risposta sia "come gestisci il progetto".

Tutti i tuoi esempi contano, sì, ma le cose fondamentali sono come viene gestita l'interazione tra gli sviluppatori, come vengono gestite/accettate le patch ecc., chi è "responsabile" e come gestiscono tale responsabilità, e così via.

Confronta e confronta (la storia non è difficile da rintracciare!) la gestione dello sviluppo di Class::DBI e DBIx::Class in Perl.

Answer 8

Stavo proprio leggendo stasera un eccellente post sull'aspetto dell'usabilità dei progetti open source di successo rispetto a quelli infruttuosi.

Estratto:

Molta larghezza di banda è stata sprecata discutendo sulla mancanza di usabilità del software open source/software libero (d'ora in poi “OSS”).Il dibattito continua in questo momento su blog, forum e thread di commenti su Slashdot.Alcuni dicono che la cattiva usabilità è endemica nell'intero mondo OSS, mentre altri dicono che l'usabilità dell'OSS è ottima ma che il vero problema sono gli utenti dalla mentalità chiusa che si aspettano che ogni programma cloni Microsoft.Alcune persone sostengono che i problemi dell'interfaccia utente siano problemi temporanei, mentre altri affermano che il modello di sviluppo OSS produce sistematicamente un'interfaccia utente scadente.Alcuni sostengono addirittura che la GPL premi indirettamente il software difficile da usare!(Per la cronaca, non sono d'accordo.)

http://humanized.com/weblog/2007/10/05/make_oss_humane/

Answer 9

Basta renderlo open source.Molto probabilmente nessuno inizierà ancora a contribuire.Ma almeno puoi scrivere sui comunicati stampa che il tuo prodotto è GPL o altro.

Il primo passo è che le persone inizino a usarlo...
E forse poi, una volta che gli utenti si saranno sentiti a proprio agio, inizieranno a contribuire.

Answer 10

Finora le risposte di tutti sono state buone, ma manca una cosa ed è una buona supervisione.Niente uccide un progetto open source più velocemente che non avere una sorta di gestione del progetto.Non dire alla gente cosa fare, quanto aggiungere semplicemente un po' di struttura e compiti per gli sviluppatori che speri di attrarre.

I progetti disorganizzati vanno in pezzi rapidamente.Non è un uccello che lasci andare e lo guardi volare via.