This week, scheduling platform Cal.com announced it was transitioning to a closed-source model — the latest in a string of well-loved open-source projects pulling up the drawbridge. HashiCorp’s BUSL move with Terraform. Redis re-licensing. Elastic’s SSPL. MongoDB’s path before that. The pattern is now so familiar it has its own genre of post-mortem blog posts and angry Hacker News threads.
For your engineering team, every one of these announcements is a small budget meeting in disguise. A library you adopted because it was free, permissively licensed, and community-driven is suddenly a vendor relationship — sometimes with a price tag, sometimes with a forced migration, sometimes with both. If your stack is a stack of cards, the next pivot can be the one that knocks it over.
Here’s how to think about open-source dependency risk in 2026, what to actually do about it, and where the real trade-offs sit.
TL;DR
- Open-source-to-closed-source pivots are no longer rare events — Cal.com, HashiCorp, Redis, Elastic and others have all changed terms in the last few years, and the trend is accelerating.
- The risk isn’t ideological; it’s operational. A licence change can force unplanned migrations, kill commercial use cases, or push you toward a vendor’s hosted product.
- Permissive licences (MIT, Apache 2.0, BSD) are far harder to revoke than copyleft or “source-available” arrangements — but governance and funding model matter more than the licence text.
- Vet new dependencies on five axes: licence, governance, funding, fork-ability, and your own switching cost.
- Build optionality into your architecture: abstraction layers, infrastructure-as-code, and dependency budgets are cheaper than panic migrations.
Why the pivots keep happening
The economics of open source have always been awkward. A small team builds something brilliant, the world adopts it, AWS or another hyperscaler wraps it in a managed service, and the original maintainers watch their addressable market evaporate. The Business Source Licence (BUSL), the Server Side Public Licence (SSPL), and the Functional Source Licence (FSL) are all attempts to solve this — by making it legally awkward for cloud providers to compete with the original creators.
That’s a defensible commercial position. It’s also a problem if you’re a paying customer or a downstream user, because the moment a project moves from “open” to “source-available”, three things change at once:
- Your legal team has to re-review. SSPL and BUSL terms are not OSI-approved. Your compliance posture might shift overnight.
- Forks fragment the ecosystem. OpenTofu (after Terraform), Valkey (after Redis), and OpenSearch (after Elastic) are all consequences. Picking the right fork becomes a strategic decision, not a developer preference.
- The roadmap belongs to one company again. The features you wanted may now be enterprise-tier. The bug you reported last quarter may not get fixed unless you’re paying.
Cal.com is a particularly interesting case because the project has long marketed itself as the “open-source Calendly”. A licence pivot doesn’t just change the terms — it changes the value proposition that drove adoption in the first place.
The five-axis dependency check
Before you adopt a new open-source project — especially one that sits on the critical path of your product — run it through five questions. Treat each as red, amber, or green.
1. Licence
Permissive licences (MIT, Apache 2.0, BSD-3) are the gold standard. Once code is published under them, that release is permanent. New versions can be re-licensed, but you can always fork from the last permissive commit. Copyleft (GPL, AGPL) restricts how you can combine code but is still genuinely open. Source-available licences (BUSL, SSPL, FSL, Elastic Licence v2) are the warning sign — they sit somewhere between open source and proprietary, and the terms are written by the vendor.
2. Governance
Who actually decides what gets merged? A project owned by a single company can pivot whenever the board says so. A project under a foundation — Apache, Linux Foundation, CNCF, Eclipse — has institutional brakes that make pivots much harder. Kubernetes won’t go closed-source. Postgres won’t go closed-source. Cal.com could.
3. Funding model
If the project’s revenue depends on selling enterprise add-ons, expect a fairly stable open core. If it depends on a hosted product competing with hyperscaler clones, expect licensing pressure. If it depends entirely on VC funding without a clear revenue model, expect a pivot the moment the runway gets short.
4. Fork health
Is there a credible fork already, or could one realistically emerge? OpenTofu materialised in weeks because the contributor base was broad and motivated. A small project with one or two committers has effectively no fork insurance.
5. Your switching cost
This is the one teams forget. A library you imported in three files is trivially replaceable. A workflow engine wired into half your microservices is not. The deeper a dependency goes into your architecture, the more weight the first four axes carry.
Designing for optionality, not paranoia
The point of all this isn’t to avoid open source — that would be absurd in 2026. The point is to architect for the real possibility that any given dependency might pivot, slow down, or fork in two.
A few practical patterns we use on client projects:
- Thin abstraction layers around critical dependencies. A workflow engine, a feature flag system, a cache layer — wrap them in your own interface so swapping providers is a refactor, not a rewrite.
- Treat managed services as commercial dependencies. If you use Redis Cloud, Confluent, or Vercel, you have a vendor relationship even if the underlying tech is “open”. Price that in.
- Pin and mirror. For self-hosted dependencies, mirror the upstream artifacts you depend on. If a project disappears overnight, your CI doesn’t disappear with it.
- Maintain a dependency budget. A simple register — what depends on what, criticality, last security audit, licence — costs almost nothing to maintain and pays for itself the first time a CVE drops.
- Watch the leading indicators. Licence changes rarely come without warning: contributor disputes, founders leaving, “transparency” blog posts about sustainability, hyperscaler-versus-vendor sniping. Pay attention.
What this means for your tech stack decisions
Three patterns we’ve seen repeatedly across client work in the last twelve months:
Greenfield SaaS teams. Default to dependencies governed by foundations or backed by well-capitalised commercial open source companies with mature open-core models. Be cautious with brilliant-but-young projects on permissive licences with a single corporate sponsor — the licence may be safe, but the project may not be.
Established teams on shifting stacks. If you’re on Terraform, Redis, or Elastic, you almost certainly already have a migration option (OpenTofu, Valkey, OpenSearch). The question is whether to migrate proactively or wait for a forcing event. Doing it during a quiet quarter is dramatically cheaper than during an incident.
Agencies and consultancies. If you build for clients, your dependency choices become their dependency choices for years. A little extra rigour in vetting upfront saves a lot of awkward conversations later.
The deeper signal
The Cal.com pivot, like the others, is a reminder that “open source” describes a licence, not a guarantee. The software industry has spent twenty years assuming open source meant durable, free, and permanent. In 2026, that assumption needs to be replaced with something more grown-up: open source as a licence regime that varies by project, with risk that has to be priced in like any other vendor relationship.
None of this is an argument against open source. We use it everywhere. We contribute to it. We build with it. But we vet it the same way we’d vet a SaaS contract — because the costs of getting it wrong have stopped being theoretical.
Need help auditing your stack?
At REPTILEHAUS, we help teams across Dublin and beyond design resilient, well-architected systems — from greenfield SaaS builds to migrations away from vendor-locked dependencies. If you’re not sure where your stack’s pivot risk sits, or you want a second opinion before betting your roadmap on a particular open-core platform, get in touch. Our team specialises in development, DevOps, AI, and Web3 — and we’ve seen the inside of enough licensing migrations to spot the patterns early.
Photo by Bernd Dittrich on Unsplash
