Come gestire i progetti open source

Question

Sto lavorando in un piccolo gruppo su alcuni progetti nel mio tempo libero. Stiamo avendo il problema che ci sembra di andare in tondo e non siamo in grado di sviluppare i nostri prodotti, tuttavia questo non è un problema durante il mio lavoro diurno. La mancanza di comunicazione faccia a faccia sembra avere un impatto reale sulla produttività.

Sarebbe gradito qualsiasi esempio di software o metodologie utilizzate dalla comunità di sviluppo open source.

Answer 1

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

Sei su una mailing list open source? Sono iscritto alla mailing list del mio favorite distro e gli sviluppatori si scambiano e-mail più volte al giorno. Inoltre, ci sono altre vie di comunicazione come IRC/Instant Messenger.

Io non sono uno sviluppatore di RoR, ma suggerirei di passare attraverso Getting Real per qualche ispirazione.

Answer 2

La mia ipotesi è che i progetti privati ​​siano tutti gestiti e codificati dagli sviluppatori. Gli sviluppatori sono noti per ... continuare a sviluppare. La grande differenza, secondo la mia esperienza, è che un'azienda ha esperienza di manager in grado di definire quando le cose sono FATTE. Consiglierei di mettere qualcuno sul compito di definire gli obiettivi e decidere quando le cose sono fatte.

Answer 3

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

1. avere obiettivi ben definiti e responsabilità.
2. Lascia che ogni sviluppatore abbia l'ultima parola su come deve essere eseguita la parte assegnata a .

Nei progetti open source l'unica motivazione reale e più forte è il divertimento da avere codificato il prodotto. Per quanto riguarda il n. 2 sopra, se alle persone viene detto cosa fare e non sono d'accordo, la motivazione inizia a mancare. Ovviamente ci sarà sempre un po 'di dare e avere come in qualsiasi altro tipo di relazione.

anche circa 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

Sono stato su alcuni progetti in cui avevamo molti più interlocutori che sviluppatori. La mia inclinazione è ignorare gli oratori e ascoltare i programmatori. Anche allora di solito c'è una persona che si occupa di accettare le patch. Possono esserci problemi politici che devono calpestare con leggerezza, ma a tutti gli effetti hanno l'ultima parola.

Linus ha avuto alcuni problemi abbastanza famosi con lo stesso problema. Prendi nota di questa discussione dal 2006: Talk is cheap. Show me the code.

Un'ultima cosa. Dato che nei commenti si dice che si dispone di codice, solo un sacco di riscritture, suggerisco caldamente di leggere il numero The Cathedral and the Bazzaar di Eric Raymond. Eric è un po 'un pazzo, in realtà, ma il saggio è inestimabile per chiunque desideri eseguire un progetto di software libero.

Answer 5

Se si legge la cronologia della maggior parte dei progetti open source, si inizia con una persona che esegue molto del lavoro iniziale. Se c'è una squadra, è piccola e una persona in realtà guida la squadra.

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

Penso che ogni progetto open source abbia un (singolare) programmatore capo che assicura che le decisioni vengano prese e fatte in modo coerente.

Torna in passato, Fred Brooks (Il Mese mitico) ha descritto "team di programmatori capo". Lo stesso concetto. Qualcuno è responsabile del contenuto tecnico. Enfasi sull'uno. Oggi chiamiamo "l'architetto" o un termine del genere.

Answer 6

Vorrei riflettere sulla motivazione e sugli obiettivi del tuo compagno di squadra e del tuo compagno in questo progetto. Sono a:

a) Creare un prodotto impressionante

o

b) giocare con il software, e imparare alcune cose nuove

Entrambe le risposte sono ugualmente valide, e sto cercando di indovinare sarebbe un mix con una tendenza verso l'uno o l'altro.

Se è più di (a), quindi, dare un'occhiata ai suggerimenti sulla metodologia, ecc. Forse anche prendere in considerazione la possibilità di formare una società attorno alla tua fantastica idea. Perché fare una cosa del genere richiede lavoro ... e probabilmente ne hai abbastanza di lavoro.

Se è per lo più (b), allora avrai più difficoltà a realizzare un prodotto fantastico, ma sarà un momento più facile in cui puoi perdonarti per non essere lì subito e soffrire più riscritture. E imparerai nuove abilità ogni volta che la guardi e lavori insieme che sono molto applicabili alle tue carriere a lungo termine.

In primo luogo vi suggerisco di essere chiari l'uno con l'altro sul perché siete lì. Poi guarda indietro a cosa stai pensando di fare, e rilascia presto e rilascia spesso. Se il progetto è composto da tre componenti e uno è completo, rilasciarlo come componente separato e iniziare a creare una comunità di utenti. Ciò si ripaga poiché questi utenti ti aiuteranno probabilmente con il tuo codice, oltre a costituire un solido nucleo di utenti per il prodotto completo e ti consentiranno di valutare come andrai presto piuttosto che dopo.

Buona fortuna.