Perché l'improvviso aumento del numero di mittenti Git sul grafico popcon Debian nel 2010-01?

Quasi ogni articolo che ho letto ¹ confrontando Git e Mercurial sembra che Mercurial abbia una UX della riga di comando migliore con ogni comando limitato a una sola idea (a differenza di dire git checkout).

Ma ad un certo punto Git è diventato improvvisamente molto popolare e il numero di utenti che hanno presentato Git sul grafico popcon Debian (vedi immagine del grafico sotto) è letteralmente esploso.

Fonte: Debian

Cosa è successo nel 2010-01 che le cose sono improvvisamente cambiate. Sembra che GitHub sia stato fondato prima di quello - 2008.

Il pacchetto "gnuit" (GNU Interactive Tools, un browser / visualizzatore di file e visualizzatore di processi) è stato chiamato "git" in Debian fino al 09/09/2009, mentre git è stato chiamato "git-core".

Pertanto, un grafico migliore da guardare è:

Il che dimostra che la popolarità non è aumentata drammaticamente (prendi la linea verde per la parte sinistra fino a quando non si incrociano, quindi prendi la linea rossa).

Il pacchetto git in Debian era precedentemente noto come git-core. Nell'aprile 2010 il pacchetto è stato rinominato git. Maggiori dettagli possono essere trovati in questo post sul blog di Julius Plenz o in questo impegno in Debian .

Ecco un grafico che mostra il numero di installazioni di entrambi gite git-corenel tempo:

Stavo usando Darcs per i miei progetti per un po '. Sono passato a git durante la rapida ascensione a cui si riferisce il tuo grafico, quindi ecco la mia osservazione:

I sistemi di controllo del codice sorgente distribuito a quel tempo rappresentavano una vera e propria crisi. I cosiddetti programmatori alfa li utilizzavano di lato, ma non rientravano nel radar della maggior parte degli sviluppatori di software professionali. Il modo di guardare al mondo CVS / SVN / SourceSafe / TFS era uno di quelli con cui i programmatori in generale erano più o meno soddisfatti e la maggior parte delle persone supponeva che i problemi che avevano generato il sistema di controllo della fonte distribuito potessero essere risolti con strumenti migliori. Proprio come hai ottenuto un miglioramento passando da CVS -> SVN che un giorno ci sarebbe qualcosa che ti permetterebbe di andare SVN -> SVN ++. In quale altro modo gestiresti il ​​controllo del codice sorgente?

Poi venne Git. Ciò che ha costretto il git sul radar di tutti è stato che c'era un enorme progetto pubblico che l'ha immediatamente adottato. Git ha avuto molti utenti gratuitamente - se avessi intenzione di fare un serio hacking del kernel, hai usato git. Anche se non posso essere sicuro al 100%, scommetterei che in quel momento nessun altro DVCS aveva una base di utenti così ampia.

Quindi ha funzionato. Ha funzionato bene Ha funzionato bene in pubblico. Inoltre, per le sue verruche iniziali, all'epoca era più stabile della maggior parte dei DVCS concorrenti. Darcs, per esempio, potrebbe essere messo in uno stato incoerente che richiedeva un'utilità assurdamente complessa (quadratica? Fattoriale? Non riesco a ricordare con certezza, ma era una cosa cattiva ) da risolvere. Git è sempre stato più stabile.

Dalla sua base di utenti di grandi dimensioni è solo un po 'dissanguato.

Ogni progetto, commerciale o open source, ha bisogno di quella massa critica. Darcs non l'ha capito. Nemmeno Mercurial. Ripensare. Molti piccoli progetti lo usano. Probabilmente ci sono anche un numero di utenti commerciali. Ma qual è la tua grande storia di successo?

"Se è abbastanza buono per il kernel Linux, è abbastanza buono per te" è un argomento molto convincente.

Quindi, per riassumere, è stato un buon prodotto che è arrivato al momento giusto e ha ottenuto una base di utenti ampia e dedicata.

Sono stato in ritardo ad adottare - passando da Mercurial a Git verso il 2010.

Il motivo per cui credo che Git sia diventato così popolare è a causa di siti come GitHub che hai avuto un effetto di rete negli strumenti di controllo della versione. Questo non era stato visto in precedenza, poiché si condivideva il codice su un progetto o su una base aziendale.

Ricordo in particolare il passaggio a Git e Github perché tutti i progetti che mi interessavano seguire e ai quali avevo contribuito avevano fatto lo stesso, così come gli sviluppatori a cui mi associo.

Questo è un effetto di rete.

GitHub era il livello di collaborazione basato sul Web più popolare basato su DVCS e Git ha finito per essere "abbastanza buono". Mercurial era sicuramente più facile da imparare e usare, Git ha molte sfumature, ma aveva un marchio solido grazie a Linus.

Solo perché GitHub è stato lanciato nel '08 e la crescita inizia nel '10 non significa che GitHub non sia responsabile. Se guardi i grafici della crescita competitiva in altre aree come i social network e la crescita di Facebook, la linea è molto simile.

Non vedi grafici di crescita del genere senza un effetto loop / rete virale.

Per es. confronta con un grafico della crescita di Facebook

Aggiornamento: so che la fonte di cui sopra potrebbe non essere stata accurata, ma ci sono molte fonti di dati che dimostrano che Git è cresciuto in modo esponenziale negli ultimi anni.

Grafico 1: menzioni di Git negli annunci di lavoro

E il sondaggio Eclipse che mostra che la quota di mercato di Git è passata dal 13% nel 2011 al 27% nel 2012 . Crescita incredibile.

Questo post fornisce una spiegazione molto migliore della crescita di Git e degli effetti di rete rispetto a quello che ho fatto qui.

Giusto per chiarire, questo grafico mostra l'installazione di git su sistemi debian.

Intorno al momento in cui si verifica il picco, il pacchetto Debian è stato rinominato da git-core a git. Forse le persone hanno trovato il pacchetto più semplice ora che il nome rifletteva il software.

Sono sorpreso che nessuno abbia menzionato Github come uno dei motivi principali per cui Git ha guadagnato popolarità . Hanno spinto Git mainstream.

Github è stato lanciato nell'aprile 2008 e dopo 1-2 anni ha guadagnato popolarità. E poi quando vedi un'improvvisa esplosione dell'uso di git / git-core è principalmente dovuta agli utenti di 2Milioni di github e ai loro 3,7 milioni di repository. Github ha reso git facile da usare. Bitbucket era lì, ma Github lo ha reso semplice. Sono sicuro che se i ragazzi di Github scegliessero Hg al posto di Git, avremmo dovuto vedere lo stesso aumento nell'uso di Hg.

L'analogia può essere: canonica: Linux :: Github: Git

Bene, IMHO, i VCS distribuiti come Hg e Git sono intrinsecamente migliori di un VCS centralizzato, quindi SVN avrebbe sempre perso uno di questi.

E git, come è già stato osservato, ha avuto l'enorme vantaggio rispetto a Hg di essere stato utilizzato dal più grande e riuscito progetto open source del pianeta - è un vero e proprio record, sin dall'inizio.

Per quanto riguarda il motivo per cui l'improvvisa esplosione all'inizio del 2010, la mia ipotesi è abbastanza prosaica. Git è geniale, ma non è estremamente intuitivo per un principiante.

Il miglior libro Git, IMHO, è Pro Git, che è stato pubblicato nel settembre 2009. Il secondo miglior (di nuovo IMHO), il libro Git di O'Reilly, è stato pubblicato nel giugno 2009.

Quindi la ragione per cui l'esplosione di Git è esplosa all'inizio del 2010 potrebbe essere tanto semplice quanto il fatto che era quando erano davvero disponibili buone risorse per imparare a usarla.

La scelta di un sistema di controllo della versione è una decisione sociale. Tutti i team devono utilizzare la stessa soluzione. A differenza di un editor di testo, che è una decisione personale, diversi sviluppatori possono utilizzare diversi editor e collaborare facilmente.

Quindi ci sono effetti di rete nella scelta di un sistema di controllo della versione, facendo sì che i sistemi che potrebbero essere un po 'migliori o un po' più popolari diventino ancora più popolari.

Ad esempio, preferisco i darc per i progetti open source, ma ho scoperto che molti dei miei potenziali collaboratori avevano familiarità con git e ho ricevuto più contributi più prontamente per i progetti ospitati con git anziché con i darc. Quindi, finisco per usare git molto invece darc. Quindi, poiché lo uso e pubblico il codice su Github, sembra che lo avallo o che lo preferisca, il che potrebbe influenzare gli altri a usarlo.

Gli sviluppatori non vogliono imparare un nuovo sistema di controllo del codice sorgente per ogni progetto a cui contribuiscono, quindi è vantaggioso per la comunità generale avere uno standard "abbastanza buono" e ampiamente popolare, quindi avere ogni team e progetto scegliere il "migliore "soluzione nel vuoto.

Github ha aggiunto solo carburante al fuoco dell'effetto rete.

Guardando il grafico corretto nella risposta di Michael, che mostra sia git-core che git sui sistemi Debian, la domanda sembra essere il motivo per cui git ha iniziato a diventare popolare nel 2006 sui sistemi Debian e perché è cresciuto esponenzialmente tra il 2006-2012.

La ragione potrebbe essere la forte adozione delle distribuzioni Linux basate su Debian, come Ubuntu, che ha iniziato a diventare popolare intorno al 2005-2006 e divenne la prima distribuzione fino al 2011, quando Mint, anch'essa basata su Debian, divenne la numero 1. Alla fine del 2012, Mint è ancora n. 1 e Ubuntu n. 3 secondo DistroWatch .

GitHub, fondata nel 2008, ha fornito l'hosting gratuito di git e tra il 2008 e il 2012 è diventato il servizio di repository di fonti n. 1 al mondo con circa 2,5 milioni di utenti e circa 4,5 milioni di progetti , secondo Wikipedia alla fine del 2012.

Rails e molti altri progetti sono passati da Rubyforge a GitHub alla fine degli anni 2000. Inoltre, Bundler è stato introdotto all'epoca in questione in origine (fine 2009) con supporto per l'installazione / aggiornamento di gemme tramite :gitun'opzione nel Gemfile e Bundler è stato incluso come dipendenza di Rails 3. Progetti in Python, Javascript, C, C ++ , Java, CSS, ecc. Sono anche migrati o avviati su GitHub.

Coloro che volevano contribuire ai progetti su GitHub dovevano biforcare il progetto in GitHub, utilizzare un client git locale per clonare il repository prima di apportare modifiche e reinserirle in GitHub e fare una richiesta pull. Questo è stato molto più semplice rispetto ad altri metodi utilizzati in precedenza e probabilmente è stato un motivo significativo per cui è stato adottato dai progetti che si sono trasferiti su GitHub o che hanno deciso di iniziare lì. Ciò significava che git-core / git doveva essere installato nelle distribuzioni basate su Debian in modo che gli sviluppatori potessero usare GitHub.

Quindi, credo che sia stata una combinazione di distro basate su Debian a diventare più popolare e ad adottare l'adozione di git a causa della crescita di GitHub in utenti e progetti, che probabilmente deriva dall'hosting e dall'esperienza utente di GitHub.

Penso che molte persone confondano la correlazione con la causalità.

I grafici presentati mostrano tutti le correlazioni tra misure di popolarità ed eventi gits ... e altre misure. Tuttavia, una correlazione non è una chiara evidenza di causalità.

Alcune altre risposte tentano di stabilire relazioni con altre cose; ad es. l'evangelismo di Linus Torsvalds per DVCS, la formazione di Github, l'ascesa dei social network. Mentre ci sono prove di correlazione (su una linea del tempo) non è così forte, ciò non esclude la causalità. Soprattutto se si accetta l'ipotesi "effetto rete"; cioè che ci sono più cause.

La linea di fondo, è che il tipo di evidenza disponibile non può mostrare la causalità. Stiamo parlando del comportamento collettivo di centinaia di migliaia di persone e le persone prendono decisioni per ragioni diverse ... o nessuna ragione logica. I programmatori non sono diversi da chiunque altro.