Cuando los proyectos de “open core” rechazan contribuciones por competir con la EE

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.