Che cos'è l'open source e come è cresciuto GitHub e come guadagna?

L'open source non consiste semplicemente nel rendere pubblico il codice sorgente. È un modo per concedere ad altri i diritti di usare, studiare, modificare e ridistribuire software in base a una licenza definita. GitHub è cresciuto fino a diventare una piattaforma commerciale collegando questo tipo di sviluppo collaborativo in un unico flusso di lavoro per repository, controllo di versione, revisione del codice e automazione.

Il modello di business principale di GitHub non consiste nel vendere direttamente progetti open source pubblici. Attrae un'ampia base di utenti gratuiti, per poi addebitare la collaborazione privata, i controlli di accesso, la sicurezza, la conformità, l'automazione, gli ambienti di sviluppo cloud e le funzionalità di intelligenza artificiale di cui le aziende hanno bisogno.

Indice

• Il significato preciso di open source
• Il contesto alla base del movimento open source
• Come funziona lo sviluppo open source
• Le differenze tra open source, Git e GitHub
• Le origini e la crescita di GitHub
• Il modello di ricavi di GitHub
• Perché l'open source gratuito crea valore economico
• Limiti e criteri di valutazione

Che cos'è esattamente l'open source?

Il software open source è un software per il quale il titolare del copyright concede agli utenti diritti tramite una licenza, inclusi i diritti di eseguirlo, studiarlo, modificarlo e ridistribuirlo. La questione fondamentale non è soltanto se il codice sia visibile, ma quali diritti siano legalmente consentiti.

Secondo la definizione dell'Open Source Initiative (OSI), una licenza open source deve consentire la libera ridistribuzione, fornire il codice sorgente e permettere la distribuzione di modifiche e opere derivate. Non deve discriminare alcuna persona, gruppo o ambito d'uso. Di conseguenza, se si applicano restrizioni quali “solo per uso non commerciale” o “non utilizzabile in prodotti concorrenti”, è difficile riconoscere il software come open source nel senso consueto, anche se il suo codice sorgente è pubblico. OSI의 Open Source Definition↗

Questa distinzione è particolarmente importante per i repository pubblici su GitHub. Anche se un repository è visibile pubblicamente a tutti, in assenza di una licenza open source si applica il diritto d'autore predefinito. Altri possono visualizzare o fare fork del repository all'interno del servizio GitHub, ma non acquisiscono automaticamente il diritto di copiare, modificare e distribuire liberamente il codice. GitHub spiega inoltre che, affinché un progetto sia realmente open source, è necessaria una licenza che indichi le autorizzazioni d'uso. GitHub의 저장소 라이선스 안내↗

Le seguenti tre affermazioni hanno quindi significati diversi:

• “Puoi visualizzare il codice” descrive se il sorgente è pubblico.
• “Puoi usarlo gratuitamente” descrive il suo prezzo.
• “È open source” descrive i diritti concessi dalla sua licenza.

Il software gratuito non è necessariamente open source, e il software open source può anche essere venduto.

Quale contesto ha portato al movimento open source?

La pratica di condividere il codice software e migliorarlo in modo collaborativo esisteva nelle prime comunità di ricerca informatica. Tuttavia, con lo sviluppo del software come prodotto commerciale indipendente e il rafforzamento delle restrizioni sul copyright e sull'uso, è cresciuta anche la preoccupazione per la capacità degli utenti di studiare e correggere il software.

Negli anni Ottanta, Richard Stallman avviò il Progetto GNU e il movimento del software libero. Nel software libero, “libero” non si riferisce al prezzo, ma alla libertà degli utenti di eseguire, studiare, modificare e ridistribuire un programma, nella sua forma originale o modificata. GNU의 자유 소프트웨어 정의↗

Il nome “open source” fu creato in una riunione strategica tenuta poco dopo che Netscape annunciò l'intenzione di rilasciare il codice sorgente del proprio browser nel 1998. Nello stesso anno, Eric Raymond, Bruce Perens e altri fondarono l'OSI e organizzarono l'Open Source Definition sulla base delle Debian Free Software Guidelines. L'obiettivo era spiegare più chiaramente ad aziende e pubblico i vantaggi pratici dello sviluppo collaborativo. OSI 역사↗

Il software libero e l'open source coincidono ampiamente nelle licenze che accettano, ma differiscono per enfasi.

Questa differenza non significa che una delle due parti sia sempre superiore. Significa che lo stesso programma può essere spiegato da una prospettiva concentrandosi sui diritti degli utenti e dall'altra sull'efficienza dello sviluppo trasparente e della collaborazione distribuita.

Come funziona lo sviluppo open source?

Open source non significa che “chiunque possa modificare il codice come vuole”. La partecipazione può essere aperta, ma i manutentori del progetto e le procedure stabilite determinano ciò che viene incorporato in una versione ufficiale.

Un tipico processo di sviluppo funziona nel modo seguente:

1. Un manutentore pubblica il codice sorgente, la licenza, le istruzioni d'uso e le regole di contribuzione.
2. Un utente clona o fa fork del repository per creare uno spazio di lavoro indipendente.
3. Le correzioni di bug o lo sviluppo di funzionalità vengono eseguiti in un branch separato.
4. Il collaboratore invia una Pull Request contenente le modifiche e la loro motivazione.
5. I manutentori esaminano il codice, i risultati dei test, la direzione progettuale e l'impatto sulla sicurezza.
6. Solo le modifiche che soddisfano i criteri vengono unite al repository ufficiale.
7. Viene rilasciata una nuova versione e i problemi scoperti successivamente vengono nuovamente tracciati.

In questo processo esistono ruoli diversi. Gli utenti usano il software e segnalano problemi. I contributori inviano codice o documentazione. I manutentori gestiscono revisioni e rilasci. Un comitato direttivo del progetto o una fondazione può anche gestire marchi, budget e regole decisionali.

In altre parole, l'“apertura” dell'open source non significa assenza di autorità decisionale. Le opportunità di partecipazione e i diritti di usare il codice sono aperti, mentre i progetti ufficiali dispongono di strutture di controllo per mantenere la qualità.

In cosa differiscono le licenze open source?

Le licenze open source possono essere comprese, in generale, come licenze permissive e licenze copyleft.

Licenze permissive

MIT, BSD e Apache License 2.0 sono esempi comuni. Purché siano rispettate condizioni come il mantenimento delle note di copyright e del testo della licenza, queste licenze generalmente consentono di includere codice modificato in software proprietario.

Ciò le rende facili da integrare nei prodotti commerciali, ma non garantisce che il codice migliorato torni alla comunità originaria. Apache License 2.0 include inoltre disposizioni esplicite relative ai brevetti, quindi le sue condizioni legali non sono identiche a quelle della MIT License.

Licenze copyleft

La GNU General Public License (GPL) è un esempio rappresentativo. Quando viene distribuito codice modificato, oppure viene distribuita un'opera derivata combinata con tale codice, può richiedere che il codice sorgente sia fornito con la stessa licenza.

Il copyleft non vieta l'uso commerciale. Il software può essere venduto commercialmente, ma devono essere rispettati gli obblighi di divulgazione del codice sorgente nell'ambito definito dalla licenza. Varianti come LGPL e AGPL sono progettate con condizioni diverse per il collegamento di librerie e i servizi di rete.

Nella scelta di una licenza, non bisognerebbe selezionarla semplicemente perché la usa un progetto noto. Occorre esaminare l'ambito di divulgazione delle opere derivate, le disposizioni sui brevetti, l'erogazione tramite servizi di rete e la compatibilità con altre licenze.

Qual è la differenza tra open source, Git e GitHub?

Questi tre concetti compaiono spesso insieme, ma operano su livelli diversi.

• Open source è un concetto che descrive i diritti d'uso del software e un metodo di sviluppo collaborativo.
• Git è un programma open source di controllo di versione che gestisce in modo distribuito la cronologia delle modifiche ai file.
• GitHub è un servizio commerciale che ospita repository Git online e offre funzionalità di revisione del codice, gestione dei problemi, automazione, sicurezza e collaborazione.

Git è stato creato nel 2005 dopo la fine del rapporto tra la comunità di sviluppo del kernel Linux e lo strumento proprietario di controllo di versione distribuito BitKeeper. Era necessario uno strumento in grado di gestire la velocità, il lavoro distribuito e il gran numero di branch paralleli richiesti da un progetto grande quanto Linux. Git 공식 역사↗

Con Git, ogni sviluppatore può mantenere un repository contenente l'intera cronologia delle modifiche senza essere sempre connesso a un server centrale. Tuttavia, Git da riga di comando da solo rendeva scomodo gestire chi avesse proposto una modifica, perché fosse necessaria, chi l'avrebbe revisionata e quando sarebbe stata unita. GitHub ha organizzato proprio questo processo collaborativo attraverso un'interfaccia web.

Git può essere usato senza GitHub e i repository possono essere eseguiti su GitLab, Bitbucket o server self-hosted. Al contrario, GitHub contiene non solo open source, ma anche codice aziendale privato e codice pubblico senza licenza. GitHub e open source non sono sinonimi.

Come è nato GitHub?

GitHub è stato sviluppato attorno a Tom Preston-Werner, Chris Wanstrath e PJ Hyett ed è stato lanciato come servizio pubblico nel 2008. Scott Chacon, esperto di Git divenuto in seguito noto come autore di Pro Git, si è unito anch'egli al team iniziale.

Il primo commit nel repository interno di GitHub è stato effettuato nell'ottobre 2007 e il servizio è stato lanciato nell'aprile 2008. Intorno al suo primo anniversario, GitHub contava oltre 20.000 repository pubblici e quattro dipendenti a tempo pieno, senza aver ricevuto investimenti esterni. GitHub의 첫해 기록↗

Il problema che GitHub mirava a risolvere non era semplicemente l'archiviazione di file. Cercava di creare un ambiente collaborativo che visualizzasse le modifiche nei repository Git distribuiti, aiutasse gli sviluppatori a scoprire il lavoro reciproco e rendesse semplici da revisionare le proposte di modifica. Anche il grafo di rete pubblicato da GitHub nel 2008 era un tentativo di mostrare su un'unica schermata le relazioni tra branch e commit di più utenti. 초기 Network Graph 소개↗

Questo approccio venne in seguito definito “social coding”. I profili degli sviluppatori, le cronologie delle attività, i follow, i fork, le star, gli issue e le pull request sono diventati collegati ai repository di codice, trasformando lo stesso processo di sviluppo in una rete ricercabile e osservabile.

Perché GitHub è cresciuto così rapidamente?

La crescita di GitHub non può essere spiegata solo dall'offerta di archiviazione Git gratuita. Tempismo tecnico, esperienza utente, effetti di rete e un modello di business per le imprese hanno agito insieme.

Ha reso comprensibile sul web il complesso processo collaborativo di Git

Branch, commit e merge sono potenti funzionalità di Git, ma non sono facili da comprendere per i principianti attraverso i soli comandi. GitHub ha riunito differenze nel codice, discussioni, risultati delle revisioni e stato dei test nell'interfaccia delle pull request.

Invece di far circolare file di patch via email, gli sviluppatori potevano condividere le modifiche tramite un unico link. I manutentori dei progetti potevano ridurre i costi di revisione poiché il codice e il processo di discussione venivano registrati insieme.

I repository pubblici hanno creato una rete di sviluppatori

Quando un progetto approda su GitHub, è più probabile che anche gli utenti e i contributori di quel progetto creino account. Questi utenti creano poi altri progetti o partecipano a quelli esistenti.

All'aumentare del numero di repository, gli sviluppatori visitano GitHub per trovare codice. All'aumentare del numero di sviluppatori, i manutentori scelgono GitHub per attirare contributori. Questo è un effetto di rete a due lati.

Le cronologie delle attività pubbliche fungevano anche da portfolio degli sviluppatori. Le aziende potevano esaminare il codice effettivo e l'esperienza di collaborazione dei candidati, mentre gli sviluppatori avevano un incentivo a costruire cronologie di attività per opportunità di lavoro e reputazione.

Ha fatto crescere contemporaneamente prodotti open source e aziendali

GitHub ha abbassato la barriera di ingresso per i repository open source pubblici, pur addebitando i repository privati fin dai primi tempi. Nel 2011 ha lanciato GitHub Enterprise, eseguibile sui server interni delle aziende e in grado di rispondere a esigenze aziendali quali autenticazione, backup e gestione dei team. GitHub Enterprise 출시 기록↗

Questa struttura ha consentito agli sviluppatori individuali di imparare a usare GitHub attraverso progetti open source, per poi usare una versione enterprise dello stesso flusso di lavoro una volta entrati in un'azienda. Ha reso possibile un'adozione dal basso, con gli sviluppatori che introducevano il prodotto nelle loro organizzazioni senza attività di vendita separate rivolte ai singoli.

GitHub ha dichiarato di aver raggiunto redditività e crescita tramite servizi a pagamento senza investimenti esterni e ha raccolto il suo primo investimento esterno nel 2012. GitHub의 2012년 투자 발표↗

Ha ampliato il livello gratuito e ridotto le ragioni per passare a servizi concorrenti

Nel 2019, GitHub ha iniziato a offrire repository privati agli account personali gratuiti. Nel 2020 ha inoltre rimosso i limiti di collaboratori per i repository privati gratuiti e reso gratuite le funzionalità principali per i team. La gestione avanzata delle autorizzazioni, la sicurezza e le funzionalità di supporto necessarie alle aziende sono rimaste offerte a pagamento. GitHub Free 확대 발표↗

Espandere il livello gratuito significa rinunciare a parte delle entrate da abbonamenti nel breve periodo. Tuttavia, mantiene sulla piattaforma più individui e piccoli team e crea opportunità di convertirli in clienti di prodotti Team, Enterprise, sicurezza e IA man mano che le loro organizzazioni crescono.

In che modo l'acquisizione da parte di Microsoft ha influenzato la crescita di GitHub?

Microsoft ha accettato di acquisire GitHub nel 2018 per 7,5 miliardi di dollari in azioni Microsoft. All'epoca, GitHub dichiarava oltre 28 milioni di utenti. Microsoft affermò che GitHub avrebbe mantenuto operazioni indipendenti e il proprio carattere incentrato sugli sviluppatori. Microsoft의 GitHub 인수 발표↗

L'acquisizione ha allineato esigenze strategiche di entrambe le parti. GitHub poteva utilizzare infrastruttura cloud globale, rete di vendita enterprise e capacità di sicurezza e conformità. Microsoft poteva superare la propria precedente immagine di azienda incentrata su Windows e software proprietario e stabilire punti di contatto con gli sviluppatori indipendentemente dal sistema operativo o dal linguaggio di programmazione. Ha inoltre ottenuto opportunità di collegare Azure, Visual Studio, VS Code e GitHub.

Dopo l'acquisizione, GitHub si è espanso oltre l'hosting di repository fino a una piattaforma che copre l'intero ciclo di vita dello sviluppo. GitHub Actions automatizza build, test e distribuzioni; Codespaces offre ambienti di sviluppo cloud; i prodotti Advanced Security eseguono scansioni di codice, dipendenze e segreti; e Copilot offre funzionalità di scrittura e revisione del codice basate sull'IA.

Nell'ottobre 2022, Microsoft ha annunciato che GitHub aveva raggiunto 1 miliardo di dollari di ricavi ricorrenti annuali (ARR) e superato i 90 milioni di utenti, tre volte il numero al momento dell'acquisizione. Microsoft FY2023 1분기 실적 발표↗

GitHub ha annunciato che oltre 100 milioni di sviluppatori hanno usato la piattaforma nel 2023 e che oltre 180 milioni lo hanno fatto nel 2025. Nel 2025, il totale dei progetti ha raggiunto 630 milioni e GitHub ha contato circa l'81,5% di tutti i contributi come avvenuti in repository privati. Ciò mostra che GitHub è diventato sia uno spazio open source sia un'infrastruttura di sviluppo aziendale su larga scala. GitHub Octoverse 2025↗

Tuttavia, queste cifre sono metriche della piattaforma conteggiate secondo i criteri di GitHub stessa. Il numero di sviluppatori registrati non va interpretato come equivalente agli utenti attivi mensili o ai clienti paganti. Microsoft inoltre non divulga ogni anno in dettaglio i ricavi correnti e l'utile operativo di GitHub come unità aziendale autonoma, quindi l'ARR di 1 miliardo di dollari riportato nel 2022 va considerato una metrica rappresentativa delle dimensioni divulgata allora, non un dato sui ricavi attuali.

Nello specifico, dove guadagna GitHub?

Il modello di ricavi di GitHub può essere riassunto come un modello freemium: acquisisce utenti tramite una piattaforma pubblica gratuita e addebita il controllo e la produttività necessari alle organizzazioni per operare.

Abbonamenti per postazione utente

Il piano gratuito consente a singoli e piccoli team di usare le funzionalità principali dei repository. Il piano Team offre funzionalità di collaborazione avanzate, mentre il piano Enterprise offre sicurezza, conformità, amministrazione centralizzata e opzioni di distribuzione.

Secondo la pagina dei prezzi ufficiale verificata nel settembre 2026, Team parte da 4 dollari per utente al mese ed Enterprise da 21 dollari per utente al mese. Gli importi effettivi possono differire in base alla durata del contratto, alla regione, alle imposte e alle condizioni dei contratti di grandi dimensioni. GitHub 공식 가격표↗

La fatturazione basata sulle postazioni presenta il vantaggio che i ricavi ricorrenti possono crescere all'aumentare del personale di un'azienda. Una volta che il codice e i processi di lavoro si sono consolidati sulla piattaforma, aumentano anche i costi di passaggio, rendendo più probabile il mantenimento dei contratti.

Abbonamenti a prodotti IA e fatturazione basata sull'utilizzo

GitHub Copilot dispone di piani a pagamento per singoli e organizzazioni. Le aziende acquistano postazioni per ciascun utente e possono essere applicati costi di utilizzo aggiuntivi quando si supera l'uso dell'IA incluso in un piano. Copilot si sta quindi sviluppando in un modello che combina i tradizionali abbonamenti software con la fatturazione per l'uso di calcolo IA. GitHub Copilot 조직 청구 안내↗

Copilot non aggiunge solo una nuova fonte di ricavo per GitHub, ma fa anche sì che l'IA venga consumata nei flussi di lavoro consolidati che coinvolgono repository, issue, pull request e revisione del codice. Questo rende più semplice la vendita incrociata di prodotti aggiuntivi agli attuali clienti della piattaforma di quanto non sarebbe vendere uno strumento IA separato.

Prodotti di sicurezza e conformità

Le grandi imprese non pagano semplicemente per un luogo in cui archiviare codice. Hanno bisogno di controlli degli account, registri di audit, single sign-on, rilevamento di segreti, analisi delle vulnerabilità del codice, gestione della supply chain e conformità normativa.

Con la crescente dipendenza dalle dipendenze open source, le organizzazioni devono eseguire continuamente scansioni per pacchetti vulnerabili e credenziali esposte. L'espansione dell'ecosistema gratuito aumenta paradossalmente anche la necessità di prodotti di sicurezza enterprise.

Utilizzo di calcolo, archiviazione e automazione

Servizi come GitHub Actions, Codespaces e Packages includono una certa quantità di utilizzo in un piano e addebitano gli extra. Una fattura enterprise può includere non solo licenze Enterprise, ma anche l'uso in eccesso di Actions o Codespaces e licenze aggiuntive per prodotti quali Copilot e strumenti di sicurezza. GitHub Enterprise 청구 구조↗

Questo modello consente ai ricavi di GitHub di crescere all'aumentare dell'attività di sviluppo. D'altra parte, GitHub sostiene anche i costi di server di esecuzione, dispositivi di archiviazione, reti e modelli IA, quindi non tutti i ricavi da utilizzo costituiscono profitto.

Commissioni sulle transazioni del Marketplace

Gli sviluppatori di terze parti possono vendere app a pagamento tramite GitHub Marketplace. GitHub fornisce la gestione dei pagamenti e degli abbonamenti e trattiene una parte del valore della transazione come commissione operativa. Secondo la documentazione ufficiale, la quota trattenuta applicata alle transazioni delle app dal 2021 è del 5%. GitHub Marketplace 판매 대금 안내↗

Oltre alle commissioni dirette del Marketplace, è importante anche il fatto che gli strumenti esterni diventino incentrati su GitHub. Man mano che vengono usate più app, al momento di abbandonare GitHub occorre sostituire più strumenti di sviluppo, rafforzando la capacità della piattaforma di trattenere gli utenti.

Perché l'open source gratuito ha valore economico per GitHub?

Per GitHub, i repository pubblici gratuiti non sono semplicemente una voce di costo. Sono una risorsa fondamentale per l'acquisizione di utenti e la formazione dell'ecosistema.

Innanzitutto, i progetti open source attirano nuovi utenti. Gli sviluppatori che desiderano usare una libreria specifica, segnalare un problema o inviare una patch creano account GitHub. GitHub può acquisire questi utenti senza spendere in pubblicità.

In secondo luogo, l'attività open source fa diventare il modo di lavorare di GitHub uno standard di fatto del settore. Gli sviluppatori imparano fork, issue e pull request a scuola o attraverso progetti personali, per poi preferire lo stesso approccio al lavoro.

In terzo luogo, l'ecosistema pubblico e lo sviluppo aziendale privato dipendono l'uno dall'altro. Anche i prodotti privati delle aziende usano innumerevoli librerie e strumenti pubblici. Nei dati GitHub del 2025, la maggior parte dell'attività di contribuzione avveniva in repository privati, mentre i progetti pubblici costituivano la maggioranza per numero di repository. L'ecosistema pubblico gratuito fornisce le fondamenta per il lavoro enterprise a pagamento.

In quarto luogo, progetti pubblici più attivi aumentano la domanda di sicurezza e automazione. Diventano necessari aggiornamenti delle dipendenze, rilevamento di pacchetti dannosi, gestione delle licenze e test e distribuzioni su larga scala.

Il supporto di GitHub all'open source gratuito è quindi difficile da spiegare come sola filantropia o sola attività commerciale. Offre valore reale alla comunità degli sviluppatori e al contempo funge da strategia di distribuzione a lungo termine verso il mercato enterprise a pagamento.

Come guadagnano in generale le aziende open source?

Il modello di business di GitHub è uno dei vari modelli di ricavo che fanno uso dell'open source. Le aziende open source spesso addebitano non il codice riproducibile in sé, ma la comodità operativa, la responsabilità, la sicurezza e la competenza.

• Supporto e consulenza: Offrono il software gratuitamente e addebitano installazione, risposta agli incidenti, formazione e supporto a lungo termine.
• Cloud gestito: Accanto all'open source che i clienti possono installare autonomamente, vendono SaaS che lo gestisce per conto del cliente.
• Open core: Rendono pubbliche le funzionalità di base, offrendo al contempo funzionalità di gestione enterprise, sicurezza e analisi con licenze proprietarie.
• Doppia licenza: Offrono lo stesso codice sia con una licenza open source sia con una licenza commerciale, consentendo agli utenti di scegliere in base alle proprie circostanze.
• Hosting e utilizzo: Addebitano in base all'uso di archiviazione, rete, calcolo ed esecuzione dell'automazione.
• Sponsorizzazioni e donazioni: Individui, aziende e fondazioni sostengono i manutentori o le operazioni del progetto.
• Certificazione e formazione: Ottengono ricavi tramite formazione ufficiale, esami, certificazioni tecniche o programmi per partner.

Questi modelli funzionano perché i costi del software non sono limitati al prezzo della licenza. Le aziende considerano il costo totale di proprietà, incluso il tempo di installazione, il rischio di interruzioni, gli incidenti di sicurezza, gli aggiornamenti, la conformità normativa e la carenza di personale specializzato. Anche se possono ottenere il codice gratuitamente, possono essere disposte a pagare per una responsabilità operativa affidabile.

Quali sono i limiti dell'open source e di GitHub?

L'open source non diventa automaticamente software sicuro e sostenibile semplicemente perché ha molti partecipanti.

Gli oneri di manutenzione possono concentrarsi su poche persone

Anche una libreria molto usata può dipendere da pochi manutentori per le revisioni e i rilasci effettivi. Con l'aumento dell'uso, cresce il carico di segnalazione dei problemi e di risposta alla sicurezza, mentre il compenso dei manutentori potrebbe non crescere di pari passo.

La revisione pubblica non garantisce la qualità

Il fatto che il codice sorgente sia pubblico è diverso dal fatto che qualcuno lo abbia revisionato a sufficienza. I rischi della supply chain includono vulnerabilità, contributi dannosi, account dei manutentori compromessi e dipendenze contaminate.

Gli obblighi di licenza possono essere trascurati

L'open source non è un bene pubblico privo di copyright. Devono essere rispettate le condizioni di ogni licenza, incluso il mantenimento delle note di copyright, la fornitura del codice sorgente, l'indicazione delle modifiche e l'applicazione della stessa licenza. La compatibilità delle licenze deve essere riesaminata soprattutto nei prodotti commerciali che combinano molte dipendenze.

La concentrazione della piattaforma crea nuove dipendenze

Poiché Git è distribuito, i repository possono essere spostati su altri server. Tuttavia, migrare completamente issue, discussioni sulle pull request, workflow Actions, policy di accesso, app Marketplace e registri di sicurezza è molto più difficile.

Più GitHub diventa comodo, più le comunità di sviluppo possono dipendere dai prezzi, dalle policy, dalla risposta agli incidenti e dalle modifiche alle funzionalità di una singola azienda. È necessario clonare il codice localmente, eseguire backup di rilasci e documentazione e comprendere le dipendenze dalle funzionalità specifiche della piattaforma.

Quali sono i fraintendimenti comuni?

“È pubblico su GitHub, quindi è open source”

Senza una licenza, non sorgono i normali diritti d'uso open source. Visibilità e licenza sono impostazioni separate.

“Tutto l'open source è gratuito”

Il costo di copia può essere assente, ma operazioni, supporto, servizi cloud, formazione e funzionalità di sicurezza possono avere costi. Le licenze open source non vietano le vendite a pagamento.

“Chiunque può modificare il codice ufficiale come vuole”

Il diritto di chiunque di modificare la propria copia differisce dall'autorità di incorporare modifiche nel progetto ufficiale. I manutentori e le regole di governance decidono se le modifiche vengono incluse ufficialmente.

“GitHub stesso è open source”

GitHub ospita progetti open source su larga scala e rilascia vari strumenti open source, ma l'intero servizio GitHub non è un unico prodotto open source. GitHub è una piattaforma commerciale di proprietà di Microsoft.

“Poiché GitHub ha molti utenti, la maggior parte di essi è pagante”

I conteggi degli sviluppatori riportati da GitHub includono account gratuiti. Totale degli sviluppatori registrati, sviluppatori attivi, clienti enterprise e postazioni a pagamento sono metriche diverse.

“Microsoft gestisce GitHub gratuitamente”

Benché i repository gratuiti siano ampiamente disponibili, GitHub genera ricavi da postazioni enterprise, IA, sicurezza, automazione, calcolo, archiviazione e Marketplace. Gli utenti gratuiti forniscono sia potenziale conversione in clienti paganti sia valore di rete.

Come si dovrebbe valutare un progetto open source?

Quando si adotta open source in un progetto reale, non bisogna guardare solo al numero di star o alle classifiche GitHub. Esaminate insieme i seguenti elementi:

• Il file LICENSE e la compatibilità legale con l'uso previsto
• La frequenza di rilasci recenti e aggiornamenti di sicurezza
• Il numero di manutentori principali e la dipendenza da persone specifiche
• La velocità di revisione di issue e pull request
• L'esistenza di procedure per test, automazione e segnalazione delle vulnerabilità
• La completezza della documentazione e delle indicazioni di aggiornamento
• Il personale e i costi necessari per il self-hosting
• La dipendenza da GitHub o da un particolare servizio cloud
• Le alternative disponibili e la fattibilità della migrazione se il progetto viene interrotto

Gli stessi principi si applicano nella scelta di GitHub come piattaforma di lavoro. Invece di confrontare solo i prezzi gratuiti, valutate insieme la gestione delle autorizzazioni necessaria, l'audit, la sicurezza, l'uso dell'automazione, l'uso dell'IA, la posizione dei dati, la risposta agli incidenti e i costi di migrazione.

Come dovrebbe essere compreso il rapporto tra open source e GitHub?

L'open source è un insieme di regole che distribuisce i diritti di usare e migliorare il software in modo collaborativo. Git è uno strumento per gestire in modo distribuito la cronologia di tali modifiche e GitHub è una piattaforma che intermedia la collaborazione basata su Git su larga scala.

GitHub non ha inventato l'open source. Ha invece semplificato in un flusso di lavoro web unificato i processi di scoperta, copia, discussione, revisione e unione necessari alle comunità open source. I progetti pubblici hanno creato una rete di sviluppatori e quella rete ha attirato su GitHub anche lo sviluppo aziendale privato.

Di conseguenza, anziché richiedere un biglietto d'ingresso per il codice pubblico, GitHub ha costruito un modello che addebita il controllo, la sicurezza, l'automazione, il calcolo e l'IA di cui le aziende hanno bisogno per collaborare su larga scala. È iniziato con un modello iniziale di “pubblico gratuito e privato a pagamento”, ma oggi può essere inteso come un'attività di piattaforma di sviluppo in cui “la collaborazione di base è gratuita e sono a pagamento le funzionalità che risolvono la complessità organizzativa”.