Pensiamo all'effetto che il telegrafo ebbe sulle idee ordinarie: sulle coordinate del pensiero, sulla naturale attitudine, sulla consapevolezza pratica...non attraverso un assalto frontale ma, piuttosto, attraverso una dettagliata investigazione dei siti dove quegli effetti posso essere più chiaramente osservati. James Carey

Gigabyte di inchiostro digitale sono stati riversati analizzando le forze politiche, culturali, sociali ed economiche che descrivono i progetti di software libero ed open source (n.d.t. FOSS: Free and Open Source Software).

In questo scritto rifletterò, condividendole, su alcune delle mie personali esperienze a proposito di un particolare progetto di software libero, e ragionerò sui metodi con cui queste osservazioni potrebbero essere generalizzate al di là della mia esperienza.

Come sono organizzati i progetti di software libero? Quali sono le motivazioni che si concretizzano poi in contributi e partecipazione? Quali tipi di attività sono richiesti per la partecipazione ad un progetto di software libero? In che modo la produzione di software libero differisce dalla produzione di altri beni informativi? In che modo l'esperienza del lavorare ad un progetto di software libero forma e trasforma il partecipante?

Gli eventi dell' 11 Settembre 2001 ebbero un drammatico effetto sul mondo intero, con effetti che si estendono dal geopolitico al personale. La mia vita non fa eccezione, in quanto newyorkese sono stato profondamente traumatizzato dall'attacco e dalle sue conseguenze. La mia carriera subì una precisa e sorprendente svolta poiché l'attacco modificò improvvisamente il paesaggio dell'economia locale ed il mercato del lavoro. A quel tempo stavo cercando un nuovo impiego poichè la bolla speculativa che il mio precedente datore di lavoro stava cavalcando era in fine scoppiata. L'economia cittadina fu devastata ed alcuni progetti incredibilmente promettenti furono vaporizzati insieme alle torri. Ho affrontato alcune difficili scelte e deciso di affrontare un ruolo che intuitivamente sentivo come una sistemazione discutibile: la consulenza. Non mi garbava l'idea di diventare un programmatore mercenario, siccome preferivo scegliere dove consacrare il mio lavoro: idealmente a organizzazioni di cui rispettavo la missione. In più mi vedevo come un artigiano specializzato che aveva lavorato con piacere a sofisticati e lunghi progetti a cui mi sarei potuto consacrare, imparando e migliorando le mie capacità lungo il cammino. Non avevo mai provato la consulenza e mi sforzai di restare con la mente aperta riguardo a questa nuova esperienza. Mi consolavo sapendo che sebbene stessi barattando la profondità per l'ampiezza e nonostante il fatto che avrei incontrato una vasta serie di situazioni e problemi, d'altra parte le battaglie sarebbero state più facili. Mentre non sarei mai riuscito a conoscere a fondo nessun progetto o sistema, la varietà dei linguaggi avrebbe reso l'esperienza comunque valevole di essere vissuta. Ed inoltre avrebbe potuto anche piacermi.

Nel 2001 fui assunto come sviluppatore software presso una piccola compagnia di marketing interattivo chiamata Abstract Edge. La società fu fondata durante la corsa all'oro della fine degli anni '90 quando tre dei fondatori svilupparono un sito web che aiutava a organizzare e gestire la Million Mom March. La Abstract Edge aspirava alla pubblicità, al marketing, e alla consulenza strategica, ma a quel tempo era essenzialmente una web agency che aveva costruito un sito dinamico per i suoi clienti. Tra i suoi clienti vi erano alcune associazioni non profit come “The Gift of New York” e “Give kids a World” così come clienti corporate come Clairol Professional e i Marriott Hotels di New York. Abstract Edge sopravvisse al collasso delle dot-com attraverso una accurata espansione e non facendosi tirare in mezzo alla folle mania per il venture capital.

Si operava su margini ridotti, mantenendo un piccolo staff con un minimo di spese generali, e spesso abbassando le proprie offerte in risposta alle richieste dei clienti.

Nell'estate del 2002 mettemmo in piedi un progetto con la American Legacy Foundation, un' organizzazione non profit miliardaria fondata come riferimento per la battaglia della class action contro l'industria del tabacco. La American Legacy Foundation sviluppò una "campagna verità" che ebbe successo: una campagna contro il tabacco con finalità didattiche rivolte ai giovani e focalizzata sullo smettere di fumare. Stavano progettando un sito sorella di truth.org, pensato per dare supporto agli attivisti contro il fumo, per insegnare loro come organizzarsi in modo più efficiente e come promuovere il messaggio contro il fumo. Volevano che il sito funzionasse come un “ambiente community”, rendendo possibile l'attivismo attraverso attività di basate sul viral social networking. Mentre siti come questo erano un luogo comune nel 2007, nel 2002 il tipo di funzionalità che avevano immaginato non era affatto un luogo comune. Quella era l'era del Web 1.0, nei giorni precedenti la popolarità di Wikipedia, MySpace e Facebook, e i siti con una forte predisposizione alla partecipazione sociale erano appena all'inizio del loro emergere.

La American Legacy Foundation aveva già investito un anno nello sviluppare i contenuti per questo ambiente quando cercarono un partner per implementare la loro visione. Avevano già sviluppato un vasto numero di risorse per il lancio del sito ed avevano già compilato oltre una dozzina di cartelle rilegate spesse dieci centimetri di materiale che includeva articoli, attività, novità, fatti, sondaggi, biografie. Questi contenuti erano densi e riccamente connessi e richiedevano un sistema per gli editori in modo che potessero organizzare e gestire il materiale. A causa della controversa natura dei loro contenuti, e della natura litigiosa dei loro avversari, tutto ciò che sarebbe stato messo on line sul sito necessitava di un beneplacito scientifico e legale prima di essere pubblicato e loro volevano un sistema per gestire questo flusso di lavoro. L'ambiente inoltre doveva provvedere al supporto agli associati, ai profili, ai forum di discussione, ai commenti, alle email, ad una chat sincronizzata, e ad un flusso di lavoro per le iscrizioni e alla moderazione.

Abstract Edge inizialmente stilò un contratto per consegnare l'intero ambiente in un lasso di tempo incredibilmente breve, ed essendo il responsabile tecnico dell'architettura in questo progetto sapevo che i precedenti modelli di sviluppo non sarebbero stati utili in questo compito. In passato Abstract Edge solitamente consegnava soluzioni aziendali ad hoc per il cliente, sviluppato in casa partendo da zero. I software sono costituiti da diversi livelli quindi è improprio parlare di "sviluppare qualsiasi cosa da zero", ma non stavamo ancora sfruttando l'effetto leva di una piattaforma o di un framework che stavano diventando necessari per tenersi all'altezza delle aspettative degli utenti. La richiesta di sistemi come questi stava crescendo in complessità, così come i media crescevano in popolarità ed importanza.

Nei primi tempi del web le organizzazioni erano soddisfatte di una pubblicazione unidirezionale gestita col supporto di uno staff tecnico. L'importanza di gestire il messaggio e la presenza di una organizzazione sul web continuò a crescere ed il personale addetto alle comunicazioni ed al marketing iniziarono a preoccuparsi del fatto che stavano perdendo il controllo preciso sulla pubblicazione. La pubblicazione dei contenuti era ora nelle mani dei webmaster o, peggio ancora, in quelle di consulenti di terze parti che necessitavano di essere contattati e pagati per ogni piccola modifica o correzione. La gestione (dei contenuti) iniziò ad essere prioritaria per lo sviluppo di sistemi che permettevano ad amministratori non tecnici di organizzare e gestire la pubblicazione sul web. Questi sistemi tendevano intrinsecamente ad essere piuttosto complessi, in quanto si sforzavano di incorporare la gerarchia e la burocrazia delle organizzazioni che andavano a servire.

Esse erano progettate per racchiudere i processi delle organizzazioni ed erano necessarie per modellarne di conseguenza i ruoli e le strutture. Questi processi possono essere colti in modo informale - attraverso gli aspetti culturali all'interno del sistema, o in modo formale - rigidamente costretti dai ruoli definiti all'interno del sistema stesso.

Molte organizzazioni istintivamente erano rivolte verso una rigida costrizione e modellizzazione, spesso sottostimando la difficoltà incontrata nel definire esplicitamente i ruoli, ed ignorando l'importanza del riuscire ad ingegnerizzare la flessibilità in questi sistemi in modo che gli stessi processi possano evolvere e cambiare nel tempo, in risposta al cambiare di necessità e condizioni.

Siccome le organizzazioni desideravano sempre più questi sistemi di pubblicazione complessi - modellati specificamente sul loro workflow e sui loro processi e pensati per essere amministrati e usati da personale non tecnico - emersero nuove soluzioni software che rispondevano sempre più a questa domanda. Questa classe di sistemi è conosciuta come "Content Management Systems" (n.d.t. Sistemi di gestione dei contenuti) e, presso grosse corporation, sistemi come questi possono essere rinvenuti sin dai primi anni novanta. All'inizio del millennio i sistemi di gestione dei contenuti per le imprese erano piuttosto costosi ed i costi superavano i milioni di dollari per la consegna, lo sviluppo ed il supporto. Gli utilizzatori classici di CMS sono siti di news come la CNN ed il New York Times il quale ha rigide direttive editoriali ed una profonda vastità di contenuti.

Ma una varietà di diversi domini può essere modellata usando gli strumenti di gestione dei contenuti, inclusi brochureware, commercio elettronico, intranet aziendali, gestione di corsi didattici ed organizzazione di community.

Come le organizzazioni iniziarono a crescere oltre le capacità dei siti di prima generazione, essi cercarono un ricambio che permettesse loro di amministrare i siti in prima persona, senza alcuna specifica competenza tecnica. Molti sistemi di gestione dei contenuti artigianali furono sviluppati ma fu soprattutto quando i blog e le wiki ottennero popolarità che interfacce più ricche e più potenti furono sempre più richieste. Allo stesso tempo i software FOSS interessati a colmare questa lacuna si facevano sempre più maturi e i progetti si consolidavano attorno a poche importanti piattaforme.

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.

I progetti software come Plone sono spesso fraintesi focalizzandosi esclusivamente sulla loro piattaforma tecnologica sottostante. Una miglior rappresentazione la si ottiene considerando l'ampia ecologia in cui la piattaforma è incorporata. Come Paul Everitt, fondatore della ZEA Partners e direttore esecutivo delle Plone Foundation, ama ripetere: "Il software è un manufatto della community". Una più matura elaborazione dell'ecologia del progetto tecnologico prende in considerazione la piattaforma, la community ed i processi che li legano. Questo modello ecologico di progetti software incorporano il ciclo di vita dinamico del progetto nel tempo e getta luce sul come il progetto potrebbe lavorare in circostanze complesse e non previste.

Gli ambienti Plone tipicamente presentano peculiarità alle persone che usano il software; molte sotto forma di innovazioni e decisioni che la community Plone decise di incorporare in esso. La community include i venditori (singoli individui, organizzazioni, corporazioni ed Università che partecipano allo sviluppo della piattaforma), i clienti (singoli, enti pubblici, organizzazioni non a fine di lucro che firmano i contratti con i venditori per creare soluzioni basate su Plone) e gli utenti (amministratori, editori, membri e visitatori dell'ambiente del cliente). Queste diverse community di partecipanti sono connesse le une alle altre attraverso strutture e processi alcuni dei quali formali, altri informali che spaziano da entità di tipo legale, agli intermediari, fino a mailing list mediate tecnicamente e cyber spazi collaborativi. Il progetto Plone non mira a far creare da una sola mano ruoli e processi che costituiscono il suo modello ecologico. Al contrario, si aggiungono costruzioni a costruzioni sull'edificio del movimento del free software, utilizzando molti degli strumenti e delle pratiche rinvenute all'interno dei processi stessi, infondendo nel progetto i sapori della cultura di cui sono fatti.

Le ecologie FOSS sono state un terreno di coltura per diversi modelli di struttura e governance che promuovono l'apprendimento di tipo costruzionista all'interno della community. Dal momento che la scrittura di software è considerata un atto di espressione creativa è prevedibile che gli artefatti creati da una software community intercettino i valori di quella community attraverso l'inclusione (o l'esclusione) di caratteristiche e le metafore utilizzate nel software da loro creato.

Il ricorsivo interrogarsi sulle meta strutture è un pattern abituale nel pensiero di un programmatore e non sorprende affatto vedere questo labirinto analitico che si curva su sé stesso. La vicinanza della community all'architettura dei propri canali di comunicazione incoraggia una attitudine riflessiva verso le loro proprie super strutture comunicative.

“Mangia quel che dai al tuo cane” è un detto comune nel settore della tecnologia utilizzato per indicare un processo che consuma il prodotto da lui stesso generato. Progetti FOSS regolarmente consumano altri prodotti FOSS creando un loop di feedback che rinforza i processi ed i valori apprezzati da quelle community. Il software che gestisce i code repository e i sistemi di monitoraggio e gestione dei bug hanno incorporati in sé stili di collaborazione, costruzione del consenso, presa di decisione, e risoluzione dei conflitti che percolano attraverso la community come fosse un unico insieme. Pratiche culturali incentrate su mailing list e chat di gruppo mettono insieme persone con le idee e persone che possono operare in base a tali idee. Le Wiki e le conferenze auto organizzate incoraggiano un'azione motivata in modo autonomo, le “produzione peer” , non come è di solito in risposta alla gerarchia o all'autorità. I progetti FOSS sono organizzati per la community e danno il via libera alla conoscenza, non alla produzione guidata dal mercato o alla vendita. I loro strumenti incorporano e riflettono queste priorità. Si potrebbe dire che, durante il processo, essi sono quello che mangiano.

Tornando a New York il nostro progetto contro il tabacco accusava ritardi e correzioni troppo comuni nel mondo software. Ma, come la Abstract Edge iniziò ad affrontare i problemi, fu chiaro che Plone rappresentava una potente strumento per affrontare una ampia serie di sforzi.

Per un programmatore lavorare come mercenario può essere devastante dal punto di vista della morale. Nella maggior parte delle situazioni questo lavoro è del tipo "o la va o la spacca", intendendo con ciò che che una volta scritto non deve più essere rivisto. La pressione di consegnare una soluzione rapidamente spesso avviene a scapito di un attento design, e le briciole sotto il tappetto non sono nulla di cui andare fieri. Esiste una scarsa continuità tra le diverse committenze, ed i progetti individuali raramente danno l'opportunità di sviluppare una struttura sofisticata, o di rispettare una certa sensibilità estetica nel creare del bellissimo software o nello scrivere dell'elegante codice. Lo sviluppo di software è una forma di produzione le cui caratteristiche ricordano da vicino quelle dell'artigianato tradizionale. Le metafore che dominano in questa attività ruotano tutte attorno a: oggetti, costruzioni, fabbricazione, e gli esperti vengono considerati dei virtuosi nella loro materia.

Come altre forme di fabbricazione manuale, scrivere software richiede immaginazione, inventiva ed ingegnosità. Se da un lato ci sono molteplici tentativi per automatizzare e componentizzare/modularizzare alcuni aspetti della produzione di software, questo resta fondamentalmente un atto creativo che si basa molto sul giudizio umano e sull'intuizione e, a maggior ragione, sul lavoro di gruppo e la collaborazione. In un'era in cui l'ambiente software si fa mediatore delle dinamiche dell' interazione umana, la progettazione dell'architettura software è molto più che una semplice analogia. Il software è arrivato ad assomigliare all'architettura tradizionale come forma d'arte importante e molti programmatori venerano la propria professione, preservandone l'integrità e considerando i prodotti del loro lavoro come importanti ed influenti. Per i singoli programmatori che abbiano a cuore i propri prodotti o il proprio lavoro, avere scarsa abilità d'artefice è considerato demoralizzante e frustrante. Ci sono alcuni stili di consulenza in cui il valore artistico e l'attenzione per i dettagli sono valorizzati, ma in molte situazioni lo standard è "tagliare corto". Con una eccellente gestione del progetto riesce facilmente ad instaurarsi la fiducia tra il cliente e l'agenzia, ma resta difficile stimolare una dinamica che contempli anche la buona fede. Partecipare ad un progetto open source ci permise di oltrepassare le limitazioni e le costrizioni della condizione oppressiva dettata dal lavoro mercenario e ci permise di rifugiarci in un mondo di auto miglioramento, espressione creativa e progettazione riflessiva. Il software funzionava come un oggetto intermedio per la collaborazione, tagliando fuori le limitazioni di tempo e di spazio. Introdusse continuità tra i nostri progetti e ci permise di collaborare con altri sviluppatori e aziende senza incorrere in aggravi burocratici costosi.

Per un free lance indipendente o per un impiegato in una piccola ditta è difficile trovare colleghi da cui imparare ed anche le sviolinate dei superiori sono poca cosa in confronto ad un onesto criticismo e rispetto da parte di professionisti con esperienza. Non c'è nulla di più apprezzato da chi vuole attivamente imparare che vedere il proprio lavoro esaminato e corretto da qualcuno di cui si rispettano ed onorano le abilità e la comprovata esperienza. Le community open source offrono esattamente questo tipo di ambiente di apprendimento, con dinamiche motivazionali che sono simili a quelle osservate nel mondo accademico. Pubblicare un pezzo di codice, farsi accettare una patch ed ottenere il privilegio della commessa alle repository del progetto sono forme di ricompensa nel mondo del lavoro “peer” che riconoscono e convalidano le abilità ed i riconoscimenti accumulati del programmatore.

Oltre al capitale accumulato in reputazione e l'apprezzamento sociale guadagnato e scambiato all'interno dei progetti FOSS, i programmatori godono di personale soddisfazione e divertimento nel loro lavoro. Molti sviluppatori FOSS sono degli hobbisti molto tecnici e la spiegazione del loro coinvolgimento risiede nella congiunzione tra il lavoro ed il gioco. Evadere le richieste quotidiane e irritanti dei clienti è il tipo di lavoro a cui solo un pervertito potrebbe volontariamente sottoporsi.

Comunque, il tipico lavoro su un progetto di free software è composto da socializzazione professionale e comunicazione, così come da costruzione di eleganti ed armoniosi ambienti e queste attività possono essere incredibilmente gratificanti.

Diversamente da quanto si crede molti sviluppatori di free software guadagnano un rispettabile stipendio per questi progetti, sia attraverso servizi diretti sia attraverso un datore di lavoro che li sponsorizza. Costruiscono inoltre una stabile carriera ed alle volte creano business intorno ai loro rispettivi entourage . Anche progetti free software con impegno ideologico, come possono essere Debian o Wikipedia, pagano lo stipendio ai membri per risolvere funzioni chiave che hanno dimostrato di essere carenti quando affidate alla gestione su base volontaria.

Dopo Rotterdam sono seguiti molti altri “sprint” e diverse conferenze. L'enfasi internazionale suscitata da Plone ha un qualcosa di unico ed il suo forte supporto alle funzionalità multilingua ha aiutato a creare un positivo loop di feedback. I governi europei e molte municipalità hanno spesso scelto Plone perché finanziare lo sviluppo di Plone avrebbe fatto restare i loro investimenti in progetti nel territorio locale, esattamente l'opposto del rimpinguare le casse di compagnie come Microsoft, IBM o Sun. Questo, a sua volta, ha aiutato a migliorare il supporto multilingua di Plone: cosa che a portato ad una adozione diffusa a livello internazionale. Siamo stati in posti come Berna, Vienna e Napoli ed abbiamo anche partecipato ad uno sprint che si è tenuto in un castello austriaco. Non avrei mai immaginato che diventare uno sviluppatore software mi avrebbe portato a girare col mio zaino per mezza Europa quando non ero neanche trentenne, né tanto meno che avrei convinto il mio capo a finanziare tali trasferte. Molti di quelli che ascoltavano la conferenza con me erano free lance indipendenti che si auto finanziavano per frequentare questi ritrovi.

I ritrovi erano opportunità incredibili ed occupavano un inedito ruolo tra il gioco ed il lavoro. In parte erano lavoro, in parte vacanza. Spesso i partecipanti riuscivano ad aggiungere qualche giorno di vacanza prima o dopo l'evento e gli organizzatori spesso includevano giri turistici e feste popolari. La community funzionava come un incrocio per i network di diversi settori. Grandi società, non profit, governi e settori educativi si sono tutti incontrati tra loro attraverso l'intermediazione dell'ecologia di questo progetto. Eravamo galvanizzati da questi posti esotici ma il compito affidato in questi incontri era reale e significativo. Si produceva, ma in modo auto organizzato, auto determinato e auto soddisfacente.

Mentre le conferenze commerciali ed accademiche sono attività tradizionali per alcuni professionisti, i programmatori FOSS mettono le loro personalità e il proprio stile durante gli eventi. Le varietà di formati alle conferenze del free software sono conformi alla loro etica non gerarchica e tipicamente fai da te. Nessuno legge le relazioni agli altri, ci sono solitamente sessioni "simili coi simili" organizzate ad hoc e sul momento, con molto tempo dedicato alla conversazione e poi la cosa preferita da tutti: le "conferenze lampo" - dove ciascuno ha a disposizione cinque minuti per illustrare un'idea o un progetto in fase di realizzazione. Questo fa sì che si creino diversi tipi di spazi e dinamiche di interazione tra i partecipanti. In contrasto con la stereotipata conferenza formale, le conferenze di free software hanno la reputazione di essere eventi divertenti, da non perdere.

La dinamica sociale che sta alla base della community di Plone mi fa venire in mente la gilda medioevale o una moderna associazione di studenti del college. Oltre alla incredibile sproporzione tra i rappresentanti dei due sessi, i partecipanti spesso adottavano dei nickname, passavano attraverso un rituale iniziatico labirintico, e venivano pressati dai colleghi a contribuire allo sviluppo della community così come immaginata. Specialmente dal momento che gli sviluppatori regolarmente comunicano utilizzando media elettronici, queste punteggiate opportunità di interagire di persona facilitano il ruolo comunicativo, rafforzando molto le pratiche culturali ed i legami sociali.

Gli "sprint" furono anche piuttosto produttivi essendo un' opportunità per focalizzarsi su una sfida scelta da sé, senza le tipiche interruzioni del classico ufficio. Le condizioni erano favorevoli ad uno “stato di flusso" dando la possibilità ai programmatori di essere assorbiti totalmente, una condizione essenziale per la produttività del programmatore. Questo stato mentale è caratterizzato da energia, concentrazione, perdita del senso del tempo e immersione ed è pensato per emergere con un appropriato equilibrio tra la sfida e le abilità. La programmazione è quel tipo di attività che è estremamente adatta per sollecitare il flusso, specialmente se in condizioni ambientali ottimali.

Il mio collega fu sempre più coinvolto nel progetto, fino al punto in cui il suo lavoro per la Abstract Edge divenne una attività transitoria che riempiva il tempo tra una conferenza ed il lavoro FOSS. Invece di dividere a metà le nostre responsabilità di sviluppo iniziai a fungere da interfaccia tra lui ed il management, al fine di permettergli di lavorare su problemi infrastrutturali più astratti. Ero il responsabile per la specifica richiesta del cliente mentre lui lavorava su strumenti più generalizzati ed astratti che io avrei poi usato per risolvere gli specifici dettagli. La disposizione ricordava lo Sviluppo e Ricerca di una grande azienda, ma noi eravamo solo una piccola ditta e si supponeva che il nostro lavoro venisse retribuito.

Quando infine lasciai la Abstract Edge ero in grado di portare il mio software e la mia community di colleghi ed amici insieme a me nel mio nuovo lavoro. Si nota una chiara ironia nel fatto che assicurarsi continuità attraverso diversi lavori è dato dall'essere sicuri che nessuno possa attribuire a sé i prodotti intellettuali del tuo lavoro. Nella maggior parte degli impieghi un dipendente non possiede scritto mentre lavora. Ma, se il software è realizzato sotto licenza libera, si può continuare ad usarlo e svilupparlo anche dopo la partenza dal vecchio posto di lavoro. Da questa prospettiva scrivere software aperto, per un dipendente con busta paga, è un potente atto di antagonismo. Ma siccome molte grosse aziende il proprio business sul software lo stanno rivedendo in termini di servizi e l'intera industria sta migrando dalla vendita di artefatti software alla vendita di servizi legati al software, la liberazione del software è economicamente razionale e l'antagonismo sta diventando la norma. Le aziende iniziano a riconoscere che possedere il software è un obbligo e non un asset e per i singoli fa parte del loro portfolio personale ed un curriculum delle realizzazioni passate.

Alcuni membri della community di Plone hanno recentemente organizzato una campagna per impegnare pubblicamente parte del proprio tempo disponibile per lavorare al progetto.

Il "10% Plone Manifesto" è un esplicito tentativo di esercitare il controllo sulla direzione in cui cresce la piattaforma, e sul tipo di problemi a cui gli sviluppatori dedicano il proprio tempo. L'introduzione del manifesto spiega:

"Negli ultimi anni molti di noi hanno creato aziende di consulenza o sviluppo Plone con le radici nella community di Plone. Per molti di noi è stato come un sogno che si avvera - poter guadagnare scrivendo software libero , allo stesso tempo lavorando in questa grande community.

Ma il tempo fa il suo corso e la vita di tutti i giorni, il mutuo, i soldi, e dover guadagnare per crescere i bambini, tutto ciò ci ha spinti nel grigio mondo degli impiegati piuttosto che grandi programmatori di software libero.

Sicuro, noi pubblichiamo software libero, non in modo occasionale, ma la maggior parte dello sviluppo è guidato dai bisogni dei nostri clienti, non da quello di cui noi crediamo Plone abbiamo bisogno o da quel che noi vorremmo costruire.

Prendiamo il controllo!

Vogliamo stare lontani dalla curva discendente. Vogliamo restare aggiornati. Vogliamo continuare a contribuire, anche in un mondo in cui si scrive il software per la pagnotta. Ispirati dalla pratica della sorprendente Google, ecco che sferriamo il nostro colpo preventivo; il 10% "Plone Manifesto".

Questa dichiarazione racchiude il sentimento che la comunità cerca di preservare. Indipendenza ed auto determinazione sono i valori di base per questi sviluppatori ed essi provano a reclamare il controllo sul tipo di software che sviluppano. Come si evince dal linguaggio utilizzato molti di essi, si considerano parte di una pacifica rivoluzione. Lottano per abbattere e frantumare i poteri e le gerarchie dominanti, proponendo una benevola ed illuminata alternativa, il tutto mentre si pagano le rate del mutuo e si mette su famiglia.

Come suggerisce questo saggio molta della partecipazione in un progetto FOSS va oltre il concetto di lavoro dell' homo faber di Hanna Arendt e chiaramente include la sua formulazione del concetto di azione. L'azione è manifesta nella capacità dei partecipanti di iniziare i principianti, e nell'asserire pubblicamente la propria identità formalizzata in comunicazioni alla pubblica società. Per la Arendt queste azioni sono intrinsecamente politiche dal momento che permettono ai suoi partecipanti di esercitare la loro influenza attraverso il discorso e la persuasione. Gran parte del valore didattico e forse gran parte del fascino esercitato sui singoli nel partecipare ad un progetto FOSS deriva dalla messa in pratica di queste alte forme di vita activa.

L'esperienza della condivisione e della partecipazione ad una community attiva ha il potere di spronare gli individui all'azione esponendoli a scelte politiche e sfide civili reali, nel senso proprio delle parole della Arendt. I progetti FOSS possono aiutare a stimolare l'autodeterminazione e permettono agli individui di sperimentare variazioni nella gestione della vita democratica che sono vitali nelle nostre emergenti società. Queste esperienze si traducono facilmente e direttamente nelle forme tradizionali di attivismo politico di base ed è un luogo comune che la partecipazione ad un progetto FOSS funzioni come forma di indottrinamento ( solitamente attraverso movimenti di software libero e cultura libera che fungono da “gateway”) insegnando ai partecipanti ad impegnarsi con la pratica politica e a testare personalmente il frutto dell'azione politica.

A parer mio, l'esperienza di aver lavorato così da vicino ad un progetto di software libero ha permesso una mia trasformazione - a livello cognitivo, personale, emotivo e sociale. Non solo la partecipazione a questo progetto è stata tecnicamente istruttiva, ma mi ha istruito su una serie di tematiche etiche e di gestione e ha contribuito ad elevare la mia consapevolezza politica. Ho fatto amicizie durevoli, ed ho iniziato a interessarmi e preoccuparmi per le cause di giustizia sociale, e il fatto di migliorare le mie condizioni di vita mi ha dato carica. Mentre le mie esperienze sono personali ed uniche, questa situazione di raggiunta consapevolezza non è affatto isolata. Le mie esperienze mi hanno dimostrato che in questi progetti c'è molto più della sola tecnologia ed anche di più dell'architettura ed ingegneria sociale - sono inoltre una sorta di una capsula di Petri per l'attivismo sociale,il suo impegno e il suo mantenimento, le cui forme dovrebbero essere studiate da vicino.

Il sistema scolastico americano ha smesso di insegnare ai bambini la condivisione negli asili nido, che lo si sia capito o no. L'esperienza diretta della partecipazione alla produzione in comune e alla pari conferma la controintuitiva affermazione che la condivisione non è necessariamente altruistica, dal momento che può sostenere l'interesse personale e portare ad un maggior valore e salute. Con la cooperazione e la fiducia tutti possono aver accesso ad una fetta un po' più grande della torta, raggiungendo un risultato di maggior valore che non attraverso una egoistica competizione. Il trattato di Yochai Benkler "La salute dei network" adduce forti ragioni per dimostrare l'esistenza di queste realtà economiche, ma molti imparano meglio attraverso l'esperienza diretta. Molti continueranno a sospettare dei suoi argomenti finché le loro stesse esperienze li condurranno a portare argomenti a favore di tale teoria.

Imparare come condividere è la lezione più difficile che in molti si ritrovano ad affrontare e i programmatori di software libero alle volte danno dimostrazione di questa etica in modi spiritosi. Essi condividono birra, sigarette e addirittura battute sul condividere partner sessuali; il tutto condito dal motivetto "sorgente aperta". In molti ritengono di essere lì a lottare per un bene comune, un bene che trascende quel particolare progetto o cliente che consuma la loro vita quotidiana. Stanno ridefinendo i confini tra il gioco e il lavoro, tra il lavoro e l'azione, e tra fabbricazione e comunicazione. Sono parte di un movimento, ma continuano senza sosta a costruire movimenti. Un carattere alla volta.