La scorsa settimana abbiamo pubblicato l’articolo dal titolo “Nessun commit in tre mesi: la versione open-source di MySQL è stata (finalmente) abbandonata da Oracle?” all’interno del quale, prendendo spunto da diverse fonti, analizzavamo la situazione del repository open-source di MySQL (https://github.com/mysql/mysql-server) per capire se fosse in effetti ancora gestito, dandoci in chiusura la risposta: praticamente, no.

Nell’arrivare a quella conclusione ci siamo basati essenzialmente su due immagini. La prima arrivava dall’articolo di DevClass dal titolo “Open source MySQL repository has no commits in more than three months“, ed era questa:

La seconda dall’articolo “Stop using MySQL in 2026, it is not true open source“, pubblicata dall’ex CEO di MariaDB, Otto Otto Kekäläinen:

Le due immagini, all’apparenza identiche, presentano delle differenze, nella seconda ad esempio si vedono i numeri di commit, quindi sembrano essere state prese in due momenti differenti. Il punto è che raccontano la stessa storia: dallo scorso ottobre, nel repository MySQL open-source non ci sono stati commit.

Il problema è che nei commenti (tanto del nostro articolo, quanto in quello dell’ex CEO) qualcuno ha fatto notare lo stato dei commit oggi, che racconta una storia decisamente diversa:

Lo screenshot, che è verificabile presso la pagina Insights del repository GitHub, dice quindi che di commit ce ne sono stati. Pochi, con un trend in discesa, ma sicuramente non zero, ed anzi, con un picco di 24 a dicembre.

A chi credere? Bella domanda.

Due entità distinte si sono accordate per creare uno screenshot ad arte? Le due fonti di partenza che interesse avrebbero avuto a raccontare frottole (con tanto di link per la verifica)? A chi sarebbe andata a vantaggio una bugia così plateale?

Qualcuno ha suggerito che dopo la pubblicazione dei blog post Oracle abbia sapientemente inserito in blocco i commit, ed il problema è che la cosa sarebbe perfettamente fattibile, poiché non c’è nulla di dimostrabile.

Git è lo strumento ideale per tracciare il cosa è stato fatto, piuttosto che il quando.

Per intenderci, se volessi creare un commit datato 2027 (o retro-datato, per quel che vale), basterebbe usare questi semplici passi:

$ mkdir myrepo && cd myrepo

$ git init
Initialized empty Git repository in /home/rasca/myrepo/.git/

$ touch TEST && git add .

$ GIT_AUTHOR_DATE="2027-01-26T10:00:00" GIT_COMMITTER_DATE="2027-01-26T10:00:00" git commit -m "Test commit date"
[main (root-commit) 8e987eec2adb] Test commit date
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 TEST

$ git log
commit 8e987eec2adb3156d760ca7cc88f75439e7814db (HEAD -> main)
Author: Raoul Scarazzini <rasca@mmul.it>
Date:   Tue Jan 26 10:00:00 2027 +0100

    Test commit date

La domanda quindi è: si può verificare che questa cosa sia stata o non stata fatta nel repository di MySQL?

No. E la ragione è la natura stessa di come il repository è gestito, che è il nocciolo di tutta la questione.

Infatti a prescindere dal numero di commit, facendo una verifica sul repository si nota un processo di gestione delle modifiche decisamente poco ortodosso e poco open-source, poiché tutte le Pull Request, ossia le proposte di contributi fatte dalla community, non risultano concludersi in un merge, bensì sono tutte “Closed with unmerged commits“, il che significa come le modifiche, se ci sono state, sono state incluse altrove, in uno dei commit fatti dai responsabili del repository.

Fosse necessario dirlo: non è così che funziona nei progetti open-source, dove normalmente è la patch dell’autore originale che segue la pipeline di promozione e, nel caso, finisce per essere inclusa. In un progetto vasto come MySQL Server invece i bug sono trattati altrove, precisamente su https://bugs.mysql.com, il Bugzilla storico di MySQL che è gestito internamente e non è pubblico, per accedervi è necessario registrarsi.

L’inclusione dei contributi quindi è completamente oscura. Non si capisce se tutto o parte del codice dei contributori viene incluso, non si capisce il criterio, è tutto molto chiuso.

Tralasciando inutili campanilismi, la scelta delle tecnologie open-source che si vogliono utilizzare dovrebbe sempre passare dall’unico aspetto realmente oggettivo che si può controllare: la trasparenza.

Ad ognuno le proprie conclusioni.