Cuando los proyectos de “open core” rechazan contribuciones por competir con la EE
Un proyecto de cliente API de open core desató controversia después de que los mantenedores rechazaran un pull request de la comunidad que añadía compatibilidad con SSO/SAML, dejando esa capacidad para su edición empresarial de pago. Los comentaristas debaten si esta es una forma razonable de que las empresas financien el desarrollo continuo o un ejemplo de usar el “código abierto” principalmente como marketing mientras se retienen funciones esenciales de autohospedaje y seguridad. El intercambio pone de relieve tensiones más amplias sobre las expectativas de los contribuyentes, las responsabilidades de los mantenedores, el “impuesto SSO” y cuándo hacer un fork es el único recurso real para los usuarios descontentos.
Contexto del proyecto y evento desencadenante
- La discusión se centra en un proyecto de “open core” que rechazó un importante PR de la comunidad que añadía compatibilidad con SSO/SAML/OIDC, solapándose con su Enterprise Edition (EE).
- El PR estuvo meses sin apenas respuesta por parte de los mantenedores y luego se cerró con razones de negocio/“visión”, y además se bloqueó el hilo, algo que muchos consideraron una falta de respeto.
Modelo open core frente a código abierto real
- Algunos sostienen que esto ilustra cómo “open core” a menudo significa publicar deliberadamente una versión gratuita peor para preservar la monetización.
- Otros responden que, sin funciones de pago, quizá no existiría ningún proyecto; la segmentación en la EE se ve como necesaria para la sostenibilidad.
- Varios comentaristas subrayan que el proyecto está bajo licencia MIT, así que es realmente código abierto en términos legales, independientemente de su modelo de negocio.
SSO/“impuesto SSO” y seguridad
- Muchos critican poner SSO tras un muro de pago, llamándolo un “impuesto SSO” y argumentando que las funciones de seguridad no deberían monetizarse.
- Contraargumento: se presenta SSO como una necesidad empresarial, no un requisito de seguridad central para individuos, por lo que constituye un discriminador de precio natural.
- Algunos autohospedadores sostienen que SSO es esencial incluso en configuraciones pequeñas para obtener 2FA/WebAuthn robustos y una gestión centralizada de cuentas.
Contribuciones, derecho percibido y responsabilidades de los mantenedores
- Un sector ve el esfuerzo del contribuyente como generoso y el rechazo (tras un largo silencio) como desmoralizador y mal comunicado.
- Otro sector enfatiza que los mantenedores no le deben nada a los contribuyentes: los PR son responsabilidades, no derechos, y los cambios grandes deberían discutirse primero.
- Debate sobre el “derecho percibido”: ¿esperar comunicación básica y respuestas no hostiles es razonable, o ya es demasiado pedir a mantenedores que trabajan gratis?
Forking y límites prácticos
- Muchos señalan que hacer un fork es el mecanismo de seguridad previsto: el código es MIT, cualquiera puede implementar y mantener las funciones rechazadas.
- Otros destacan el coste real: rebases continuos, resolución de conflictos, lanzamientos separados y gestión de bugs en código divergente.
Conclusiones más amplias sobre open core
- Se considera que open core es intrínsecamente un modelo lleno de tensiones: la comunidad quiere el “mejor OSS posible”; las empresas deben retener deliberadamente parte del valor.
- Algunos concluyen que evitarán productos open core / “autohospedables” respaldados por una empresa, o al menos los tratarán con sospecha.