Why Open Source Your Product? The Strategic Case

HashiCorp relicensed Terraform under the Business Source License on August 10, 2023. Fifteen days later, a fork was announced. On September 20 the Linux Foundation took it in and gave it a name: OpenTofu. Six weeks from license change to a foundation-backed competitor, built out of HashiCorp's own code and staffed partly by people who used to be its loudest advocates.

That's the ugliest example and the cleanest evidence for the argument that follows. Open sourcing is a distribution and trust decision. It has mechanics, running costs, and a ratchet: cheap to do, brutally expensive to undo. Almost everything written about it argues ethics instead. Legitimate argument. No help at all when you're deciding what to do on a Tuesday afternoon.

So, economics only. And the conclusion up front, because it's the unpopular half: for most products, the answer is no.

A repo is a distribution channel, and a narrow one

The strongest argument for going open is that developers find software by reading code, not by clicking ads. A README that solves your problem in the first screenful converts better than any landing page, because it's proof rather than a claim. Supabase, Plausible, and shadcn/ui grew through developers finding their repos, not through paid acquisition. The repo was the marketing asset, which is why "open source as go-to-market" became a category.

It's also survivorship bias with a bow on it. GitHub's 2025 Octoverse counts 630 million repositories, 395 million of them public and up 19% year over year, and attention piles into a thin slice at the top. Publishing your source doesn't put you in front of anyone; it puts you in a directory. The projects that turned repos into distribution had a second thing going: a developer audience already hunting for that exact tool.

Which gives you the first real test, and it isn't philosophical. Does your buyer read code? If the person who decides to adopt your product will plausibly open your source before installing, the repo is a sales asset. If that person is a marketing lead, a compliance officer, or somebody's dad, it's a filing cabinet nobody will ever open.

You can answer that from data you already have. Installs from search or an LLM recommendation are a different population from installs via Hacker News, a developer subreddit, or somebody's dotfiles. Cheapest instrument: put a GitHub link in the footer and measure the click-through. Fractions of a percent means the repo would be a badge, not a channel.

Trust is the argument that actually holds up

The distribution case is oversold. The trust case is not, and it gets stronger the deeper your software reaches into someone's data.

uBlock Origin sees every request your browser makes. Bitwarden holds your entire credential set. Both are open source, and in both cases that's load-bearing — not because most users read the code, but because someone does, and the maintainers know it. A team that knows any shortcut will show up in a public diff takes fewer shortcuts. People file that under "transparency builds trust." It's closer to a standing threat of review.

Bitwarden hit exactly this in October 2024. A new sdk-internal dependency shipped under a license clause forbidding its use with anything other than Bitwarden, which made the client unbuildable from purely free-licensed sources. The community noticed within days. By November 4, Bitwarden had relicensed sdk-internal under GPLv3 and restructured the packaging so the apps build cleanly. Only sdk-internal moved: the original repo was renamed sdk-secrets and kept its proprietary Bitwarden SDK License. That's the loop working, unglamorously: enough eyes on a dependency list that a bad decision got expensive in about a month.

The commercial version is procurement. Enterprise security review is a queue that moves faster when the reviewer can read the thing, so source-available (code visible, rights restricted) often cuts a review from months to weeks. That's why plenty of companies publish source with no intention of letting anyone fork it. It also kills the "what happens when you shut down" objection, a genuine deal-loser for a solo-founder product. A permissive license is credible escrow that costs nothing to set up.

Before assuming that applies to you, separate a blocking objection from a preference. A blocking objection names a capability, a data type, and a refusal. "It reads every page I'm logged into, so it's not going on my work laptop" is blocking. "Would be nice if it were open source" is a preference wearing the same clothes. The blocking kind leaves traces: one-star reviews about permissions, line 14 of a security questionnaire. If you can't quote one from somewhere it cost you an install or a deal, trust isn't your blocker, and publishing source won't move the number.

Commoditize the layer under your competitor

The last argument for is Joel Spolsky's, from Strategy Letter V in 2002: demand for your product rises as the price of its complements falls, so smart companies commoditize their complements. Open sourcing is the fastest way to drive a complement's price to zero.

Facebook open-sourced React in May 2013 (under BSD+Patents until the September 2017 MIT relicense) and made front-end framework expertise abundant, worth far more to it than any license fee. Google released Kubernetes in June 2014 and gave it to the CNCF a year later, making container orchestration free infrastructure that runs anywhere, Google Cloud included. Neither was charity. Both made a complement free and left the money somewhere else.

The indie version is identically shaped. If a competitor charges for the thing your users need alongside your product, giving it away is a competitive act. The related payoff is work you didn't fund: adapters and plugins other people build because your interfaces are readable.

What it actually costs

Now the half most posts skip, and the reason the default answer is no.

Open sourcing isn't free marketing. It's a second product with a second support surface and no revenue attached. Every issue filed is a decision you make in public. Every pull request is either a review you owe someone or a relationship you damage by ignoring it. And a neglected public repo is worse for your credibility than no repo: dated evidence that you stopped caring.

It also slows shipping, structurally. The moment your internals are public, they become an API. Someone will depend on the module boundary you were about to move, or the function you exported by accident. Every refactor now carries a compatibility question, and the ones you resolve in favor of speed generate issues. Closed source lets you rip out a subsystem on a Wednesday and tell nobody. That freedom has cash value when you're small and still finding the shape of the product.

Then there's free-riding, which produced every license fight of the last eight years. If your product can be run as a hosted service, a company with better distribution than yours can run it, sell it, and contribute nothing back. This isn't hypothetical resentment. It's the stated reason MongoDB, Elastic, HashiCorp, and Redis all left their prior open-source licenses: AGPLv3, Apache 2.0, MPL 2.0, and BSD-3-Clause respectively.

You can price the load before you take it on. Every issue takes a read, a reproduction attempt, and a reply: twenty minutes for the trivial ones, an afternoon for the real bugs. Five issues and a pull request a week is unremarkable for a small project, and it's most of a working day, every week, indefinitely. On a two-person team that's a feature a month, taken off the roadmap by people who never asked for it.

The ratchet: what going back costs

MongoDB moved Community Server to the SSPL for releases on or after October 16, 2018, submitted the license to the OSI, then withdrew the submission in 2019; SSPL has never been OSI-approved. Elastic followed on January 14, 2021, dual-licensing Elasticsearch and Kibana under SSPL and Elastic License v1. AWS announced its intent to fork a week later, on January 21; ELv2 arrived February 3, shipping with 7.11, and OpenSearch shipped April 12, forked from Elasticsearch 7.10.2. HashiCorp went BSL in August 2023 and got OpenTofu. Redis went dual RSALv2/SSPL on March 20, 2024; eight days later AWS, Google Cloud, Oracle, Ericsson, and Snap were backing a Linux Foundation fork called Valkey.

Two of them walked it back. Elastic added AGPLv3 as a license option in August 2024; Redis added AGPLv3 in Redis 8.0 in May 2025. Both forks are still going. That's the ratchet in one sentence: the fork you trigger by leaving doesn't disappear when you come back.

Sentry took the more honest route: it published the Functional Source License in November 2023, a delayed-open license that converts to Apache 2.0 or MIT after two years, then helped launch Fair Source as a named category instead of pretending it was open source. Starting there is cheap. Retreating there is not.

The decision framework

Six questions, in the order that resolves the decision fastest. If the first two both come back negative, you can stop reading.

1. Does your buyer read code? Not "are your users technical," but does the person who makes the adoption decision plausibly open your source before installing? Developer tools, CLIs, libraries, and self-hosted infrastructure clear this bar. Consumer apps almost never do.

2. Is trust the thing blocking adoption? A user who'd like transparency is not the same as a user who won't install because they can't verify what you do with their data. If you can quote that objection in a real person's words, this is a yes. Password managers, content blockers, VPNs, and browser extensions live here.

3. Is the code your moat? Be brutal here. If a competent engineer could rebuild your core in a month, the code was never the moat and publishing it costs little. If the moat genuinely is an algorithm, a model, or years of accumulated implementation detail, don't publish it. Most moats are data, distribution, brand, or operations, and none of those leak through a repo.

4. Can you monetize a complement? Open source is a business model only when something adjacent is sellable: hosting, support, a managed control plane, an enterprise tier gated on SSO and audit logs. If the product is the value and there's nothing adjacent, you've published your only asset.

5. Do you have the capacity? Community maintenance is a recurring job, not a launch task. Budget hours per week. If you can't name the hours, the answer is no.

6. Which threat are you defending against? That determines the license, and it's the question people answer with ideology instead of a threat model.

MIT maximizes adoption and defends nothing. AGPL is the strongest genuinely open-source defense against hosted free-riding, but know its ceiling: MongoDB was already on AGPLv3 when it moved to SSPL, because forcing a competitor to disclose source doesn't stop it reselling your software as a service. AGPL is also the license most enterprise legal departments reject on sight, so it costs deals. BSL and FSL are not open source, and calling them that is the fastest way to lose the audience you adopted them to attract.

The extension paradox: open source proves less than you think

Browser extensions are the sharpest test of the trust argument, and question two comes back a loud yes for the whole category.

An extension with broad host permissions can read every page a user visits. That's a rational trust barrier, so the obvious move is to publish the source and let people verify. Except verification doesn't work the way people assume.

What runs in your browser is the package uploaded to the Chrome Web Store. Not the repo. Nothing in the review process binds one to the other. Chrome's code readability policy bans obfuscation and requires that functionality not be concealed, but it explicitly permits minification and does not require you to submit unminified source. Firefox is stricter: AMO requires source-code submission with build instructions whenever the shipped code is transpiled or minified. Chrome has no equivalent rule.

So an open-source extension is a promise about a repository and a hope about a build. The Great Suspender was open source its entire life; its original developer sold it in June 2020, and that October version 7.1.8 shipped to the Web Store with code that tracked users and ran scripts fetched from a remote server. None of it was ever published to the GitHub repo, which sat at the last clean release while more than two million people ran something else. Google removed the extension in February 2021. Everyone who had "checked that it was open source" had checked the wrong artifact.

What would close the gap is reproducible builds: publish the exact toolchain and commit, let anyone rebuild the package and compare hashes against the store version. That's the guarantee people think open source gives them, and almost nobody in the extension world ships it, because it means pinning your whole build environment and treating byte-identical output as a release requirement.

So the honest framing is narrower than "open source means safe." A public repo gives a reviewable design, a permissions rationale anyone can check against the manifest, and a maintainer working under observation. It does not guarantee the bytes Chrome installed, and that caps the payoff on the strongest argument for opening a product in this category.

Which is where the framework lands for most commercial products: don't. Not as a hedge. As the default the evidence supports.

Three conditions flip it. The buyer and the installer are the same engineer, so the repo is the sales page. A blocking trust objection exists in words you can quote, and readable source answers it. Something adjacent is sellable, so giving the code away prices a complement instead of your only asset. Any two of those is a yes. Two vetoes sit above all of it: if the code genuinely is the moat, keep it; if you can't name the hours per week, you aren't opening a repo, you're abandoning one in public.

The strongest argument against everything above

The strongest objection to this entire framework: it treats open source as a lever you pull for return, and the people who built the most durable software communities didn't think that way at all. Linux, Postgres, curl, and SQLite weren't go-to-market strategies. They were built by people who wanted the software to exist and outlive them, and the compounding trust that produced took decades no ROI model would have justified in year one. Reasoning about it purely as economics probably undervalues the thing, the same way economics undervalues writing documentation or answering forum questions at 11pm.

That objection is correct, and the strategic frame is still the right one for a commercial product, because the alternative is making an irreversible business decision on vibes and calling it principle. If you go open for reasons a spreadsheet can't hold, say so plainly. That's a better answer than a bad growth thesis.

Caveats

• This analysis draws on public cases, relicensing post-mortems, and vendor documentation, not on running a large open-source project. The cost section reflects how maintainers describe the load, not a first-hand accounting.
• License mechanics are jurisdiction- and fact-specific. BSL's change date, FSL's two-year conversion, and AGPL's network clause all have legal texture this summary flattens. Get a lawyer before relicensing anything with revenue attached.
• The relicensing timeline covers the four best-documented cases. Others (Grafana, MinIO, Akka) went differently, and four data points don't make a law.
• Store policies change. The Chrome-versus-Firefox asymmetry on source submission is accurate as of August 2026; check the current program policies before relying on it.