Antes de publicar mi primera CLI en npm, tenía una idea bastante romántica de cómo funcionaba esto.

Subes el código, la gente lo encuentra, lo usa, te manda PRs bien escritos, todos contentos. Una comunidad que se construye sola alrededor de algo útil que hiciste un fin de semana.

La realidad es bastante más prosaica.

Publicar es la parte fácil

El día que subí sgomez-cli y lo anuncié llegaron las primeras estrellas en GitHub. Eso se siente bien, no voy a mentir. Pero tres días después llegó el primer issue. Y con él una pregunta que no me había hecho antes: ¿hasta dónde llega mi compromiso con esto?

Un issue no es solo un bug. Es una persona real que usó algo que hiciste, se encontró con un problema, se tomó el tiempo de reportarlo y ahora está esperando una respuesta. Ignorarlo tiene un coste, no económico sino de coherencia con lo que dices que eres.

Y cuando tienes varios proyectos activos, un trabajo a tiempo completo, un podcast y un SaaS en construcción, la pregunta de dónde va el tiempo se vuelve muy concreta muy rápido.

La deuda que nadie menciona

Hay mucho escrito sobre deuda técnica. Casi nada sobre lo que yo llamo deuda de atención.

La deuda técnica es el código que sabes que deberías refactorizar pero no tienes tiempo. La deuda de atención es el issue abierto hace tres semanas, el PR que merece un review decente, la documentación que quedó desactualizada cuando añadiste esa feature nueva.

Las dos se acumulan. Las dos tienen interés.

La diferencia es que la deuda técnica solo te afecta a ti. La otra le afecta a la gente que confió en lo que construiste.

Con sgomez-cli llegué a soportar 14 frameworks, 11 features adicionales y 73 tests automatizados. Todo eso suena bien en un README. Pero cada framework nuevo es documentación nueva, casos edge nuevos, issues nuevos. En algún punto tienes que hacerte una pregunta incómoda: ¿estoy añadiendo valor o estoy añadiendo complejidad?

Lo que aprendí a hacer

No tengo un sistema perfecto. Tengo uno que funciona para mí ahora mismo.

Separar bugs de feature requests. Un bug en algo que ya prometiste que funciona va primero. Una feature request, por muy buena idea que sea, entra en una lista y se evalúa en contexto. No todo lo que alguien pide tiene que existir.

Documentar decisiones, no solo código. Los comentarios explican el qué. Lo que realmente ayuda, a ti mismo seis meses después y a cualquiera que quiera contribuir, es saber el por qué. Por qué la arquitectura es así. Por qué se descartó la alternativa obvia.

Saber cuándo archivar. Esto es lo más difícil. Un proyecto que ya no mantienes pero que tampoco marcas como abandonado es un problema real. La gente sigue abriéndolo, sigue confiando en él, sigue encontrando problemas que nadie va a resolver. Ser honesto sobre el estado de un proyecto es más valioso que mantener las apariencias.

Por qué vale la pena igualmente

Con todo esto dicho, ¿merece la pena?

Para mí sí, aunque no por las razones que se suelen mencionar. No es por el portfolio ni por las estrellas. Es porque mantener algo público te obliga a un estándar diferente. Cuando sabes que alguien más va a leerlo y a depender de él, escribes de otra manera. Documentas porque te da vergüenza que no esté documentado. Piensas en los casos edge que en un proyecto privado ignorarías.

Es un tipo de disciplina que no se consigue de otra forma.

Y de vez en cuando alguien te dice que tu herramienta le ahorró tiempo real. Eso no tiene equivalente en ningún otro sitio.

Si estás pensando en publicar algo open source por primera vez, una pregunta útil antes de hacerlo: ¿qué nivel de soporte estás dispuesto a mantener durante los próximos doce meses?

La respuesta honesta debería dictar el scope del proyecto, cómo lo documentas y qué prometes en el README. No tienes que comprometerte con todo para siempre. Pero sí ser honesto, contigo y con los demás, sobre lo que sí.

Nos leemos.

Santi