L’edizione 2010 della conferenza Free/Open Source Software in Academia Conference (fOSSa) è stata molto interessante, come potete leggere in un altro mio articolo. In questa pagina voglio parlare di uno solo dei temi più o meno espliciti della conferenza, che ho ritrovato in diversi interventi: qualcosa di importante per chiunque abbia (o dovrebbe avere) a cuore una gestione efficace della propria organizzazione e delle relative risorse umane in ogni settore, non solo nell’industria del software!

I grandi progetti di sviluppo di Software Libero/Open Source (FOSS in inglese) hanno molte meno esigenze di coordinamento di quelli della stessa complessità portati avanti da aziende tradizionali. Questo non significa che funzionino per magia, ovviamente: perché abbiano successo ci vogliono comunque tanta pianificazione e lavoro di gruppi ben motivati, cioè tanta buona dirigenza. Nel suo intervento al fOSSa proprio su questo tema, Martin Michlmayr ha fatto notare, fra le altre cose, che:

• le qualità essenziali di un buon manager di progetti FOSS sono leadership, capacità di coordinare il lavoro degli altri e motivarli adeguatamente, organizzazione, pianificazione. In particolare, secondo Michlmayr, motivare adeguatamente significa assicurarsi che i partecipanti al progetto sentano che col loro lavoro aiuteranno altre persone al di fuori del progetto a risolvere i loro REALI problemi
• per avere successo, chi dirige una comunità o uno specifico progetto FOSS deve:
• sbarazzarsi rapidamente di chi pianta grane per il solo gusto di farlo, degli incompetenti o di chi non contribuisce perché ha già troppo da fare. Insomma, nel FOSS non c'è posto per il Principio di Peter
• (desiderare sinceramente di) stabilire contatti diretti con tutti i partecipanti al progetto, costruendo relazioni dirette e personali (anche quando sono solo attraverso Internet) con le persone che effettivamente possono aiutare la comunità e sono davvero interessate al successo del progetto
• prima di entrare in un progetto FOSS o di iniziarne uno da zero, i programmatori dovrebbero prima di tutto chiedersi se davvero necessario che quel progetto veda la luce o che loro si aggreghino

Questi invece sono, nello stesso ordine, i pensieri che mi sono venuti istintivamente mentre ascoltavo ogni punto:

• Motivazione:
• quanti dei problemi e bisogni per cui le grandi aziende vendono "soluzioni" NON sono reali, e quanto questa consapevolezza influenza la motivazione di chi ci lavora?
• Procedure e strutture delle grandi aziende sono troppo rigide per far sentire liberi (di fare bene il loro lavoro, non certo di grattarsi la pancia!) la maggioranza dei propri dipendenti, ma quella una libertà che ha un effetto diretto su motivazione e felicità generale delle persone. Ho anche l'impressione che se i programmatori che sono dipendenti di qualche grande azienda e ricevono da questa l'incarico (o il permesso) di lavorare su progetti FOSS sono in media più felici dei loro colleghi, lo sono anche, o proprio, perché progetti come quelli gli danno interazioni sociali, visibilità e prestigio anche al di fuori dell'azienda. Quanto si potrebbe applicare questo principio in altri campi?
• A me questo suona tanto come "per avere successo un manager FOSS deve fare (e può farlo!) tutto quello che a un dirigente d'azienda è proibito da regolamenti o interessi e giochi di potere interni all'azienda pi o meno inconfessabili"
• Quante persone possono permettersi il lusso di farsi domande del genere quando cercano lavoro? Come sarebbe il mondo se i colloqui di lavoro reali potessero funzionare allo stesso modo? "Ipotizziamo per un attimo che io sia davvero bravo in questo lavoro che lei mi offre: potrebbe per favore spiegarmi, al massimo in 100 parole, come e perché questa cosa che mi paghereste per fare far del mondo un posto migliore?"

In un altro intervento Dave Neary ha parlato di anti-modelli (di comportamento) nelle comunit FOSS (Community anti-pattern), cio di comportamenti buoni in teoria, ma che in pratica finiscono per creare problemi di tutti i tipi, ma sempre sociali, non tecnici. Un anti-modello che io ho incontrato personalmente in passato la cosiddetta discussione per il portabiciclette o Legge di Parkinson: la quantità di tempo impiegata per approvare ogni voce di un budget inversamente proporzionale alla quantità di denaro richiesta. Questo accadrebbe quando i sommi dirigenti:

• prima approvano senza battere ciglio spese enormi per cose che non capiscono (ad esempio miliardi di Euro per una centrale nucleare), solo per non fare la figura degli ignoranti
• ma poi discutono fino all'esaurimento colore e ogni altro dettaglio insignificante del portabiciclette per i tecnici della centrale, solo per mostrare a tutti quanto sono competenti e sinceramente interessati all'intero progetto

Infine, durante l'ultimo giorno di fOSSa, Ross Gardler, vicepresidente della Apache Software Foundation ha spiegato che tutti i progetti della fondazione producono software di buona qualità perché (insieme ad altri fattori, ovviamente) chiunque lavora sul progetto ha la possibilità di essere ascoltato da tutti gli altri e di votare sulle decisioni importanti".

La conclusione? Che persone, obiettivo e visione vengono prima dei prodotti

Io ho lavorato per diversi anni in una grande azienda ma facendo altre cose, non progettazione di software. Nonostante questo, mentre ascoltavo Martin, Dave e Ross mi pareva davvero che stessero parlando dei vari dipartimenti di cui ho fatto parte.

Certo, ci sono tantissime cose che non si possono trasportare dall'industria del software ad altre attività. Medici e personale delle pulizie, tanto per fare due fra un milione di possibili esempi, non possono certo lavorare dove e quando preferiscono, è chiaro. Per le presentazioni che ho riassunto qui sono tutti esempi di come, oggi, le discussioni sul software (libero) possono essere importanti, in mille modi diversi, anche per chi non sar mai un programmatore!

Molte aziende e altre grandi organizzazioni tradizionali (a partire dalle Pubbliche Amministrazioni) che ho incontrato fino a oggi potrebbero e dovrebbero davvero copiare un'abitudine o due da chi gestisce singoli progetti o comunit FOSS. Inoltre, come dicevo tempo fa a un gruppo di sociologi, chi predica la libertà del software e tutto il resto del mondo dovrebbero davvero iniziare a parlarsi più spesso. Introdurre lo studio dei progetti FOSS nei Master di Direzione d'Azienda potrebbe essere un buon modo di cominciare. Perché convincere aziende e Pubbliche Amministrazioni ad adottare certe abitudini del mondo FOSS, tipo l'apertura e il pragmatismo, potrebbe essere molto più importante e urgente che convincerle a usare quel tipo di software.