Come il software open source viene avviato

Nel settore del software, l’open source è diventato uno stile di vita. Se non è proprio la scelta di fatto per il software aziendale a tutti i livelli (il software proprietario chiuso dal fornitore non scomparirà in qualsiasi momento in questo decennio), allora possiamo almeno dire che stiamo vedendo grandi organizzazioni abbracciare un alto grado di tecnologia aperta piattaforme, prodotti e protocolli a molti livelli nelle loro pile IT.

Laddove le aziende non abbiano acquistato deliberatamente l’open source, molto spesso potrebbero utilizzare servizi basati su cloud che vengono venduti come prodotti “di marca e supportati” dopo essere stati basati su tecnologie essenzialmente open core. Ciò significa che i livelli di distribuzione e i casi d’uso sono molto diffusi, anche se il core aperto è solo un ingrediente in una piattaforma tecnologica più ampia in questione.

Ciò che ciò implica per i dipartimenti IT aziendali che vanno avanti è una nuova responsabilità. Devono essere “alla ricerca” di prodotti e servizi aperti che gorgogliano verso l’alto, avanzando e godendosi il bagliore dell’adozione diffusa da parte degli utenti. Non è un’ipotesi completa: a volte gli utenti te lo dicono semplicemente, altre volte possiamo cercare il punto in cui un progetto viene ufficialmente avviato.

Ma cos’è il bootstrap?

Bootstrap del software definito in termini semplici

Da non confondere con il processo che il computer attraversa quando si “avvia” (anche se il termine potrebbe prendere in prestito da quell’origine in alcuni sensi etimologici) Alois Reitbauer, Vicepresidente e capo stratega tecnico presso dynaTrace spiega che il bootstrap per un’entità software open source non è uguale al lancio di un prodotto, è qualcosa che accade prima di quel momento.

“L’idea chiave qui per identificare il punto di bootstrap è che ci sono alcuni investimenti iniziali da parte di un collettivo – un gruppo di persone o organizzazioni – a) portare il prodotto a un livello di funzionalità ma anche b) ottenere una comunità iniziale attorno al progetto per raggiungere la “massa critica” attorno ad essa “, ha affermato Reitbauer. “Ma anche se la funzionalità di base è ovviamente la cosa più importante in quanto nessuno utilizzerà un prodotto / progetto se non fornisce alcun valore aggiunto – ci sono tuttavia molti più elementi della struttura di supporto che devono essere costruiti attorno a un open (o addirittura chiuso) prima di poter dire che è stato avviato correttamente. “

L’approccio di Dynatrace al suo sviluppo di Keptn e il successivo bootstrap di questa tecnologia racconta una storia non solo su ciò che fa il prodotto stesso, ma su come le organizzazioni potrebbero spostare un prodotto in avanti verso lo stato open source … e su come considerano di gestirlo in seguito. Keptn è un “piano di controllo” collegabile open source (in termini più semplici: tecnologia che configura e orchestra il modo in cui il software viene spedito e gestito) e fa parte degli sforzi dell’industria del software per promuovere il movimento verso cloud autogestiti autonomi.

Quali “punti di maturità” definiscono il bootstrap?

Quindi cos’altro ci dice che siamo pronti per avviare un progetto software? Reitbauer afferma che il bootstrap significa anche assicurarsi che il software supporti il ​​caso d’uso per il quale è stato inizialmente concepito. Ma in realtà, la definizione di un caso d’uso chiave in termini precisi non è sempre una questione essenziale.

“Scegliere casi d’uso chiave è sempre una sfida. Di solito ci sono (quasi) già soluzioni là fuori che coprono parti di ciò che fa un nuovo progetto. La chiave è identificare il fondamentale [work] problema che stai cercando di risolvere, perché questo incoraggerà le persone a provare il progetto, anche se il suo sviluppo iniziale non è perfetto in ogni area ”, ha affermato Reitbauer.

Il bootstrap richiede anche che tu abbia dato al progetto stesso una mentalità, forse una personalità. Quello che dobbiamo capire è che un progetto software è molto più di un semplice codice. Ci sono principi di progettazione, valori fondamentali e concetti più ampi che il progetto segue. Questi devono essere ben consolidati e testati con il pubblico target. Dalla loro esperienza con il software di sourcing aperto, il team di Dynatrace afferma che i primi mesi – o anche l’anno – sono sempre particolarmente difficili … e hai bisogno di un team dedicato che lo vede come la loro missione per rendere il progetto di successo.

Dopo aver eseguito il bootstrap, arriveranno, giusto?

È vero che dopo una riflessione_, strategico e potremmo forse dire che il processo di bootstrap “coscienzioso” è stato eseguito, un progetto è pronto per aprire le sue porte alla comunità globale di programmatori che lo aiuteranno a progredire e agli utenti che lo adotteranno. Ma come per tante altre cose, raramente è così semplice.

“Dopo il bootstrap, sei aperto alla community dal primo giorno. Tuttavia, nessuno verrà visualizzato perché il codice del software è accessibile e scaricabile su GitHub. Molto spesso, le persone daranno una rapida occhiata al progetto e aspetteranno una versione futura, più matura … o non vorranno essere coinvolti attivamente perché non vedono ancora il valore. Una volta superati questi ostacoli iniziali, una comunità (si spera) inizierà a emergere attorno al progetto “, ha spiegato Reitbauer.

Guardando un po ‘più a lungo termine ai prossimi passi, pensiamo 1 anno in più lungo la linea. Potremmo scoprire che anche dopo l’avvio del bootstrap, l’organizzazione di sviluppo originale rimane il principale contributo. Questo va bene in linea di principio. Red Hat Linux è ancora in gran parte sviluppato da Red Hat (e in effetti Linux è per lo più contribuito da Red Hat). Tuttavia, ci sono altri esempi – come Kubernetes – anche.

“Lo sviluppo open source è un investimento significativo per un’azienda … e può essere buono se fatto seriamente. Le aziende rimarranno e contribuiranno maggiormente quando vedranno i risultati di business adeguati. Ovviamente, l’organizzazione che ha contribuito inizialmente lo fa molto spesso, poiché questo è il motivo per cui hanno iniziato il progetto in primo luogo. Le organizzazioni che sviluppano progetti in cui sono gli unici utenti verranno e verranno. Potrebbero anche smettere di contribuire man mano che il progetto diventa più maturo. Non si tratta di una vera libertà open source ”, ha dichiarato Reitbauer di Dynatrace.

Ignorare l’open source è un mandato di morte del software?

Se accettiamo l’ascesa dell’open source aziendale e vediamo dove sono coinvolti i fornitori su larga scala da Microsoft a Oracle e ogni altro ramo dell’albero, lo sta ignorando come un suicidio del software? Per porre la domanda in un altro modo, se non apri alcune parti (forse tutte, eventualmente, eventualmente) della tua proposta tecnologica totale, allora hai firmato il mandato di morte sul tuo software per diventare codice legacy?

“Non penso che questa proposta possa essere generalizzata in questo modo. Per alcuni software, non è necessario essere open source. Ci sono casi in cui un prodotto SaaS (Software as-a-service) di cloud computing deve avere un livello gratuito per stimolare lo slancio del mercato. Ciò è particolarmente vero per il software che usi come prodotto pronto come Google Gmail ecc. Non è ancora una convalida per tutto il software che deve essere open source. Invece devi pensare di avere almeno una proposta open source a un certo livello in modo che altre persone possano costruire sul tuo software o persino integrarlo come parte chiave del proprio stack di software “, ha affermato Reitbauer.

Man mano che la pratica del bootstrap di progetti aperti cresce e diventa una parte più diffusa dello sviluppo del software, non si tratterà di sapere quando il bootstrap è abbastanza stretto: la tensione in realtà non tiene conto in questo modo.

Ciò che sarà importante è sapere quanto bootstrap sarà necessario per far decollare un progetto … e quindi essere in grado di mettere in discussione le risorse interne di un’organizzazione (in questo caso intendiamo i membri del team e il tempo del flusso di lavoro, piuttosto che le macchine) e poter valutare se il team è disposto e in grado di dedicare lo sforzo. Se lo sono, è ora di andare a cercare un paio di calzini puliti e allacciarsi gli stivali.