La carga de mantener Código Abierto

O: ¿Porqué no puedes fusionar mi PR de diez líneas de una vez?

Mantengo más de 200 proyectos de Código Abierto, aparentemente (y esto es una novedad para mí) estoy clasificado entre los 200 mejores usuarios de GitHub por seguidores. Hay 18 000 bifurcaciones y 42 000 estrellas en mis repositorios.

En un día promedio veo entre 50 y 100 correos electrónicos sobre Issues (problemas o mejoras) y Pull Requests (solicitudes de incorporación de cambios). Los filtro hasta dejar alrededor de 5 a 10 que considero dignos de un seguimiento personal.

Fusiono entre 5 y 10 PR (Pull Requests) por mes y confirmo código nuevo o correcciones alrededor de 166 veces.

Soy solo una persona en un pequeño rincón del Internet que mantiene un conjunto pequeño pero amplio de proyectos, desde roles de Ansible para la automatización de infraestructura hasta algunas bibliotecas PHP y Node.js pequeñas pero aún utilizadas.

¿Cómo lidiar con el agotamiento?

En varias ocasiones me he agotado, es habitual en muchos mantenedores. O aprendes estrategias para evitarlo o te quemas por completo y, en el mejor de los casos, acabas siendo carpintero o granjero (lo he visto la mayoría de las veces).

Mi estrategia durante los últimos cinco años ha sido cerrar de forma un tanto despiadada PR e Issues. También escribí sobre la habilitación del stale bot hace dos años y déjame decirte:

A pesar de lo mucho que algunas personas detestan el stale bot, este, junto con una actitud más laissez-faire hacia mis proyectos, es la mejor medida de prevención del agotamiento que he tomado.

Publico mis proyectos con una licencia de Código Abierto por dos razones:

1. Tengo una filosofía de "pagar por adelantado" en lo que respecta al código y al conocimiento.
2. Me ayuda a ser estricto con la documentación, la estandarización y la seguridad.

No hago proyectos de Código Abierto porque quiera aprovecharlos para obtener financiación o crear una nueva empresa de Silicon Valley. Tampoco planeo monetizar ninguno de mis proyectos a través de servicios o un modelo de "opciones premium".

Tengo familia y una enfermedad crónica y tengo que mantener una especie de equilibrio entre el trabajo y la vida.

El problema es que los usuarios no entienden los objetivos de mi proyecto ni mi situación personal, aunque tampoco espero que lo hagan.

Pero algunos de estos usuarios y posibles colaboradores se ofenden cuando un Issue o una Pull Request que publican se queda estancada durante unos meses y finalmente es marcada como obsoleta y se cierra.

No es nada personal.

Yo lo veo de esta manera: si no usara estas estrategias para evitar el agotamiento no podría mantener mis proyectos. Y tener un proyecto que funcione bien y sea mantenido para el 80% de las personas que lo usan es mejor, en mi opinión, que nada en absoluto. Al final, mantengo los proyectos para satisfacer mis propias necesidades primero.

Quizá suena cruel pero es la realidad del contrato de Código Abierto, ya sea que el proyecto en cuestión esté mantenido por una corporación multimillonaria o por un tipo cualquiera en St. Louis.

¿Por qué marcaste mis PR como obsoletas?

Incluso una PR de una sola línea que parece inofensiva podría romper casos de uso existentes, causar errores extraños que las pruebas de integración no cubren y agregar una sobrecarga de mantenimiento de la que seré responsable durante la vida del proyecto.

Y tal vez ese cambio de una sola línea conduzca a la próxima vulnerabilidad como la de Log4J. Pero la persona que lo envió no va a ser la que se quede despierta hasta tarde el fin de semana antes de un feriado limpiando el desastre.

La responsabilidad recae siempre en él o los encargados del mantenimiento.

Por lo tanto nunca considero que ninguna solicitud de incorporación de cambios sea "simple", salvo las correcciones gramaticales en un README.

Soy muy exigente con respecto a las PR a las que dedico incluso cinco minutos: normalmente solo miro los cambios en el código si se trata de (a) corregir un error en mi proyecto o (b) añadir una característica que yo consideraría añadir por mi cuenta.

Y de esas PR, encuentro problemas que requieren un seguimiento más de la mitad de las veces.

Además tengo el problema particular de mantener un conjunto diverso de proyectos en vez de uno o dos grandes, por lo que a veces no puedo profundizar tanto en el código de cada proyecto como me gustaría... pero incluso para los encargados del mantenimiento de uno o dos proyectos, un cambio aparentemente inocuo puede introducir errores importantes para un porcentaje de los usuarios existentes, por lo que esa posibilidad siempre modera el entusiasmo por fusionar código.

Y luego están las PR para características que sé que nunca utilizaré, generalmente (en el caso de mis proyectos) para funcionalidades poco conocidas que solo se necesitan en entornos empresariales con restricciones severas.

Por eso, suelo adoptar uno de estos dos enfoques:

1. En lugar de fusionar la solución directamente, desarrollo alguna funcionalidad que permita que mi proyecto sea más flexible, para que puedan incorporar sus cambios específicos con mayor facilidad (pero no tan fácilmente como si inyectaran su código directamente en mi proyecto, lo que me daría a mi la carga del mantenimiento).
2. Recomiendo que bifurquen el proyecto.

Y la opción número dos es, honestamente, donde las cosas terminan muchas veces para características que yo considero un caso de uso minoritario. Cuando trabajaba en el entorno empresarial estaba acostumbrado a mantener bifurcaciones y/o parches para varios proyectos de modo que pudiera hacer que funcionaran en nuestro severamente restringido entorno.

Y cuando pensaba que podría ser útil para el proyecto original, enviaba parches y PR pero entendía perfectamente que había pocas posibilidades de que se fusionaran los cambios.

Así es la vida en el mundo del Código Abierto. Es por eso que hay un millón de bifurcaciones del núcleo Linux. Es por eso que hay 18.000 bifurcaciones de mis 200 proyectos.

Entonces, cuando alguien se enoja por mi decisión de ignorar una característica o se pone demasiado entusiasta al mencionarme públicamente por no responder, le digo amablemente que se vaya a bifurcar (go fork yourself). El proyecto es de Código Abierto por una razón.

Dinero

Cada pocos años surge otra discusión sobre cómo si tan solo pudiéramos inyectar dinero en los bolsillos de los mantenedores de Código Abierto no tendríamos más problemas como los de Log4J, Heartbleeds o Shellshocks en el futuro. No creo que ese sea el caso.

Soy uno de los pocos mantenedores que realmente puede pagar su hipoteca con el apoyo de individuos y pequeñas empresas que contribuyen a mi trabajo de Código Abierto. Y estoy sumamente agradecido por eso.

Pero tengo dos ideas en lo que respecta a la "compensación":

1. De acuerdo con mis objetivos establecidos anteriormente, las donaciones no son un contrato: si $megacorp quiere que haga un cambio en mi código, sería más amigable si donaran, pero no estoy en deuda con ellos, ni quiero estarlo nunca (si quisiera, simplemente trabajaría para ellos).
2. He tenido Patreon y otros métodos de patrocinio durante años; fue hasta que cambié mi enfoque que comencé a recibir patrocinios significativos.

En ese segundo punto tengo que sacar a relucir la temida palabra que empieza por M y que todos los desarrolladores de software odian: marketing.

La única forma en que finalmente pude aventurarme a vivir por mi cuenta y dedicar más tiempo al trabajo de Código Abierto fue promocionar cosas como mis libros y mi canal de YouTube. Actualmente las ventas de libros constituyen la mayor parte de mis ingresos, y YouTube + patrocinios completan el resto. Incluso se podría argumentar que la mayoría de los patrocinios que tengo son el resultado de una mayor visibilidad en YouTube.

Aun así, con YouTube + ventas de libros + donaciones, gano la mitad de lo que ganaba como desarrollador de software a tiempo completo, especialmente cuando era consultor y cobraba una tarifa sustancial por hora.

La verdad es que el dinero no evitará la próxima vulnerabilidad de Log4J ni evitará el agotamiento de los mantenedores. Sí ayuda y es necesario tratar de financiar mejor a los desarrolladores, pero no se puede simplemente decir "Microsoft debería pagarle al desarrollador X $80,000/año y eso evitará otro Shellshock".

El dinero corporativo suele venir acompañado de expectativas y ya tengo suficientes preocupaciones como mantenedor de Código Abierto para además tratar de estar al pendiente de qué esperan los patrocinadores o donantes, es por eso que dejo en claro que no están "comprando" mi tiempo o atención. Solo están eliminando barreras para que pueda mantener mejor los proyectos de Código Abierto.

Creo que las empresas deberían tener fondos para asignarlos mensualmente a los proyectos y mantenedores de los que dependen. Pero no creo que eso resuelva el problema de la financiación, principalmente porque este tipo de sugerencia ya ha estado sobre la mesa durante más de una década y aunque hay múltiples formas de canalizar los fondos (GitHub Sponsors, Open Collective, etc.) las empresas más grandes siguen asignando una miseria (si es que) a los mantenedores de Código Abierto.

Conclusión

Esta publicación fue algo así como un flujo de conciencia para mí, así que lamento que esté un poco desorganizada. Si quieres tener la mayor posibilidad de que fusione tu código, escribí sobre eso en el 2018: ¿Cómo puedo lograr que mi PR sea aceptada?

Y si trabajas para una megacorporación, sigue luchando para asignar algo de financiación a proyectos de Código Abierto y a sus encargados. Algunas empresas están dispuestas a respaldar sustancialmente ciertos proyectos de los que dependen, pero lamentablemente son la excepción, no la norma.