Quando projetos de “open core” rejeitam contribuições por competirem com a EE

Contexto do projeto e evento desencadeador

• A discussão gira em torno de um projeto de “open core” que rejeitou um grande PR da comunidade que adicionava suporte a SSO/SAML/OIDC, sobrepondo-se à sua Enterprise Edition (EE).
• O PR ficou parado por meses com pouca ou nenhuma resposta dos mantenedores e, então, foi encerrado com argumentos de negócio/“visão”, e a thread foi bloqueada, o que muitos acharam desrespeitoso.

Modelo open core vs. open source de verdade

• Alguns argumentam que isso ilustra como “open core” muitas vezes significa lançar deliberadamente uma versão gratuita pior para preservar a monetização.
• Outros respondem que, sem recursos pagos, talvez o projeto nem existisse; a restrição na EE é vista como necessária para a sustentabilidade.
• Vários კომენტadores enfatizam que o projeto tem licença MIT, então é genuinamente open source do ponto de vista legal, independentemente do modelo de negócio.

SSO/“SSO tax” e segurança

• Muitos criticam colocar SSO atrás de um paywall, chamando isso de “SSO tax” e argumentando que recursos de segurança não deveriam ser monetizados.
• Contra-argumento: SSO é apresentado como uma necessidade empresarial, não um requisito de segurança central para indivíduos, tornando-se um discriminador de preço natural.
• Alguns que fazem self-hosting argumentam que SSO é essencial até para pequenas instalações, para obter 2FA/WebAuthn robusto e gerenciamento centralizado de contas.

Contribuições, senso de direito e responsabilidades dos mantenedores

• Um lado vê o esforço do contribuinte como generoso e a rejeição (após longo silêncio) como desmotivadora e mal comunicada.
• Outro lado enfatiza que os mantenedores não devem nada aos contribuidores: PRs são responsabilidades, não direitos, e mudanças grandes deveriam ser discutidas antes.
• Debate sobre “senso de direito”: esperar comunicação básica e respostas não hostis é razoável, ou isso já é pedir demais de mantenedores voluntários?

Forking e limites práticos

• Muitos observam que fazer fork é a válvula de escape pretendida: o código é MIT, qualquer pessoa pode implementar e manter recursos rejeitados.
• Outros destacam o custo real: rebases contínuos, resolução de conflitos, lançamentos separados e lidar com bugs em código divergente.

Conclusões mais amplas sobre open core

• Open core é visto como inerentemente tenso: a comunidade quer o melhor OSS possível; as empresas precisam reter parte do valor de forma deliberada.
• Alguns concluem que evitarão produtos open core / “self-hostable” apoiados por uma empresa, ou pelo menos os tratarão com desconfiança.