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

Hacker News Discussion ↗

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.