Un CI server nato in Sun
Hudson — continuous integration server scritto in Java — è stato creato da Kohsuke Kawaguchi presso Sun Microsystems a partire dal 2005 come strumento personale, progressivamente adottato dalla comunità Java fino a diventare il CI server Open Source più usato al mondo alla fine degli anni 2000. Plugin architecture, build distribuito (master/agent), interfaccia web semplice, support massiccio a linguaggi e strumenti di build: Hudson è la scelta standard in migliaia di progetti, dal singolo sviluppatore a progetti enterprise con migliaia di job.
La disputa Oracle
Nel gennaio 2010 Oracle acquisisce Sun Microsystems. Nell’autunno 2010 emerge una disputa tra Oracle e la community di Hudson su:
- Controllo del marchio Hudson — Oracle lo registra e lo rivendica
- Governance del progetto — Oracle propone di passare Hudson a un’infrastruttura Oracle controllata; la community preferisce governance più aperta
- Policy di contribuzione — tensioni su chi può effettuare release
Il fork
A gennaio 2011 la community Hudson vota in maggioranza schiacciante (oltre il 90%) per forkare il progetto sotto nuovo nome. Il nuovo nome scelto è Jenkins. Kohsuke Kawaguchi — autore originale, che aveva intanto lasciato Oracle — si sposta con Jenkins insieme alla maggioranza della community e dei committer.
Il primo rilascio di Jenkins (1.396, rinominato da Hudson 1.395) esce l’11 febbraio 2011. Licenza MIT.
Hudson rimane a Oracle, che lo cede all’Eclipse Foundation. La traiettoria del progetto nei mesi successivi dirà se riuscirà a mantenere rilevanza.
Jenkins, al contrario, parte subito forte:
- Plugin — in rapida crescita, ecosistema tra i più ricchi dell’Open Source
- Adozione industriale — Netflix, Twitter, LinkedIn, Yahoo (con configurazioni di scala enterprise)
La governance post-fork
Jenkins adotta governance esplicita: Jenkins Project Board, processi di decisione pubblici, CLA (Contributor License Agreement), infrastruttura ospitata da Software in the Public Interest.
Il fork Hudson/Jenkins diventa caso di studio nella letteratura Open Source per:
- Dinamiche di controllo tra sponsor corporate e community
- Importanza di trademark e governance indipendente
- Meccanismi di risoluzione quando la fiducia si rompe
- Dimostrazione empirica che una community attiva può prevalere su un vendor che possiede solo il nome
Il valore tecnico di Jenkins
Indipendentemente dalla storia, Jenkins risolve concretamente:
- Build automatico ad ogni commit
- Testing continuo con report integrati (JUnit, TestNG, coverage)
- Build distribuito — master coordina, agents eseguono in parallelo
- Integrazione con oltre 1000 strumenti — Git, Maven, Gradle, Ant, Docker, Kubernetes, cloud providers, notifiche Slack/email, deployment tools
- Pipelines as code —
Jenkinsfileversionato in Git accanto al codice
Nel contesto italiano
Al 2011 Jenkins/Hudson è già ampiamente diffuso nei team di sviluppo Java italiani. Il fork non causa frammentazione notevole: la maggior parte delle installazioni migra a Jenkins entro pochi mesi, seguendo il percorso della community e dei plugin (che si spostano rapidamente sulla nuova piattaforma).
L’eredità del fork è una lezione: la sostenibilità dell’Open Source dipende dal controllo del nome e della governance, non solo dalla licenza del codice.
Riferimenti: Jenkins 1.396 (11 febbraio 2011), fork da Hudson 1.395. Kohsuke Kawaguchi. Licenza MIT. Disputa sul marchio Oracle vs. community, gennaio 2011. Eclipse Foundation per Hudson post-fork.