When 'open core' projects reject contributions for competing with the EE

Original Article ↗ Hacker News Discussion ↗

Project context and triggering event

  • Discussion centers on an “open core” project rejecting a major community PR that added SSO/SAML/OIDC support, overlapping with its Enterprise Edition (EE).
  • The PR sat for months with little or no maintainer response, then was closed with business/”vision” reasoning and the thread locked, which many found disrespectful.

Open core model vs. real open source

  • Some argue this illustrates how “open core” often means intentionally shipping a worse free version to preserve monetization.
  • Others respond that without paid features there might be no project at all; EE gating is seen as necessary for sustainability.
  • Several commenters stress that the project is MIT-licensed, so it is genuinely open source legally, regardless of its business model.

SSO/“SSO tax” and security

  • Many criticize putting SSO behind a paywall, calling it an “SSO tax” and arguing security features should not be monetized.
  • Counterpoint: SSO is framed as an enterprise necessity, not a core security requirement for individuals, making it a natural price discriminator.
  • Some self-hosters argue SSO is essential even for small setups to get robust 2FA/WebAuthn and centralized account management.

Contributions, entitlement, and maintainer responsibilities

  • One camp sees the contributor’s effort as generous and the rejection (after long silence) as demoralizing and poorly communicated.
  • Another camp emphasizes that maintainers owe contributors nothing: PRs are liabilities, not entitlements, and big changes should be discussed first.
  • Debate over “entitlement”: is expecting basic communication and non-hostile responses reasonable, or already too demanding of free maintainers?

Forking and practical limits

  • Many note that forking is the intended safety valve: the code is MIT, anyone can implement and maintain rejected features.
  • Others highlight the real cost: ongoing rebasing, conflict resolution, separate releases, and handling bugs in diverging code.

Broader takeaways about open core

  • Open core is seen as inherently tension-filled: community wants “best possible” OSS; companies must intentionally withhold some value.
  • Some conclude they’ll avoid open core / “self-hostable” products backed by a company, or at least treat them with suspicion.