Pagamento ai membri del progetto open source per correzioni di errori e funzionalità

Question

Ho un problema da risolvere che penso ci vorranno 4 giorni, ma se avessi una richiesta di funzionalità ordinata e una release di snapshot, allora potrei averlo fatto in uno. Superficialmente questo crea un budget di 3 volte la mia tariffa giornaliera per ottenere la richiesta di funzionalità.

Quindi, le mie domande sono: hai mai pagato un membro del progetto O/S per aggiustare qualcosa per te? Ha funzionato OK? Come hai venduto l'idea al tuo manager/colleghi e da dove vengono i soldi?

Ancora più importante, come hai fatto a chiedere gentilmente? Esiste un'etichetta per queste cose? I leader del progetto saranno probabilmente ricettivi all'idea?

Nel caso in cui sia importante, il software con la caratteristica mancante è un progetto JBoss - la casa dell'open source professionale - e sono in grado di richiedere le spese in quanto sono un appaltatore.

Answer 1

Al lavoro, abbiamo avuto la fortuna di assumere manutentori open source per migliorare le librerie che usiamo.

Ecco alcuni dei progetti che abbiamo fatto in passato:

1. Abbiamo bisogno di integrare Quake 2 con wxWidgets. Abbiamo assunto Vadim Zeitlin, uno dei principali contributori di wxWidgets. In meno di 4 giorni, ha creato un widget wxQuake2 adattando la versione Windows di Quake 2.
2. In seguito, avevamo bisogno dell'accesso portatile ai bitmap grezzi. Quindi abbiamo assunto di nuovo Vadim e abbiamo lavorato con lui per produrre una nuova API bitmap non elaborata. Ciò ha comportato un notevole lavoro di progettazione, ma ci è piaciuta molto l'API risultante e la usiamo fino ad oggi.
3. In un secondo momento, abbiamo assunto un altro dei principali contributori per migliorare il supporto dell'accessibilità di wxWidgets. Come si è scoperto, abbiamo finito per non utilizzare questo codice subito, per vari motivi tecnici. Ma altre persone hanno potenziato questo codice da allora, e speriamo di usarlo un giorno.

In altre parole, assumere manutentori open source è come assumere un altro tipo di appaltatore. Ma alcune cose sono anche un po 'diverse. Ecco alcuni consigli basati sulle nostre esperienze:

1. Avrai la maggior fortuna se desideri migliorare un progetto esistente e rilasciare le modifiche come open source.
2. In generale, si desidera assumere membri del team principale. Hanno i migliori track record, sono i più produttivi e hanno le migliori possibilità di unire le modifiche a monte.
3. Si desidera ottenere la fusione delle modifiche a monte. Se non lo fai, manterrai un fork locale, che è un mal di testa.
4. Prima di assumere, fare qualche ricerca. Chi lavora alle funzionalità che ti interessano? Sono qualcuno con cui ti piacerebbe lavorare? Leggi le mailing list e guarda la cronologia del controllo della versione e scegli alcune persone da avvicinare.
5. Durante la fase di progettazione, potrebbe esserci un po 'di give-and-take. Gli sviluppatori stanno valutando la salute più ampia del progetto e stai osservando le esigenze di un'azienda specifica. Questo a volte ha reso le trattative un po 'più complicate per noi, ma il risultato finale è stato in genere un design migliore di quello che avremmo scelto da soli.

E, soprattutto, non essere timido. In qualsiasi progetto open source sufficientemente ampio, diversi membri del team principale gestiscono già attività di consulenza.Nei progetti open source più piccoli, generalmente si trovano diversi contributori che desiderano per eseguire attività di consulenza.

E se sei ancora riluttante ad avvicinarti a qualcuno, puoi sempre chiedere: "Conosci qualcuno che sarebbe interessato a essere pagato per lavorare su $ FEATURE?" Se non sono interessati, non li hai messi sul posto e potrebbero dirti chi chiedere.

Nel complesso, siamo rimasti colpiti dalla professionalità e produttività dei manutentori open source e consiglierei questo percorso per gli altri.