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

El paquete "gnuit" (Herramientas interactivas de GNU, un navegador / visor de archivos y un visor de procesos) se llamó "git" en Debian hasta 2009-09-09, mientras que git se llamó "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 . Puede encontrar más detalles en esta publicación del blog de Julius Plenz o this commit en Debian .

Aquí hay un gráfico que muestra el número de instalaciones de git y git-core a lo largo del 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 tu gráfica, así que aquí está mi observación:

Los sistemas de control de fuente distribuida en ese momento eran una cosa de vanguardia. Los llamados programadores alfa los usaban en el lateral, pero se salieron del radar de la mayoría de los desarrolladores de software profesionales. La forma de ver el mundo de CVS / SVN / SourceSafe / TFS fue una con la que los programadores en general estaban más o menos contentos y la mayoría de la gente asumió que los problemas que generaban el sistema de control de fuente distribuida podían solucionarse con mejores herramientas. Al igual que obtuviste una mejora al pasar de CVS - > SVN que algún día habrá algo que te permita ir a SVN - > SVN ++. ¿De qué otra manera manejarías el control de la fuente?

Luego vino git. Lo que obligó a Git a entrar en el radar de todos fue que había un enorme , proyecto público que lo adoptó de inmediato. Git consiguió muchos usuarios de forma gratuita: si ibas a hacer un grave hackage del kernel, usaste 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ó. Funciono bien Funcionó bien en público. También, por sus verrugas iniciales, era más estable que la mayoría de los DVCS concurrentes en ese momento. Darcs, por ejemplo, se podría poner en un estado inconsistente que requería una utilidad absurdamente compleja (¿cuadrada? ¿Factorial? No puedo recordar, pero era mala ) para corregirla. Git siempre ha sido más estable.

Desde su gran base de usuarios simplemente se desangró.

Todo proyecto, comercial o de código abierto, necesita esa masa crítica. Darcs no lo entendió. Tampoco Mercurial. Piénsalo bien Muchos proyectos más pequeños lo utilizan. 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 ti" es un argumento muy convincente.

Entonces, para resumir, fue un buen producto que apareció en el momento adecuado y obtuvo una base de usuarios grande y 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 debido a que sitios como GitHub tuvieron un efecto de red en las herramientas de control de versiones. Esto no se vio anteriormente, ya que compartiría el código en base a un proyecto o compañía.

Recuerdo específicamente que me cambié a Git y Github porque todos los proyectos en los que estaba interesado en seguir y en los que contribuí, hicieron lo mismo, al igual que los desarrolladores con los que me asocio.

Eso es un efecto de red.

GitHub fue 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 gracias a Linus.

Solo porque GitHub se lanzó en 2008 y el crecimiento comienza en 2010 no significa que GitHub no sea responsable. Si observa gráficos de crecimiento competitivo 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 red / bucle viral.

Por ejemplo, Compare con un gráfico de crecimiento de Facebook

Actualización:Séquelafuenteanteriorpuedenohabersidoprecisa,perohaymuchasfuentesdedatosquedemuestranqueGithaestadocreciendoexponencialmenteenlosúltimosaños.

Gráfico1:MencionesdeGitenanunciosdetrabajo

Y la encuesta de Eclipse que muestra que la cuota de mercado de Git pasó de 13% en 2011 a 27% en 2012 . Crecimiento asombroso.

Esta publicación hace una Explicación mucho mejor del crecimiento de Git y los efectos de red que lo que he hecho aquí.

Para aclarar, este gráfico muestra la instalación de git en los sistemas Debian.

Alrededor del momento en que ocurre el pico, el paquete Debian fue renombrado de git-core a git. Tal vez a las personas les pareció más fácil el paquete ahora que el nombre reflejaba el software.

Me sorprende que nadie haya mencionado a Github como una de las razones más importantes para que Git gane popularidad . Ellos empujaron git mainstream.

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

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

Bueno, IMHO, los VCS distribuidos como Hg y Git son intrínsecamente mejores que los VCS centralizados, por lo que SVN siempre iba a perder con uno de ellos.

Y, como ya se ha observado, git tenía la enorme 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 increíble, desde el principio. / p>

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

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

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

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.

Entonces 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 usando mucho git en lugar de darcs. Luego, debido a que lo uso y publico código en Github, parece que lo endoso 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 es beneficioso para la comunidad en general tener un estándar que sea "suficientemente bueno" y ampliamente popular, y que cada equipo y proyecto elija La "mejor" solución en un vacío.

Github solo agregó combustible para disparar el efecto de red.

Mirando el gráfico corregido en la respuesta de Michael, mostrando tanto git-core como git en los sistemas Debian, el La pregunta parece ser por qué git comenzó a ser popular 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 las distribuciones de Linux basadas en Debian, como Ubuntu, que comenzó a popularizarse entre 2005 y 2006 y se convirtió en la distro número 1 hasta alrededor de 2011, cuando Mint, también basada en Debian, se convirtió en # 1. A finales de 2012, Mint sigue siendo el # 1 y Ubuntu # 3 según DistroWatch .

GitHub, fundado en 2008, proporcionó alojamiento gratuito de git, y entre 2008 y 2012 se convirtió en el servicio de repositorio de origen número 1 del mundo con ~ 2.5 millones de usuarios y ~ 4.5 millones de proyectos , según Wikipedia a finales 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 ( a finales de 2009) con soporte para instalar / actualizar gemas a través de una opción :git en Gemfile, y Bundler se incluyó como una dependencia de Rails 3. Los proyectos en Python, Javascript, C, C ++, Java, CSS, etc. también se migraron a o comenzó en GitHub.

Aquellos que querían contribuir a los proyectos en GitHub tenían que bifurcar el proyecto en GitHub, usar un cliente Git local para clonar el repositorio antes de hacer modificaciones y volver a ingresar a GitHub y hacer una solicitud de extracción. Esto fue mucho más simple que otros métodos utilizados anteriormente y podría decirse que fue 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 crecientes en la adopción de git debido al crecimiento de GitHub en usuarios y proyectos, que probablemente se derive de la experiencia de usuario y alojamiento gratuito de GitHub.

Creo que muchas personas están confundiendo la correlación con la causalidad.

Los gráficos presentados muestran todas las correlaciones entre las medidas de popularidad de gits y los 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; p.ej. Linus Torsvalds evangelismo para DVCS, formación de Github, el auge de las redes sociales. Si bien hay evidencia de que la correlación (en una línea de tiempo) no es tan fuerte, eso no excluye la causalidad. Especialmente si aceptas la hipótesis del "efecto red"; es decir, que hay múltiples causas.

La conclusión es que el tipo de evidencia disponible no puede mostrar la causalidad. Estamos hablando del comportamiento colectivo de cientos de miles de personas, y las personas toman decisiones por diferentes motivos ... o sin ningún motivo lógico. Los programadores no son diferentes de los demás.