Il lavoro a contratto necessita di essere trattato con cura nei progetti di software libero. Idealmente voi volete che un lavoro di imprenditore sia accettato dalla comunità di sviluppo e impacchettato nella distribuzione pubblica. In teoria, non interesserebbe chi sia l'imprenditore, finché il suo lavoro è buono ed è fatto secondo le linee guida. Teoria e pratica possono a volte coincidere, anche: Un perfetto sconosciuto che si metta in evidenza con una buona patch, sarà generalmente capace di metterla nel software. Il problema è, è molto difficile produrre una buona patch per una crescita non banale o una nuova funzionalità quando si è veramente un perfetto sconosciuto; uno deve prima discutere quella con il resto del progetto. La durata della discussione non può essere predetta con precisione. Se il lavoratore a contratto è pagato ad ore, voi potete concludere pagando più di quanto aveste previsto; se lui è pagato con una somma secca, può concludere facendo più lavoro di quanto possa produrre.
Ci sono due modi per aggirare questo. Quello preferito è quello di fare una erudita congettura sulla lunghezza della durata del processo di discussione, basata su passate a esperienze, aggiungere qualche riempitivo per errori, e basare il contratto su quello. Ciò aiuta anche a suddividere il problema in due pezzi quanto più piccoli possibile, per aumentare la possibilità di predire ogni pezzo. L'altro modo è contrattare solamente per il rilascio di una patch, e trattare l'accettazione delle patches nel pubblico progetto, come una questione separata. Allora diventa molto più facile scrivere un contratto, ma siete inceppati con il il carico di mantenere una patch privata tanto a lungo quanto dipendete dal software, o almeno tanto a lungo quanto ci vuole a inserire la patch o l'equivalente funzionalità nella linea principale. Certamente, anche con il modo preferito, il contratto stesso non può esigere che la patch sia accettata nel codice, perché ciò comporterebbe vendere qualcosa che non è in vendita. (Cosa accadrebbe se il resto del progetto decidesse di non supportare quella funzionalità?). Comunque il contratto può richiedere un sforzo bona fide a far si che il cambiamento sia accettato dalla comunità, e che esso sia inviato al deposito se la comunità lo accetta. Per esempio, se il progetto aveva scritto standards riguardo ai cambiamenti al software, il contratto può far riferimento a quegli standards e specificare che il lavoro deve adattarsi ad essi. In pratica ciò si risolve nella maniera in cui uno spera.
La migliore tattica per contrattare con successo è ingaggiare uno degli sviluppatori del progetto preferibilmente uno con l'accesso all'invio come contraente. Ciò potrà sembrare una modo di comprare influenza, ebbene, lo è. Ma non è una forma corrotta come potrebbe sembrare. Una influenza di uno sviluppatore nel progetto e dovuta principalmente alla qualità del suo codice e alla sua interazione con gli altri sviluppatori. Il fatto che egli abbia il contratto per fare certe cose non eleva il suo stato in alcun modo, sebbene ciò possa far si che la gente lo osservi con più attenzione. La maggior parte degli sviluppatori non rischiano la loro posizione a lungo termine sostenendo una funzionalità fuori luogo o che non piace a molti. Infatti, ciò che conseguite, o dovreste conseguire quando assumete tale persona a contratto è il parere su quale sorta di cambiamento è verosimilmente accettato dalla comunità. Voi anche pervenite a un leggero cambiamento nelle priorità del progetto. Poiché l'elenco delle priorità è giusto una materia di chi ha tempo di lavorare a qualcosa, quando pagate per il tempo di qualcuno, voi fate sì che il suo lavoro salga un poco nella coda delle priorità. Questo è un ben compreso fatto di vita fra gli sviluppatori esperti open source, e almeno qualcuno di essi dedicherà attenzione al lavoro del lavoratore a contratto semplicemente perché sembra che ciò debba essere fatto, in modo tale che che essi si adoperano a che sia fatto bene. Forse essi non scriveranno nulla del codice, ma tuttavia discuteranno del progetto e della revisione del codice, ambedue delle quali cose possono essere molto utili. Per tutte queste ragioni, il lavoratore a contratto è dipinto al meglio dai ranghi di quelli già coinvolti nel progetto.
Ciò solleva immediatamente due questioni: i lavoratori a contratto devono essere sempre privati? E quando no lo sono, dovete preoccuparvi per il fatto che potreste creare delle tensioni nella comunità per il fatto che avete fatto contratti con alcuni e non con altri?
La cosa migliore è essere aperti sui contratti, quando potete. Diversamente il comportamento del lavoratore a contratto può sembrare strano agli altri nella comunità può darsi il suo dare improvvisamente e inspiegabilmente priorità a funzionalità per le quali non aveva mai avuto interesse in passato. Quando le persone gli chiedono perché le vuole ora, come può egli rispondere in modo convincente se non può parlare del fatto che è stato assunto per scriverle?
Allo stesso tempo nè voi né il lavoratore a contratto dovreste agire come se gli altri dovrebbero considerare il vostro aggiustamento come un buon affare. Troppo spesso io ho visto lavoratori a contratto ballare il valzer nella mailig list dello sviluppo con l'atteggiamento che i loro posts dovrebbero essere presi più seriamente solamente perché pagati. Questo tipo di atteggiamento dà il segnale al resto del progetto che il lavoratore a contratto guarda al fatto del contratto come opposto al codice risultato del contratto—essere la cosa più importante. Ma dal punto di vista degli altri sviluppatori, solo il codice conta. Sempre, il fuoco dell'attenzione dovrebbe essere mantenuto sugli aspetti tecnici, non sui dettagli di chi ha pagato chi. Per esempio, uno degli sviluppatori nella comunità di Subversion tratta il contratto in una particolare graziosa maniera. Mentre discute i suoi cambiamenti in IRC egli vuol far menzione a parte (spesso in una privata osservazione, un privmsg, su IRC ad uno degli altri con accesso all'invio) che lui è stato pagato per il suo lavoro su questo particolare bug o funzionalità. Ma egli da anche tangibilmente l'impressione che avrebbe accettato di lavorare a quel cambiamento comunque, e che è felice che il denaro stia rendendogli possibile fare ciò. Egli può o non può rivelare la sua identità individuale, ma in ogni caso non si sofferma sul contratto. Le sue osservazioni su questo sono giusto un ornamento per una discussione diversamente tecnica su come fare qualcosa.
Questo esempio mostra un'altra ragione per cui è bene essere aperti sui contratti. Ci possono essere molte organizzazioni che sponsorizzano i contratti su un progetto open source, e se una conosce ciò che le altre stanno cercando di fare, esse possono essere in grado di mettere insieme le loro risorse. Nel caso sopra, il più grande finanziatore (CollabNet) non è coinvolto in ogni modo con questi contratti di lavoro a cottimo, ma la conoscenza che qualche altro sta sponsorizzando alcune correzioni di bugs permette a CollabNet di reindirizzare le sue risorse verso altri bugs, col risultato di una maggiore efficienza per il progetto nella sua interezza.
Si offenderanno alcuni sviluppatori perché altri sono pagati per lavorare al progetto? In generale, no, specialmente quando quelli che sono pagati sono stabilizzati, rispettati membri della comunità comunque. Nessuno si aspetta che il lavoro a contratto sia distribuito in modo uniforme fra tutti coloro che fanno gli invii. La gente capisce l'importanza di una relazione a lungo termine: le incertezze connesse col contratto, sono tali che una volta che hai trovato uno con cui poter può lavorare affidabilmente, sareste riluttanti a passare ad un'altra persona giusto a scopo di egualitarismo. Pensate a ciò così: la prima volta che ingaggiate, non ci saranno lamentele, perché chiaramente dovete scegliere qualcuno—non è una vostra mancanza il fatto che non potete prendere tutti. Più tardi, quando ingaggiate qualcuno per la seconda volta, questo è giusto il sentire comune: già lo conoscete, l'ultima volta con successo, così perché correre rischi non necessari. Così, è perfettamente naturale avere una o due persone cui rivolgersi nel progetto, invece di distribuire il lavoro uniformemente.
La comunità è tuttavia importante per il successo del lavoro a contratto. Il suo coinvolgimento nel processo di progettazione e revisione per cambiamenti su misura non può essere un pentimento. Deve essere considerato parte del lavoro e pienamente compreso dal lavoratore a contratto. Non pensate all'esame accurato della comunità come a un ostacolo da superare pensate ad esso come a un libero tavolo di progetto e a un dipartimento di QA. E' un beneficio essere inseguiti come in una caccia, non solamente sopportatati.
Nel 1995 io ero una metà della partenership che fornì il supporto e la crescita del CSV (il Concurrent Versions System; vedere http://www.cvshome.org/). Il mio partner Jim ed io eravamo informalmente i sostenitori di CSV a quel punto; ma non avevamo mai pensato con attenzione a come dovevamo metterci in relazione alla comunità di sviluppo di CSV in maggioranza costituita da sviluppatori volontari. Noi avevamo giusto accettato che che essi mandassero le patches, e noi le avevamo applicate, e questo era praticamente come funzionava.
A quei tempi, un CSV in rete poteva essere realizzato soltanto su un remoto programma di login come rsh. L'uso la stessa password per l'accesso al CSV e al login era un ovvio rischio di sicurezza, e diverse organizzazione furono rimandate nel tempo per questo. Una banca importante di investimenti ci ingaggiò per aggiungervi un ulteriore meccanismo di autenticazione, così che esse potessero usare il CSV in rete con sicurezza per il loro uffici.
Jim e io accettammo il contratto e ci sedemmo attorno a un tavolo per progettare il nuovo sistema di autenticazione. Ciò a cui arrivammo era molto semplice (gli Stati Uniti avevano esportato controlli su un codice crittografico all'epoca, cosìcchè il cliente capì che noi non potevamo implementare una efficace autenticazione), ma mentre non avevamo esperienza di progettazione di simili protocolli, tuttavia facemmo poche gaffes che sarebbero state ovvie per un esperto. Se ci fossimo preso il tempo per metter giù una proposta, e mostrarla agli altri sviluppatori per la revisione, avremmo intercettato questi errori in anticipo. Ma noi non facemmo mai così, perché non ci serviva pensare alla mailing list di sviluppo come una risorsa da usare. Noi sapevamo che la gente avrebbe probabilmente accettato qualunque cosa avessimo inviato e poiché, e—e poiché noi non cooscevamo ciò che non sapevamo—non ci infastidimmo a fare il lavoro in un modo visibile, per esempio, postando patches frequentemente, facendo piccoli, digeribili invii a una sezione speciale, ecc.. Il risultante protocollo di autenticazione non fu molto buono, certamente, una volta che diventò stabile, era difficile da migliorare, a causa di questioni di compatibilità.
La radice del problema non era una mancanza di esperienza; noi avremmo potuto facilmente aver imparato ciò che era necessario. Il problema era il nostro atteggiamento nei confronti della comunità di sviluppo dei volontari. Noi guardavamo all'accettazione dei cambiamenti come a una barriera da saltare, piuttosto che a un processo col quale la qualità dei cambiamenti poteva esser migliorata. Poichè confidavamo che ogni cosa che avessimo fatto sarebbe stata accettata (come lo era), facemmo uno sforzo piccolo per coinvolgere gli altri.
Certamente quando state scegliendo un imprenditore, volete qualcuno con le giuste capacità tecniche ed esperienza per il lavoro. Ma è anche importante scegliere qualcuno con una traccia dei precedenti comportamenti e realizzazioni di una costruttiva interazione con gli altri sviluppatori nella comunità. In questo modo voi state prendendo più di una singola persona; voi state prendendo un agente che sarà capace di disegnare una rete di esperienze in modo da essere sicuri che il lavoro sia fatto in modo solido e mantenibile.