Más allá de quienes hacen y quienes toman: ser un "faker" en el código abierto

El mundo de WordPress está en llamas en este momento. La pelea muy pública entre Matt Mullenweg y WP Engine ha sacado a la superficie algo que me ha estado molestando por un tiempo: cómo contribuimos al código abierto y qué significa eso realmente.
Esta no es una discusión nueva. Dries Buytaert, el fundador de Drupal, ha escrito dos posts importantes sobre los "makers" y "takers" en el código abierto. Primero en su artículo "Balancing Makers and Takers to Scale and Sustain Open Source" y más recientemente en "Solving the Maker-Taker Problem in Open Source". Lo explica con bastante claridad: tienes a los makers, que contribuyen activamente (código, documentación, organización de eventos, lo que sea que ayude al proyecto), y a los takers, que usan el software sin devolver nada.
En Drupal, en realidad hemos hecho algo al respecto. Hemos construido un sistema muy completo para reconocer y fomentar las contribuciones. Todos los que se unen a Drupal.org obtienen un perfil personal para mostrar y compartir sus contribuciones. No importa si estás escribiendo código, creando documentación, organizando eventos o mentoreando a nuevos colaboradores: todo cuenta. Este sistema ayuda a celebrar a quienes devuelven algo al proyecto e inspira a otros a involucrarse. Tanto las personas como las organizaciones pueden ganar reconocimiento por sus contribuciones. Se trata de construir una cultura donde la contribución sea valorada y accesible para todos.
Pero aquí está lo que me ha quitado el sueño últimamente. Mientras construyo Palcera y miro mi propio historial en el código abierto, estoy viendo una tercera categoría de la que necesitamos hablar. Los llamo los "fakers": aquellos que crean una apariencia de contribución sin comprometerse realmente con las necesidades de la comunidad.
Déjame explicar a qué me refiero. He visto empresas que anuncian tener numerosos desarrolladores certificados por Acquia. En mi opinión —y esta es solo mi perspectiva personal después de años en el ecosistema— si bien las certificaciones de Acquia son definitivamente valiosas para validar conocimientos, son solo una pieza del rompecabezas. A veces lo que se presenta como "desarrolladores certificados" resulta ser principalmente certificaciones de site builders. Seré claro: los site builders son absolutamente cruciales para nuestro ecosistema. De hecho, soy un fuerte defensor de resolver problemas mediante site building en lugar de código personalizado cuando sea posible. Pero hay una distinción importante aquí: la certificación de site builder valida habilidades para configurar módulos, crear tipos de contenido y gestionar campos, mientras que la certificación de desarrollador cubre un conocimiento arquitectónico más profundo y capacidades de desarrollo personalizado. Ambas son valiosas, pero sirven para propósitos distintos y requieren diferentes niveles de expertise. Lo que más me preocupa es ver a empresas promover estas certificaciones sin participar en el programa de partners de Drupal ni aparecer en los registros de contribuciones.
Recientemente, noté a alguien criticando nuevas iniciativas de Drupal sin ofrecer soluciones constructivas. Lo que llamó mi atención fue su perfil de LinkedIn donde se describía como "core/module contributor". Esto es algo que se ve cada vez con más frecuencia en nuestra comunidad: lo que algunos llaman "issue astroturfing". Ocurre de distintas maneras: dividir lo que podría ser un único cambio automatizado de formato de código en múltiples pull requests pequeños, enviar numerosos cambios superficiales generados por herramientas de linting, o comentar en exceso en los issues sin agregar valor real.
Yo lo experimenté de primera mano cuando mi hijo, que apenas estaba empezando con Drupal, creó su primer issue: un cambio sencillo de CSS. De un día para otro, el issue acumuló más de diez comentarios, pero solo uno abordaba parcialmente el problema que habíamos identificado. Si bien revisar y discutir issues es crucial para nuestra comunidad, simplemente decir "sí, esto es un problema" realmente no hace avanzar las cosas.
No me malentiendan: las herramientas automatizadas, la limpieza de código y las discusiones en los issues tienen su lugar. Pero cuando alguien deliberadamente divide estos cambios en docenas de contribuciones separadas o agrega comentarios solo para aumentar su conteo de créditos visibles, puede crear más trabajo para nuestros maintainers y dificultar la búsqueda de soluciones significativas. Más importante aún, se pierde el punto de lo que realmente significa contribuir: hacer Drupal mejor para todos.
Estas observaciones me llevan a reflexionar sobre mi propio camino. Si miras mi perfil mencionado arriba, verás que he contribuido a la documentación, a eventos, y que sigo actuando como community developer. Esto es una de las grandes cosas de Drupal: cualquiera puede usar sus habilidades y fortalezas para contribuir de maneras significativas, no solo con código. Si bien no escribo código tanto como antes (mi última contribución mayor fue un patch para Drupal 8), he encontrado otras formas de contribuir de manera significativa. Actualmente estoy trabajando en la IXP Initiative, que busca ayudar a nuevos desarrolladores a entrar al ecosistema de Drupal. También estoy activamente involucrado con la Colombian Drupal Association, trabajando para hacer crecer nuestra comunidad local y crear oportunidades para nuevos colaboradores.
Pero aún me preocupa. Mientras construyo Palcera, constantemente me pregunto: ¿estamos haciendo suficiente? ¿Cómo nos aseguramos de no solo cumplir con las formas, sino de estar agregando valor real a la comunidad? Esto no es solo el síndrome del impostor hablando: es una preocupación genuina por contribuir de manera significativa en lugar de solo marcar casillas.
La dinámica maker-taker no es blanco o negro. La mayoría empezamos como consumidores de código abierto: aprendiendo, creciendo y encontrando nuestro camino. A veces podemos hacer solo lo suficiente para parecer activos sin comprometernos de verdad, y eso es una parte natural de encontrar nuestro lugar en la comunidad. Lo importante es seguir avanzando.
Contribuir al código abierto no se trata de la cantidad de contribuciones ni de los títulos que reclamamos. Se trata de encontrar formas auténticas de devolver algo, sin importar qué tan pequeñas sean. Ya sea ayudando a responder preguntas en las colas de issues, mentoreando a los que recién llegan, o simplemente siendo honestos sobre dónde estamos en nuestro camino: cada contribución genuina hace avanzar a nuestra comunidad.
Así que me gustaría abrir esto a la discusión: ¿cómo podemos apoyarnos mejor para encontrar formas significativas de contribuir? ¿Qué te ayudó a pasar de usar código abierto a participar activamente en él? ¿Cómo podemos hacer que el camino hacia la contribución sea más accesible y gratificante para todos?
Comparte tus ideas y experiencias. Trabajemos juntos para construir una comunidad donde todos puedan encontrar su forma auténtica de contribuir.