Nel chiudere l’articolo relativo all’acquisizione di HashiCorp da parte di IBM ci chiedevamo come sarebbe stata gestita la cosa dalla Linux Foundation, la quale in seguito al cambio di licenza sul software Terraform da parte di HashiCorp aveva preso sotto la sua ala protettrice il suo fork, ossia OpenTofu.

Bene, pare che il day after l’acquisizione abbia suscitato più di una riflessione all’interno del progetto OpenTofu, alcune delle quali, a dispetto delle recenti vicissitudini sulla paternità del codice, sono sorprendentemente di apertura verso una clamorosa riunificazioni.

Le racconta questo articolo di The New Stack, riportando le parole di Sebastian Stadil, co-maintainer di OpenTofu:

A lot of [OpenTofu] folks were puzzled about what exactly IBM intends to do, beyond all of the marketing speak. We’re hopeful that IBM understands open source better than HashiCorp does.

Molti all’interno di OpenTofu si interrogano su cosa IBM voglia fare [di Terraform], al netto di tutti i discorsi di marketing. Speriamo che IBM capisca meglio l’open-source di quanto non faccia HashiCorp.

Ed a proposito del “sentimento” generale della community vengono aggiunte altre riflessioni:

Nobody likes split communities. Nobody likes fragmentation of efforts. So we would welcome Terraform.

Le community divise non piacciono a nessuno. La frammentazione dei contributi non piace a nessuno. Quindi accoglieremmo con favore Terraform.

Parole non banali, almeno per come era partita la storia di OpenTofu, ma ovviamente l’acquisizione ha cambiato le carte in tavola.

A questo punto tutti i potenziali scenari del dualismo Terraform/OpenTofu sono aperti, anche perché il fork prosegue spedito i suoi sviluppi, tanto da annunciare pochi giorni fa la release 1.7.0, che porta con sé alcune delle novità attese per Terraform ma che per qualche ragione non sono (ancora) finite nel software gestito da HashiCorp.

Prima fra queste la tanto attesa End-to-End State Encryption che consente di rendere i file di configurazione sicuri indipendentemente da dove questi vengono archiviati, consentendo di integrare le varie chiavi di accesso ai provider remoti finalmente in maniera sicura. Seguono poi le Dynamic Provider-Defined Functions che estendono il supporto ai linguaggi utilizzabili nei manifest e i Loopable Import Blocks and Removal Blocks che rende più semplice la gestione massiva delle risorse (feature al centro della diatriba sul codice di cui sopra).

Considerato come la versione 1.8 sia già stata avviata, chissà che con l’annuncio della stessa vedremo la riunificazione dei progetti.

A questo punto… Mai dire mai.

Raoul Scarazzini

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.