Pirro e l'Oracolo

Quando iniziai ad occuparmi di Linux e di open source nel 2001 l'unico antagonista del colosso microsoft nel campo dell'office era il pacchetto openoffice che, staccatosi da staroffice iniziava a muovere i primi passi. In quegli anni il logo della suite, pesante e monolitica era un globo azzurro con due gabbiani a simboleggiare la libertà dal software proprietario.
È quindi per me abbastanza buffo aprire l'evoluzione ultima di questo prodotto e trovarci la scritta ORACLE che nell'ultima release ha sostituito SUN. Sia chiaro, sono entrambi due aziende i cui interessi non necessariamente sono allineati con quelli della comunità open source, ma Oracle per me rappresenta qualcosa di più per il semplice fatto che appartengo a quella che chiamo la setta dei DBA ORACLE che, un po' come il mondo parallelo degli inservienti di scrubs, ha un modo molto particolare di porsi nei confronti dei database.

I migliori prodotti del mondo
Non ci sono dubbi. Quando si parla di Oracle stiamo avendo a che fare con il miglior software presente sul mercato. Niente e nessuno lo batte. I vari prodotti a disposizione di clienti e sviluppatori, offrono una vasta gamma di funzioni che progressivamente si sono affiancate al database per definizione. E se qualcun altro fa le stesse cose, Oracle le fa meglio.
Questa è più o meno la conversazione tipo che si può affrontare con un DBA Oracle parlando dei prodotti della casa di Redwood Shores. Personalmente, facendo parte di questa categoria mi sento di confermare quasi tutte queste affermazioni, principalmente per un motivo.
La qualità di un qualsiasi professionista che abbia lavorato con Oracle è fuori discussione. Chiunque lavori con questi sistemi è forzato a dare il massimo senza sconti in quanto l'elevata complessità e la ricchezza di funzionalità rappresentano una sfida costante con la quale confrontarsi e accrescere il proprio bagaglio di conoscenze.
Se poi ci mettiamo un settore marketing che fa bene il suo lavoro allora le affermazioni in corsivo possono essere prese come memento da scolpire nella pietra anche se poi nei fatti, specialmente per alcuni prodotti non strettamente legati alla gestione dei dati, si fa fatica a riconoscerne il primato.
Alla luce di ciò è quindi stato un evento significativo nella mia vita professionale, quando di punto in bianco ho deciso di occuparmi di PostgreSQL, il vero concorrente open source di Oracle, che in maniera alquanto altisonante dichiara di essere il più avanzato database libero.

Un elefante dai piedi d'argilla
Nel lontano 2005 la versione di produzione era la 7.4 che, confrontata con la sua controparte, Oracle 9i, risultava essere alquanto arretrata e rudimentale.
Difficile reggere il passo con l'assenza di una gestione seria della memoria una rozza gestione dello spazio disco e con carenze strutturali che esponevano al rischio di corruzione dei dati sia in caso di crash che di riempimento della directory data.
La mia scelta però fu ben motivata in quanto il salto generazionale che stava per avvenire con la versione 8.0 era notevole. Con questa versione venivano finalmente introdotti concetti moderni come le tablespace e nel contempo avveniva una ristrutturazione dell'algorimo di gestione della memoria, che passava dal rudimentale LRU al più complesso 2queue. Venivano infine risolti i problemi di corruzione dati dovuti a crash del database e finalmente compariva un meccanismo di protezione per il failure prodotto dal wrap around dei transaction id.
Alla luce di ciò viene spontaneo chiedersi come mai il livello di penetrazione di questo notevole prodotto è ancora modesto. Le motivazioni che ho analizzato sono varie e complesse ma generalizzando posso inquadrarle in due grossi blocchi.
L'assenza di un sistema strutturato per il supporto e la documentazione e un'advocacy che fa acqua da tutte le parti.

Che ce ne facciamo del petrolio? Noi abbiamo il boiler!
Torniamo un attimo al mondo dei DBA Oracle. La risposta alla domanda “dove trovo la documentazione per l'operazione XY?” è sempre la stessa: “il metalink”. Chiunque abbia esperienza su Oracle prima o poi s'è confrontato con questo repository di documentazione e, in caso di prodotti con licenza non da sviluppatore, anche di supporto e assistenza tecnica.
La stessa domanda rivolta ad un DBA PostgreSQL ha un range di risposte non deterministico: “la mailing list admin, il wiki, la chat IRC, il sito tal dei tali, mandami una mail che ti dico, etc. etc.”. Se poi osserviamo lo scalcinato panorama italiano la situazione è ancora peggiore in quanto, a parte il tentativo che ho portato avanti da solo di produrre un sito di documentazione in italiano con annessa mailing list, non c'è assolutamente nulla che dia un minimo di parvenza di professionalità comunitaria.
Difficile quindi convincere qualcuno ad adottare un prodotto senza che sia definito un sistema di documentazione ufficiale che imponga uno standard di formattazione dei documenti con contenuti ufficialmente approvati dal team di sviluppo.
Una cosa che ho imparato a fare nei primi mesi di apprendistato come DBA Oracle è stata proprio la messa in opera di documenti organizzati ed esaustivi per permettere a chi non fosse informato sullo stato dei sistemi di avere una visione della situazione e degli eventuali rischi/problemi ad essa legati.
Devo ammettere che l'azienda per cui ho lavorato e che mi ha permesso di raggiungere una buona professionalità è particolarmente strutturata, ma queste cose non si imparano dall'oggi al domani e sicuramente un buon incentivo ad attestarsi in pratiche di questo genere è dato anche dal lavoro quotidiano con un un prodotto, le cui metodiche sono orientate alla chiarezza ed al consolidamento di pratiche di qualità.
Pertanto finché gli utenti non avranno un sistema che cataloghi la documentazione in maniera strutturata e dotato di un motore di ricerca che permetta di accedere ai singoli documenti in maniera mirata le possibilità di portare un utente dal mondo dove la risposta è sempre rintracciabile, quale è un Oracle o un MySQL, volendo restare nel mondo open source, saranno sempre molto basse. Inutile dire che il wiki o l'accesso agli archivi delle mailing list, non sono assolutamente adatti a tale scopo.

La vittoria di Pirro
Sottovalutare la strategia di marketing è una grave mancanza, ma ci sono comportamenti decisamente peggiori.
Ad esempio insistere in una modalità operativa priva di spunti innovativi che va avanti da anni è assolutamente deleterio sia per il prodotto che per la comunità.
Per spiegarmi meglio farò un esempio che mi ha toccato di persona.
Fino al 2006 intorno a PostgreSQL ruotavano, e tuttora esistono, un tot di conferenze organizzate con cadenza annuale e prettamente orientate agli addetti ai lavori. Eventi di questo genere permettono un incontro fisico degli sviluppatori che sono sparsi ai quattro capi del mondo e, oltre a delineare la direzione dello sviluppo, permettono un interscambio decisamente più efficiente dell'approccio remoto.
Nel 2007 grazie ad una mia idea fu organizzato un evento completamente diverso per natura e per contenuti, il PostgreSQL Day, meglio conosciuto come PGDay. La novità di questa conferenza, della cui organizzazione mi sono occupato nella prima edizione, fu prima di tutto negli argomenti dei talk, che finalmente erano diretti ad un pubblico di non addetti con sostanziali ammiccate ai responsabili dei CED.
Altra due novità importanti sono state la presenza di mini corsi di formazione tecnica e la quasi totale assenza di spesa per i visitatori, salvo i suddetti mini corsi la cui iscrizione aveva un costo di 11 euro.
Il risultato di questa conferenza fu decisamente entusiasmante visto che una buona percentuale dei circa 200 partecipanti era composta da responsabili IT o addirittura titolari d'azienda, venuti ad informarsi su di un prodotto potenzialmente valido le loro imprese.
Sfortunatamente la conferenza del 2007, tenutasi a Prato, è rimasto un evento isolato in quanto, nel 2008 si è tenuta quella che è poi è diventata la conferenza del PGDay europeo, con un programma internazionale che si è appiattito di nuovo su argomenti per addetti ai lavori e al cui interno è stato inserito il PGDay Italiano.
Il programma di quest'ultimo lo considero, oggettivamente alquanto mediocre con dei talk ad argomentazione prettamente tecnica e privi di omogeneità di traccia.
Sfortunatamente, non avendo preso parte all'organizzazione di questo evento ne del successivo, avvenuto nel 2009 e il cui programma è sostanzialmente identico a quello del 2008, non posso entrare nel merito delle scelte fatte dal comitato organizzatore.
Fatto sta che, dopo un evento che sembrava aver scosso il panorama di PostgreSQL dal suo torpore di prodotto di nicchia, nessuno ha voluto continuare su quella strada che aveva reso visibile il database a potenziali utilizzatori, rendendo il PGDay del 2007 una vittoria di Pirro.