Come si superano i problemi di tooling in un progetto open source comunale?

Penso che tu abbia risposto alla tua stessa domanda; mentre ti piacerebbe usare 1 strumento, "molti" dei tuoi colleghi preferiscono usare qualcos'altro. Senza un 'capo' per decidere gli strumenti, le regole di maggioranza e devi andare con lo strumento preferito.

Ora, non c'è motivo per cui non si possa provare a interagire con loro nella discussione degli strumenti. Dovrai prendere l'iniziativa e condurre il dibattito intorno al cambiamento, dovrai anche convincerli a concordare con te e questo richiederà un po 'di sforzo.

Pensa a questa domanda dal loro punto di vista. A meno che tu non collabori con loro, uno di loro potrebbe pubblicare una domanda "come gestire uno sviluppatore che insiste nell'usare uno strumento diverso per il nostro standard?". Come reagiresti se uno sviluppatore decidesse di cambiare uno strumento che hai già accettato di usare?

In definitiva, devi accettare di utilizzare strumenti comuni, proprio come il design comune. Se non lo fai ci sarà il caos.

Ti consiglio di rivedere le esigenze e decidere quali strumenti devono essere comuni. Ad esempio non puoi avere alcune persone che usano svn e altri che usano git quando c'è molta condivisione di codice. Tuttavia, quando si tratta di editor, le differenze possono essere ok. Il tempo, i costi e le motivazioni che spingono le persone a cambiare strumenti che riguardano essenzialmente le preferenze spesso non ne valgono la pena.

Alcuni esempi pratici:

Devi essere comune:

• Il database utilizzato
• La lingua utilizzata
• Il sistema di controllo del codice sorgente

ok per essere diversi:

• git tools - gui's, cli, ecc. L'artefatto finale (il codice è in git) è lo stesso.
• Editor: qui ci sono molte scelte

Un fattore importante è la condivisione è freqently l'editor. Fondamentalmente se la gente va bene con un editor diverso, è necessario accettarlo inizialmente. Su un progetto in stile open source è molto probabile che le persone si attengano a ciò che sanno e siano a loro agio.

Se hai bisogno di accoppiare il codice hai tre opzioni:

• Una persona esegue la digitazione e usa l'editor con facilità e competenza.
• Entrambe le persone usano un editor molto semplice (notepad, gedit, ecc.)
• Una persona investe il tempo per imparare l'editor che l'altro utilizza.

La mia esperienza personale per i redattori (mentre lavoravo nella comunità Ruby on Rails negli ultimi anni) è che le persone sono abbastanza divise tra gli editori (di solito tra emacs e vi). Quando si tratta di scrivere codice o addirittura di accoppiarsi, non importa più di tanto, a patto che la codifica della persona sia abile nel proprio strumento e la persona che osserva possa seguire e vedere il codice ok.

Nel tuo caso, si tratta più di strumenti piuttosto che di strumenti di per sé. Il problema su quale framework di test (phppec vs. phpunit) utilizzare durante la scrittura del codice, è certamente complicato. Penso che questo dipenda da cosa succederà mentre vai avanti. Ogni gruppo / persona dovrà mai leggere o alterare test scritti in un altro quadro che non conoscono? La collaborazione open source spesso richiede questo. Se è così, dovrai raggiungere un accordo sulla struttura. Avrai bisogno di lavorare attraverso le discussioni difficili e spesso controverse. È meglio iniziare con un accordo sulle cose ... su cui puoi essere d'accordo ... come "dobbiamo sceglierne uno" e "qualunque cosa decidiamo al termine della discussione, siamo tutti d'accordo di esserne vincolati ',' la prima cosa che faremo è ascoltarci attentamente ', ecc.

Per questo problema con diversi strumenti, vorrei mostrare i motivi per cui il mio strumento funziona bene al posto di altri. Ad esempio con l'editor, è comunque lo stesso output alla fine. Se i test vengono utilizzati per generare codice (ad esempio tdd) e scartati dopo, la loro implementazione è meno importante. Se vengono conservati in seguito e usati come test di regressione, probabilmente ha più senso usare lo stesso framework.

Ogni progetto ha bisogno di una sorta di leadership centrale per chiamare i colpi e prendere decisioni del genere.

In un'azienda, di solito è il capo del progetto nominato dalla direzione. In una grande comunità open source, la leadership è spesso una sorta di processo comunitario meritocratico in cui ogni partecipante può dare suggerimenti e un gruppo di esperti vota su di loro.

Il tuo progetto sembra essere un punto tra questi due. Due società sono coinvolte in parti uguali, e lasciare che si assuma l'unica direzione del progetto sembra inaccettabile per l'altra. Ma non sembra essere abbastanza grande da giustificare un processo comunitario con tutte le pratiche burocratiche e burocratiche coinvolte.

Una possibile soluzione potrebbe essere quella di nominare due leader di progetto, uno per ciascuna azienda, che concordano insieme un processo di flusso di lavoro comune e lo applicano nelle rispettive società.

Un'altra soluzione potrebbe essere quella di assumere un capo progetto indipendente che non fa parte di nessuna delle due società. Questo potrebbe essere fatto formando una terza società come joint-venture che è posseduta in parti uguali da entrambi i partner e ha l'unica missione di creare quel software. L'unico impiegato regolare di tale società sarebbe un capo progetto indipendente. La tua squadra e quella dell'altra azienda sarebbero ancora impiegati dalle rispettive società, ma verranno assegnati al lavoro come contraenti per la joint-venture. Entrambe le squadre farebbero rapporto al capo progetto, che a sua volta riferisce ai proprietari della sua azienda (i rispettivi capi).