¿Por qué el aumento repentino en el número de remitentes de Git en el gráfico popcon de Debian en 2010-01?

Casi todos los artículos que he leído ¹ comparando Git y Mercurial parece que Mercurial tiene una mejor línea de comando UX con cada comando limitado a una sola idea (a diferencia de decir git checkout).

Pero en algún momento, Git de repente se volvió súper popular y el número de remitentes de Git en el gráfico popcon de Debian (ver imagen del gráfico a continuación) explotó literalmente.

Fuente: Debian

Lo que sucedió en 2010-01 que las cosas cambiaron repentinamente. Parece que GitHub se fundó antes que eso: 2008.

El paquete "gnuit" (GNU Interactive Tools, un buscador / visor de archivos y visor de procesos) se llamaba "git" en Debian hasta el 2009-09-09, mientras que git se llamaba "git-core".

Por lo tanto, un mejor gráfico para mirar es:

Lo que muestra que la popularidad no aumentó dramáticamente (tome la línea verde para la parte izquierda hasta que se crucen, luego tome la línea roja).

El paquete git en Debian se conocía anteriormente como git-core. En abril de 2010 se cambió el nombre del paquete a git. Se pueden encontrar más detalles en esta publicación de blog de Julius Plenz o esta confirmación en Debian .

Aquí hay un gráfico que muestra el número de instalaciones de ambos gity git-corecon el tiempo:

Estuve usando Darcs para mis propios proyectos por un tiempo. Cambié a git durante la rápida ascensión a la que se refiere su gráfico, así que aquí está mi observación:

Los sistemas de control de fuente distribuidos aproximadamente en ese momento eran algo innovador. Los llamados programadores alfa los usaban de forma paralela, pero quedaban fuera del radar de la mayoría de los desarrolladores de software profesionales. La forma de ver el mundo de CVS / SVN / SourceSafe / TFS fue algo con lo que los programadores en general estaban más o menos contentos y la mayoría de la gente asumió que los problemas que generaron el sistema de control de fuente distribuido podrían solucionarse con mejores herramientas. Así como obtuviste una mejora al pasar de CVS -> SVN a que algún día habría algo que te permitiría ir a SVN -> SVN ++. ¿De qué otra forma gestionarías el control de código fuente?

Luego vino git. Lo que forzó a git al radar de todos fue que hubo un gran proyecto público que lo adoptó de inmediato. Git consiguió muchos usuarios de forma gratuita: si ibas a hacer un hackeo serio del kernel, usabas git. Si bien no puedo estar 100% seguro, apostaría a que en ese momento ningún otro DVCS tenía una base de usuarios tan grande.

Entonces funcionó. Funcionó bien Funcionó bien en público. También, para sus verrugas iniciales, era más estable que la mayoría de los DVCS concurrentes en ese momento. Darcs, por ejemplo, podría ponerse en un estado inconsistente que requiriera una utilidad absurdamente compleja (¿cuadrática? ¿Factorial? No puedo recordarlo con seguridad, pero fue malo ) para solucionarlo. Git siempre ha sido más estable.

Desde su gran base de usuarios, simplemente se desangra.

Todo proyecto, comercial o de código abierto, necesita esa masa crítica. Darcs no lo entendió. Tampoco Mercurial. Piensa de nuevo. Muchos proyectos más pequeños lo usan. Probablemente hay incluso una serie de usuarios comerciales. Pero, ¿cuál es tu gran historia de éxito?

"Si es lo suficientemente bueno para el kernel de Linux, es lo suficientemente bueno para usted" es un argumento muy convincente.

Entonces, para resumir, fue un buen producto que apareció en el momento adecuado y obtuvo una gran base de usuarios dedicada.

Fui un adoptante tardío, cambiando de Mercurial a Git alrededor de 2010.

La razón por la que creo que Git se hizo tan popular es porque sitios como GitHub tuvieron un efecto de red en las herramientas de control de versiones. Esto no se había visto anteriormente, ya que compartiría el código según el proyecto o la empresa.

Recuerdo específicamente cambiar a Git y Github porque todos los proyectos que me interesaban seguir y en los que contribuí habían hecho lo mismo, así como a los desarrolladores con los que me asocio.

Ese es un efecto de red.

GitHub era la capa de colaboración basada en web más popular construida en DVCS y Git terminó siendo "lo suficientemente bueno". Mercurial fue ciertamente más fácil de aprender y usar, Git tiene muchos matices, pero tenía una marca sólida debido a Linus.

Solo porque GitHub se lanzó en el '08 y el crecimiento comienza en el '10 no significa que GitHub no sea responsable. Si observa las tablas de crecimiento competitivas en otras áreas, como las redes sociales y el crecimiento de Facebook, la línea es muy similar.

No ves gráficos de crecimiento como ese sin un efecto de bucle viral / red.

Por ej. comparar con un gráfico de crecimiento de Facebook

Actualización: Sé que la fuente anterior puede no haber sido precisa, pero hay muchas fuentes de datos que demuestran que Git ha estado creciendo de manera exponencial en los últimos años.

Gráfico 1: Menciones de Git en anuncios de trabajo

Y la encuesta de Eclipse que muestra que la cuota de mercado de Git pasó del 13% en 2011 al 27% en 2012 . Increíble crecimiento.

Esta publicación explica mucho mejor el crecimiento de Git y los efectos de red que lo que he hecho aquí.

Solo para dejar en claro, este gráfico muestra la instalación de git en sistemas debian.

Alrededor del momento en que ocurre el pico, el paquete Debian cambió su nombre de git-core a git. Tal vez la gente encontró el paquete más fácil ahora que el nombre reflejaba el software.

Me sorprende que nadie haya mencionado a Github como una de las principales razones para que Git gane popularidad . Empujaron git mainstream.

Github se lanzó en abril de 2008 y en 1-2 años, ganaron popularidad. Y luego, cuando ves una explosión repentina del uso de git / git-core se debe principalmente a los 2 millones de usuarios de github y sus 3.7 millones de repositorios. Github hizo que git sea fácil de usar. Bitbucket estaba allí, pero Github lo hizo sin esfuerzo. Estoy seguro de que si los chicos de Github eligieron Hg en lugar de git, deberíamos haber visto el mismo aumento en el uso de Hg.

La analogía puede ser: Canonical: Linux :: Github: Git

Bueno, en mi humilde opinión, los VCS distribuidos como Hg y Git son inherentemente mejores que un VCS centralizado, por lo que SVN siempre iba a perder con uno de ellos.

Y git, como ya se ha observado, tenía la gran ventaja sobre Hg de que fue utilizado por el proyecto de código abierto más grande y exitoso del planeta, eso es un historial excelente, desde el principio.

En cuanto a por qué la explosión repentina a principios de 2010, mi suposición es bastante prosaica. Git es brillante, pero no es enormemente intuitivo para un principiante.

El mejor libro de Git, en mi humilde opinión, es Pro Git, que se publicó en septiembre de 2009. El segundo mejor (en mi humilde opinión), el libro de O'Reilly's Git, se publicó en junio de 2009.

Por lo tanto, la razón por la cual el uso de Git explotó a principios de 2010 podría ser tan simple como el hecho de que fue cuando los recursos realmente buenos para aprender cómo usarlo estuvieron disponibles.

Elegir un sistema de control de versiones es una decisión social. Todo el equipo necesita usar la misma solución. A diferencia de un editor de texto, que es una decisión personal: diferentes desarrolladores pueden usar diferentes editores y colaborar fácilmente.

Por lo tanto, hay efectos de red al elegir un sistema de control de versiones, lo que hace que los sistemas que pueden ser un poco mejores o un poco más populares se vuelvan aún más populares.

Por ejemplo, prefiero darcs para proyectos de código abierto, pero descubrí que más de mis contribuyentes potenciales estaban familiarizados con git, y recibí más contribuciones más fácilmente para proyectos alojados con git en lugar de darcs. Entonces, termino de usar git mucho en lugar de darcs. Luego, como lo uso y publico código en Github, parece que lo apruebo o incluso lo prefiero, lo que podría influir en que otros lo usen.

Los desarrolladores no quieren aprender un nuevo sistema de control de fuente para cada proyecto al que contribuyen, por lo que beneficia a la comunidad en general tener un estándar que sea "suficientemente bueno" y ampliamente popular, y que cada equipo y proyecto elija el "mejor "solución en el vacío.

Github solo agregó combustible al fuego del efecto de red.

Mirando el gráfico corregido en la respuesta de Michael, que muestra tanto git-core como git en los sistemas Debian, la pregunta parece ser por qué git comenzó a popularizarse en 2006 en los sistemas Debian y por qué creció exponencialmente entre 2006-2012.

La razón podría ser la fuerte adopción de distribuciones de Linux basadas en Debian, como Ubuntu, que comenzó a popularizarse alrededor de 2005-2006 y se convirtió en la distribución # 1 hasta alrededor de 2011, cuando Mint, también basada en Debian, se convirtió en # 1. A finales de 2012, Mint sigue siendo # 1 y Ubuntu # 3 según DistroWatch .

GitHub, fundada en 2008, proporcionó alojamiento gratuito de git, y entre 2008 y 2012 se convirtió en el servicio de repositorio de fuentes n. ° 1 en el mundo con ~ 2.5 millones de usuarios y ~ 4.5 millones de proyectos , según Wikipedia a fines de 2012.

Rails y muchos otros proyectos cambiaron de Rubyforge a GitHub a fines de la década de 2000. Además, Bundler se introdujo alrededor del tiempo originalmente en cuestión (finales de 2009) con soporte para instalar / actualizar gemas a través de una :gitopción en Gemfile, y Bundler se incluyó como una dependencia de Rails 3. Proyectos en Python, Javascript, C, C ++ , Java, CSS, etc. también migraron o comenzaron en GitHub.

Aquellos que quisieran contribuir a los proyectos en GitHub necesitaban bifurcar el proyecto en GitHub, usar un cliente git local para clonar el repositorio antes de hacer modificaciones y empujarlos nuevamente a GitHub y hacer una solicitud de extracción. Esto era mucho más simple que otros métodos utilizados anteriormente y podría decirse que era una razón importante por la que fue adoptado por los proyectos que se trasladaron a GitHub o decidieron comenzar allí. Esto significaba que git-core / git necesitaba ser instalado en las distribuciones basadas en Debian para que los desarrolladores pudieran usar GitHub.

Por lo tanto, creo que fue una combinación de distribuciones basadas en Debian que se hicieron más populares y crecieron en la adopción de git debido al crecimiento de GitHub en usuarios y proyectos, lo que probablemente se deba a la experiencia de usuario y alojamiento gratuito de GitHub.

Creo que mucha gente confunde la correlación con la causalidad.

Los gráficos presentados muestran todas las correlaciones entre las medidas de popularidad de gits y eventos ... y otras medidas. Sin embargo, una correlación no es una evidencia clara de causalidad.

Algunas otras respuestas intentan establecer relaciones con otras cosas; por ejemplo, el evangelismo de Linus Torsvalds para DVCS, la formación de Github, el surgimiento de las redes sociales. Si bien existe evidencia de que la correlación (en una línea de tiempo) no es tan fuerte, eso no excluye la causalidad. Especialmente si acepta la hipótesis del "efecto de red"; es decir, que hay múltiples causas.

La conclusión es que el tipo de evidencia disponible no puede mostrar causalidad. Estamos hablando del comportamiento colectivo de cientos de miles de personas, y las personas toman decisiones por diferentes razones ... o ninguna razón lógica en absoluto. Los programadores no son diferentes a los demás.