Ir al contenido

El riesgo de "factor autobús" en MongoDB, MariaDB, Redis, MySQL, PostgreSQL y SQLite

·992 palabras·5 mins
Alejandro Duarte
Autor
Alejandro Duarte
Alejandro Duarte es Ingeniero de Software, escritor, Ingeniero de Relaciones con Desarrolladores en MariaDB y consultor en desarrollo de software. Ha programado computadores desde mediados de los 90s. Comenzando con BASIC, Alejandro transitó a C, C++ y Java durante sus años académicos en la Universidad Nacional de Colombia. Se mudó primero al Reino Unido y luego a Finlandia para profundizar su participación en la industria del código abierto. Alejandro es reconocido en círculos de Java y MariaDB.

¿Alguna vez te has preguntado qué pasaría con un proyecto de base de datos de código abierto si sus desarrolladores principales “fueran atropellados por un autobús”? O sin tanto drama, si abandonaran el proyecto por completo. Eso es lo que mide el “factor autobús” (también llamado “factor camión”): Cuántas personas tendrían que desaparecer para que ninguno de los que quedan sepa cómo corregir o actualizar partes específicas del código.

El ranking del factor autobús
#

Estuve experimentando con una herramienta llamada Bus Factor Explorer de JetBrains para explorar el riesgo asociado en algunas de las bases de datos de código abierto más populares. Analicé seis de las más importantes para ver dónde se posicionan. Esta es la línea base actual (Marzo de 2026) según la herramienta:

Base de datosFactor autobús (más alto es mejor)
MongoDB7
MariaDB5
Redis5
MySQL2
PostgreSQL2
SQLite2

Por ejemplo, para que MongoDB “se quede sin rumbo”, 7 desarrolladores tendrían que abandonar el proyecto. En el caso de MySQL, PostgreSQL y SQLite, si 2 desarrolladores se van, el proyecto corre el riesgo de estancarse. Por supuesto, este es solo un factor; existen otros elementos que influyen en la continuidad de los proyectos de código abierto. Aun así, es un dato interesante que puedes considerar al elegir una base de datos.

La herramienta clasifica los proyectos según su factor autobús (una línea base que se puede ajustar en la herramienta si lo deseas):

  • OK: 5 o más (MongoDB, MariaDB, Redis)
  • ⚠️ Bajo: 2 a 4 (MySQL, PostgreSQL, SQLite)
  • 🔴 Peligroso: 0 o 1 (N/A)

Simulando la salida de los principales contribuidores
#

También utilicé la herramienta para ver qué ocurre con los directorios en la raíz del projecto (las partes funcionales del código) si comienzas a desmarcar a los principales contribuidores de cada proyecto. En concreto, quería analizar la proporción de directorios que se “perderían” si el principal contribuidor o los dos principales abandonaran el proyecto. Ignoré los archivos individuales al el nivel raíz. Los resultados son los siguientes:

Base de datosDirectorios (total)Directorios perdidos (1 dev fuera)Directorios perdidos (2 devs fuera)
Redis60 (0.0%)0 (0.0%)
MariaDB302 (6.7%)5 (16.7%)
MongoDB281 (3.6%)7 (25.0%)
PostgreSQL60 (0.0%)5 (83.3%)
MySQL301 (3.3%)30 (100.0%)
SQLite115 (45.5%)11 (100.0%)

Aquí, un número más bajo es mejor (menos directorios impactados). Por lo tanto, Redis es bastante sólido en esta simulación, ya que ningún directorio se vería afectado. En el otro extremo están MySQL y SQLite con el 100% de sus directorios potencialmente sin mantenimiento si los dos principales desarrolladores se retiran. PostgreSQL perdería el 83% de sus directorios en una situación similar. Estos resultados me sorprendieron bastante, aunque están alineados con el hecho de que tienen un factor autobús bajo (alto riesgo) de 2.

MariaDB obtuvo un resultado bastante bueno, especialmente en comparación con MySQL, lo que respalda lo que he intentado explicar en mis artículos y charlas sobre cómo MariaDB es mucho más que un fork de MySQL (mira esto y esto, si te interesa).

Otros factores importantes al evaluar proyectos de código abierto
#

No deberías basarte únicamente en evaluaciones de riesgo de “factor autobús”. Este indicador es útil en situaciones de misión crítica o cuando comparas proyectos que están muy parejos en otras métricas que estés utilizando para analizarlos y evaluarlos. Aquí tienes otros aspectos que conviene revisar:

  • Respaldo corporativo: ¿El proyecto cuenta con el apoyo de empresas grandes? Incluso si un desarrollador principal se retira, es probable que la empresa contrate a otra persona para cubrir ese rol y garantizar la continuidad.
  • Actividad de la comunidad: Observa la cantidad de issues activos, pull requests y discusiones. Una comunidad dinámica puede sostener un proyecto mejor que unos pocos expertos en silencio.
  • Calidad de la documentación: Una documentación completa garantiza que el conocimiento no quede solo en la cabeza de alguien, lo que facilita la incorporación de nuevos contribuidores.
  • Licenciamiento: Asegúrate de que la licencia se ajuste a tu caso de uso, ya que esto influye en la viabilidad y adopción a largo plazo del proyecto. Por ejemplo, un proyecto con licencia GPL no permite distribuir aplicaciones de código cerrado basadas en él; por lo tanto, el proyecto queda protegido en el futuro en términos de licenciamiento.

Investiga tus proyectos y sus dependencias
#

Analicé el factor autobús de otros proyectos de código abierto que me gustan mucho, como MyBatis, Vaadin y otros, pero te invito a que hagas tus propios hallazgos con la herramienta. Cuéntame si encuentras algo interesante!


Apéndice: Datos brutos de impacto
#

Este apéndice enumera cada directorio y archivo en el nivel raíz que caería a un factor autobús de 0 en las simulaciones.

1. MongoDB (Línea base: 7 - OK)
#

  • Con 1 dev fuera: .bazelrc.local.example, .gitattributes, .prettierignore, MODULE.bazel, distsrc, etc
  • Con 2 devs fuera: Todo lo anterior, más bazel, buildscripts, jstests

2. MariaDB (Línea base: 5 - OK)
#

  • Con 1 dev fuera: VERSION, config.h.cmake, CMakeLists.txt, libmysqld, debian
  • Con 2 devs fuera: VERSION, config.h.cmake, CMakeLists.txt, libmysqld, debian

3. Redis (Línea base: 5 - OK)
#

  • Con 1 dev fuera: Ninguno
  • Con 2 devs fuera: Ninguno

4. MySQL (Línea base: 2 - Bajo)
#

  • Con 1 dev fuera: mysql/mysql-server (meta raíz), iwyu_mappings.imp, config.h.cmake, CMakeLists.txt, libmysql, mysys, client, components, strings, mysql-test
  • Con 2 devs fuera: Prácticamente todos los directorios del proyecto (36 en total), incluidos storage, sql, router, extra, plugin, utilities, etc.

5. PostgreSQL (Línea base: 2 - Bajo)
#

  • Con 1 dev fuera: COPYRIGHT, meson_options.txt
  • Con 2 devs fuera: Prácticamente todos los directorios funcionales (23 en total), incluidos src, contrib, doc, config, interfaces, etc.

6. SQLite (Línea base: 2 - Bajo)
#

  • Con 1 dev fuera: VERSION, manifest.tags, make.bat, manifest.uuid, configure, README.md, mptest, main.mk, Makefile.msc, doc, manifest, tool, src, ext, test
  • Con 2 devs fuera: Prácticamente todos los componentes del proyecto (28 en total), incluidos los scripts en el nivel raíz y todos los subdirectorios principales.
¿Te gustó este artículo? Puedo ayudar a tu equipo a implementar soluciones similares. Contáctame para saber más.

Relacionados


comments powered by Disqus