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

Original Article ↗ Hacker News Discussion ↗

An open-core API client project sparked controversy after maintainers rejected a community pull request adding SSO/SAML support, instead keeping that capability for their paid enterprise edition. Commenters debate whether this is a reasonable way for companies to fund ongoing development or an example of using “open source” primarily as marketing while withholding essential self-hosting and security features. The exchange highlights broader tensions around contributor expectations, maintainer responsibilities, the “SSO tax,” and when forking is the only meaningful recourse for dissatisfied users.

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.