Su MySQL lo spettro del closed source?

Su MySQL lo spettro del closed source?

Sun sembra intenzionata a sviluppare funzionalità di MySQL closed source, riservate esclusivamente agli utenti paganti. Sulla questione, ancora confusa, si è sollevato un grande dibattito. Intanto sta per debuttare MySQL 5.1
Sun sembra intenzionata a sviluppare funzionalità di MySQL closed source, riservate esclusivamente agli utenti paganti. Sulla questione, ancora confusa, si è sollevato un grande dibattito. Intanto sta per debuttare MySQL 5.1

Santa Clara (USA) – Il celebre database open source MySQL sta attraversando una delle fasi più travagliate e cruciali della propria esistenza. Da una parte c’è l’attesa per la nuova versione 5.1, appena posticipata di diverse settimane e ora disponibile come release candidate, dall’altro lato ci sono i molti interrogativi sollevati dalla recente acquisizione di MySQL da parte di Sun .

Ad agitare ancor più le acque un post apparso sul blog di Jeremy Cole, noto consulente di MySQL. Cole afferma che Sun avrebbe intenzione di introdurre nella versione commerciale del database, la Enterprise, alcune funzionalità non presenti nella versione Community (gratuita): tra queste, il supporto ai backup online . “Questo rappresenta un sostanziale cambiamento al suo modello di sviluppo”, ha scritto Cole. “Fino ad oggi, infatti, tutte le nuove funzionalità sono state sviluppate sia per MySQL Community che per MySQL Enterprise”.

Alcuni hanno interpretato questa indiscrezione come la volontà di Sun di chiudere progressivamente il codice di MySQL , tanto che Slashdot ha ripreso la notizia titolandola Sun to Begin Close Sourcing MySQL : l’effetto, all’interno della comunità open source, è stato equivalente a gettare un fiammifero in una polveriera.

Ma come stanno realmente le cose? Cole afferma che Mickos ha confermato quanto da lui rivelato , ossia che Sun svilupperà delle nuove funzionalità per MySQL Enterprise 6.0 senza renderle disponibili nell’edizione Community. Sul forum di Slashdot Mickos ha però precisato che MySQL Enterprise 6.0 conterrà una funzionalità di backup nativa che sarà disponibile a tutti sotto licenza GPL. Il dirigente ha tuttavia ammesso che verranno sviluppati anche “add-on high-end”, che implementeranno funzionalità come la cifratura o supporteranno specifici motori di storage, che verranno forniti solo insieme all’edizione Enterprise. Mickos afferma che Sun non ha ancora deciso sotto quale licenza rilasciare questi add-on: si potrebbe trattare della GPL, di un’altra licenza FOSS o di una commerciale. L’ex CEO di MySQL AB ha poi detto che questa decisione era stata presa prima che Sun acquisisse la sua azienda, e ha garantito che il core di MySQL, nonché l’attuale codice del software, resteranno per sempre sotto GPL.

Mickos ha spiegato che l’add-on per il backup si interfaccerà con le API per il backup di MySQL come qualsiasi altro plug-in (commerciale o gratuito) di terze parti.

“Cosa c’è di sbagliato in questo?”, domanda l’utente Kristoph sul forum di Slashdot . “Per prima cosa, non c’è niente che impedisca lo sviluppo di soluzioni di backup open source per questa API, o che impedisca alle terze parti di creare le proprie soluzioni. Perché Sun non dovrebbe avere lo stesso diritto?”

C’è tuttavia chi teme che Sun finirà per eliminare dal ramo di sviluppo della versione Community buona parte delle funzionalità più avanzate, specialmente relative al backup e alla gestione dei database, trasformando di fatto l’edizione Community in una sorta di versione “lite” di MySQL.

Cole fa infine notare come MySQL Enterprise abbia una base di utenti assai più piccola rispetto a quella di MySQL Community. “Questo significa – afferma il consulente – che le funzionalità critiche saranno testate soltanto da pochi clienti. Così, di fatto, Sun fornirà ai suoi utenti paganti del codice non testato”.

Per il momento, a parte le precisazioni di Mickos pubblicate sui forum, dai vertici di Sun non è arrivato alcun annuncio ufficiale , e gli osservatori più cauti sottolineano che i piani commerciali dell’azienda relativi a MySQL appaiono tutt’altro che definiti. Come si è detto, negli scorsi giorni Sun ha rilasciato la prima release candidate di MySQL 5.1. La versione finale avrebbe dovuto vedere la luce in questi giorni, ma Sun ha deciso di posticiparne il lancio ufficiale al prossimo giugno.

Il motivo di questo ritardo, secondo quando dichiarato da Marten Mickos, ex CEO di MySQL AB ed ora vice presidente di Sun, è la volontà di non ripetere l’errore compiuto due anni fa con la release 5.0 : questa, su stessa ammissione di Mickos, fu infatti rilasciata prematuramente, quando ancora non aveva raggiunto gli standard qualitativi prefissati.

Morale della favola, il team di sviluppo di Sun intende testare MySQL 5.1 ancora per un paio di mesi , correggendo tutti i bug emersi di recente e quelli che saranno scovati in queste settimane.

Sun afferma che la prossima release di MySQL è stata progettata per migliorare le performance e semplificare la gestione delle applicazioni basate su database di grandi dimensioni: in quest’ultimo campo applicativo, MySQL 5.1 fornirebbe il 15% in più di performance rispetto alla versione attuale.

Tra le novità della nuova release si citano il supporto a cinque differenti tipi di partizionamento orizzontale dei dati (range, hash, key, list e composite), replica ibrida e raw-based dei dati, tool per lo scheduling degli eventi, e un nuovo Upgrade Advisor per l’add-on commerciale MySQL Enterprise Monitor.

Di seguito una breve intervista a Patrizio Tassone , consulente e fondatore della prima società partner di MySQL AB in Italia, sulle indiscrezioni riportate da Cole e sulle novità dell’imminente MySQL 5.1. Punto Informatico : Cosa ne pensi della prospettata strategia di Sun di aggiungere funzionalità in MySQL Enterprise non presenti nella versione Community?

Patrizio Tassone : Le funzionalità di backup online sono molto importanti per chi gestisce database, in particolare di grandi dimensioni, per cui l’utilizzo del tool mysqldump non è sufficiente né consigliato. Sun ha stretto alleanze con altri fornitori di soluzioni di backup, ma si tratta comunque di tool esterni all’ambiente.

Certo, il fatto che questo sarà disponibile solo per gli utenti paganti può creare un po’ di risentimento, ma se questo è un modo per poter disporre di un buon prodotto, un prodotto che Sun cercherà di migliorare nel tempo e su cui investirà non solo in funzionalità ma anche in qualità, direi che tale mossa è benvenuta: dopotutto già adesso il tool di monitoring è solo per i clienti Enterprise, e non mi pare che nessuno si sia particolarmente scandalizzato per questo. Inoltre nulla vieta di utilizzare eventuali API del motore per sviluppare tool esterni, rilasciandoli sotto licenze libere.

È un approccio, quello di riservare parte di feature avanzate solo agli utenti paganti, che stanno seguendo diverse aziende che gravitano intorno al software open: francamente non so se sia la via per la sostenibilità di tali società, ma se la versione “libera” rimane sufficiente per la maggioranza degli usi, penso non ci sia molto da contestare. In fin dei conti Sun ha appena speso un miliardo di dollari, ed è abbastanza scontato che intenda rientrare di tale cifra il più presto possibile.

PI : C’è chi pensa che l’acquisizione di MySQL da parte di Sun possa contribuire a diffondere questo database tra le grandi aziende, mentre altri temono che potrebbe ridurre la partecipazione degli sviluppatori open source allo sviluppo del software. Tu che ne pensi?

PT : Non mi pare che MySQL abbia mai avuto grandi contributi – in termini di codice – da sviluppatori esterni: la quasi totalità di chi scrive il sorgente è stipendiato da MySQL AB (ora di Sun), e questo da diversi anni. Il contributo della comunità è dato dall’enorme base di test – e per un database la stabilità e l’assenza di bug sono fondamentali – che riesce a raggiungere; per contro, la comunità ottiene indietro un database a costo zero e sotto licenza GPL2: mi sembra, tutto sommato, uno scambio equo.

Sicuramente Sun aiuterà la crescita di MySQL offrendo un supporto globale, non solo tecnico ma anche commerciale, che MySQL AB da sola non sarebbe riuscita ad offrire, e questo potrà farla diventare un player credibile nella ricca partita dei database, dominata oggi da IBM, Oracle, Microsoft e Sybase. Certo, dovrà dotarsi di quelle funzionalità enterprise che ancora oggi mancano, come fanno notare diverse analisi indipendenti: i database open source, infatti, non sembrano scalfire minimamente la base forte di installato, rimanendo relegati a compiti di secondo ordine.

PI: Un commento sulle novità di MySQL 5.1?

PT : Le novità di questa release sono di particolare interesse, sicuramente per gli addetti ai lavori, un po’ meno per chi fa uso generico del database.

Quella più generica è sicuramente un (atteso) miglioramento delle performance: si parla di un 15% medio, sicuramente rispetto alla 5.0; da verificare le performance rispetto alla 4.0, che rimane una delle migliori versioni di MySQL e che ne hanno decretato il successo.

Il partitioning, che fa la prima comparsa in questa nuova release, permette una gestione dei dati suddivisa su diverse tabelle fisiche: la velocità di accesso alle informazioni aumenta notevolmente, ed è una soluzione fondamentale quando i dati crescono e laddove l’applicazione non permetta un partizionamento “logico” lato applicazione. Ovviamente non è certo una prerogativa di MySQL, una funzionalità analoga è presente su tutti i database concorrenti, proprietari, nella loro versione enterprise (che, solo per disporre di questa funzionalità, passano ad avere costi spesso improponibili per la piccola e media impresa).

Tra le novità maggiormente attese da chi necessita di elevate performance e affidabilità c’è l’utilizzo del disco per lo storage NBD, che permetterà a MySQL Cluster, la versione parallela di MySQL sotto licenza GPL2, di non essere più un database totalmente in memoria, il che ne amplierà sicuramente gli ambiti di utilizzo: il prodotto non è certo di facile gestione, ma in certi ambiti non si può fare a meno di questa complessità.

Interessante anche l’uso di uno scheduler interno al database, che permetterà di lanciare procedure o istruzioni SQL senza appoggiarsi al cron di Linux o al task scheduler di Windows: utile, ad esempio, quando sono presenti procedure batch di importazione dati o di ottimizzazione delle tabelle.

Le novità non sono solo queste, ovviamente, in ogni caso ritengo che la direzione intrapresa dal team di sviluppo sia quella giusta. C’è però ancora molto da lavorare, e non solo sul motore, ma anche sui tool “esterni” al database, che aiutano nella gestione dello stesso.

Intervista a cura di Alessandro Del Rosso

Link copiato negli appunti

Ti potrebbe interessare

Pubblicato il 18 apr 2008
Link copiato negli appunti