Il delfino e l'elefante

È qualche giorno che il google alert settato sulla parola chiave PostgreSQL mi inonda di link ad articoli, per lo più in italiano, che parlano dello spegnimento dei server dedicati alla buildfarm, un sistema applicativo per il test e la ricerca di bug su PostgreSQL in maniera automatizzata, da parte di Oracle.

Faccio una piccola divagazione a beneficio di chi non conosce le varie vicissitudini che hanno caratterizzato il mondo dei DBMS open source negli ultimi anni.
Fino al 2007 la Sun Microsystems ha investito molto nel database PostgreSQL sia in termini di supporto che di sviluppo offrendo alla comunità un gruppo di server applicativi per la suddetta buildfarm e ponendo il DBMS dell'elefante al centro di un pacchetto integrato che sembrava potesse mettersi in competizione con prodotti commerciali di grande caratura e costo.

Successivamente ci fu un dietrofront clamoroso e le attenzioni di Sun si concentrarono su MySQL culminando nell'acquisizione di MySQL AB.
Nell'ultimo anno l'acquisto di Sun da parte di Oracle ha fatto si che MySQL stesso divenisse un prodotto di Oracle pur restando nella situazione anomala della doppia licenza GPL/Commerciale.

Personalmente dello spegnimento di questi server non mi importa nulla, anzi mi sembra una cosa alquanto normale visto che molto più di MySQL, che in tutta onestà non riesco a definire un Database Relazionale in senso ortodosso, PostgreSQL è un pericoloso concorrente della casa che produce il database per definizione.

Capisco che questa mia affermazione può essere oltremodo forte, specialmente per le orecchie delicate degli informatici italiani che spesso confondono la considerazione tecnica con l'attacco personale, ma non approfondirò ulteriormente questo concetto per evitare che questo mio scritto diventi un pesante trattato sui database relazionali infarcito di termini tecnici.
Lo stesso farò per il discorso sulla doppia licenza di MySQL.
Se volete approfondire questo pdf http://www.flameeyes.eu/articoli/mysqlsevil.pdf che chiarisce in maniera molto dettagliata tutte le implicazioni di questa anomalia.
Il motivo che mi ha spinto a scrivere è sostanzialmente una perplessità indotta da alcuni colloqui di lavoro su posizioni in cui veniva ricercato un DBA MySQL.

Le situazioni in cui mi sono ritrovato sono state fondamentalmente due.
La prima in cui una grossa ditta aveva deciso di affidarsi alla versione GPL di MySQL in quanto quella commerciale non aveva le funzionalità di cui avevano bisogno, e un'altra in cui era in atto una migrazione da una soluzione closed con database Oracle, ad una open source su database MySQL.

In entrambe le situazioni la domanda che mi è salita in gola è stata “why not PostgreSQL?”, considerato che l'utilizzo del DBMS dell'elefante porterebbe vantaggi non da poco grazie alle sue peculiarità che lo rendono molto più gestibile rispetto alla sua controparte forse-sono-open-source-ma-dipende-dalla-tua-licenza.

Nel primo caso l'utilizzo di PostgreSQL, essendo rilasciato sotto licenza BSD che a differenza della GPL non è infettiva, garantirebbe alla ditta il controllo completo sul codice sorgente senza dover sottostare a logiche commerciali ne tanto meno a politiche di rilascio forzato degli hack.

A discapito di ciò verrebbe da obiettare che PostgreSQL non ha un supporto commerciale solido ne tanto meno una comunità ricca come quella di MySQL. Inoltre l'assenza di funzionalità di replica degne di questo nome lo rendono inadatto a configurazioni di bilanciamento di carico tipiche invece della piattaforma MySQL.

In risposta a ciò posso solo affermare che con una struttura societaria in grado di personalizzarsi un DBMS il supporto esterno ha poco senso visto che la forza per fare tutto in casa c'è. Riguardo alla replica e al bilanciamento è da valutare quanto la necessità di averla dipenda da carenze di scalabilità del database piuttosto che da un vero bisogno indotto da carichi di lavoro importanti.

La seconda situazione, la migrazione dal prodotto closed ad open, dimostra una scarsa conoscenza del prodotto di destinazione e delle notevoli difficoltà che vanno a manifestarsi nel passaggio da un mero sistema operativo, solido ed efficiente quale Oracle è, ad un caricatore di plugin con una gestione della memoria rudimentale e con la gestione dello storage demandata a soluzioni di terze parti, quale MySQL è.
Inoltre, ricordando che MySQL AB acquisita da Sun è diventata un'azienda di Oracle, a conti fatti la transizione avviene da un Oracle affidabile ad un Oracle che fa finta di essere un database relazionale e che, secondo la mia modesta opinione, rischia di fare una brutta fine in quanto in diretta concorrenza con il prodotto gratuito, la XE, del colosso dei database.

Alla fine di questa breve considerazione viene quindi da chiedermi come mai i responsabili IT siano all'oscuro di un prodotto di classe enterprise come PostgreSQL.
Un DBMS non è un detersivo, la sua adozione avviene sulla base della conoscenza delle funzionalità del prodotto e sulla possibilità di ottenere documentazione chiara ed efficiente.

Da questo punto di vista la documentazione a corredo di PostgreSQL è notevole, ben fatta chiara e senza punti ambigui.
Quello che davvero manca affinché il prodotto venga visto dagli utilizzatori e dagli ISP sotto la stessa luce di MySQL è la presenza di una forma di certificazione di qualità sulle professionalità in gioco.

Volendo fare un paragone, vedo la rete di professionalità su PostgreSQL alla stessa maniera del web in Italia. In guazzabuglio di voci, spesso incompetenti, che però, per il fatto che non esista un'autorità certificante, si sentono autorizzate a dire la loro, spesso producendo castronerie dall'esito catastrofico.
È quindi chiaro come, nell'ambito ambito commerciale, una simile giungla sia un deterrente potentissimo all'adozione di un prodotto che invece potrebbe migliorare, e non di poco, le dinamiche aziendali.

Va bene quindi fare conferenze, documentazioni on line, promozioni e volantini.
Ma finché non ci sarà la certezza nei potenziali clienti che potranno contare su di una soglia di competenza minima nei professionisti di PostgreSQL il più avanzato database open source del mondo sarà sempre visto alla stregua di un gioco per smanettoni privo di potenzialità commerciali.