In quale fase di un progetto Open Source dovresti invitare contributi della community? [chiuso]

Mi chiedevo come ottenere contributi per un nuovo prodotto open source che il mio team svilupperà. È incoraggiante per noi ottenere il maggior supporto possibile da parte della più ampia comunità, ma posso anche vederlo assorbire molto tempo assicurandoci che terze parti situate fuori dal nostro ufficio siano sulla buona strada per quanto riguarda la qualità del codice. Inoltre all'inizio del progetto è probabile che avremo molte discussioni informali all'interno del team principale per quanto riguarda la progettazione del sistema, i picchi, ecc. E il fatto di portarli online per consentire il coinvolgimento della comunità richiederà molto tempo e posso immaginare che discussione meno efficace.

C'è un lato più umano di ciò che probabilmente deve essere preso in considerazione: consentire il coinvolgimento della comunità nel processo di progettazione può anche avere i suoi vantaggi per quanto riguarda la proprietà percepita del progetto, e c'è sempre la possibilità che il coinvolgimento precoce possa raccogliere problemi che il nucleo la squadra non l'ha notato.

Quindi la domanda: in quale fase di un progetto Open Source dovresti invitare contributi dalla comunità?

Proprio all'inizio! Volete che la comunità senta di avere un vero interesse nel vostro progetto, altrimenti sentiranno di essere utilizzati come lavoro gratuito.

Tutte le comunicazioni dovrebbero avvenire su una mailing list o forum pubblici, ancora una volta questo migliora l'idea della comunità.

Puoi mitigare il problema "progetta per commissione" presentando una visione chiara nei tuoi post iniziali nella mailing list, ad es.

"Quindi stiamo guardando un modello di dominio per rappresentare il nostro negozio di animali domestici (secondo JIRA-4). Qualcuno ha riscontrato problemi importanti con questo modello?"

In termini di accettazione dei contributi fisici effettivi, è necessario iniziare accettando le patch ed eseguendo revisioni del codice pubblico su di esse. In questo modo i partecipanti possono già vedere pubblicamente a quale tipo di standard di codifica devono aderire. Assicurati che i tuoi commit siano disponibili anche in una mailing list di commit - devi essere tenuto agli stessi standard!

Vale anche la pena avere standard di progetto su un Wiki o alcuni documenti simili.

Leggi http://www.producingoss.org per maggiori dettagli su come eseguire un progetto open source di successo.

Questo è stato discusso a lungo nel Google IO talk Myth of the genious programmator , di Brian Fitzpatrick e Ben Collins-Sussman di Subversion. In breve hanno concluso che non dovrebbe essere così presto che non c'è ancora niente lì (es. "Vieni a vedere il mio fantastico progetto! Non c'è ancora molto qui ma sono in programma molte cose fantastiche!") O troppo tardi quindi tutte le decisioni sono già state prese (è difficile parlare di un progetto solista.)

Sono d'accordo con Martijn Verburg . Dovresti iniziare a sollecitare contributi fin dall'inizio. Ho scritto un po 'su questo prima.

Il riassunto di quel post è che il software è marcito. Se vuoi mantenerlo fresco, devi fare manutenzione. E più popolare diventa un progetto, più bug verranno trovati, più funzioni verranno aggiunte e più questa attività di manutenzione ti farà impazzire.

In realtà, questo è un problema molto comune. C'è un grande discorso di Fat chiamato What Is Open Source e Why Do I Feel So Guilty? In questo discorso (che consiglio vivamente di guardare) racconta la storia di uno dei suoi progetti OSS e come, nel tempo, si è ritrovato a passare gran parte del suo tempo libero a svolgere attività di triage e gestione dei biglietti. E parla di quanto sia stato dannoso. Il che è qualcosa con cui posso entrare completamente in empatia.

La soluzione, ovviamente, è quella di aggiungere persone al progetto in anticipo e spesso. Il tuo tempo è limitato e prezioso. Investilo nella crescita della tua base di collaboratori e il resto dei tuoi problemi inizia a prendersi cura di se stessi.

Come ho detto alla fine del mio post: "Cosa è più importante per il tuo progetto: caratteristiche o un futuro? Scegline uno e dai la priorità ai tuoi sforzi di conseguenza".