Azioni sul documento
4.
Un progresso continuo
Su di un livello
Il progetto della American Legancy Foundation era decisamente complesso e io ritenni che approcciarlo utilizzando i nostri processi tradizionali portava con se un elevato rischio di insuccesso. Così iniziai a cercare altre alternative, esaminando soluzioni hosting, strumenti di lavoro proprietari, e soluzioni open source. Il rischio dell'utilizzo di un framework sofisticato implicava una quantità di tempo richiesto per diventare esperto della complessità dei concetti e dei costrutti. Così come con ogni strumento specialistico, imparare ad usarlo in modo efficiente aumenta drasticamente l'efficienza e la produttività, ma richiede affinamento e tempo per padroneggiarlo.
Il mio superiore un po' esitando fu d'accordo con me e dopo una rapida valutazione dei processi noi scegliemmo per il progetto un giovane e poco testato CMS chiamato Plone. Spendemmo parte del budget per far arrivare un esperto Plone per iniziare la nostra formazione con il software e assumemmo un secondo programmatore free lance esperto in linguaggio Python per assisterci durante lo sviluppo. Il fatto che Plone fosse un software libero fu un fattore rilevante per la nostra decisione ma principalmente per ragioni di ordine finanziario, non politiche o strategiche - non avevamo un'idea chiara di come fosse la community alla quale stavamo per unirci e dell'esperienza di trasformazione che la avrebbe accompagnata.
A quel tempo utilizzavo software open source quotidianamente, ma oltre al postare qualche domanda sulle mailing list non avevo mai partecipato così da vicino ad un progetto. Ero decisamente sprovveduto per quanto riguarda la differenza tra le diverse licenze open source ed ero solo parzialmente a conoscenza delle politiche che ruotano attorno alla proprietà intellettuale, alla cultura libera ed al software libero. Avevo sperimentato GNU/Linux al college e pensai che era una gran cosa che il codice sorgente fosse disponibile, ma non ero un evangelista del software libero. Avevo studiato diverse metodologie di sviluppo e buona parte della letteratura sulla gestione dei progetti ed ero molto interessato a processi alternativi per creare un software migliore, ma da una prospettiva pratica, non teoretica.
Come iniziammo ad entrare nel giusto ritmo di sviluppo venne fuori un qualcosa di distintamente diverso in questo sforzo. In passato le tecnologie open source che avevo utilizzato erano separate da diversi livelli di astrazione al di sotto del problema vero e proprio che stavo provando a risolvere. Così avrei potuto programmare lavorando con un sistema operativo open source, (per esempio GNU/Linux), in un linguaggio open source (Perl o Python), scontrandomi con un database open source (PostGreSQL o MySQL) ed utilizzando un web server open source (Apache) ma non avrei sviluppato sistemi operativi, linguaggi di programmazione, database o web server - avrei sviluppato applicazioni per il web. In questo caso l'applicazione che stavamo sviluppando era molto simile allo strumento che stavamo utilizzando per svilupparla - le specifiche del nostro problema potevano essere interpretate come un livello molto sottile in cima alla sottostante piattaforma Plone. In modo non sorprendente molte delle sfide e e dei problemi che affrontavamo erano assai simili ai problemi che gli altri membri della software community stavano affrontando e assomigliava da vicino i problemi che questo progetto stava tentando di generalizzare ed etichettare. Le loro attitudini, interessi ed obiettivi erano spesso molto simili ai nostri e scoprimmo di avere un accordo in comune con gli altri membri di questa community di sviluppatori.
Iniziammo a lavorare a stretto contatto con la community, comunicando regolarmente via email e chat IRC a riguardo del tipo di problemi che stavamo trattando e di chi aveva tentato di risolverli. La vastità della nostra sfida suggerì di automatizzare alcune operazioni quotidiane che noi avremmo affrontato a mano con la forza bruta se il nostro progetto fosse stato più piccolo. Quando descrivemmo la struttura che stavamo sviluppando per automatizzare certi aspetti dello sviluppo stesso, ci fu un vero e proprio interesse per la nostra soluzione. Il programmatore che avevamo assunto si dimostrò piuttosto brillante ed aveva già esperienze pregresse di lavoro avendo partecipato allo sviluppo di software open source. Condividemmo parti del software su cui stavamo lavorando ed altri sviluppatori iniziarono a lavorarci sopra trovandolo intelligente ed utile. Fummo invitati ad un piccolo workshop, anche detto "sprint" che gli sviluppatori di questo progetto stavano preparando in Rotterdam per condividere i nostri progressi e partecipare allo sviluppo della successiva rivisitazione della piattaforma.
La nostra compagnia non aveva certo l'abitudine di spedire i propri sviluppatori in viaggi di lavoro e fu arduo convincere il management che avrebbero tratto un beneficio diretto dal mandarci a questo evento. Spiegammo loro i vantaggi del partecipare a sforzi di produzione di tipo "peer", facendo il riepilogo degli argomenti standard che spiegano gli auto-benefici che si traggono dal partecipare allo sviluppo di progetti open source. Oltre all'efficienza dell'avere diversi sviluppatori che testano e debuggano il nostro software, realizzammo anche che accattivarsi la visione condivisa dei programmatori sarebbe stato un ottimo investimento a lungo termine in quanto avremmo potuto indirizzare la community verso la soluzione di problemi per i quali avevamo delle commesse. Il nostro management controvoglia si arrese ed accettò di sponsorizzare la nostra partecipazione. Ricordo distintamente la determinazione dei miei colleghi nel partecipare all'evento, decidendo che se i nostri capi avessero deciso di non mandarci il programmatore avrebbe preso ferie e ci sarebbe andato a sue spese. Ricordo che pensai quanto suonasse strano considerare di spendere i giorni di ferie per un evento legato al lavoro, ma fino ad allora non avevo frequentato uno sprint o una conferenza di sviluppatori e non ne apprezzavo ancora il fascino.
Uno "sprint" (detto anche "hackaton") è una sessione di più giornate focalizzate sulla programmazione, ispirata da una pratica descritta dalla metodologia dello sviluppo agile nota come "programmazione estrema". Diversamente da una conferenza tradizionale non ci sono relatori già convocati o lezioni formali, anche se è ricco di sessioni di formazione decise al momento e brevi presentazioni. Al contrario, i partecipanti si auto organizzano e creano un consenso attorno alcuni piccoli progetti che sono in grado di portare a termine nel tempo concesso. Lavorano in modo assiduo in coppia o in piccoli gruppi, utilizzando l'approccio della “programmazione alla pari”, che peraltro è sostenuta dalla filosofia di sviluppo detta "extreme programming". Spesso programmatori più esperti si affiancano ai meno esperti, e solitamente c'è un "insegnante" a condurre la sessione, aiutando a fissare l'agenda e a registrare le attività su una lavagna bianca. Questi incontri di persona sono importanti occasioni in cui lo sviluppo del progetto avanza, si stabilisce una leadership nella community, gli approcci alla programmazione sono condivisi e scambiati e vengono discusse la pianificazione architetturale e strategica , sulle quali è difficile lavorare in modo asincrono. Gli "sprint" sono inoltre occasioni sociali dove l'etica del "lavoro intenso" lascia il posto all'etica del "gioco intenso". Gli "sprinters" spesso scrivono codice fino a tardi la sera e poi restano in piedi per chiacchierare fino al mattino.
Roderdam fu un' incredibile avventura ed incontrai molti programmatori indipendenti che erano dentro il progetto da anni. La community di Plone attira molti imprenditori fieramente indipendenti e rappresenta una particolare declinazione dell'economia ibrida. Gli sviluppatori e le aziende che fan parte della community raramente competono direttamente tra di loro. Piuttosto, competono con altre piattaforme che occupano lo stesso spazio di soluzioni e competono regolarmente contro queste formidabili piattaforme sullo stesso terreno di gioco. Individuando sempre nuovi e più complessi impegni, la piattaforma continua a crescere piuttosto che cannibalizzare sé stessa con battibecchi, fork e rebranding.
La community di Plone è inoltre molto riflessiva e consapevole della sua immagine e dei suoi processi e costantemente alla ricerca della ridefinizione del modo in cui cresce. Nuove funzionalità vengono aggiunte al progetto attraverso un misto di consenso sulle priorità e di bisogni dei clienti. Alle volte i clienti, senza saperlo, sottostanno alla creazione di nuove generalizzate funzionalità, di cui sono i primi a sentire il bisogno, ma questo è economicamente corretto e razionale, dal momento che che essi fanno leva su decine di altre funzionalità che furono, a loro volta, sviluppate e condivise con le stesse modalità. Queste modalità sono formalizzate attraverso strutture legali e culturali che rinforzano ed incoraggiano questo stile di cooperazione. I membri della community addirittura si impegnano essi stessi nel marketing e nella divulgazione del brand del progetto dal momento che un miglior riconoscimento del software è apprezzabile da tutti gli appartenenti all'universo Plone. Questa esperienza allargò i miei orizzonti in merito alla possibilità di carriera all'interno del mondo del software, e mi insegnò una grande lezione a proposito del fascino del lavoro in progetti FOSS a lungo termine. Nel fragile ed incerto mercato del lavoro dei nostri tempi l'identità e la coesione che un progetto come Plone è in grado di offrire al programmatore è un modo per cucire insieme una carriera post moderna in una economia globale post geografica.
