I turned my open-source project into a full-time business

Original Article ↗ Hacker News Discussion ↗

An email tooling project that began as free open source software was relicensed as a paid, source-available product with a simple license-key check, enabling its solo developer to earn a full-time income. Commenters explore why this model works in B2B — most companies prefer paying under $1,000/year over risking license violations or engineering time — and contrast it with the near-impossibility of monetizing “free” tools via donations alone. The thread also surfaces ethical and practical tensions around contributor license agreements, perceived “rug pulls” when projects go proprietary, and whether copyleft licenses like GPL/AGPL better protect maintainers from large companies extracting value without giving back.

Licensing shift & business model

  • Core move: project went from open source (AGPL, though article says LGPL) to source-available with a commercial license and license-key check.
  • This was enabled by requiring CLAs from the start, giving the main maintainer the legal right to relicense.
  • Old AGPL versions remain on GitHub; the closed licensing applies only going forward.
  • Several commenters see this as a rational response to large companies extracting huge value without contributing money, PRs, or even thanks.

Piracy, license enforcement & customer behavior

  • Many note that local license checks are trivial to bypass or patch.
  • Consensus: for B2B, the main deterrents are legal risk, due diligence red flags, and the value of support/updates; most serious customers just pay.
  • For niche dev tools and B2C, piracy would be much higher; some solo devs report few observed pirates even with weak checks.
  • Some argue that pirates who would never have paid anyway don’t represent “lost sales.”

CLAs, contributor rights & “rug pull” concerns

  • CLAs are seen by some as explicitly enabling later “rug pulls” (relicensing to proprietary).
  • Critics argue contributors’ labor is monetized without revenue sharing, even if their share of code is tiny.
  • Others counter that in this case outside contributions were minimal and that any prior open releases stay free and forkable.
  • Several recommend treating “CLA required” as a clear signal that relicensing is likely.

Pricing, enterprise purchasing & billing

  • Sub‑$1k/year flat pricing is repeatedly described as a “sweet spot”: below approval thresholds, easy to justify, far simpler than per‑seat SaaS.
  • Complexity and procurement friction, not price level, often block adoption.
  • Marketplaces (e.g., cloud) and Merchants of Record (Paddle, Lemon Squeezy, FastSpring) are discussed as ways to offload tax/VAT and paperwork; Stripe is common when you can handle taxes.

Open source sustainability, copyleft & motivation

  • Many argue “open source is not a business model”; you must design revenue (support, dual licensing, hosted service, etc.).
  • Experiences of burnout and resentment when unicorns profit from FOSS without giving back are common.
  • Some advocate GPL/AGPL or dual AGPL/proprietary to force “give back or pay,” and criticize MIT/BSD as harmful to authors.
  • Others emphasize that FOSS should be approached with clear non-monetary goals (learning, status, contributing to the commons), or you risk disillusionment.

Source-available & support dynamics

  • Source-available is valued for debugging, security transparency, and the option to self-fix critical issues.
  • Paying users reportedly give more focused, business-driven feedback than free users, who often request speculative “what if” features.
  • Solo-dev support load in this case is described as modest (about an hour a day), helped by the self-hosting competence of customers.