GitLab vuole rendere Open Source 18 funzionalità dei tier a pagamento

0

Nell’ultimo post di Sid Sijbrandij sul blog ufficiale di GitLab, il CEO e co-fondatore della società ci dice cosa ha fatto nell’ultimo mese, mentre nel nostro Paese si consuma(va) la quarantena.

A quanto pare, nelle settimane passate il nostro caro Sid ha passato in rassegna tutte le funzionalità dei tier non-free e ha messo in discussione il business model adottato dalla compagnia, secondo il quale una funzionalità viene inserita in un tier o in un altro a seconda dell’utente target che ne farà utilizzo. Ed è stato proprio questo modello a spingere Sid nella decisione di includere nel tier Core/Free nel prossimo futuro ben 18 feature che prima erano a pagamento.

Ci piace Sid, ci piace quando si mette in discussione e soprattutto ci piace quando fa dono alla comunità di strumenti che possono migliorare (automatizzandolo) il lavoro di tutti nel magico mondo dell’IT:

“I spent some time reviewing GitLab features and determined that eighteen features that appear in seven different stages of the DevOps lifecycle ought to be open source.”

“Ho trascorso diverso tempo a rivedere le funzionalità di GitLab e ho deciso che diciotto funzionalità che compaiono in sette diverse fasi del ciclo di vita DevOps dovrebbero essere open-source.”

Le fasi a cui si riferisce sono quelle nell’immagine sottostante:

qui la fonte

Per ognuna di queste fasi GitLab vuole regalarci una pletora di strumenti (l’elenco completo è nel post linkato a inizio articolo) tra cui succose possibilità di:

  • Pianificare con Related Issues (correlazione fra issue collegate fra loro) e Board Focus Mode (una sorta di tabella kanban);
  • Creare mockup con Design Management o contribuire al codice via Terminal for Web IDE (un terminale affacciato direttamente sul progetto in una delle tab del browser) in un ambiente pre-configurato grazie a File syncing to web;
  • Buildare” con i package manager Conan (C/C++), Maven (Java), NPM (Node) e NuGet (.NET)
  • Rilasciare e Configurare l’applicazione su un set di macchine predefinito con Canary Deployments, o di pod Kubernetes (su cluster differenti per assicurare la data separation) con Incremental Rollouts, o in maniera personalizzata con le Feature Flags, mantenendo le redini del progetto con le interfacce di Deploy Boards;
  • Testare la messa in sicurezza delle applicazioni e difenderle dalle intrusiono con Network policies for container network security;

GitLab è da sempre attenta al feedback della comunità e questa attenzione la si respira anche quando viene chiesta la nostra collaborazione, per fare in modo che tutto questo accada.

[…] we invite you to contribute yourself to speed up the process. We’re not just giving you permission to help us move this code – we’re asking you to help us move it

[…] vi invitiamo a contribuire voi stessi a velocizzare il processo (di migrazione delle feature al tier core/free NdA). Non vi sitamo solo dando il permesso di migrare il codice, mi stiamo chiedendo aiuto per poterlo fare.

In sostanza, prima collaboriamo, prima potremo mettere le mani su tutte queste nuove feature. GitLab diventerà l’applicazione full-stack per tutti coloro che praticano DevOp?

Amministratore di sistema “umile ma onesto”. Inciampato in Linux per caso, è stato l’inizio di una storia d’amore bellissima.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *