Lo que nadie cuenta sobre los $100M de inversión en GitHub

GitHub ha recibido una inversión de 100 millones de dólares para desarrollar GitHub Enterprise, su versión corporativa ¿Qué hay más allá del comunicado oficial?

Github Money OctocatHace un par de días, se anunció la inversión de 100 millones de dólares en GitHub, el servicio más popular para alojar repositorios de código en la nube.

Un par de días en los que he estado esperando a que alguien rasque la superficie -más allá de la simple inversión- y, como casi siempre, la prensa especializada no se ha querido enterar del negocio de miles de millones de dólares por el que se está gestando una guerra despiadada.

Como Embajador de Atlassian, la empresa que cuenta con BitBucket, el único competidor que ha conseguido robarle una significativa cuota de mercado a GitHub, estoy viviendo esta competición desde las trincheras, donde se tiene una visión muy diferente de todo lo que está pasando.

DVCS, donde está la pasta

El mercado del control de versiones distribuido -o DVCS,  en inglés- moverá decenas de miles de millones de dólares en los próximos años.

Aunque a muchos desarrolladores les pueda sorprender, el porcentaje de empresas tecnológicas de tamaño medio y grande -donde está la PASTA con mayúsculas- que están utilizando DVCS es ridículo.

Hasta ahora, los usuarios tipo de estos sistemas de control de versiones han sido early adopters: pequeñas empresas y startups, proyectos Open Source y desarrolladores individuales. El chocolate del loro en términos de gasto en licencias y servicios de software.

Pero DVCS está a punto de cruzar el abismo del ciclo de adopción tecnológico y, en los próximos años, veremos como los grandes dinosaurios del sector empiezan a migrar sus antiguos controles de versiones. Un movimiento que generará mucho dinero y del que todos quieren sacar tajada.

GitHub, una máquina de generar Hamor

GitHub lo ha hecho bien, MUY bien. No sólo fueron los primeros en llegar al mercado y apostaron por Git, el DVCS con mayor adopción del mercado, sino que contaron desde el principio con una tecnología, diseño y usabilidad exquisitas.

Pero el gran acierto de GitHub ha sido su marketing. Un marketing que apostó por el desarrollador hardcore, eones antes de que las grandes corporaciones se dieran cuenta de lo que estaba pasando, que el centro de poder de la industria del software se estaba desplazando a los técnicos, un recurso cada vez más escaso.

GitHub construyó, alrededor de Git, un montón de funcionalidades sociales para unir y cohesionar a esa Comunidad de early adopters que, pronto, empezaron a considerarlo the-place-to-be. Si no estabas en GitHub, no estabas.

Esto no es ni bueno ni malo, es marketing de libro: construye un ecosistema para desarrolladores y generarás su hamor. Atrae a los early adopters y, si consigues masa crítica, el resto les seguirá.

La guerra detrás del Firewall

Pero GitHub, además de una máquina de generar Hamor, es una empresa y -como cualquier empresa- quiere ganar dinero. Y el dinero de verdad no está en las startups ni en los desarrolladores. Los números son evidentes:

Hoy mismo, en su web, GitHub anuncia que cuenta con 1.852.884 desarrolladores. Si suponemos que un 5% de esos desarrolladores son clientes de pago -lo cual es MUCHO suponer-, contaríamos con 92.664 clientes que, a 12$ al mes -el plan medio de GitHub-, supondrían unos ingresos de menos de 14 millones de dólares al año. Nada espectacular para una empresa de Silicon Valley con más de 100 empleados y la relevancia de GitHub.

Así que GitHub apunta a donde está la pasta, el mercado corporativo, y crea GitHub Enterprise, una versión especial para las empresas que no quieren que su código esté pululando por la nube, que les permite instalar su propio GitHub en sus servidores, detrás del firewall.

Y, al entrar en el territorio detrás del firewall, invade el ecosistema tradicional de Atlassian que, al verse amenazada, lanza Stash, un competidor directo de GitHub Enterprise, iniciando una guerra termonuclear. Y las guerras cuestan dinero, aproximadamente unos 100 millones de dólares.

Déjate de Hamor y enséñame la Pasta

Es curioso ver como los desarrolladores viven esta guerra, como si lo fuera de verdad, con hordas de partidarios defendiendo con pasión GitHub y, unos pocos, aguantando la avalancha desde las trincheras de BitBucket. Pero, al fin y al cabo, esto no es más que un negocio y, los señores de la guerra, acaban el día tomando cervezas en el mismo bar.

Porque, en el terreno corporativo, GitHub no busca hamor sino pasta. En concreto, a partir de [highlight]21$ al mes por desarrollador[/highlight]. Y digo “a partir de” porque, al venderse en paquetes de más de 2o usuarios, si tienes la desgracia de tener 21 desarrolladores en tu compañía, GitHub Enterprise te costará casi 39,7 dólares al mes -32,35€- por desarrollador. No sé si eso es hamor, pero desde luego es mucha pasta.

GitHub Enterprise

Ojo, Stash también se vende por tramos de licencias, pero a diferencia de GitHub Enterprise, lo estás comprando, no alquilando. Por 1.800$ tendrías una licencia para 25 desarrolladores que podrías utilizar toda la vida y un año de mantenimiento.

Atlassian StashSin entrar en cuál es la mejor o peor opción -al fin y al cabo, como Embajador de Atlassian mi objetividad siempre puede ser puesta en entredicho-, lo inaudito del caso es que, pocas veces he visto que el precio de alquiler de un producto sea casi 10 veces mayor que el coste en propiedad de su inmediato competidor. ¿Hay alguien que todavía no ve una guerra termonuclear?

Por supuesto, al comparar dos productos, hay que ir mucho mas allá del precio… y las comparaciones son odiosas. Al probar a fondo GitHub Enterprise, encontramos problemas, desde una instalación que te exige saber mecánica cuántica a problemas a la hora de realizar un fork… al igual que se podrán encontrar fallos en Stash, por supuesto.

¿Cómo puede luchar Atlassian?

Atlassian ha cometido algunos errores que le han dado ventaja a GitHub. El principal, llegar tarde y mal porque, al principio, BitBucket sólo admitía Mercurial como sistema de DVCS.

Pero, incluso en marketing, algo en lo que hemos destacado normalmente, nos han quitado las pegatinas. Empezando por el logotipo. ¿Cómo podemos competir contra una mascotita tan mona como el Octocat? ¿A qué mente enferma se le ocurrió utilizar UN CUBO?

Pero los problemas no acaban ahí, mientras GitHub ha utilizado un branding sencillo y racional, Atlassian tiene un nombre distinto para cada cosa: GitHub vs. BitBucket, GitHub for Mac vs. SourceTree, GitHub Enterprise vs. ¿Stash? O_o

También se debe mejorar en el diseño y la UX. Es cierto. En diciembre llegará el cambio integral del layout de las aplicaciones de Atlassian, que llevan utilizando la misma base de diseño desde el 2007.

Pero no nos engañemos, para ganar batallas, sobre todo, hacen falta soldados y Atlassian necesita muchos más. Porque, al contrario de lo que la gente cree y de lo que su departamento de marketing tan bien vende, GitHub no es el pez pequeño: supera en número al equipo de BitBucket en una proporción de 4 a 1. De momento, bastante hacemos resistiendo como una auténtica guerrilla organizada.

¿Y el resto qué? ¿Qué podemos esperar del futuro?

El resto hace lo que puede. Desde herramientas Open Source como Gitolite, hasta soluciones propietarias como el PRODUCTÓN español Plastic SCM.

De los que no se sabe nada es de los gigantes del sector, Microsoft -que ha ido mucho más allá de su monolítico Team Foundation Server, muy orientado al desarrollo para Windows- o IBM del que no se conoce nada en absoluto. Cuando empiecen a moverse, el mercado temblará. Al contrario que otros, ellos pueden permitirse llegar tarde sacando el talonario y comprando empresas, objetivo final de inversiones como… la de Andreessen Horowitz en GitHub o la de ACCEL Partners en Atlassian. El juego ha comenzado.

Bola Extra

  • Xavi Gost

    “Al probar a fondo GitHub Enterprise, encontramos problemas, desde una instalación que te exige saber mecánica cuántica a problemas a la hora de realizar un fork… al igual que se podrán encontrar fallos en Stash, por supuesto”

    Unos links a articulos acerca de esos problemas y para hacer gala de la elegancia que te caracteriza otros a los encontrados en Stash me vienen faltando para hacer tolerable estas lineas en concreto.

    Por lo demas buen analisis, aunque ligeramente tendencioso comparar el numero de empleados del equipo de Bitbucket (un equipo dentro de una empresa) con el de la empresa GitHub.

    • De Stash, como de todos los productos de Atlassian, tienes un JIRA público donde puedes ver las incidencias reportadas, votar las que te parezcan mas prioritarias de resolver y hasta el roadmap:

      https://jira.atlassian.com/browse/STASH

      También puedes ver las incidencias resueltas en el pasado, en el change log de cada versión. Ej.

      https://confluence.atlassian.com/display/STASH/Stash+1.2+change+log

      Respecto a los errores encontrados, saqué 2 o 3 -por poner un ejemplo de que todo software tiene errores- de una página interna de Atlassian donde el equipo que evaluó comentaba lo que le había gustado y lo que no. No son artículos, sino una lista de errores, de los podría ponerte capturas de pantalla.

      No se si eso hace tolerable o no el artículo, pero me sorprende que te haya llamado la atención cuando le he dado mucha mas caña al marketing de Stash. Como curiosidad, Candela, al leer el artículo me ha dicho “no dejas bien a Bitbucket” ^_^

      Te pido disculpas si parezco ligeramente tendencioso, pero me parece un triunfo que solo parezca ligeramente trabajando para Atlassian. Respecto a la organización del equipo de Bitbucket, ya te digo que son autónomos y que tienen sus propios Product Managers.

      A mi, comparar Stash y GitHub me parece UNA IDIOTEZ que tenderá al flamewar. El fondo de este artículo era explicar el porqué de esa inversión y el dinero que hay en juego.

      • No sé si dejas bien parado a Bitbucket o no, lo cierto es que al menos a mi (supongo que a algún otro también) me hiciste conocer su existencia, lo cual es un punto a favor. Y ya que estoy aprovecho: ¿existe alguna herramienta que me permita vincular un repositorio con un sistema de gestión de issues y tests? Es decir, un sistema que cree issues cuando un test falla o lo elimine cuando el test pasa correctamente.

        • Si, Bamboo (servidor de Integración continua de Atlassian) tiene conectores y plugins para trabajar con JIRA.

          Ojo, no digo que Jenkins no lo haga. Digo que no lo conozco ^_^

        • En GitHub puedes hacerlo a través de los hooks, por ejemplo con Jenkins, hay muchos proyectos en Software Libre que lo utilizan.

          En Bitbucket también a través de los services.

          Busca en la documentación de ambos, te darán pistas de como hacerlo.

  • Vicente Cartas

    Y Kiln de la gente de Fog Creek? Como pinta en esta guerra de DCVS? Yo lo he usado en el pasado y sinceramente un 10/10, no nos dio nunca ni un problema.

    • Bueno… el tema con Kiln es que, se centra exclusivamente en Mercurial -lo cual no es malo- y que, por lo menos la última vez que le eché un vistazo no se podría descargar, sólo ofrecía servicio alojado, al contrario que GitHub Enterprise o Stash

  • No termino de ver muy claro si GitHub Enterprise es interesante… Es decir, es cierto que las grandes empresas van a empezar a utilizar más DVCS, y en particular, git (deberían, por lo menos). Sin embargo, montar un repositorio de git en una red local es algo que se puede hacer en poco tiempo (minutos si tienes todo listo), y configurar los clientes es igual de fácil o difícil que hacerlo sobre GitHub.

    ¿Las funcionalidades extra que aporta GitHub respecto a una instalación de git “pelada”? Utilísimas para el software libre, pero no para una gran empresa. ¿Hacer forks del código? ¿Una red social? Quizá lo único que se me ocurre que puede tener cierto interés es, si quieres que todo se revise, utilizar el sistema de ‘pull request’, y aun así, posiblemente tenga más sentido utilizar un flujo adecuado en git (que lo acepta)…
    Vale, compro el tenerlo en la nube (especialmente en equipos distribuidos), pero eso es GitHub, no GitHub Enterprise, y las empresas de tamaño medio o mayor que tengan esos problemas posiblemente tengan ya la infraestructura adecuada para ello.

    Claro, otro tema es márketing y git=GitHub, y poder “vender la moto” a empresas de tamaño adecuado para que paguen un sobreprecio importante por algo que pueden tener, ya digo, por mucho menos haciendo una instalación propia.

    Otro tema, totalmente differente, es vender formación, que ahí sí que puede estar el quid de la cuestión. git es difícil. Lo sé porque me considero un usuario avanzado y, al principio sobre todo, cuesta muchísimo adaptarse a su forma de hacer las cosas y cambiarlas de otros sistemas. Me costó mucho saber como usarlo adecuadamente y sigo resolviendo dudas de gente (soy considerado el “experto en la sala en git”, y bien orgulloso que estoy) que lleva el mismo tiempo que yo utilizándolo día a día… Vender un producto de este estilo puede llevar asociado ser “el experto”, y eso también puede venderse.

    • Ah, otro detalle. GitHub para una empresa pequeña es fantástico, porque te olvidas de casi todos los problemas de instalación y demás y puedes dedicarte a lo importante, tu código, desde el segundo 0.
      Pero una gran empresa es distinto.

    • No conozco GitHub Enterprise como conozco Stash, por ejemplo, pero en el caso de este último te puedo dar algunas razones de compra:

      – Integración con los sistemas de autenticación de la empresa, de una forma sencilla y rápida (si tienes todos tus usuarios en un LDAP, que no tengas que volver a picarlos)
      – Gestión de permisos y accesos más sencilla.
      – Integración con otras herramientas (en el caso de Stash, JIRA, Bamboo, etc..)

      Luego es cuestión de echar números y ver si, como empresa, te renta o no.

      • Sí, entiendo que el tema de la autenticación puede ser interesante, y, por supuesto, entiendo que puede simplificar la integración con otros sistemas que ya existan… Pero todo eso va siendo menos interesante cuanto más caro sea, y especialmente si es por desarrollador. Un precio cerrado puede ser interesante, pero un precio por usuario (en el caso de GitHub) puede salirse de madre muy fácilmente y hacer que una integración y mantenimiento propios (con sus líos) sea algo que asuste mucho menos.

        Ya digo, no es que lo vea impensable, pero me resulta algo menos atractivo según tu tamaño es mayor.

        • Antonio Muñiz

          Hay soluciones completas que SÍ tienen un precio fijo (sin límite de usuarios ni proyectos) – http://clinkerhq.com

          Disclaimer: sí, trabajo en Clinker, es mi criatura 🙂

          • Me estaba refiriendo únicamente a GitHub 😉

        • jcborras

          Comparto tu comentario inicial, Jaime, pero como comenta Bonilla si tu proceso/workflow usa productos Atlassian (Jira y Confluence me vienen a bote pronto) la solución australiana va de mano si consigue que un commit de un bugfix acabe cerrrando el ticket en el Jira y notifique a los que lo tienen bajo vigilancia. Así se lidia con menos burocracia. Lo de la autenticación lo veo como un problema menor (hay otras maneras de solucionarla).

          Que las tarifas de GitHub no sean especialmente tentadoras no debería ser problema tampoco para quien negocia la compra de grandes volúmenes.

          Lo que ahora mismo no veo es la ventaja de un GitHub corporativo, y éso es volver a tu comentario inicial. Claro que ahora tienen 100 millones para hacerme cambiar de idea… 100 millones que dudo hubieran podido levantar si no se hubieran convertido en un escaparate, útil fuera de toda duda.

  • La verdad es que cuando vi el precio de Github Enterprise pensé que se habían equivocado.

  • En mi opinión lo mejor que ha hecho Github desde que eran 3 personas fue enseñar a la mayoría de nosotros a usar git.
    http://git-scm.com/book

    http://schacon.github.com/2008/05/20/gitcasts-git-screencasts.html

    http://learn.github.com/p/intro.html

    y 50 más….
    Entiendo que ese fue su principal marketing.

    • Coincido al 100% contigo Pablo. Como comentaba, apostaron fuerte por GIT e hicieron una labor de evangelización ACOJONANTE. Es decir, en vez de enfocarse al decission maker se preocuparon de que los desarrolladores entendieran las ventajas de Git y como usarlo.

      Ahora, muchos los copian. Ya sabes lo de muy de moda que está el puesto de Evangelista Técnico 😉

  • Juan Quijano

    GenbetaDev, allí tienes información para rato de Team Foundation Service, un TFS en la nube que no es solamente un repositorio de código, es toda una plataforma ALM.
    Yá se está moviendo Microsoft, y está en otro nivel.

    • acido69

      Yo soy usuario de git y desde hace un mes estoy usando TFS; sólo te puedo decir una cosa: Es una jodida tortura china con regresión al pasado.

      Imagino que los que están acostumbrados a usar VisualStudio les viene bien porque así tienen todo controlado; pero como sistema de versiones es lo mismo que usar SVN (obsoleto) con todo el dolor de huev** que eso supone.

      ¿está a otro nivel porque puedes hacer un seguimiento? si usas github, bitbucket, … tienes todo eso.

      Pero lo que es el propio sistema de versiones; el de TFS es una absoluta basura (en mi humilde opinión). Como muestra de ello es que podrás leer comentarios aconsejando (para los que les obligan en el trabajo) a meter git dentro del TFS para poder tener todo el poder de las ramas, hacer merges sin miedo y así el TFS solo vale para avanzar en una sola rama

      • Toni

        TFS hace ABSOLUTAMENTE TODO lo que hace Git. Me atrevo a decir, que si desarrollas en .Net o con Visual Studio en general usar algo que no se sea TFS debería ser pecado… Concentras todo en una unica herramienta de trabajo: Integración Continua, Repositorio de Código, Seguimiento y Tíquets asociados a check-ins, haces SCRUM…

        En otras plataformas entiendo que haya soluciones mas baratas o menos “aparatosas”, mas agiles que TFS, y digamos, mas molonas. Pero para .Net creo que es una tonteria comerse la cabeza con alternativas a TFS.

  • Guest

    Hombre, esta bien que menciones a otros proyectos, pero no debemos olvidarnos de Sourceforge (que aún es más grande que GitHub), de Google Code o de Launchpad.
    Por otro lado tenemos Gitorious (Git) o Klin (Hg)

    Y como plataforma hospedable dentro de la empresa y proyecto open source tenemos a Rhodecode, http://rhodecode.org

    Y otros que me dejo (orientados a java, por ejemplo). Vamos, que ni de lejos es una batalla entre dos 🙂

    Saludos

    • Este comentario está repetido ¿no? Y además, te he contestado en el anterior. Insisto, no pretendía ser exhaustivo.

      • Si, he querido borrarlo, no me deja 🙂 Además lo repetí porque no veía el mio ni tu respuesta. Parece que Disqus está fallando bastante últimamente.

  • Un par de experiencias del mundo real:

    Una empresa lider en gambling acaba de tomar la decision de migrar sus repositorios a git. Obviamente por temas legales sera un sistema in-house. He hablado con la gente de infraestructura hace nada y lo ven como un proceso tecnologicamente complejo que tomara bastantes meses.

    Nosotros, y la mayoria de empresas medianas/grandes que veo alrededor tienen un sistema de integracion/deploy continuo testado y probado. Cambiar a un paradigma diferente que permita sacar ventajas de los DVCS no es facil. Bajo esa situacion, en muchos casos el esfuerzo de migracion (no solo tecnologico) no compensa las posibles ventajas. Que ademas no son tantas, porque al final la gente tiene que seguir tirando codigo al trunk varias veces al dia.

    En nuestra empresa usabamos originalmente github enterprise (~30 usuarios). Todavia tenemos algun repo alli, pero nos hemos ido por precio.

    • Un reality check siempre es importante y bienvenido para contextualizar las cosas ^_^

      ¿Ahora que estáis utilizando?

      • Creo que mi comentario se ha perdido, es la segunda vez que me pasa con disqus :/

        Decia que habiamos pasado a Cloudbees, donde teniamos ya el servicio de integracion continua. La factura de los dos servicios Jenkins+Git es solo un poco mas alta que github.

        Dejar github, mas que por la cantidad (a amazon le soltamos 10 veces mas por cosas varias, sin contar hosting ec2 y s3), es por la cara que se te queda soltando una pasta por algo que puedes solucionar poniendo una maquina mas en la oficina.

  • psantosl

    Qué interesante David!

    Disclaimer: soy uno de los fundadores de plasticscm.com.

    Nuestro discurso ha sido: desde 2008 todos los proyectos open source relevantes del mundo se han movido a DVCS, la “enterprise” será la siguiente. Hay una oportunidad enorme y nuestro objetivo con Plastic es ser “the enterprise DVCS”.

    No es fácil porque:

    * Está claro que los chicos de GitHub son buenísimos. Buenísimos. El libro de Scott Chacon sobre “git internals” (peepcode’s) es el mejor que he leído.
    * Desarrollar un DVCS completo (y no trincar uno open source y sacarle pasta) cuesta muchísimo esfuerzo. En Marzo, de los 70 de GitHub (por aquél entonces), tenían a … *1* contribuyendo con el core de Git. Pero, el negocio es el negocio, aunque se vista de otra cosa.

    Es curioso que las soluciones empresariales se muevan a otro ritmo:
    * El más grande del mercado (en pasta) sigue siendo ClearCase: 40%. (Para que os hagáis una idea, a nivel de pasta, incluso cuando SVN era el más grande, representaba un 0,8% de la facturación. No contaba)
    * Ni TFS, ni CC ni ninguno de los comerciales es distribuido ni por asomo
    * La mayoría son un coñazo de usar

    * Me llama poderosamente la atención que los analistas (los que influyen en las decisiones de las grandes corporaciones) no prestan mucha atención a DVCS (lo consideran como “impacto moderado” en el desarrollo en los últimos informes que he leído) ni a Git. Para mi, viven en un mundo casposo y anticuado ajeno a la realidad dinámica (NVidia, Cisco, Facebook… ¡¡usan Git!!)

    Nosotros intentamos abrirnos hueco con Plastic: somos un equipo pequeño, con clientes muy gordos (hace 2 meses cerrábamos un contrato con el segundo fabricante de móviles coreano, que lleva usando Plastic desde Noviembre realmente, 1100 usuarios concurrentes, no está mal) y también muy pequeños. Ofrecemos muchas de las cosas que les faltan a los DVCS (http://codicesoftware.blogspot.com/2012/02/dvcs-myths-facts.html).

    Será una dura batalla. 🙂

    • Interesantísimo comentario… Sin duda, hay una diferencia enorme en empresas grandes y establecidas y empresas “emergentes” en estos asuntos. Aunque no sea por otra cosa, el “llevamos haciendo esto así desde hace 15 años o más” pesa muchísimo…

  • Anónimo

    Gracias por publicar este artículo tan completo.

    Un duda: al principio del artículo comentas: “BitBucket, el único competidor que ha conseguido robarle una significativa cuota de mercado a GitHub”

    ¿Existe alguna fuente donde podamos verificar ese dato? Gracias.

    • No entiendo porque dejáis comentarios anónimos. Para empezar, Disqus no podrá enviaros mails automáticos con las respuestas 🙁

      No tengo datos exactos de la cuota de mercado exacta de GitHub y BitBucket así que me puedes MASACRAR por inexacto o, si lo prefieres, oportunista.

      Esa frase está basando en mi opinión personal después de llevar un año viajando y conociendo desarrolladores por todo el mundo, desde San Francisco a Oslo. Prácticamente todo el mundo usaba GitHub y, a mucha distancia, BitBucket. No vi mucha más competencia en hosting de repositorios.

      • ¿Puede ser que esos desarrolladores que conocías fuesen un tipo particular de desarrolladores? Todos sabemos que hay una gran masa sumergida de gente que trabaja de manera muy diferente a todos estas herramientas “molonas”.

        No es crítica ni mucho menos, es sólo constatar este hecho. Hay herramientas que parece que todo el mundo usa porque lo usa la gente que publicita lo que usa (no sé si me explico)

    • Tines una comparativa con datos en esta página de la Wikipedia, eso si no sé hasta que punto es fiable:

      http://en.wikipedia.org/wiki/Comparison_of_free_software_hosting_facilities

      • No se que decirte… :/ Según ese artículo, BitBucket tiene 170.000 usuarios y en un comentario de Justen Stepka, el Product Manager, del 2011 -cuando empezaron a soportar Git, ya anunciaban que tenían 20.000 usuarios.

        http://blog.bitbucket.org/2011/10/03/bitbucket-now-rocks-git/

        Supongo que ahora han tenido que pegar un buen empujón por el tema Git y los repositorios privados gratuitos.

        • No te digo que no, y espero que así sea. Pero hay algo muy significativo y en línea con el comentario que acabo de hacer y que ha salido en alguna conversación. GitHub apuesta directamente por el marketing de números, mostrando orgullosa sus cifras en la página de entrada. Bitbucket omite estas cifras, algunos piensan que deliberadamente y muchos son amigos de unirse siempre al rebaño más grande, sin más.

          • Normalmente, todos menos el líder ocultan sus cifras de usuarios. No es una justificación, es la manera de darte la razón.

  • De todo lo que comentas en el articulo, creo que lo más importante es el tema del marketing. Me explico, desde que Atlassian adquirió BitBucket se ha evolucionado bastante en el trabajo inicial de Jesper (sobre todo en el tema de errores solucionados), y os agradezco mucho el trabajo. Al principio tenía la sensación de que se estaba quedando detrás de GitHub, ahora ya no es tanto así.

    Pero lo que si veo es que la masa de proyectos y usuarios no ha aumentado de forma significativa, o así lo percibo. Y que por ejemplo seguís básicamente con la misma página de presentación y con los mismos proyectos estrella. Y cuando hablo con gente, todos siguen asociando Bitbucket con Mercurial (que me encanta y lo prefiero) y muchos de ellos ni siquiera saben que se puede emplear Git.

    En serio, copie mis humildes proyectos a GitHub porque tenía la sensación de que me estaba perdiendo algo. Y creo que lo comentaba antes y esa sensación que comparten también otros, es lo primero que teníais que empezar a cambiar. Sigo prefiriendo muchas cosas de Bitbucket, pero la verdad es que recibo más feedback (relativamente) en GitHub, quizás por la mayor masa de usuarios.

    Recibe esto como una critica positiva, siempre he defendido a Bitbucket, pero cada vez me cuesta más.

    • ¡Es una crítica superconstructiva! También tengo que coincidir contigo en esta ocasión. No sólo creo que Bitbucket tenga el problema de ser asociado con Mercurial sino… hasta con Python!

      Efectivamente, habría que hacer un trabajo para empezar a atraer más desarrolladores y proyectos estrella.

      Espera cambios PROFUNDOS en la interfaz en Diciembre y, poco a poco, más funcionalidades y añadidos como las Bitbucket Cards: http://www.bitbucketcards.com

      • Si, Bitbucket nació en la comunidad Python y esta muy ligado a ella, que este montado sobre Django y Hg ayudo mucho a su aceptación en la comunidad. Pero también es cierto que proyectos como el mismo Django se hayan pasado a Git y GitHub le han hecho mucho daño.

  • Manuel Jesús Recena Soto

    Como parece que es lo correcto:

    Disclaimer: yo parte muy implicada en http://clinkerhq.com

    A mi la verdad es que las cifras que se manejan me confunden. Como a uno que yo me sé la noche. Especialmente las que llevan el símbolo del $.

    Sin entrar a valorar funcionalidad arriba o abajo, sólo puedo decir que Clinker ofrece por un coste fijo, con independencia de usuarios, proyectos, repositorios y otros tantos parámetros, SVN/Git, Jenkins, Sonar, Nexus, Trac y Redmine, y un SSO con autenticación, autorización y programación de la sesión entre aplicaciones.

    Lo curioso es que todo esto está disponible desde 0€ hasta 199€ (plan más elevado). Y digo 0€ porque la Virtual Appliance está para su descarga sin coste alguno.

    Cuál ha sido vuestra inversión? Pues básicamente lo que hemos ido ganando de otros proyectos y productos que tenemos en marcha. Y que no falten.

    Está claro que muchas cosas no estaremos haciendo bien cuando la gente sigue dispuesta a mantener sus propias infraestructuras y ecosistemas sin pensar en el elevado coste que eso supone a finales de año.

    Un saludo

    • La verdad es que el servicio que ofreceis es muy competitivo en precio.

      Personalmente, te puedo decir que prefiero contratar individualmente, buscando el mejor servicio en cada campo. El mejor ejemplo es Jenkins. Los sistemas de CI son muy complejos, y su grado de disponibilidad es clave en una infraestructura de desarrollo. Ese 99.99% de disponibilidad para todos los servicios (supongo que es la que os da Amazon) da poca informacion. Podriais dar un un numero para Jenkins como servicio individual?

      • Manuel Jesús Recena Soto

        Hola Miguel:

        Te he mandado un mensaje por twitter para poder continuar la conversación en otro hilo. No veo bien “monopolizar” este.

        Tu experiencia migrando a CloudBees nos interesa mucho. Saber si habéis contemplado Clinker es importante para que podamos mejorar.

        Quedo a la espera de tu respuesta por twitter.

        Un saludo

  • demosc

    En mi empresa acabamos cogiendo github sobre bitbucket, el motivo?
    Diseño y usabilidad, bitbucket necesita un pequeño lavado de cara, no mucho pero esta claro este aspecto lo tiene un poco abandonado (o le presta menos atencion que github).

    Es cierto que los precios de bb son imbatibles, pero como no pagamos nosotros… :p pues los responsables de area acabamos votando y salio github

  • Guillermo Montoya

    Esto me pasa por tener un día lleno de reuniones. me he perdido la wikipedia de GIT concentrada el el blog de David Bonilla. Trataré de leerlo en detalle, pero lo poco que he podido ver, todo es muy interesante. Espero poder sacar tiempo. Y sobre todo aprender de los comentarios que de por sí son posts interesantes todos.

  • Muy buenos todos los comentarios, sobre todo los que vienen de gente que está directamente implicada en el sector.
    Por mi parte aportar que en mi empresa usamos gran parte de la suite de Atlassian (Jira, GreenHopper, Confluence, FishEye, …), pero sin embargo hemos decidido usar GitHub, en parte porque la curva de aprendizaje nos ha parecido más liviana que la de Bitbucket (como algún comentario decía, tienes mucho más feedback y recursos donde aprender).

    Añadir que también usamos SourceTree, que personalmente creo que está muy por encima de GitHub for Mac.

  • Raimon Lapuente

    Muy buen articulo!

    Soy usuario de SourceTree con un servidor git local en una pequeña empresa de desarrollo. Promovi el uso porque me parece muy simple y muy correcto de usar (la versión gratuita). En cambio no lo es el Git for Mac (almenos para mi).

    Con lo que respecta a las 2 plataformas, GitHub és el cool, el hardcore para los desarrolladores. Pero no es de uso. Me explico: yo no quiero pagar (a no ser que algo valga mucho la pena) si tengo una alternativa gratuita de calidad.
    GitHub es interesante por “imagen” pero si quiero trabajar con un repositorio privado, on lo puedo usar sin pagar. Aqui es donde entra Bitbucket.

    Pero… hasta hace poco Bitbucket solo soportaba Mercurial -> ahora no!

    Con lo que, puede que Bitbucket gane adeptos para trabajar en privado, gane adeptos porque su software para Mac me parece mejor, pero de momento GitHub gana por imagen (lo cual es una putada, pero en este momento es lo que vale y vende).

    Así que, valor y al toro (aunque no soy taurino)

  • GuillermoAlvarado

    Es su éxito tan bueno, que hasta tienen una tienda en linea para vender tazas, playeras y demás. Es igual de geek traer una playera de ubuntu o firefox como de github. De verdad que han llegado lejos…

  • Hola David,

    En mi humilde opinión, creo que no deberías descartar el poder económico de la “Long Tail” http://es.wikipedia.org/wiki/Larga_cola

    Ahora estoy trabajando en una startup, y conociendo los productos de atlassian tengo que confesarme que soy un poco fanboy.

    Decidí usar Bitbucket por que nos permitía tener repositorio privado sin coste, y ahora que estamos creciendo hemos adquirido licencia. Pero el valor que me aporta bitbucket junto a servicios onDemand es la puesta en marcha de todo de una manera fácil y cómoda. Ojalá tengamos un crecimiento que tengamos que pagar 200$/mes o llegar a plantearnos utilizar Stash.

    Una de las ventajas que para mi tiene Bitbucket sobre Github es su modelo de negocio, Bitbucket no cobra por repositorios, sólo por colaboradores. Si llevo 5 años utilizando Bitbucket puedo tener un repositorio por cliente, siendo una pequeña empresa. Si utilizo Github, aunque no haya aumentado en infraestructura y en personas por haber aumentado en clientes a lo largo del tiempo, me cobra más, lo que me obliga a tener que andar eliminando repositorios que no tienen mucho movimiento simplemente por economía.

    Sólo me plantearía dejar de utilizar servicios en la nuve si los usuarios + volumen de proyecto + velocidad de línea fuera un impedimento para poder trabajar de una forma satisfactoria.

    Si las empresas tienen “miedo” de dejar el código fuente de sus desarrollos en la nube creo que sigue siendo por la mentalidad del código es el valor de sus productos, cuando creo que realmente el valor de los productos es por la gente que los crea y los mantiene. Con esto no quiero decir que el código no sea importante, pero hay más posibilidades de que un trabajador se lleve una copia de un proyecto a que el sistema DVCS tenga un fallo que permita que otros vean el código…

    Tengo que reconocer que primero he sido usuario de GitHub, y lo sigo siendo. Pero Bitbucket ayuda al lanzamiento de pequeñas empresas, la fidelización de las empresas junto con el coste que supone mantener el servicio en comparación de sus competidores puede ser la diferencia competitiva con GitHub. Y yo estoy en ese grupo tal vez minoritario que defiende el uso de Bitbucket 🙂

    • No descarto, para nada, el poder del Long Tail 🙂

      De hecho, ya sabes que Atlassian apuesta mucho más por las ventas bottom up que top down (que sean los programadores los que pidan las herramientas, en vez de intentar convencer al jefazo para que imponga un producto).

      También veía más justo el pago por usuario que por repositorio, aunque la verdad, no se me había ocurrido una aplicación práctica de ese modelo. Lo que me cuentas de tener un repositorio por cliente, me parece un caso de libro y con mucho sentido.

  • Con los $14M de revenue que mencionas, y con la trayectoria de crecimiento que tiene GitHub pueden tener facilmente un multiplicador de 25 (normalmente entre 15-25), lo que pondria la valoracion en $350M, asi que no es tan raro que les hayan invertido 100M, aunque no he visto por ahi cuanto % han cedido.

    Sobre git y DVCS, la adopcion en empresas tardara, pero llegara. No tanto por “distributed” pero mas por la rapidez y funcionalidad extra. A mi me toco vivir bastante de cerca el cambio a subversion en unas cuantas empresas, y les llevo años desde que los desarrolladores “cool” (o early adopters) estaban usandolo, pero al final cayeron, sobre todo porque los nuevos desarrolladores llegan “malacostumbraos” y empujan por el cambio.

  • Pingback: Gestión de conocimiento para el mainstream: sistemas de control de versiones | Cartograf()