InnerSource è una Bugia - Una Risposta ai Malintesi Comuni
Quando cerchi “InnerSource” su YouTube, uno dei primi risultati che probabilmente incontrerai è un video che afferma che “InnerSource è una bugia.”
(link: https://youtube.com/shorts/53jEP3mPP3E)
Questo punto di vista rappresenta una tipica trappola in cui molte persone cadono quando imparano per la prima volta di InnerSource.
Voglio usare questo video come caso di studio per spiegare che tipo di conclusioni fuorvianti promuove. Questo è un errore che ho commesso anch’io in passato, ed è una trappola in cui molte persone che non hanno esplorato profondamente questo campo possono facilmente cadere. Ecco perché voglio esaminare questo con auto-riflessione e aiutare altri a trovare la strada giusta svelando queste insidie.
Il Primo Malinteso: “Usa React Così Altri Possono Contribuire” #
Lasciami prima analizzare l’argomento in questo caso. Il video suggerisce di usare React per applicazioni interne “Usa React perché altre persone possono contribuirvi.” Questo tipo di ragionamento è raramente sentito nelle discussioni reali su InnerSource.
should you use react HTMX or solid or something for your company’s internal application now a lot of people what you’re going to hear is use react so other people can contribute to this
Questo argomento può essere scomposto in tre problemi chiave:
- Fraintendimento fondamentale di cosa InnerSource significhi realmente
- Scegliere il dominio sbagliato per l’applicazione di InnerSource
- Confondere le prospettive individuali versus di team
Cosa InnerSource Significa Realmente #
InnerSource riguarda la pratica dei principi open source all’interno di un’azienda. Non riguarda solo “contribuire” o “ricevere contributi.”
La maggior parte delle persone che interagiscono con l’open source sono semplicemente “utenti.” Alcuni sono solo consumatori, altri segnalano bug, e solo una piccola frazione invia effettivamente pull request. InnerSource applica gli insegnamenti dell’open source internamente per creare organizzazioni che sono aperte, ampiamente accessibili, con processi decisionali trasparenti, e relazioni di team costruite sulla fiducia attraverso ownership e mentorship. Questo crea una cultura di trasparenza e collaborazione.
Questo è ciò che significa “praticare l’open source internamente” - non riguarda solo “ricevere pull request.” Le pull request sono semplicemente un risultato di questa cultura, non l’obiettivo primario.
Un Dominio Meno Ottimale per l’Applicazione di InnerSource #
Il secondo problema è che questo argomento si sviluppa in un dominio dove InnerSource e l’open source affrontano sfide particolari.
Se vuoi “ricevere pull request” o “avere molte persone che usano il tuo codice per migliorare la qualità,” questo potrebbe essere limitato dalla natura del tuo prodotto. È chiaro che condividere “componenti ad alta dipendenza” o strumenti a livello di piattaforma creerebbe più valore rispetto alle applicazioni per utenti finali. Mentre i team stream-aligned dovrebbero comunque adottare pratiche open source quando benefiche, le dinamiche di collaborazione differiscono significativamente.
Nella mia esperienza lavorando con aziende enterprise, usare InnerSource per iniziative a livello di progetto dove gli utenti finali sono “non-ingegneri” presenta sfide uniche. Perché? Perché alla fine, questi prodotti devono servire i bisogni di “utenti finali” o “utenti business” che potrebbero mancare di competenze di sviluppo e canali di comunicazione diretti con i team di sviluppo. Questo crea requisiti complessi e individualizzati e tempi di comunicazione più lunghi.
Le implementazioni di InnerSource tendono a funzionare relativamente bene quando applicate a librerie condivise, componenti di piattaforma, strumenti di sviluppo, e codice di infrastruttura—aree dove gli “utenti” sono principalmente altri sviluppatori che possono contribuire significativamente e beneficiare delle pratiche di sviluppo collaborativo.
Mentre applicare le pratiche InnerSource alle applicazioni rivolte agli utenti può portare benefici preziosi come trasparenza e miglioramento del tracking dei problemi (che da solo lo rende utile).
Prospettiva Individuale vs. Team #
Il terzo problema riguarda se “tu” si riferisce a un individuo o a un team.
È importante notare che InnerSource non riguarda necessariamente aspettare che qualcuno contribuisca al “tuo progetto personale” all’interno di un’azienda. Quando InnerSource viene applicato, potrebbero esserci casi dove le persone contribuiscono a progetti sviluppati durante il 20% del tempo, come nelle grandi aziende tech, ma quello non è necessariamente l’approccio mainstream.
InnerSource viene introdotto e mantenuto principalmente perché genera ROI attraverso riduzione dei costi, evitando di reinventare la ruota, creando sinergie, assicurazione qualità, e rimuovendo l’overhead di comunicazione dal processo decisionale gerarchico. Questo tipicamente coinvolge librerie interne condivise, componenti proprietari di vantaggio competitivo, o cose con alte dipendenze che sono di nicchia all’interno dell’enterprise. E questi “benefici business” tipicamente ritornano alle “operazioni del team” nella maggior parte dei casi. Alla fine, è tutto questione di ROI per team e organizzazioni. Se non pensiamo ai team, qualcuno ti impedirà di contribuire ai progetti. Devi giustificare il tuo ROI che sia a breve o lungo termine.
Ciò che è unico di InnerSource è che riguarda fondamentalmente la collaborazione team-to-team. È qui che la maggior parte delle implementazioni finisce. Non riguarda necessariamente individui che contribuiscono casualmente a progetti personali convenienti. È tipicamente implementato attraverso relazioni di host team e guest team, dove i guest team si appoggiano a parti mantenute dagli host team. La maggior parte delle enterprise ha dipendenti con ruoli e responsabilità definiti, e la collaborazione tende a succedere all’interno di queste strutture.
Pertanto, InnerSource è particolarmente efficace quando vengono stabilite relazioni tra platform team e stream-aligned team (guest team e host team). La co-creazione attiva tra stream-aligned team o individui è più incerta per avere successo naturalmente.
Criticare tutto InnerSource basandosi su scenari che è improbabile funzionino non ha senso logico.
Il Secondo Malinteso: “Non Succede Mai nelle Aziende Reali” #
because we want people doing that the reality is that’s not what’s going to happen ever at any company ever inner source
In realtà, questo sta succedendo. I casi di studio lo dimostrano. Punto.
Il Terzo Malinteso: “Il 99,69% dei Progetti InnerSource Falliranno” #
99.69% a lie you’re going to build the entire project by yourself when it goes down people are going to look to you
Questo potrebbe essere corretto a seconda di come definisci “InnerSource.” Come menzionato prima, InnerSource non riguarda “ricevere contributi PR.”
Tuttavia, ci sono tre punti importanti da considerare:
- InnerSource si applica specialmente a componenti strategici - non è richiesto per tutti i componenti
- I benefici si estendono oltre i contributi attivi
- L’open source ha lo stesso problema del “tasso di fallimento”
InnerSource è una Strategia Aziendale #
Quando le persone pensano a InnerSource, a volte immaginano idee radicali come “condividere tutto il codice all’interno dell’enterprise” o “tutti contribuiscono a tutto.” Potrebbero immaginare centinaia di repository condivisi all’interno di un’azienda con tutti che scambiano attivamente contributi. Come l’open source essere una strategia per le aziende, InnerSource è anche una strategia aziendale con priorità. Le aziende condividono “ciò che vale la pena condividere” per primo.
Pertanto, il numero effettivo di codebase dove il codice fluisce attivamente tra team e avviene una collaborazione vibrante cross-team è relativamente piccolo. Questo potrebbe infatti essere percentuali a singola cifra. Tuttavia, anche senza collaborazione attiva cross-team, molti progetti possono beneficiare dall’essere aperti e trasparenti. In questo senso di InnerSource, le enterprise possono spesso condividere valore attraverso molti più casi.
Mentre InnerSource include contributi individuali, è principalmente focalizzato sulla collaborazione team-to-team. Pertanto, ciò che viene condiviso attraverso InnerSource tende ad essere relativamente di nicchia all’interno delle enterprise, o elementi specifici come distribuzioni Linux forkate per bisogni particolari. O potrebbe semplicemente essere cultura di sviluppo simile all’open source, come quando GitHub condivide codice Ruby on Rails tra tutti i dipendenti.
Quando condizioniamo questa discussione percentuale su InnerSource che collabora attivamente e viene mantenuto come requisiti comuni, la percentuale potrebbe infatti essere relativamente bassa. Tuttavia, piccole collaborazioni come pull request di documentazione o modifiche di configurazione minori (invio di piccole patch) tra guest team e platform/host team succedono relativamente frequentemente. Quando includi queste micro-collaborazioni e benefici di trasparenza che prevengono sforzi duplicati, questi numeri aumentano significativamente.
L’Open Source Ha lo Stesso “Problema” #
D’altra parte, se lo definiamo in quel modo, anche l’open source sarebbe una “bugia.” Perché “il 99,69% dei progetti open source falliranno.” La maggior parte del codice pubblicato come open source non riceve contributi. Ma nessuno dice “l’open source è una bugia” per questo. Le persone perseguono l’open source perché ci sono benefici oltre ricevere contributi.
Ancora, “ricevere contributi” non è l’unico valore di InnerSource. E lo stesso vale anche per il valore dell’open source
I Veri Benefici della Trasparenza #
Mantenere il codice interno aperto piuttosto che nascosto - a GitHub, architetti o solution engineer nel team revenue potrebbero essere in grado di esaminare il codice sorgente per trovare informazioni rilevanti, potenzialmente trovando dettagli molto vicini alle richieste dei clienti, facilitando conversazioni di supporto più fluide, ed estraendo informazioni più accurate dai problemi. Vivo a Tokyo, e a volte è più veloce guardare semplicemente il codice Ruby per controllare l’implementazione, o andare ai problemi per controllare il background delle modifiche, piuttosto che aspettare che il team prodotto basato a SF si svegli per fare domande di implementazione sui cambiamenti e il loro background.
Usando il comando git blame, puoi identificare i “veri” stakeholder del codice e fare domande sul background delle decisioni.
Inutile dire che lo stesso si applica ad altri team di sviluppo. Avere informazioni prontamente disponibili sui componenti che potrebbero creare dipendenze riduce chiaramente l’overhead di comunicazione.
InnerSource riguarda praticare i principi open source internamente. InnerSource non riguarda solo inviare pull request avanti e indietro - riguarda assicurare trasparenza e ottenere benefici attraverso collaborazione in stile open source. Questi benefici si estendono ben oltre i pochi percento di repository attivamente mantenuti ai benefici di implementazione culturale più ampi.
Il Quarto Malinteso: “Ti Richiameranno Quando Te Ne Vai” #
“when you leave the company they’re going to send you a message 6 months later asking you questions or seeing if you would like to contract with them to upgrade your application there is no such thing as innersourcing”
Le risorse a volte rimangono non mantenute, ma questa non è una critica appropriata di InnerSource stesso - è critica del fallimento nell’implementare InnerSource correttamente. Questa non è critica di InnerSource, ma critica della mancanza di cultura di manutenzione dove nessuno mantiene il codice. Questo risulta dal fallimento nell’implementare InnerSource correttamente o non considerarlo affatto - il risultato della mancanza di ownership.
L’Analogia DevOps #
Questa è critica del fallimento nel fare InnerSource, non critica di InnerSource stesso. A volte questo confonde la logica. Per metterla in termini DevOps: è come dire “le aziende finiscono per adottare cicli di review lenti di diversi mesi o audit, o aggiungendo processi per decisioni di rilascio, quindi i rilasci diventano trimestrali o solo due volte l’anno. Pertanto DevOps, che afferma di abilitare rilasci veloci, non va bene.” Non è perché la metodologia DevOps è cattiva, ma semplicemente perché “ci sono stati casi dove DevOps non poteva essere implementato.”
Rompere i processi business è estremamente difficile, e molte aziende hanno detto che DevOps era impossibile. Ma anche quando le persone pensavano fosse impossibile, c’erano pionieri coraggiosi che hanno lavorato duramente per cambiare la cultura e hanno raggiunto DevOps. Lo stesso può succedere con InnerSource.
Il Quinto Malinteso: “Devi Possedere Tutto al 100%” #
you own it 100% (which implies: InnerSource where you don’t own 100% is impossible)
“InnerSource significa abbandonare la code ownership” è sbagliato. InnerSource richiede effettivamente che i team possiedano il codice. Questo è un errore comune. È come le persone che vogliono abbandonare la responsabilità di manutenzione e dicono “rendiamolo open source.” Quello non funziona.
Ownership Individuale vs. Team - È InnerSource Strong Code Ownership? #
Prima, questo “Tu” è individuale o plurale? Anche se gli individui potrebbero essere elencati come file CODEOWNERS nelle organizzazioni, i team alla fine detengono la responsabilità per il codice. Contestualmente, probabilmente sta parlando di Strong Code Ownership. Ma questo non è buono quando si considera la manutenzione organizzativa. Perché i dipendenti potrebbero dimettersi.
InnerSource non è Strong Code Ownership. Come minimo, più persone devono condividere la responsabilità. Detto questo, riconosco che Strong Code Ownership può emergere nel breve termine, e nelle fasi iniziali di un progetto, una forte volontà individuale potrebbe naturalmente portare a tali arrangiamenti, ma se vuoi raggiungere successo a lungo termine, è necessario delegare l’autorità così che l’organizzazione possa gestire la manutenzione collettivamente.
Tipi di Team Ownership - È InnerSource Collective Code Ownership? #
Questo tipo di argomento potrebbe a volte riferirsi a Collective Ownership. In questo caso, l’argomento sembra anche suggerire che InnerSource significa collective ownership, ma quello è effettivamente diverso. InnerSource non è Collective Code Ownership InnerSource coinvolge host team che alla fine gestiscono la manutenzione. InnerSource è Weak Code Ownership. Quindi mentre la responsabilità di manutenzione è corretta al 100%, dire “devi possedere al 100% e InnerSource è diverso” è completamente illogico. Questa è effettivamente un’opinione incorretta.
Come Martin Fowler ha famosamente argomentato sulla code ownership, avere tutti che possiedono codice al 100% (collective ownership) a volte crea situazioni dove nessuno si prende la responsabilità. È molto problematico - la responsabilità diventa poco chiara e i progetti alla fine falliscono.
Modello Weak Code Ownership #
In Weak Code Ownership, i maintainer esistono, gli host team mantengono i progetti, e parti specifiche potrebbero portare trusted committer/maintainer da altri team. Qualcuno potrebbe contribuire, qualcuno potrebbe mantenere, ma non al 100% da “te” o “il tuo team” - potrebbe essere abbastanza diverso. Per esempio, il 98% del codice potrebbe essere posseduto dal tuo team, mentre il 2% potrebbe essere posseduto da altri team.
In questo caso, ricorda che anche se gli individui sono assegnati come code owner nelle organizzazioni, i team alla fine detengono la responsabilità per il codice. I team dovrebbero possederlo, e non dimenticare questo punto importante.
Il Sesto Malinteso: “Qualcuno Ti Scaricherà 7000 Righe Addosso” #
Every now and then there will be a sufficiently motivated coworker who’s really great and do like a 7,000 line update no explanation but don’t ever fall into this idea that choosing anything for an internal app that you are going to be working on
Avere pull request da 7000 righe che appaiono improvvisamente è esso stesso un fallimento nell’introdurre la cultura InnerSource - non è qualcosa che succede facendo InnerSource. Questo caso potrebbe preoccuparsi che introdurre InnerSource faccia succedere tale collaborazione, ma è completamente sbagliato.
Il Vero Problema #
Questo argomento rappresenta fallimento nell’implementare cultura InnerSource e pratiche collaborative, non InnerSource stesso. Implementazioni da 7000 righe sono casi molto limitati. Questo rappresenta fallimento della cultura di collaborazione dove 7000 righe vengono inviate come pull request improvvisamente senza alcuna notifica - l’organizzazione dovrebbe sistemare questo problema culturale fondamentale, che è pre-InnerSource.
Se vuoi prevenire questo, c’è una soluzione. Promuovi la cultura InnerSource all’interno della tua organizzazione:)
La Realtà: Cosa InnerSource È Realmente #
InnerSource è implementazione culturale - usare pratiche di collaborazione open source per godere di vari benefici che l’open source riceve attraverso la collaborazione. Lo scopo ultimo di InnerSource non è solo ricevere contributi (pull request), ma include richieste di funzionalità attraverso issue, coordinamento del supporto, e vari altri benefici, più trasparenza nel processo decisionale e promozione culturale pratica.
Pertanto, rifiuto definitivamente l’affermazione che “implementare le best practice InnerSource per ottenere pull request è una bugia.”
Comprendere la Realtà dei Contributi #
“Nessuno mai contribuirà”
Nella collaborazione open source, i contributori sono infatti una frazione minuscola. Su 1000 utenti, forse la grande maggioranza sono solo utenti, 20 potrebbero inviare issue o richieste di funzionalità, 5 potrebbero inviare pull request, e forse solo uno diventa un maintainer.
Ancora, le best practice InnerSource non faranno contribuire tutte le 1000 persone. InnerSource aiuta a indurre tale collaborazione, ma alla fine mira a rompere i silos enterprise, migliorare la collaborazione che è ostacolata dai vincoli organizzativi tradizionali, ridurre i tempi di lead dai silos informativi, e ottimizzare l’allocazione delle risorse organizzative usando pratiche open source.
Conclusione #
Mentre gli argomenti in questo caso toccano alcune sfide reali, sono basati su malintesi comuni che molte persone incontrano quando imparano per la prima volta di InnerSource. Queste sono insidie ben conosciute nella community, ed è comprensibile come qualcuno possa raggiungere queste conclusioni senza un’esplorazione più profonda del campo.
L’insight chiave è che InnerSource non riguarda forzare le pratiche open source in un framework rigido. Invece, riguarda tornare alla domanda fondamentale: cosa possiamo imparare dall’open source? Esaminando l’open source attraverso una lente più ampia, possiamo meglio adattare questi principi internamente.
Puoi unirti a questa conversazione e portare prospettive fresche. Che tu voglia costruire su questa discussione, esplorare dettagli di implementazione più specifici, o anche sfidare completamente questi argomenti - tutti gli approcci sono benvenuti. Ciò che conta di più è mantenere quella prospettiva ampia sugli insegnamenti open source e come si traducono nei contesti organizzativi interni.
Per informazioni complete su InnerSource, raccomando di controllare la InnerSource Commons Foundation. Accolgono punti di vista diversi e dialogo continuo su come i principi open source possono creare valore all’interno delle organizzazioni.
