Come vengono gestiti i progetti open source [chiuso]

Question

Nel tempo libero lavoro in un piccolo team su alcuni progetti.Abbiamo il problema che sembriamo girare in tondo e non siamo in grado di sviluppare i nostri prodotti, tuttavia questo non è un problema durante il mio lavoro quotidiano.La mancanza di comunicazione faccia a faccia sembra avere un impatto reale sulla produttività.

Qualsiasi esempio di software o metodologie utilizzate dalla comunità di sviluppo open source sarebbe apprezzato.

Answer 1

Questa è una domanda difficile a cui rispondere, perché "i progetti open source" è molto ampia selezione di progetti. Credo che la caratteristica è il progetto ha un unico obiettivo unificante (forse, un insieme di obiettivi correlati).

Sei su eventuali mailing list open source? Sono iscritto al mio preferito lista d 'distro e gli sviluppatori di posta elettronica tra loro molte volte al giorno. Inoltre, ci sono altre vie di comunicazione come IRC / Instant Messenger.

Io non sono uno sviluppatore RoR, ma vorrei suggerire sfogliando Ottenere reale per un po ' ispirazione.

Answer 2

Se si legge la storia della maggior parte dei progetti open source, cominciano con una persona che fa un sacco di lavoro iniziale. Se c'è una squadra, è piccolo, e una persona in realtà conduce la squadra.

Per scegliere un esempio. Nella comunità Python, si riferiscono a Guido van Rossum come Benevolent Dictator for Life (BDFL). La sua parola è (più o meno) finale. In molti casi ci sono persone non sono d'accordo con lui - ma per il bene della comunità Python - sembrano accettare al suo giudizio

.

Penso che ogni progetto open source ha un (singolare) capo programmatore, che assicura che le decisioni vengono fatte, e fatto in modo coerente.

Torna nei tempi antichi, Fred Brooks ( The Mythical Man Month ) ha descritto "squadre programmatore capo". Stesso concetto. Qualcuno è responsabile del contenuto tecnico. L'enfasi sulla uno. Al giorno d'oggi noi chiamiamo il ' "architetto" o qualche tale termine.

Answer 3

Nessuna vera metodologia qui, ma penso che 2 cose sono importanti:

1. Avere obiettivi ben definiti e responsabilità.
2. Lasciate ogni sviluppatore avere l'ultima voce in capitolo come la loro parte assegnata dovrebbe essere fatto.

In progetti open source l'unica motivazione reale e più forte è il divertimento per essere avuto codifica del prodotto. Relative al di sopra # 2, se la gente viene detto che cosa fare, e non sono d'accordo con esso, la motivazione comincia carente. Naturalmente ci sarà sempre un po 'di dare e prendere come in qualsiasi altro tipo di rapporto.

Anche per il tempo faccia, Skype è grande per avere incontri faccia a faccia, che vi consiglio almeno una volta alla settimana o al mese (a seconda delle dimensioni e la quantità di moto del progetto)

Answer 4

La mia ipotesi è che i tuoi progetti privati ​​siano tutti gestiti e codificati dagli sviluppatori.Gli sviluppatori sono noti per...continuare a svilupparsi.La grande differenza, secondo la mia esperienza, è che un'azienda ha manager esperti che possono definire quando le cose vengono FATTE.Consiglierei di affidare a qualcuno il compito di definire gli obiettivi e decidere quando le cose vengono completate.

Answer 5

Sono stato su alcuni progetti in cui abbiamo avuto molti più chiacchieroni di sviluppatori. La mia inclinazione è di ignorare i chiacchieroni e ascoltare i programmatori. Anche allora di solito c'è una persona che si occupa di patch accettare. Ci possono essere questioni politiche che hanno da percorrere leggermente in giro, ma per tutti gli effetti hanno l'ultima parola.

Linus ha avuto alcuni problemi piuttosto famosi con lo stesso problema. Prendere atto di questa discussione a partire dal 2006: Parlare è facile. Mostrami il codice.

Ancora una cosa. Dal momento che si dice nei commenti che si ha il codice, solo un sacco di riscritture, io consiglio vivamente di leggere di Eric Raymond la cattedrale e il Bazzaar . Eric è un po 'un pazzo in realtà, ma il saggio non ha prezzo per chi vuole eseguire un progetto di Software Libero.

Answer 6

Penserei alla motivazione e agli obiettivi tuoi e dei tuoi compagni di squadra in questo progetto.Devono:

a) Crea un prodotto fantastico

O

b) giocare con il software e imparare alcune cose nuove

Entrambe le risposte sono ugualmente valide e immagino che sarebbe un mix con una tendenza verso l'una o l'altra.

Se è più di (a), guarda i suggerimenti sulla metodologia, ecc.Magari prendi in considerazione anche la possibilità di formare un'azienda attorno alla tua fantastica idea.Perché realizzare una cosa del genere richiede lavoro..e beh probabilmente ne avrai abbastanza al lavoro.

Se si tratta principalmente di (b), allora avrai più difficoltà a realizzare un prodotto fantastico, ma un momento più facile in quanto puoi perdonare te stesso per non essere arrivato subito e aver subito più riscritture.E ogni volta che lo guarderete e lavorerete insieme, imparerete tutti nuove abilità che sono molto applicabili alle vostre carriere a lungo termine.

Innanzitutto vi suggerisco di essere tutti chiari tra voi sul motivo per cui siete lì.Quindi cerca di ridurre ciò che stai pianificando di fare, rilascia presto e rilascia spesso.Se il tuo progetto è composto da tre componenti e uno è completo, rilascialo come componente separato e inizia a costruire una comunità di utenti.Ciò ti ripagherà poiché questi utenti probabilmente ti aiuteranno con il tuo codice, oltre a formare un solido nucleo di utenti per il prodotto completo e ti consentiranno di valutare come stai andando presto piuttosto che dopo.

Buona fortuna.