Ask HN: Founders who offer free/OS and paid SaaS, how do you manage your code?

Hacker News Discussion ↗

Founders offering both self-hosted open source and paid SaaS versions of their products are converging on a few patterns: single monorepos with feature flags or environment variables, plugin architectures, and “core vs. extensions” designs. Many argue that keeping one codebase and gating enterprise features via licenses or plugins is far easier to maintain than split repos, even if it’s theoretically easy to bypass restrictions. Licensing choices (AGPL, ELv2, BUSL, SSPL, “Fair Source”) and concerns about long‑term customer freedom, IP protection, and avoiding code churn are central trade-offs in how they structure and ship their products.

Codebase Strategies

  • Strong preference from many for a single codebase for free + paid, with feature gating via:
    • Environment variables (e.g., EDITION, MODE, SELF_HOSTED).
    • SKU-aware services or dependency injection (different implementations per plan).
    • License-key checks for “enterprise” features.
  • Arguments for single codebase:
    • Avoids divergence, duplicated bugfixing, and slow paid releases.
    • Simpler mental model and easier continuous deployment.
  • Alternatives mentioned:
    • Private fork that imports the public repo and adds billing/enterprise logic.
    • Git submodules or private repos with OSS as a subfolder, synced out with custom tooling.
  • Several posters warn that separate codebases or complex submodule setups cause CI pain and support friction.

Plugin and Extension Models

  • Common pattern: open-source core + plugin architecture.
    • Core is stable and mostly OSS; SaaS adds many plugins, some proprietary.
    • Plugins selected/auto-installed based on app, tier, and user role; lifecycle hooks manage DB metadata, menus, etc.
  • Seen as making private/enterprise forks more maintainable and configurable.

Licensing Approaches

  • Mix of licenses: Apache/MIT cores, ELv2, BUSL, SSPL, AGPLv3, and “fair source”/non-compete style.
  • ELv2 highlighted for:
    • Allowing monorepo with license-gated EE features.
    • Prohibiting removal/circumvention of license checks.
  • AGPL used explicitly to:
    • Ensure user freedoms and force commercial users to contribute or buy enterprise licenses.
    • Some argue AGPL hinders adoption in IP-sensitive companies.

Handling Self‑Hosting vs SaaS

  • Typical model: same app, different env flags for:
    • Billing, multi-tenant vs single-tenant, branding, supporter badges, and marketing footer.
  • Many keep SaaS dashboards or orchestration layers proprietary while open-sourcing “nuts and bolts” components.

Concerns: Piracy, Complexity, and Openness

  • Most agree determined users can bypass checks, but:
    • B2B customers rarely risk license violations.
    • Self-maintaining a fork is costly and unattractive for serious users.
  • Some criticize mixing OSS and proprietary code in one repo if:
    • License boundaries are fuzzy.
    • Building an OSS-only version is non-trivial.
  • A few question whether to open source at all unless an ecosystem is strategically crucial.