El cliente de API de escritorio Yaak se vuelve de código abierto

• Hace 3 meses, Yaak publicó el texto "Why Not Open Source", donde explicaba por qué no iba a convertirse en código abierto
• Como antes sufrió burnout en proyectos de código abierto, compartió su proceso de decisión pensando que podría ser útil para otras personas
• La mayoría de los usuarios de Yaak estuvo de acuerdo, pero en la comunidad más amplia de código abierto hubo una fuerte oposición a la mayor parte del contenido

Reacción de la comunidad de código abierto

• "No confundas el open source/software libre con cierto modelo social de GitHub o con las contribuciones" - lobste.rs

• "Pero todo eso también aplica al software de código cerrado" - ycombinator.com

• "El argumento de este texto es una completa tontería. Ni siquiera sé qué es esta 'app'. No hace falta. Que se vaya al basurero de la historia" - reddit.com

• La mayoría de las respuestas no fue constructiva, pero un comentario de 500 palabras en lobste.rs fue realmente excelente. Al verlo, pensó que quizá estaba equivocado

Ventajas del código abierto

• El código abierto no necesariamente significa contribuciones abiertas
• Con solo publicar el código ya se obtienen la mayoría de las ventajas:
  • Abierto a auditorías de seguridad
  • Funcionalidad transparente (nada sospechoso)
  • Flexibilidad (se puede hacer fork y modificar)
  • Puede seguir funcionando aunque el desarrollador se vaya

Cambio a código abierto con contribuciones limitadas

• Existen proyectos como SQLite que son de código abierto pero no aceptan contribuciones externas
• Litestream al principio no aceptaba contribuciones, pero después cambió para permitir solo correcciones de errores
• Yaak también adopta este modelo: se vuelve de código abierto bajo licencia MIT y solo acepta contribuciones de corrección de errores

[rmekdma]

Me impresionó que leyera tantos comentarios y eligiera lo constructivo para aceptarlo. Se nota que es una persona de mente abierta.

[savvykang]

Los comentarios constructivos también son realmente excelentes.

[xguru]

Este es un resumen de un comentario de 500 caracteres en lobster.rs incluido en el artículo.
Este comentario fue escrito sobre el post original Why Not Open Source ?.

• Para empezar por la conclusión: no confundan el “open source” / “software libre” con el modelo social específico de GitHub de las contribuciones espontáneas, ni con las contribuciones en sí
• Es difícil estar de acuerdo con la explicación de por qué el open source no funciona
• Muchos de los puntos presentados son falsos dilemas. Por ejemplo: “agregar funciones es difícil en la práctica y muchas veces es más rápido que el mantenedor lo implemente directamente”
• Si es código cerrado, siempre tienes que hacerlo tú mismo, pero incluso si es open source también puedes elegir hacerlo así. No hay obligación de aceptar contribuciones de otras personas

Refutación de cada punto

Posibilidad de agregar funciones - 🟥 En la práctica es difícil

• No es necesario aceptar todo lo que cualquiera envíe para que sea open source

Mayor transparencia - 🟧 No se necesita que sea open source para tener transparencia. También se puede lograr con un roadmap público, además del código

• Es un buen punto. Pero no se trata solo de tener código, sino de tener también el código disponible. Puedes tener código transparente y roadmap transparente

Mejoraría la seguridad - 🟧 Depende del caso. Los usuarios pueden auditar el código de un proyecto open source y publicar los problemas

• Incluso si se vuelve open source, no empeora. Puede que no mejore mucho, pero al menos no tiene desventajas

La comunidad crecerá - 🟧 Solo es posible si se invierte esfuerzo. No es algo exclusivo del open source

• De nuevo, no empeora, aunque también reconozco que el autor admite que no está muy relacionado

Refutación de las desventajas

Es difícil lidiar con feedback grosero

• También recibirás feedback si es código cerrado. En cualquiera de los dos casos, no estás obligado a aceptarlo

Es difícil gestionar ciclos largos de feedback

• Simplemente no aceptes envíos de feedback/cambios. Así desaparece el ciclo de mejoras

Es difícil rechazar contribuciones enviadas sin aprobación

• Basta con poner en el readme “no se aceptan contribuciones” y cerrar automáticamente todos los PR

Cuando el proyecto madura, es difícil rechazar la mayoría

• Incluso si es código cerrado, los usuarios seguirán haciendo solicitudes

Es difícil si un buen contribuidor se va

• Basta con no aceptar a otros contribuidores. No hay diferencia entre open source y código cerrado

Es difícil aceptar que la gente trabaja sin paga

• El software libre no significa necesariamente gratis. También puede existir software libre comercial, y no tienes que aceptar que otros trabajen sin paga

No se ve bien tener más de 1000 issues sin resolver

• Se pueden cerrar automáticamente

Lo difícil es que no tiene fin

• Tener usuarios/clientes en código cerrado es exactamente lo mismo