La semana pasada fue lanzado PostgreSQL 13. Como desarrollador de PostgreSQL, en estas ocasiones, tengo la costumbre de seguir las noticias y las redes sociales para ver qué opina el público sobre la nueva versión y qué características son las más comentadas. Las novedades siempre causan sorpresa.
Lo que en especial me llamó la atención este año fue que gran parte de las discusiones no parecían girar demasiado en torno a las características y la orientación tecnológica. Al contrario, elogiaban a la comunidad y al proyecto PostgreSQL, así como a sus colaboradores, por el éxito (poco frecuente) logrado por un proyecto dirigido por una comunidad. Es estupendo escuchar estos comentarios, ya que trabajamos duro para lograrlo. Pero entonces, ¿por qué razón, nos preguntan, no hay más proyectos de este tipo? Por qué no hay más proyectos de bases de datos como este?
Una de las razones es que llegar a este punto no es fácil.
Consideremos tres modelos de gestión de proyectos de código abierto:
- a cargo de un individuo (o tal vez dos, pero no muchos)
- controlado por una compañía
- dirigido por una comunidad
Ahora piense en cómo empieza un proyecto de código abierto. Por supuesto, la mayoría de los proyectos inician como el modelo #1 y así permanecen. Algunos proyectos empiezan directamente como el #2. Otros comienzan como el #1 pero primero aparecen al público como el #2. Muy pocos proyectos empiezan como el #3. Piense en cómo eso ocurriría en la práctica. Para empezar un proyecto desde cero haría falta un grupo de, digamos, cuatro o diez personas (no todas empleadas en la misma empresa). Eso suena complicado. Las situaciones en las que más a menudo este escenario se presenta son cuando una universidad inicia un proyecto que luego abandona. O, de manera parecida, cuando es un laboratorio de investigación o un organismo sin fines de lucro quien lo inicia. Muchos proyectos derivados de BSD y GNU comenzaron de esa manera, así como Postgres. (Por supuesto existen excepciones. Por ejemplo, el proyecto KDE. Hasta donde me consta, creció de la nada hasta convertirse en un proyecto comunitario. Esto es impresionante).
Por lo tanto: Es preciso que un proyecto dirigido por una comunidad empiece como proyecto comunitario.
¿Es posible pasar de un modelo a otro? Claramente una transición desde el modelo #1 al #2 es plausible y común. La transición del #2 al #3 es posible aunque se produce mayormente cuando la empresa fracasa en términos comerciales, así que raramente resulta una opción exitosa. Una transición del #1 al #3 es posible, aunque ardua. Normalmente requiere un esfuerzo excepcional por parte del fundador del proyecto, que incluso podría terminar abandonando). A menudo, resulta más atractivo pasar del modelo #1 al #2. Tenga en cuenta que es muy poco probable que un proyecto pase del modelo #3 a uno de los demás modelos. Una empresa tendría que comprar a toda la comunidad, lo cual sería complicado. O todos, excepto un colaborador, abandonarían la comunidad, y eso constituye un problema. Cuando uno se encuentra en el modelo #3, la tendencia es a quedarse allí, hasta que tal vez el proyecto desvanezca, colapse o se fraccione debido a desacuerdos en la comunidad. Así que, pasar prematuramente al modelo #3 también supone un riesgo si lo que se desea es terminar en el #2.
En conclusión: La transición, tanto hacia como desde un proyecto comunitario, es difícil y no suele tener éxito.
Por eso no existen muchos otros proyectos dirigidos por una comunidad como el de PostgreSQL, sobre todo entre los sistemas de bases de datos.
Por supuesto, existe también la siguiente pregunta: ¿Cómo puede una comunidad seguir teniendo éxito y creciendo? La respuesta queda pendiente para, tal vez, otro post.