- La base de personas que realmente mantiene el código central de PostgreSQL, lanzado en 1986, está envejeciendo, y surge un problema de sostenibilidad sobre quién continuará este trabajo dentro de 20 años
- En 2022, 192 desarrolladores fueron autores principales de al menos un commit, y una estructura altamente concentrada donde 14 personas escribieron el 66% del código nuevo y 40 personas el 90%
- La comunidad central de desarrollo tiene una edad promedio de alrededor de 50 años, y Tom Lane, con 68 años, sigue cumpliendo un papel central en el proyecto
- Neon está invirtiendo deliberadamente en formar a la próxima generación, contratando juniors y haciéndolos crecer de contributor a committer y maintainer, en lugar de solo fichar talento top existente
- Para el mantenimiento continuo del proyecto se necesitan intencionalidad, financiamiento e interés propio ilustrado (enlightened self interest)
El envejecimiento de PostgreSQL y el problema del personal de mantenimiento
- PostgreSQL, lanzado en 1986, se ha convertido en la opción por defecto en gran parte del desarrollo de software moderno, pero con el paso del tiempo surge la cuestión de la continuidad de quienes realmente construyen la base de datos
- Se plantea la pregunta de cuánto tiempo podrán seguir realizando este trabajo pesado (heavy lifting) sobre una base de código crítica de la que dependen tantas personas
- Postgres es un proyecto pequeño y muy unido
Estadísticas de contribución en 2022
- Robert Haas, chief database scientist de EnterpriseDB y committer de Postgres, publicó estas cifras en su reporte periódico "Who Contributed to PostgreSQL Development in 2022?"
- En 2022, 192 personas fueron autores principales (principal author) de al menos un commit de PostgreSQL
- El 66% de las nuevas líneas de código fue escrito por una de 14 personas
- El 90% de las nuevas líneas de código fue escrito por una de 40 personas
La estructura etaria de la comunidad central
- La comunidad central de desarrollo está algo envejecida, con una edad promedio de aproximadamente 50 años
- Tom Lane, de Crunchy Data, tiene 68 años y sigue cumpliendo un rol de pivote (fulcrum) en el proyecto Postgres
Gobernanza abierta y la pregunta de dentro de 20 años
- La open governance de Postgres es una base confiable y un ejemplo refrescante en una época en la que abundan los cambios unilaterales de licencias comerciales open source (rugpull)
- Desde la perspectiva de la sostenibilidad open source, si asumimos que Postgres seguirá fuerte dentro de 20 años, surge la pregunta: ¿quién hará ese trabajo en 2043?
Neon y la conversación con Nikita Shamgunov
- En una conversación con el CEO de Neon, Nikita Shamgunov, se discutió el envejecimiento de los proyectos tecnológicos y su relación con la sostenibilidad de los proyectos
-
Introducción a Neon
- Neon es una base de datos Postgres totalmente administrada y optimizada para apps serverless, que separa almacenamiento y cómputo y adopta el principio de diseño de que "la base de datos es una URL"
- Soporta branching, que permite despliegues preview, y gracias a ello formó una alianza con Vercel
- Su orientación es hacerlo "fácil, moderno, con una API zero config"
- Tiene 62 empleados, ha levantado un total acumulado de 108 millones de dólares ($108m) y compite con Supabase, entre otros
-
Diferencia entre committer y contributor
- Shamgunov: "La capa de committers de Postgres está en sus 50, 60 y 40 años; hay pocos en sus 30"
- Convertirse en committer requiere mucho esfuerzo, pero para ser contributor solo hace falta escribir buen código
Inversión en formar a la próxima generación de committers
- Neon está invirtiendo deliberadamente en la próxima generación de contributors, committers y maintainers
- La elección natural de muchas empresas es fichar talento top existente en vez de formar talento nuevo
- Shamgunov: "Discutimos si debíamos buscar y contratar más committers de Postgres, pero no estaba claro si ese era el mejor uso del dinero"
- "Es mejor formar nuevos, y así podemos seguir haciendo crecer al equipo de Postgres"
- Shamgunov enfatiza que contratar y entrenar juniors para convertirlos en committers, y más adelante en maintainers, es importante para la evolución continua del motor de Postgres
Licencias e interés propio ilustrado
- La IP de Neon está actualmente bajo una licencia permisiva, pero Shamgunov no es un purista del open source
- En el futuro, Neon podría ejercer el derecho de relicenciar (relicense), como Redis, MongoDB o Elastic, y pasar a términos más restrictivos
- Sin embargo, el código ya contribuido a Postgres no se vería afectado por esa decisión
- Tener maintainers centrales de Postgres dentro de la empresa es un ejemplo de interés propio ilustrado (enlightened self interest): un mecanismo que mantiene honesta a la compañía y que beneficia a la comunidad y a la base de código central, sin importar qué decisiones se tomen
La universalidad del envejecimiento de las cohortes
- El envejecimiento de las cohortes no es un problema exclusivo de Postgres; como ocurrió con Y2K, las comunidades y ecosistemas envejecen, y eso puede generar problemas en lo técnico, laboral y en el relevo generacional
- IBM es un caso exitoso de atracción de desarrolladores jóvenes al mundo del mainframe mediante programas universitarios de formación profesional
- También existen muchos proyectos con millones de usuarios que son operados por una o dos personas, sin patrocinio corporativo como Postgres o Kubernetes
Conclusión — la intencionalidad del mantenimiento
- Postgres no tiene ninguna dificultad para atraer nuevos usuarios y sigue siendo una plataforma enormemente popular que incluso hoy los desarrolladores de 22 años eligen por defecto
- Pero para garantizar el mantenimiento continuo del proyecto hacen falta intencionalidad, financiamiento e interés propio ilustrado
Divulgación
- Neon no es cliente de RedMonk; Crunchy Data, IBM y Vercel sí lo son, y este texto fue publicado de manera independiente, sin relación con esas relaciones comerciales
1 comentarios
Opiniones de Hacker News
Tengo 46 años, pero me gustaría formar parte de la siguiente generación, y seguro que también hay gente más joven
La última charla que di en PGCon fue sobre los huecos que hay que conocer para hackear Postgres, en particular la etapa del ejecutor y los intentos de llenar
TupleTableSlotNo soy la persona más indicada, pero a veces alguien que está aprendiendo entiende mejor lo que necesita otro aprendiz
Hace poco también escribí el índice de un libro sobre cómo contribuir a Postgres, y creo que vendería al menos 10 copias
Quizá sería mejor publicarlo como serie en línea; en cualquier caso, me pregunto si habría gente interesada
Ahora Postgres es más bien un hobby para mí, pero si hay algún lugar que busque a alguien para dedicarse de tiempo completo a contribuir a Postgres como open source, estaría dispuesto a conversar
Una buena parte de la siguiente generación actual también llegó a Postgres bastante tarde
Tom también lo diría con modestia, pero trabajó durante años en temas de imágenes y participó de alguna forma en el proceso de creación de tiff, jpg y png antes de descubrir Postgres y empezar a trabajar en él
Crea mucho contenido sobre cómo empezar a contribuir a Postgres y también es muy abierto a conversar con otros entusiastas de PG
Podría haber colaboración o consejos: https://www.youtube.com/watch?v=rihfAnd_leM
Se le puede contactar por email en x4mmm@.ru o en Twitter como @x4mmmmmm
Como la barrera de entrada ha bajado, me intriga si más gente se jubilará temprano y participará en open source
Algunas editoriales permiten que lectores de acceso anticipado reporten errores: https://nostarch.com/early-access-program
Es tan interesante que mi objetivo sería jubilarme temprano para poder hackear Postgres de tiempo completo
Incluye redes, almacenamiento, datos, algoritmos y más
Sinceramente, C es el menor de los problemas; Postgres tiene un buen estilo de código y es bastante consistente
Lo difícil es la complejidad de su estructura interna, y si la comunidad es pequeña, eso también puede afectar la velocidad con la que recibes ayuda
Me pregunto si en el futuro las bases de código en C tendrán dificultades para encontrar mantenedores
Postgres tiene soporte comercial e inercia, pero parece faltar una vía de entrada para desarrolladores C experimentados
C sigue siendo un lenguaje vivo y no le faltan usuarios activos; además, para alguien que programa sistemas en otro lenguaje, la curva de aprendizaje no es tan pronunciada
Para los desarrolladores web y de aplicaciones de hoy, hay una cortina opaca entre ellos y la arquitectura de los sistemas subyacentes, por lo que C puede parecer intimidante; pero los programadores de sistemas que usan C++ o Rust ya trabajan detrás de esa cortina con guantes más gruesos
Muchos de ellos han estado expuestos a C, aunque sea por formación o experimentación, y si lo asumen profesionalmente pueden estudiarlo deliberadamente y adaptarse a sus trampas peligrosas
Hay argumentos en contra de elegir C para nuevos proyectos de sistemas, pero salvo por el problema de la escasez de programadores de sistemas en general, no parece haber una gran preocupación inmediata para encontrar mantenedores de código existente
No lo he medido científicamente, pero parece que el nivel promedio de habilidad en C de los nuevos contribuidores es más bajo que antes; claro, quizá sea mi barba canosa hablando
Hasta ahora la gente ha ido “aprendiendo en el trabajo”, pero no está claro qué tan grande es esa brecha
Algún día probablemente habrá que facilitar el uso de otros lenguajes en algunas partes del sistema, por ejemplo en implementaciones de tipos de datos dentro del core, aunque en la práctica todavía parece algo bastante lejano
La parte difícil es tener el conocimiento de dominio correcto, y toma mucho tiempo familiarizarse con todo el sistema
Conozco a muy pocos desarrolladores experimentados de Rust o C++ que no sean también competentes en C
Lo que sí me da curiosidad es cuándo más bases de código en C empezarán a separar módulos y reemplazarlos por Rust
Ya está ocurriendo en Linux, curl, proyectos C++ como Chrome, varios productos de MS, Amazon S3, etc.
La resistencia más explícita que conozco es OpenBSD, porque intenta mantener pequeños el bootstrap y la toolchain de instalación básica
Incluso el sistema de tipos de TypeScript es bastante más complejo que C
O quizá solo estoy dejando ver mi ignorancia sobre lo complejo que es C
He pensado mucho sobre este tema
La comunidad lleva mucho tiempo creciendo y achicándose por ciclos, y digo algunas cosas con la intención de compartir un poco más sobre la comunidad de PG
Durante varios años no hubo ningún committer nuevo, y recientemente el equipo ha intentado agregar nuevos committers de forma más deliberada y depurar a las personas que ya no participan
Hace unos 15 años hubo una época en la que bastantes jóvenes obtuvieron permisos de commit, y recuerdo a tres que tenían menos de 25 años, quizá todos menos de 22
Uno de ellos se fue de la comunidad de Postgres poco después, otro estuvo más de 10 años ocupado discretamente en otras cosas y luego volvió, y otro siguió participando activamente
Creo que la incomodidad con la gente que desaparece después de recibir permisos de commit hizo que durante algunos años se ralentizara la incorporación de gente nueva
En resumen, significa que es difícil obtener permisos de commit en Postgres justo después de graduarse de la universidad
Un dato interesante, pero difícil de recopilar, es a qué edad la gente se convierte en committer de Postgres
No me sorprendería que, en promedio, la edad a la que se reciben permisos de commit estuviera cerca de los 45 años
Muchos colaboradores llegan a Postgres después de trabajar en otros sistemas, o sienten que enviar parches a una lista de correo es intimidante y recién consideran contribuir cuando ya tienen cierta experiencia
La historia de su primer commit es excelente
Mientras probaba el comportamiento de SQL en Materialize, intentó verificar si los dos sistemas manejaban de la misma manera las funciones de interval, y con mucho cuidado probó cosas como
select interval '0.5 months 2147483647 days';Se puede probar directamente en dbfiddle: https://www.db-fiddle.com/f/ijT76fsmL99bHvXxhAtf7j/0
En vez de un error, Postgres devolvía un valor incorrecto,
{"days":-2147483634}, y se puede leer el motivo aquí: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...Así que, naturalmente, lo corrigió en Postgres, y gracias a eso en las versiones 15 y superiores se maneja correctamente: https://www.db-fiddle.com/f/i3KikCb72AN1EZpywErZvr/1
Me gusta tanto Postgres que hasta tengo un tatuaje de PG, pero ninguno de los dos caminos para contribuir es fácil
Aunque quieras contribuir como usuario cualquiera en tu tiempo libre, no hay muchos tickets del tipo “buen primer issue”, y es difícil empezar si no conoces al menos algo del contexto y las razones históricas de varias partes de la arquitectura de PG
También puede ser intimidante que personas como Tom o Andres revisen tus parches
El camino de entrar como desarrollador en una empresa paga de PG como EDB, PG Pros o Crunchy también es casi un problema del huevo y la gallina
Es difícil que te contraten como junior sin experiencia previa hackeando PG, pero tampoco es fácil conseguir esa experiencia
Si no fuera por mi empresa actual, me gustaría trabajar en un lugar que haga trabajo con PG, pero no hay muchos caminos realistas de entrada
Para las 10 personas que se convirtieron en committers recientemente, usé algunos comandos de git como los de abajo para comparar el momento en que su nombre apareció por primera vez en un mensaje de commit con el momento de su primer commit como committer
El tiempo promedio de participación fue de unos 8.9 años al comparar solo mes/año, y el caso más corto fue de unos 6.5 años
Se podría hacer un análisis mejor, pero el objetivo era tener una idea aproximada
git log --grep 'Name' --format=%cs | sort | head -1git log --author 'Name' --format=%cs | sort | head -1En ese entonces quizá era más accesible para alguien de 22 años y era posible entender más partes
Además, en esa época C era un lenguaje estándar, pero hoy es más probable que los desarrolladores jóvenes programen en Rust que en C
No tenía idea de que hubiera habido una concentración de personas que recibieron permisos de commit con menos de 22 años
Soy un nuevo colaborador que empezó a contribuir a Postgres hace 5 meses, y a fin de este mes cumplo 27 años.
Todavía no he hecho muchas contribuciones valiosas, pero ya tengo algunos commits y, en adelante, me gustaría facilitar la compilación de extensiones de Postgres con Meson y, si es posible, también acelerar la eliminación de las compilaciones con autotools.
Es posible que pronto me vean también en los repositorios de pgbouncer o pgvector.
Lo que me llevó a contribuir fue que me cansé de la empresa de consultoría de software donde trabajé durante 3 años.
Yo originalmente quería dedicarme al software de sistemas de código abierto, y encontré en Micron un trabajo relacionado con un motor de almacenamiento de código abierto.
Sinceramente tuve suerte, pero la oferta parecía escrita para mí, así que postulé, y trabajé felizmente en ese proyecto durante 2.5 años.
Lamentablemente, a fines de febrero Micron despidió a todo el equipo, y después MongoDB me ofreció trabajar en drivers C/C++, pero luego retiró la oferta.
Después de eso empecé a apoyarme más en mis contactos, y una persona que conocía de #mesonbuild en Libera.Chat/Matrix estaba trabajando en Postgres, así que le pregunté si había algún puesto relacionado con Postgres que encajara con mi perfil.
Me dijo que Neon estaba contratando, y postulé al equipo de motores de almacenamiento, pero en la primera entrevista la persona que más tarde sería mi manager consideró que encajaba mejor en el nuevo equipo de Postgres que estaban formando, es decir, el equipo que contribuye al Postgres upstream.
Estoy muy agradecido con Neon por darme la oportunidad.
El tema de este texto me parece interesante porque surgió justo mientras hablaba con otros jóvenes colaboradores de Postgres en PGConf NYC.
Es difícil conseguir que revisen incluso parches pequeños, y cuanto más conocido es tu nombre en la comunidad, más revisiones pareces recibir, lo que se vuelve un problema circular.
La estructura de las listas de correo de Postgres tampoco es buena: hay que beber directamente de la manguera contra incendios llamada pgsql-hackers, mientras que LKML está dividida en varios subsistemas.
Los foros de código modernos tienen el valor de permitir suscribirse a etiquetas específicas de PR/issues, pero hoy pgsql-hackers no tiene nada parecido.
Agregar un elemento al commitfest también es algo engorroso, y para pasar el CI completo de Postgres hay que ponerlo en el commitfest; aun después de eso, hay que revisarlo uno mismo o esperar que un committer te avise que mires una falla de CI.
Los reportes de bugs también van a la lista de correo pgsql-bugs, y Postgres no tiene un equivalente a Linux bugzilla.
Los parches se envían como adjuntos por email y ni siquiera tienen que estar en formato git-format-patch, mientras que LKML, al menos por lo que se ve, parece usar exclusivamente git-send-email.
En general, las herramientas de la comunidad de colaboradores de Postgres parecen adaptarse mejor a quienes llevan más de 15 años profundamente inmersos en ella.
No quiero convertir esto en un texto de “usemos GitHub/GitLab”; de hecho, creo que el email es superior para discutir parches, pero las herramientas alrededor de las listas de correo podrían mejorar.
Todo está demasiado separado, y creo que SourceHut ha hecho un buen trabajo haciendo que el desarrollo basado en listas de correo sea más accesible para colaboradores cotidianos.
Issues, listas de correo, CI/CD y repositorios están todos conectados, no separados en servicios distintos como ocurre ahora con Postgres.
Este comentario en sí podría convertirse algún día en una entrada de blog aparte, pero lo dejo aquí.
Si alguien acaba de empezar a contribuir a Postgres, creo que podríamos compartir experiencias; me pueden escribir a tristan neon.tech o tristan partin.io.
Otro colaborador de Postgres pensó que podría ser útil una reunión mensual entre colaboradores no committers para hablar de los parches en los que están trabajando o que ya publicaron, y recibir revisión de pares.
Tristan podría liderar una reunión en línea.
Melanie Plageman también estaba interesada en una idea así, y alguna vez conversamos brevemente sobre distintos formatos de office hours.
Esto podría convertirse en un buen texto, y parece una parte donde la comunidad de Postgres podría mejorar con relativa facilidad en términos de organización y procesos.
Dicho eso, no estoy tan seguro de la parte del “reconocimiento del nombre”, y parece que también hay bastante abandono en el otro extremo.
Es cierto que pgsql-hackers se siente como una manguera contra incendios, y creo que en los últimos años empeoró mucho.
Puedes activar CI en el repositorio sin ponerlo en el commitfest: https://github.com/postgres/postgres/blob/master/src/tools/c...
Es el mismo CI que corre para los elementos del commitfest.
Detesto que los reportes de bugs vayan a una lista de correo, y yo también me los pierdo constantemente.
También creo que el bugzilla del kernel es bastante inútil, pero no sería difícil hacerlo mejor que eso.
Tampoco creo que el manejo de parches al estilo LKML sea bueno; en particular, que cada revisión de un patchset genere un nuevo hilo no hace que sea muy fácil de seguir.
Aunque llevo unos 15 años participando en el desarrollo, no diría que las herramientas actuales funcionen especialmente bien.
El proceso de desarrollo ha evolucionado algo durante ese tiempo, pero no hasta el nivel necesario.
Cambiar una comunidad con tantas barbas grises como la de PG requiere mucho esfuerzo; no es imposible, pero tampoco es fácil.
Personalmente, detesto con fuerza usar GitHub o GitLab para trabajos complejos, pero creo que deberíamos aceptar PR/MR a través de alguno de los dos para facilitar la entrada a nuevos colaboradores.
Sin embargo, eso no es algo que dependa solo de mi decisión.
Creo que no habrá más de 2 o 3 personas que se opongan a la idea de que el email es superior para discutir parches, pero que hay que mejorar las herramientas alrededor.
El problema es que mucha gente prefiere dedicar su tiempo a hackear Postgres antes que a herramientas o integraciones del proceso de desarrollo.
He trabajado un poco con Postgres con ayuda de pgrx, y lo recomendaría como plataforma para construir soluciones de datos.
El canal de CMU también fue un buen recurso: https://www.youtube.com/@CMUDatabaseGroup
Por ejemplo, aunque quieras escribir un nuevo handler de Table Access Method, el SDK central pg-sys tiene bindings relacionados con TableAM, pero no hay documentación ni ejemplos sobre cómo usarlos desde Rust.
La observación es que la mayoría de la gente que entra a TI hoy en día solo busca dinero, y ya casi no queda gente apasionada
Es muy triste, y parece que muchos proyectos de código abierto se están muriendo por eso
Es como “copiar y pegar de Stack Overflow y cobrar el sueldo”, sin contribuir ni ayudar a cambio
No quiero decir que todos sean así, pero por lo que he observado de cerca y conversado trabajando en varias empresas, la proporción era más o menos de 19:1
Como referencia, yo termino el trabajo demasiado rápido en comparación con el estándar y a menudo pierdo tiempo esperando reuniones, así que trabajo todos los días en dos empresas
También hice muchos trabajos secundarios para hacer cosas interesantes, y muchas veces incluso gratis para probar hardware nuevo o experimentar
Las cláusulas de cesión de invenciones y de actividades externas en los contratos elevan la barrera para contribuir
Estoy de acuerdo en que Postgres no está teniendo dificultades para atraer usuarios nuevos
Yo también uso Postgres en varias apps self-hosted
Pero en las aplicaciones PHP sigo usando MariaDB, que suele ser la opción predeterminada o la única base de datos
En resumen, parece decir que la base de contribuidores de PostgreSQL está envejeciendo, y que Neon está ampliando la base de desarrolladores al contratar y capacitar juniors en lugar de recurrir a committers existentes
Como programador sin experiencia en C/C++ pero con interés, creo que una serie de videos que explique el código en detalle ayudaría muchísimo a empezar a contribuir