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
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 verde-agua 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.
Las once fichas, en texto (sin necesidad de ratón)
-
OpenOffice · Oracle compra Sun · 2009 · degradación · dominio top 98,8% · bus factor 4 · técnico
La 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.
-
PostgreSQL · control sano, mismo corte de 2009 · prospera · dominio top 42,6% · bus factor 2 · control
El gemelo de control: Tom Lane firmaba él solo el 42,6% de los commits y el bus factor era 2. La señal de personas, leída sola, habría gritado peligro sobre el proyecto que sigue vivo y sano hoy.
su pero Su dominio top no es una empresa: es la máquina personal de Lane. Detrás había 12 organizaciones independientes, lo contrario de un monocultivo.
-
Travis CI · Idera (private equity) la compra · 2019 · degradación · dominio top 16,3% · bus factor 4 · mixto
Comprada por un private equity en enero de 2019; semanas después salió gran parte del equipo técnico. A los 24 meses el repo principal iba al 43% de su ritmo y del top-5 de autores solo seguían 2.
su pero Su 16,3% del eje X es un suelo: el equipo commiteaba con correo personal y la lente del dominio no ve al patrocinador que pagaba casi todas las nóminas.
-
MySQL · Oracle compra Sun · 2009 · prospera · dominio top 54,3% · bus factor 10 · comercial
Mismo comprador y mismo día que OpenOffice, resultado opuesto: el original aceleró (D1 1,40) y 4 de 5 del núcleo siguieron. El ruido mediático de la compra no engañó a la etiqueta mecánica.
su pero Su historia viene importada de otro sistema de control de versiones: el 54,3% es una recuperación manual y dos señales se reportan como no computables limpias.
-
nginx · F5 compra Nginx Inc · 2019 · prospera · dominio top 45,5% · bus factor 1 · comercial
El peor bus factor posible: 1. Maxim Dounin firmaba él solo el 56,8% del último año. Y tras la compra el proyecto casi dobló el ritmo (D1 1,94) con el núcleo entero en su sitio (5 de 5).
su pero El 45,5% es el número crudo del script; con contexto externo (Dounin en nómina), en torno al 91% salía de una sola casa. Y años después, ya fuera de la ventana, Dounin rompió con F5.
-
Terraform · cambio de licencia a BSL · 2023 · estable · dominio top 16,5% · bus factor 5 · mixto
La víspera del cambio a BSL, un sustrato sano: bus factor 5, 154 autores al año, releases semanales. El fork OpenTofu no lo destronó: empate a 89 commits en el mes 24.
su pero Otro suelo en el eje X: la mayoría del núcleo cobraba de HashiCorp y commiteaba con correo personal.
-
Redis · cambio de licencia a SSPL/RSAL · 2024 · degradación · dominio top 24,6% · bus factor 5 · mixto
Sano por las seis señales: muchas manos, diverso, activo, renovándose. Y aun así el núcleo se fue casi entero (quedó 1 de 5) y el fork Valkey lo superó en dos años. Los que se fueron no dejaron el proyecto: dejaron al dueño.
su pero Su riesgo era el control legal de la licencia, en manos del dueño de la marca con ~21% del código. Eso no está en el git.
-
Atom · Microsoft compra GitHub · 2018 · degradación · dominio top 45,7% · bus factor 4 · comercial
El dueño nuevo ya tenía otro editor en casa. A los 24 meses el ritmo había caído al 47%: muerte por decisión de negocio, no por el código.
su pero Su D1 de 0,47 roza el umbral (0,5) y el equipo seguía commiteando (5 de 5). El archivado real llegó en 2022, fuera de la ventana sellada.
-
npm · GitHub compra npm · 2020 · estable · dominio top 21,4% · bus factor 1 · comercial
Bus factor 1 y frenada la víspera. El comprador repuso las manos: equipo nuevo y la actividad multiplicada por 2,4. La fragilidad era real; el relevo vino de fuera.
su pero Se queda en ESTABLE porque dos de los cinco del núcleo dejaron de commitear tras la compra: la regla sellada pedía 4 de 5 y salieron 3.
-
Docker/moby · venta de Docker Enterprise a Mirantis · 2019 · estable · dominio top 29,7% · bus factor 2 · comercial
La crisis era del negocio de Docker Inc, no del código: 134 organizaciones en la ventana y releases de reloj. Tras la venta, el núcleo siguió intacto (5 de 5) y sin fork.
su pero D1 de 0,503, en la frontera exacta del umbral: el proyecto sobrevivió, pero se dejó la mitad del ritmo.
-
Elasticsearch · cambio de licencia a SSPL · 2021 · prospera · dominio top 41,1% · bus factor 18 · mixto
El bus factor más alto del mapa: 18. El original siguió entregando tras el cambio de licencia y el fork OpenSearch quedó en un quinto de sus commits en el mes 24.
su pero D1 de 0,801: cumple la continuidad por centésimas. Un puñado de commits menos y la etiqueta habría sido ESTABLE.
¿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.