Cos'è l'InnerSource?

L'InnerSource è una strategia di sviluppo software in base alla quale le aziende adottano un approccio e una cultura open-source per collaborare in modo più efficace.

Cosa significa InnerSource?

L'InnerSource è una tendenza sempre più diffusa fra i team di sviluppatori e tecnici, che scelgono di adottare processi open-source per lavorare e collaborare in modo più efficiente. I team che decidono di seguire questa strategia possono sviluppare software proprietario e rafforzare la collaborazione interna in modo che tutti, dagli sviluppatori ai product manager, possano contribuire al codice sorgente.

L'InnerSource è una strategia di sviluppo software che prevede l'applicazione di pratiche open-source al codice proprietario. L'InnerSource aiuta a favorire una cultura open-source all'interno di un'organizzazione mantenendo il software per uso interno. I team sfruttano tale strategia per aumentare la visibilità, rafforzare la collaborazione ed eliminare i silo.

Garantendo l'accesso automatico ai progetti interni dell'organizzazione, i team possono riutilizzare le soluzioni esistenti e ridurre al minimo le ridondanze, potenziare la collaborazione fra i membri del personale e sfruttare il contributo dei talenti. Le organizzazioni di qualsiasi dimensione traggono vantaggio dall'InnerSource e possono incorporare continuativamente le moderne pratiche di sviluppo software imparando dai progetti open-source su larga scala.

Nel caso delle aziende di grandi dimensioni, i team di sviluppo sono spesso distribuiti in diversi reparti o dislocati in fusi orari differenti. Alcuni sviluppatori potrebbero non incontrarsi mai né avere accesso alle stesse strategie di reparto. Tuttavia, grazie all'InnerSource, possono aderire allo stesso modello di flusso di lavoro che si è rivelato efficace nei progetti open-source.

Il caso di PayPal dimostra come le pratiche di sviluppo open-source rendano le aziende più efficienti e redditizie, anche se la componente "open" varia a seconda delle dimensioni del team interessato. Altre aziende pionieristiche che hanno scelto la strategia InnerSource, tra cui Bosch, Autodesk, Bloomberg e SanDisk, sono in grado di portare a termine progetti complessi e creare prodotti innovativi implementando lo stesso sistema snello e a basso costo utilizzato in ambito open-source.

Perché le organizzazioni vogliono operare come progetti open-source

Al loro interno, le organizzazioni più importanti funzionano in modo simile ai grandi progetti open-source. In entrambi i casi, diverse sono le parti chiamate in causa: diversi collaboratori, vari strumenti e un'ampia serie di direttive e strategie. Tuttavia, nel modello aziendale tradizionale, un'organizzazione funziona seguendo le indicazioni formulate da una gerarchia di alti dirigenti. La reale efficienza di un'organizzazione si basa in parte sulla capacità dei manager di monitorare grandi quantità di informazioni in entrata.

La mole dei dati tende spesso a formare un collo di bottiglia di stampo manageriale, facendo in modo che tantissimi progetti finiscano sotto traccia. Man mano che i progetti diventano più complessi o entrano in gioco ulteriori team, anche altre attività rischiano di essere trascurate. Nei progetti open-source, le informazioni correlate allo sviluppo sono gestite attraverso un processo di documentazione e di controlli appositamente strutturati per evitare che i componenti finiscano per venire trascurati nel corso del tempo.

Di seguito sono riportate le principali pratiche inerenti a un flusso di lavoro open-source per le aziende:

Visibilità
Fork
Richieste di pull/merge
Test
Integrazione continua
Documentazione
Monitoraggio dei ticket

Adottando una mentalità open-source nell'ambito dello sviluppo software, le organizzazioni sono in grado di colmare le lacune ed eliminare i silo, accelerando e consolidando il ciclo di sviluppo. Inoltre, crea le basi per un ambiente di lavoro migliore per gli sviluppatori, metodologie di sviluppo semplificate e una cultura collaborativa trasparente.

Un approccio del genere non solo rende più veloce il lavoro degli sviluppatori, ma incentiva anche la collaborazione tra i membri dei team principali nei vari progetti di sviluppo software.

Vantaggi dell'InnerSource

Le organizzazioni che adottano l'InnerSource possono usufruire dei vantaggi tipici degli ambienti di sviluppo open-source, ad esempio:

Codice di alta qualità: grazie a test unitari, copertura del codice e integrazione continua, i team possono migliorare la qualità del codice nelle prime fasi del ciclo di vita.
Documentazione completa: il codice è corredato da una documentazione più esaustiva, sia a livello di commenti che in termini di discussioni più informali, che costituisce un'unica fonte di riferimento e offre una maggiore trasparenza e una conoscenza condivisa.
Riutilizzo efficace del codice: il codice e l'architettura sono facilmente individuabili e a disposizione del team e di tutta l'organizzazione.
Collaborazione solida: le revisioni del codice incontrano meno attriti, la comunicazione si rafforza e i contributi diventano più significativi in termini numerici.
Cultura sana: i silo vengono smantellati, ragion per cui gli sviluppatori traggono maggior soddisfazione dal proprio lavoro. Ne conseguono una migliore fidelizzazione dei talenti e un processo di reclutamento più efficace.

Problemi risolvibili grazie all'InnerSource

Ecco alcune delle problematiche che affliggono spesso le grandi organizzazioni e che l'InnerSource può aiutare a risolvere.

Problema	Soluzione
Comunicazione: generalmente, nelle grandi organizzazioni non c'è solo un team che lavora per raggiungere un singolo obiettivo. Al contrario, i membri del team tendono a essere suddivisi in diversi gruppi di lavoro scollegati l'uno dall'altro e ognuno con la propria struttura e leadership. Le norme e la terminologia di comunicazione possono variare a seconda del team, mentre la comunicazione e la condivisione delle conoscenze tra i singoli reparti sono inefficaci e ridotte al minimo.	I sistemi open-source incentivano il coinvolgimento e la partecipazione su larga scala. Le linee di comunicazione sono dirette e visibili a chiunque faccia parte del progetto. Le gerarchie di comunicazione sono generalmente piatte, c'è una maggiore trasparenza nella trasmissione delle informazioni e una migliore comunicazione fra le parti coinvolte.
Scoperta: una soluzione software può essere creata più volte perché i reparti non comunicano fra loro, non c'è trasparenza nella trasmissione delle informazioni e manca la collaborazione, determinando uno spreco di risorse ed energie. Di norma non esiste un processo finalizzato a verificare se una soluzione sia già stata creata.	Il vantaggio dei progetti open-source è che sono trasparenti per natura. Avere accesso al progetto significa che i team possono cercare di stabilire se esista la soluzione a un problema che bisogna risolvere. Se non si effettuano ricerche prima di dare inizio ai lavori, gli altri collaboratori del progetto otterranno un quadro completo e saranno in grado di identificare una soluzione preesistente. I progetti open-source consentono di individuare più facilmente le soluzioni già sviluppate da altri, permettendo di risparmiare tempo e risorse.
Burocrazia: nella maggior parte degli ambienti commerciali, le strutture organizzative definiscono le prerogative di accesso per i team. Anche se un membro conosce la soluzione a un problema, deve comunque rivolgersi a un amministratore per richiedere l'accesso a un progetto. Tale processo provoca perdite di tempo e incide sullo svolgimento delle attività importanti.	Con i progetti open-source, i membri del team hanno pieno accesso alle attività o alla visualizzazione dei progetti. Ne consegue una riduzione del carico amministrativo e dei ritardi nella gestione delle richieste di accesso.
Modifiche: in un ambiente commerciale tradizionale, se i team possono accedere a un progetto in sola lettura, non dispongono delle autorizzazioni né hanno la possibilità di modificare o aggiungere una funzionalità, essendo costretti a rivolgersi a qualcun altro perché lo faccia. Se i soggetti preposti sono troppo impegnati o non comprendono il punto della questione, i collaboratori non possono fare nulla al riguardo. Il team responsabile dell'app ha il compito di garantire che quest'ultima venga sviluppata nel rispetto delle scadenze e che funzioni correttamente. In altre parole, il lavoro degli altri collaboratori dipende dal grado di manutenzione di quella applicazione. Anche se un altro team potrebbe trarre vantaggio da questa nuova funzionalità, la richiesta di modifica dell'applicazione potrebbe interferire con la sua stabilità, ragion per cui concedere l'accesso può rivelarsi un rischio. Se a uno sviluppatore è negato l'accesso per apportare le modifiche necessarie, i team dovranno a creare una codebase o un'applicazione specifica per risolvere il problema; ciò potrebbe ripetersi con persone diverse. Di conseguenza, i reparti tendono a creare ciascuno la propria app per risolvere problematiche comuni a tutti.	Se i team vogliono apportare modifiche a un progetto open-source, non devono richiederne dell'autorizzazione. Al contrario, possono fornire il proprio contributo e lasciare che il sistema testi le funzionalità e l'efficacia delle soluzioni. In pratica, i team eseguono il fork dalla codebase, apportano le modifiche necessarie e creano una richiesta di merge in modo che un altro sviluppatore possa verificarla, porre delle domande e infine testarla. Rispetto allo scenario precedente, chi deve accettare la richiesta di merge ha un carico di lavoro inferiore perché non deve svolgere direttamente lavoro extra per completare un'attività o un progetto. Un ulteriore vantaggio di questo approccio è che riduce il carico complessivo sul generatore di report, dal momento che deve supportare una singola codebase anziché otto.

In che modo i team possono utilizzare l'InnerSource

L'InnerSource è un modo semplice per creare un flusso di lavoro più efficiente, sia per i team che collaborano in fusi orari diversi (una prassi ormai abbastanza diffusa), sia per le organizzazioni composte da più reparti. I team possono eliminare i silo di informazioni e incentivare una collaborazione più efficace all'interno dell'organizzazione. Inoltre, l'InnerSource può essere utilizzato per accelerare l'onboarding degli sviluppatori e incoraggiare i membri del team a fornire il proprio contributo.

Adottare progetti InnerSource vuol dire abbandonare gli approcci tradizionali al processo di sviluppo in favore di flussi di lavoro più dinamici, inclusivi ed efficienti.

Conclusioni

L'InnerSource rappresenta un cambiamento radicale nel modo in cui le organizzazioni affrontano lo sviluppo software. Non solo permette di migliorare la qualità e la sicurezza dei prodotti, ma stimola inoltre una trasformazione culturale che pone le organizzazioni in una posizione di primato in ambito tecnologico. L'utilizzo delle pratiche InnerSource permette alle aziende di affrontare le sfide attuali in materia di sviluppo software con un approccio agile, incentivando al contempo l'innovazione collaborativa per la crescita del business.

Poiché le organizzazioni guardano al futuro, l'adozione dell'InnerSource rappresenta un imperativo strategico che può metterle nelle condizioni di trasformare le problematiche odierne in nuove opportunità da capitalizzare.