2010-08-05 9 views
8

Qualche tempo fa ho notato alcune persone che cercavano di avviare un progetto open source. Circa una settimana dopo l'inizio del progetto, si è più o meno completamente dissolto, in parte a causa di problemi relativi alla gestione del progetto stesso.Come si avvia un progetto open source di successo?

Le idee alla base del progetto sono state comunque molto ben pensato e un sacco di persone sono ancora interessati a vederlo realizzato. Finora nessuno ha tentato seriamente di ricrearlo, ma alcuni di noi stanno pensando di farlo. Ovviamente non vogliamo che il progetto finisca nello stesso modo in cui l'ha fatto l'ultima volta.

Ora alla mia domanda. Come si dovrebbe avviare un progetto open source di successo, dove con successo viene definito come "il progetto non muore a meno che nessuno non sia più interessato al software stesso?"

+0

Fai questa domanda anche su Hacker News (news.ycombinator.com/), se non lo hai già fatto. Questo è anche un buon posto per chiedere domande su Open Source e startup. –

risposta

10

Bella domanda, anche se è più degna di un libro che un semplice articolo, IMHO. E spero che non sorprenda che la maggior parte del consiglio migliore sia sociale, non tecnico.

Ecco alcune osservazioni in ordine sparso:

  • non fare un grande investimento infrastrutturale in attacco A meno che non sei già un committer di Apache (o somesuch), non guardarsi intorno per un'organizzazione sponsor o ospitante i propri server, ecc. Risolvi su GitHub in 5 minuti e non guardare indietro. Metti la tua energia in funzionalità.
  • Abbassare la barriera per l'ingresso Non fare in modo che i potenziali contributori saltino attraverso i cerchi o si sottopongano a un controllo in background prima di ascoltare le loro idee. I progetti open source sono economie in rete ... hai bisogno dell'energia di altri. Anche un'attività errata è meglio di nessuna attività sul tuo progetto. Puoi sempre guidare il codebase in una direzione migliore in seguito.
  • Minimizzare codice personalizzato Non scrivere uno strumento di registrazione personalizzata o parsing XML API ... ci sono implementazioni open source che sono (1) abbastanza buono, (2) meglio mantenuto, e (3) migliore della tua volontà diventare comunque. Più energia puoi concentrarti sul tuo problema principale, meglio è.
  • Live on the edge Le persone e le organizzazioni investiranno solo nel miglioramento del progetto se ne beneficeranno direttamente. Mangia il tuo cibo per cani. Crea dipendenze nei tuoi altri progetti (come con il tuo datore di lavoro) nel tuo progetto open source, anche se non è ancora "perfetto". (Suggerimento: i progetti software non sono mai perfetti, sono in lavorazione o morti.)
+1

Karl Fogel ha un libro intitolato "Producing Open Source Software" .. prendilo subito. Quando ho lasciato dotproject per iscriversi a web2project, quel libro è stato l'ispirazione per impostare correttamente le cose. Stava aprendo gli occhi. L'esperienza di Fogel è stata uno dei protagonisti di Subversion. – CaseySoftware

+0

+1 mantieni una messa a fuoco semplice. Questo è praticamente il consiglio perfetto. –

+0

Al giorno d'oggi, code.google.com non è più o meno sostituito da GitHub? –

1

Lo dici tu stesso. La cosa più importante è che dovrebbe avere persone che se ne preoccupano abbastanza per affrontare i problemi invece di abbandonare.

Se a nessuno interessa abbastanza, morirà di nuovo. Prova un altro progetto in cui ti interessi abbastanza.

"Un sacco di persone interessate a vederlo realizzato" non significa nulla se nessuno effettivamente farà il lavoro, combatterà i combattimenti e rimarrà in pace.

1

Questo è un po 'fuori tema in SO, ma mi morderò comunque.

La maggior parte dei progetti FOSS viene avviata da UNA SINGOLA persona. Altre persone vengono a bordo dopo che questa persona ha prodotto un codice che fa qualcosa di vagamente utile. Quindi, se vuoi iniziare un progetto, fallo da solo, imposta un sito su qualcosa come Google Code e scrivi del codice. L'ultimo è il più importante.

5

GitHub è un buon posto perché rende facile per qualcuno anche solo con un po 'di interesse bifare il tuo progetto e applicare le sue patch per condividerle con gli altri.

Ma è davvero sugli atteggiamenti intorno alla vostra progetto di più di dove si ospitano o altre considerazioni semplici come quella. Sii benevolo, serio e giudizioso, mantieni una comunità attiva anche se sarà piuttosto piccola per un po ', e così via. Accetta le patch che dovrebbero essere accettate, rifiuta le patch che dovrebbero essere rifiutate. Sii una brava persona, sviluppatore e manager e applica queste abilità al tuo progetto, e dovrebbe andare bene.

1

Non penso sia scolpito nella pietra, ma per me il punto più importante è che il tuo progetto dovrebbe colmare una lacuna nell'ecosistema esistente. In altre parole, c'è spazio per il tuo progetto di vivere.

Oltre a ciò, posso dire che il modo migliore per rimanere motivati ​​è lavorare insieme con le persone. Dici che ci sono ancora molte persone interessanti nel vederlo realizzato. Quindi, perché queste persone non fanno qualcosa al riguardo? Sicuramente possono fare qualcosa. Penso che un malinteso comune sia che contribuire a un progetto open source significa che devi essere in grado di scrivere codice. C'è di più ad esso:

  • Scrivi documentazione
  • Creare elementi grafici
  • Discutere caratteristiche e roadmap
  • promuovere il progetto
  • ecc ecc

Certo, non tutti questi punti sono applicabili a tutti i progetti, ma cercare di convincere le persone a impegnarsi in un progetto finirà per aiutare voi e/o i vostri membri di progetto a rimanere impegnati. Non vuoi deludere tutte le altre persone del progetto, vero? ;-)

Problemi correlati