Cosa Significa Definire l'InnerSource

La Domanda #

Le persone mi chiedono spesso quale sia la definizione di InnerSource. Ora, cos’è l’InnerSource? Voglio condividere alcuni pensieri sull’InnerSource e cosa significa per me.

Permettetemi di essere chiaro fin dall’inizio: queste sono le mie opinioni personali, non una posizione ufficiale. Sebbene attualmente ricopra il ruolo di Presidente della InnerSource Commons Foundation, l’InnerSource è stato plasmato da molti pionieri che rispetto profondamente. I loro contributi hanno costruito quello che l’InnerSource è oggi.

Le fondamenta dell’InnerSource derivano dall’intreccio di pratiche aziendali, ricerca accademica e, naturalmente, l’evoluzione dell’open source stesso. Data questa ricca trama, sarebbe presuntuoso da parte mia pretendere di definire personalmente l’InnerSource. Solo perché attualmente ricopro il ruolo di Presidente non significa che abbia l’autorità o la saggezza per creare quella definizione da solo.

Piuttosto che fornire un’unica risposta definitiva, vorrei condividere diverse prospettive su questa domanda, offrendo punti di vista che potrebbero aiutarvi a scoprire la vostra definizione e comprensione di cosa significhi l’InnerSource per il vostro contesto.


I Due Percorsi verso l’InnerSource #

Ci troviamo in un punto di svolta interessante. Permettetemi di essere più esplicito su cosa intendo. Ci sono essenzialmente due tipi di persone che si avvicinano all’InnerSource oggi:

Il primo gruppo è composto da coloro che hanno praticato l’open source, hanno trovato potenti i suoi metodi collaborativi e hanno naturalmente applicato questi principi internamente. Per loro, l’InnerSource era semplicemente un nome dato a qualcosa che stavano già facendo—portare l’eccellenza della collaborazione open source nelle loro organizzazioni.

Il secondo gruppo ha scoperto l’InnerSource come metodologia denominata. Potrebbero non avere un ampio background nell’open source, ma riconoscono che l’InnerSource come metodologia organizzativa offre un valore enorme per la trasformazione. Stanno adottando l’InnerSource non perché erano praticanti dell’open source, ma perché l’InnerSource stesso promette benefici organizzativi.

Questa dualità crea opportunità affascinanti nella nostra comunità. Il primo gruppo comprende intuitivamente cosa significa implementare l’InnerSource all’interno di un’organizzazione, così come il valore e la cultura dell’InnerSource e dell’open source. Pertanto, potrebbero contemplare come dovrebbe essere definito l’InnerSource e pensarci all’interno del framework dell’open source. D’altra parte, il secondo gruppo non ha necessariamente coinvolgimento con l’open source, quindi tende a cercare idee più chiare su cosa sia realmente.

90%


Imparare dal DevOps: Il Potere del Nominare #

Per comprendere la sfida definitoria dell’InnerSource, guardiamo al DevOps. Ecco come comprendo la sua evoluzione: i praticanti in aziende come Flickr stavano facendo qualcosa di innovativo—abbattendo i silos tra sviluppo e operazioni. Quando condivisero le loro esperienze e qualcuno gli diede un nome—“DevOps”—accadde qualcosa di magico. Improvvisamente, le aziende ovunque si resero conto che stavano facendo cose simili, e iniziarono tutte a condividere le loro storie.

L’intuizione chiave è questa: la pratica esisteva prima del nome, ma nominarla creò una comunità. Con quella comunità arrivarono strumenti, concetti condivisi, conferenze e crescita esplosiva. Il DevOps non fu inventato; fu scoperto e nominato. Il nominare catalizzò tutto il resto.

L’InnerSource segue un modello notevolmente simile. Tim O’Reilly lo menzionò in un post del blog nel 2000. Nel 2015, Danese Cooper e colleghi, allora a PayPal, formalizzarono l’InnerSource Commons, successivamente trasformandolo in una fondazione. Ma non inventarono la pratica—nominarono qualcosa che le persone stavano già facendo.

Questo nominare fu magico. Improvvisamente, i praticanti isolati si resero conto di non essere soli. “Oh, quella cosa che stiamo facendo con le nostre librerie interne? Quello è InnerSource!” La comunità esplose con la condivisione di pattern, portando a risorse come InnerSource Patterns che catturano la saggezza collettiva.

Cos’è il DevOps Oggi? Una Prospettiva tra Molte #

Le persone definiscono il DevOps in innumerevoli modi, e non posso possibilmente coprirli tutti. Ecco un esempio di come potrebbe essere compreso:

  • Una cultura di collaborazione tra team tradizionalmente separati
  • Un insieme di pratiche e strumenti di automazione
  • Una filosofia che si oppone allo sviluppo tradizionale a cascata
  • Una collezione di metodologie e framework
  • Estensioni in aree specializzate: BizDevOps, DevSecOps e oltre

Questa è solo un’interpretazione. Chiedete a dieci praticanti, e otterrete dieci enfasi diverse. Questa diversità non è debolezza—è forza evolutiva.

90%


I Molteplici Significati di “Open Source Interno” #

La frase “open source interno” sembra paradossale, e questo paradosso rivela perché l’InnerSource significa cose diverse per organizzazioni diverse. Permettetemi di condividere alcuni esempi rappresentativi emersi dalle discussioni della nostra comunità:

InnerSource come Percorso verso la Maturità Open Source #

Per alcuni, l’InnerSource apre un percorso organico verso la partecipazione open source e la trasformazione digitale. Non si tratta solo di prepararsi per un eventuale contributo open source—si tratta di creare un ambiente dove l’organizzazione può crescere per diventare una vera azienda software. Aziende come Microsoft e Google esemplificano questo viaggio, dove le pratiche interne evolvono naturalmente per rispecchiare quelle esterne, creando collaborazione senza soluzione di continuità sia dentro che fuori dall’azienda.

Ma che dire delle aziende manifatturiere, dei rivenditori o delle istituzioni finanziarie? Mentre potrebbero usare enormi quantità di open source, il loro viaggio è diverso. Per loro, l’InnerSource potrebbe essere il primo passo in una trasformazione più lunga—costruire capacità software, promuovere una cultura dell’innovazione e forse eventualmente trovare il loro modo unico di impegnarsi con l’open source che si allinei con il loro modello di business.

InnerSource come Trasparenza Organizzativa #

Molti sono attratti dall’InnerSource per la trasformazione culturale. Non si tratta solo di inviare pull request—anche se questo fa parte—si tratta di creare trasparenza organica dove puoi:

  • Inviare richieste di funzionalità ad altri team
  • Vedere cosa stanno costruendo i team vicini
  • Comprendere il panorama tecnologico organizzativo più ampio
  • Abbattere i silos che impediscono la collaborazione
  • Creare una cultura organizzativa più aperta e respirabile dove le informazioni fluiscono naturalmente

Questa trasparenza trasforma le organizzazioni da gerarchie rigide in reti viventi di collaborazione.

Alla fine, questi contribuiscono alla felicità e al benessere degli ingegneri, dei team di prodotto e di tutti i coinvolti nell’organizzazione. Sentirsi fidati in un ambiente di lavoro di supporto—sentirsi fidati per default—è incredibilmente importante. Questo si collega all’esperienza dello sviluppatore, e di conseguenza porta a una migliore retention dei talenti mentre fornisce anche risultati positivi per il reclutamento.

InnerSource come Ottimizzazione delle Risorse #

La gestione tradizionale gerarchica dei progetti aggiunge margini a ogni livello. I requisiti fluiscono verso il basso, ogni strato aggiunge tempo di buffer per l’incertezza. Quando il lavoro raggiunge l’implementazione, le tempistiche sono gonfiate e gli ingegneri sono sotto pressione.

L’InnerSource inverte questo. Le persone più vicine ai problemi li comprendono meglio. Possono dare priorità, discutere e risolvere problemi senza riunioni e approvazioni a cascata. Questo non è sempre giusto—i team sul campo conoscono solo il loro campo—ma quando bilanciato con supervisione strategica, è potente.

Ma l’ottimizzazione delle risorse va oltre le risorse umane e di team. Riguarda anche sfruttare gli asset di codice dell’organizzazione, la proprietà intellettuale e i vantaggi competitivi. Quando i team possono condividere e costruire sui strumenti, librerie e conoscenze degli altri, creano sinergie che non esisterebbero in strutture siloed. Quella libreria interna di machine learning che il vostro team ha costruito? Un altro team potrebbe estenderla in modi che non avete mai immaginato. Il framework di testing che vi ha dato vantaggio competitivo? Condividerlo internamente moltiplica il suo valore attraverso l’organizzazione. L’InnerSource aiuta le organizzazioni a realizzare che i loro asset di codice e conoscenza sono risorse che diventano più preziose quando condivise, non accumulate.


Il Dilemma della Definizione: Il Contesto è Tutto #

Questa sfida di significati multipli non è unica dell’InnerSource. Considerate come i sostenitori dell’Open Source Program Office (OSPO) promuovono l’open source internamente. Usano assolutamente messaggi diversi per pubblici diversi perché ogni attività ha bisogno del consenso di stakeholder diversi, e ogni livello dell’organizzazione ha interessi e preoccupazioni diverse.

Per la promozione dell’InnerSource, il messaggio potrebbe apparire così:

Agli ingegneri: “Collaborate con colleghi brillanti, imparate dal miglior codice, contribuite a progetti entusiasmanti oltre il vostro team immediato”

Al middle management: “Riducete la duplicazione, aumentate l’efficienza, accelerate la consegna attraverso riuso e collaborazione”

Agli esecutivi: “Riducete i costi, aumentate la velocità di innovazione e trattenete i migliori talenti”

La stessa iniziativa InnerSource serve tutti questi obiettivi simultaneamente, ma enfatizzate aspetti diversi per pubblici diversi. Questo non è inganno—è riconoscimento che l’InnerSource, come qualsiasi metodologia trasformativa, fornisce valore a livelli multipli.

La vostra definizione di InnerSource non è solo dipendente dal pubblico—è dipendente dalla fase. E questo va perfettamente bene.


Il Vostro Viaggio InnerSource: Una Definizione in Evoluzione #

Quindi cos’è l’InnerSource? È quello che definite che sia.

Forse in futuro, la InnerSource Commons Foundation svilupperà una definizione più chiara e comunicabile che renderà immediatamente ovvio cosa sia l’InnerSource. Personalmente, aspetto con impazienza quel giorno, anche se riconosco che creare una tale definizione in mezzo a tanta diversità è un compito incredibilmente difficile.

Inoltre, la vostra definizione può e dovrebbe evolversi. L’InnerSource che vi aiuta a iniziare il vostro viaggio potrebbe essere diverso dall’InnerSource che praticate tre anni dopo. La vostra definizione potrebbe cambiare man mano che la vostra organizzazione matura, man mano che le vostre sfide cambiano, man mano che la vostra comprensione si approfondisce.

Potete portare la vostra definizione alla comunità, condividere la vostra prospettiva e aiutarci tutti a riflettere insieme su queste domande. Questa esplorazione collettiva è come arriveremo eventualmente a una comprensione condivisa—non attraverso decreto dall’alto verso il basso, ma attraverso scoperta collaborativa.

90%


Un Invito all’Azione #

Piuttosto che cercare la definizione perfetta, vi incoraggio a sperimentare l’InnerSource:

  • Inviate un issue descrivendo un problema che vedete
  • Inviate una pull request correggendo la documentazione
  • Richiedete una funzionalità da un altro team
  • Condividete il vostro codice con i colleghi
  • Esplorate cosa stanno costruendo altri team
  • Collaborate attraverso i confini organizzativi

Attraverso la pratica, scoprirete cosa significa l’InnerSource per la vostra organizzazione. Potreste persino inventare nuovi pattern da cui il resto di noi può imparare.

Unitevi alla Conversazione #

Nel 2025, mentre l’AI trasforma come scriviamo e collaboriamo sul codice, i principi dell’InnerSource diventano ancora più rilevanti. Come manteniamo la qualità quando l’AI può generare migliaia di righe istantaneamente? Come preserviamo la condivisione della conoscenza quando la creazione del codice è automatizzata? Come assicuriamo che il giudizio umano rimanga centrale nello sviluppo software?

Per questa questione, fate riferimento a l’articolo che copre la metodologia di collaborazione nell’era dell’AI.

Bene, queste domande non hanno ancora risposte, ma credo che l’InnerSource—con la sua enfasi su apertura, trasparenza, mentorship prioritaria e contributo volontario al codice—sia posizionato in modo unico per esplorarle.

L’InnerSource ha molti sapori. Potete aggiungere il vostro. Potete nominare pattern che esistono ma non sono stati articolati. Questo è il motivo per cui l’InnerSource è entusiasmante: è una bandiera sotto la quale una comunità cresce, evolve e diffonde innovazione.

La InnerSource Commons Foundation accoglie queste discussioni. I membri della nostra comunità stanno esplorando quotidianamente queste domande, condividendo esperienze e costruendo il futuro della collaborazione interna.

Quindi vi chiedo: Qual è il vostro InnerSource? Come lo definirete per la vostra organizzazione? Quali pattern scoprirete e condividerete?

Esploriamo insieme queste domande. Il viaggio è appena iniziato. Non vedo l’ora di darvi il benvenuto nella conversazione su innersourcecommons.org.

Yuki Hattori

Yuki Hattori

President of the InnerSource Commons Foundation
Sr. Architect at GitHub
Open Source Technical Advisor at IPA (Japanese government administration)
Author of two books on AI and GitHub
O’Reilly books translator for Prompt Enginnering for LLMs and two InnerSource books[1][2]
 
Opinions expressed here are my own and do not represent any organization I am affiliated with.