demo técnica · inversión / m&a
Leer el código de una empresa antes de comprarla
Once operaciones célebres del software, examinadas la víspera de su compra o de su cambio de licencia con una sola fuente, la historia de commits, sin dejar entrar un solo dato posterior a la firma.
Una due diligence tecnológica es el examen del software de una empresa antes de comprarla: qué hay, en qué estado está y de quién depende. Al comprador le importa porque el precio de la operación descansa sobre ese software, y porque los problemas que no se ven al firmar se pagan después.
La idea de esta demo: la historia de cambios del software se puede auditar como unos libros de contabilidad. Todo programa serio vive en un repositorio, el archivo donde está el código con toda su historia; cada apunte de esa historia es un commit: un cambio concreto, con su autor, su fecha y su correo. Nadie escribe esos apuntes pensando en una auditoría, y por eso cuentan la verdad: quién trabaja, cuánto, para qué casa y desde cuándo.
La conclusión, por delante: el git te dice mucho más de lo que crees la víspera de una compra, pero no todo, y sabemos exactamente qué parte no te dice. El detalle está en el mapa y en los casos de abajo.
Aquí el objeto es código, pero la lógica, exprimir el rastro que un negocio deja sin querer para saber qué compras antes de firmar, es la de cualquier due diligence: las nóminas, los contratos y los albaranes cuentan su verdad igual que los commits.
el expediente a fecha de la víspera · fecha del commit
11
vísperas examinadas, de OpenOffice 2009 a Redis 2024
6
señales con fórmula sellada, solo de la historia de git
24
meses posteriores al evento, etiquetados con otra fórmula sellada
resumen
- los datos
- Los repositorios públicos de once proyectos de software en el centro de una operación: OpenOffice, MySQL, nginx, Redis, Terraform, Atom, npm, Docker, Elasticsearch, Travis CI. Solo su git.
- la pregunta
- La víspera de firmar, ¿qué decía realmente el código? ¿De cuántas manos dependía, de cuántas casas, y se podía separar eso del follón comercial que venía?
- la prueba
- Seis señales con fórmula fijada antes de computar, medidas al día exacto anterior a cada evento. Lo que pasó después se etiqueta a 24 meses con reglas también selladas, sin excepciones manuales.
- lo que salió
- Una de las dos premisas se cumplió entera; la otra, a medias, con las dos causas del fallo explicadas.
Cuando se compra una empresa, las cuentas pasan semanas de auditoría. El software del que depende el negocio, muchas veces, un vistazo. Y la pregunta que importa la víspera de firmar no es si el código funciona hoy: es de cuántas manos depende, de cuántas casas, y qué pasará con ellas cuando cambie el dueño.
Los casos son famosos y sabemos cómo acabaron: esto no es una predicción a ciegas. Lo que quedó congelado antes de mirar es la definición de cada señal, con su fórmula, y el cómputo es mecánico: cualquiera puede correr el mismo script sobre el mismo repo a la misma fecha y le sale el mismo número.
Las premisas, selladas antes de mirar
Antes de computar un solo número dejamos por escrito qué esperábamos encontrar y con qué reglas lo íbamos a medir. Es la diferencia entre un examen y una historia contada a toro pasado: si la premisa falla, no se puede retocar.
premisa 1
Los proyectos que dependen de una sola casa y de pocas manos acaban mal.
Si casi todo el código lo escribe gente de una única empresa, y además son pocos, el proyecto está a merced de las decisiones de esa empresa. Es la esquina del riesgo del mapa.
premisa 2
El drama comercial no ensucia al código bueno.
Los proyectos con sustrato sano aguantan compras y peleas de licencia: el titular asusta, pero el trabajo diario sigue. Separar la verdad técnica de la decisión comercial debería ser posible y medible.
el compromiso del método
Reglas y umbrales congelados antes de computar.
Fórmulas, fechas de corte y umbrales quedaron fijados en un pre-registro público antes de mirar un solo dato. Lo que salga mal se publica igual, con su pero.
pre-registro · commit 15bcb3a
Lo que el sistema ve y lo que tiene tapado
Cada proyecto se examina a una fecha de corte: la víspera exacta de su evento. Las seis señales solo pueden mirar hacia atrás desde ese día, en ventanas de 12 y 24 meses. Todo lo que pasó después queda tapado; solo se destapa al final, para etiquetar cómo acabó cada caso.
la fecha de corte fecha del commit · ni un dato posterior
Las seis preguntas que se le hacen a cada repo
Cada señal responde una pregunta que cualquier comprador entiende, con una fórmula fijada de antemano sobre la historia de commits.
S1¿De cuántas personas depende?
El bus factor: cuántos autores habría que quitar para perder más de la mitad del trabajo del último año.
S2¿De cuántas empresas depende?
El dominio del correo de cada commit dice de qué casa sale el trabajo, y cuánto pesa la casa que más pone.
S3¿Acelera o frena?
La tendencia de commits al mes en el último año: si el proyecto gana ritmo o lo pierde.
S4¿Entra gente nueva?
Cuántas caras nuevas han llegado al núcleo de autores en los últimos dos años, y qué antigüedad tiene ese núcleo.
S5¿Entrega versiones?
La cadencia de releases: si publica versiones con regularidad hasta la víspera o lleva meses sin entregar.
S6¿Cuánta historia tiene?
Edad, commits y autores totales. No es una alarma: es el contexto para leer las otras cinco.
Cómo lo hacemos
- Cada proyecto se mira a la víspera exacta de su evento (compra o cambio de licencia), con fecha de committer, sin un solo dato posterior al corte.
- Lo que pasó después se etiqueta a evento más 24 meses con una fórmula también sellada: cuánto ritmo conserva el original, cuántos del top-5 de autores siguen, y si un fork lo supera. DEGRADACIÓN, ESTABLE o PROSPERA, sin excepciones manuales.
- Todo quedó sellado en un pre-registro antes de computar señal alguna commit 15bcb3a.
- Antes de fiarnos de una cifra, inspección a mano: los repos importados de otros sistemas mienten si no se mira. En MySQL, dos señales se reportan como no computables limpias en vez de un número bonito.
El resultado: once vísperas en un plano
Cada punto es un proyecto la víspera de su momento crítico, colocado por lo que su git decía ese día. Cuanto más a la derecha, más dependía de una sola casa. Cuanto más abajo, de menos manos. El color dice cómo acabó: los rojos acabaron mal, los ámbar prosperaron, los grises quedaron a medias.
Si la premisa 1 fuera exacta, todos los rojos estarían abajo a la derecha. Pasa el ratón o pulsa un punto para leer su ficha.
el mapa de los 11 casos pre-registro 15bcb3a · etiqueta a evento+24m
OpenOffice
DEGRADACIÓNLa víspera de que Oracle comprara Sun, el 98,8% de los commits del último año salía de un único dominio. Un monocultivo de libro: casi todo lo escribía gente de una sola casa. Un año después nació el fork LibreOffice y se llevó el desarrollo.
su pero Por actividad y renovación parecía sano: subía, y metía caras nuevas en el núcleo. La única señal que veía el riesgo era la del patrocinador único.
¿Se cumplieron las premisas?
premisa 1 · una sola casa y pocas manos
a mediasOpenOffice la cumple de libro: 98,8% de una casa, único punto en la zona roja, y el fork se llevó el desarrollo. Pero Travis, Redis y Atom degradaron fuera de la esquina, por dos causas que son los dos hallazgos del ejercicio: desde ~2015 los equipos commitean con correo personal y el eje de la casa es un suelo, no una foto (el patrocinador real de Travis o Atom pesaba mucho más de lo que marca el git); y el riesgo jurídico de la licencia no está en los commits, como enseña Redis.
premisa 2 · el drama no ensucia al código bueno
síMySQL, nginx, npm y Docker atravesaron compras con mucho titular y no degradaron: la etiqueta mecánica no se dejó arrastrar por el ruido. Es la mitad de la hipótesis que más importa para una due diligence: separar la verdad técnica de la decisión comercial es posible y computable.
el compromiso del método · reglas congeladas
síTodo se computó con las fórmulas y umbrales del pre-registro, sin retocar nada después. Cada caso publica sus comandos y cualquiera puede reproducir el mismo número. La premisa que salió tocada queda como salió.
OpenOffice: la señal estaba en los commits
En 2009 OpenOffice parecía el líder ofimático libre: actividad subiendo, caras nuevas en el núcleo. Pero el 98,8% de los commits del último año salía de un único dominio. Casi todo lo escribía gente de una sola casa, y esa casa cambió de dueño. Un año después, el fork LibreOffice se llevó el desarrollo. PostgreSQL, el control sano del mismo corte, era lo contrario: una federación de independientes donde ningún dominio era dueño del proyecto.
una casa contra una federación ventana de 12 meses · a fecha de 2009
nginx y PostgreSQL: un equipo pequeño no es una alarma
La señal de personas, leída sola, habría gritado peligro dos veces en falso. nginx llegaba a su víspera con bus factor 1 (Maxim Dounin firmaba el 56,8% él solo) y salió de la compra casi doblando el ritmo, con el núcleo entero en su sitio. PostgreSQL, con Tom Lane al 42,6% y bus factor 2, sigue vivo y sano hoy. Un equipo pequeño no es un equipo frágil mientras la casa que paga siga pagando: ninguna señal suelta sirve de veredicto.
Y el patrón que más nos importa para una due diligence: los "comercial con código bueno" no degradan. MySQL, nginx, npm y Docker atravesaron compras con mucho titular y la etiqueta mecánica no se dejó arrastrar por el ruido. Separar la verdad técnica de la decisión comercial es posible, y es computable.
Atom: la frenada era visible antes del anuncio
Atom era el editor de GitHub, y Microsoft, al comprar GitHub en 2018, ya tenía otro editor en casa (VS Code). Lo que dice su git es que el proyecto ya frenaba antes del anuncio: el último semestre previo al corte rendía un 37% menos que el anterior. Tras la compra, el ritmo quedó en el 47% del previo (de 174,7 a 82,6 commits al mes), justo bajo el umbral de degradación. El equipo seguía commiteando (5 de 5), pero en volúmenes de retirada: muerte por decisión de negocio, no por el código.
atom/atom · commits al mes 2016-2020 · fecha del commit · sin merges
Redis: lo que el código no puede decir
Redis llegó a su víspera sano por las seis señales: muchas manos, diverso, activo, renovándose. Y degradó igual: tras el cambio de licencia, el núcleo se fue casi entero y el fork Valkey lo superó en dos años. Su riesgo era el control legal de la licencia, en manos del dueño de la marca con ~21% del código, y eso no está en el git. La rúbrica de código no ve el riesgo de gobernanza jurídica.
De los cinco autores que más código habían puesto el año previo, cuatro dejaron el repo original y reaparecieron en el fork. No dejaron el proyecto: dejaron al dueño. El quinto, Oran Agra, trabaja en Redis Ltd, la empresa dueña de la marca.
a dónde fue el núcleo de Redis top-5 de autores pre-evento · destino post-2024
El caso deja además una lección para el método: la misma diversidad que hacía sano el sustrato es la que hizo viable el fork inmediato. En OpenOffice el monocultivo era el riesgo; en Redis, la diversidad fue el seguro de vida del código y el problema del dueño. El código vive hoy mejor que nunca, repartido en dos casas.
La continuidad, caso a caso
De las reglas selladas, la primera (D1) mide cuánto ritmo conservó cada proyecto: los commits al mes de los dos años posteriores al evento divididos por los del año previo. Por debajo de 0,5, el proyecto perdió más de la mitad del ritmo y la regla lo marca como degradación fuerte.
D1: ritmo conservado tras el evento post 24m / pre 12m · umbral sellado 0,5
Los peros, uno por uno
- n = 11 es ilustración, no estadística. El piso de cientos de repos para calibrar pesos sigue siendo la asignatura pendiente.
- La lente del dominio de email infra-mide al patrocinador desde ~2015: los equipos commitean con gmail o dominio propio. En 2009 el correo corporativo confesaba el monocultivo; en 2019 lo esconde. El eje horizontal de los casos modernos es un suelo, no una foto. La mejora concreta para la v1: mailmap y afiliaciones declaradas.
- El riesgo jurídico no está en el git. Quién puede cambiar la licencia, de quién es la marca, qué firmaron los contribuidores: nada de eso aparece en los commits, y Redis lo demuestra.
- Tres etiquetas caen en la frontera exacta del umbral (Atom 0,47; Docker/moby 0,503; Elasticsearch 0,801): son sensibles a la definición. Se publican tal cual porque el umbral estaba sellado antes de computar.
- Los repos importados de otro sistema de control de versiones exigen inspección a mano; dos señales de MySQL se reportan como no computables limpias en vez de un número bonito.
- El éxodo del núcleo mide "sigue commiteando en el repo", no "sigue en la empresa" ni "sigue vivo el proyecto".
Datos y agradecimientos
Existe porque estos once proyectos desarrollan o desarrollaron en abierto, con su historia completa a la vista. Gracias.
Sin afiliación con ninguna de las empresas ni fundaciones citadas. Los nombres de autores que aparecen son los públicos del propio git, y se citan como lo que son: las personas de las que dependían proyectos enormes.
¿Puedes usar esto? Sí. Nuestros cómputos, el mapa y los textos de esta página se publican bajo licencia CC BY 4.0: úsalos, compártelos o analízalos libremente, citando la fuente, Team Banzai (team-banzai.com). Los repositorios públicos analizados conservan sus licencias originales.
Hecho con Python sobre la historia de git (git log, fecha de committer), estadística clásica y fórmulas selladas antes de mirar (commit 15bcb3a). Los gráficos se dibujan con ECharts. Ningún modelo de lenguaje decide nada.
Sobre esta demo
Estudio retrospectivo con fines ilustrativos sobre repositorios públicos. Mide señales de la historia de commits y etiqueta lo que pasó después con fórmulas fijadas de antemano; no evalúa la calidad del trabajo de las personas citadas ni emite juicio sobre las empresas. No es asesoramiento de inversión.
¿Y en tu empresa?
La misma lectura fría sirve para medir la deuda técnica de tu propio equipo sin depender de lo que te cuenten, para auditar un proveedor de software del que dependes antes de renovarle, o para ver, tras una fusión, qué dos sistemas hacen lo mismo y cuál sobra.
Si alguno de estos experimentos te recuerda a un problema tuyo, una compra que mirar por dentro, un proveedor de software del que no sabes cuánto dependes, datos que nadie mira, escríbenos y lo comentamos. Sin rollo: te decimos si se puede o no.