Cal.com announced it is going closed source, and the Hacker News thread erupted with the usual combination of betrayal and told-you-so. The scheduling infrastructure project, long positioned as the open alternative to Calendly, built a substantial community partly on the promise that you could self-host, audit, and contribute to the codebase. That promise is now being retired.
This is not a surprising outcome. It is, at this point, a recognizable pattern.
What Cal.com Actually Was
Cal.com is a scheduling platform, but describing it that way undersells the technical ambition. The project is built on a modern TypeScript stack: Next.js for the frontend and API routes, tRPC for end-to-end type-safe APIs, Prisma as the ORM, and a monorepo architecture that made it one of the more instructive real-world examples of how to structure a large Next.js application. The GitHub repository had over 30,000 stars. The codebase was genuinely useful to read, not just as a product but as a reference architecture.
For developers, the open source nature meant something practical. You could stand up your own instance. You could integrate it into internal tooling. You could read the source when the API documentation was incomplete. These are real affordances that disappear when a project goes closed source, regardless of what the hosted tier offers.
The Pattern Has a Name Now
Cal.com joins a list that grew substantially between 2021 and 2024. Elasticsearch moved from Apache 2.0 to SSPL in 2021, which prompted AWS to fork it as OpenSearch. HashiCorp moved Terraform and Vault to the Business Source License in August 2023, which prompted the OpenTofu fork under the Linux Foundation. Redis moved to RSALv2 and SSPL in March 2024, which led to the Valkey fork that now has backing from AWS, Google, Oracle, and others. Sentry has used BUSL for years. MariaDB tried BSL for MaxScale.
The reasoning in each case follows a similar structure: a large cloud provider (usually AWS) is running the software as a managed service, capturing the commercial value, and contributing relatively little back. The company that built the software cannot compete on distribution with a hyperscaler. The open source license that made the software widely adopted is also what makes it impossible to stop this from happening.
The Cal.com announcement almost certainly makes a version of this argument. The scheduling space has enough enterprise interest that a well-resourced competitor could theoretically package and sell Cal.com’s own infrastructure against it.
The Fundamental Tension in VC-Backed Open Source
Here is what makes this pattern so predictable: venture capital and permissive open source licensing have structurally incompatible endgames.
VC-backed companies need to grow into their valuations. Open source licensing, especially Apache 2.0 or MIT, deliberately removes the friction that would otherwise make that growth exclusive. The company trades exclusivity for distribution: you get a large community, fast adoption, organic word-of-mouth, a hiring brand, and a contributor base. Those are real benefits. But the implicit contract with the community is that the software remains open.
When growth pressures mount and the community’s usage does not convert to revenue at the rate investors expect, the license becomes the obvious lever to pull. It is the fastest way to put a wall around commercial value without rebuilding the product from scratch.
The projects that navigate this well tend to be ones where the open source component and the commercial product are clearly separated from the start. Grafana Labs maintains the core Grafana under AGPL but charges for managed hosting, enterprise plugins, and support. GitLab keeps its community edition genuinely open while selling enterprise features. The key is that the boundary between free and paid is drawn at the feature level, not the license level. When you change the license, you are telling your community that the original deal was always provisional.
What Closed Source Means Practically
For most users of a hosted scheduling service, the license change means nothing immediately visible. The product still works. The API still responds. Your calendar links still route correctly.
For the self-hosting community, it means something more significant. Existing self-hosted installations continue to run on whatever version was the last open release, but they stop receiving upstream security patches, new features, and compatibility fixes. The longer you run a frozen version of any web-facing application, the worse your security posture gets. You are either forced onto the hosted tier or you are maintaining a fork of a codebase that will gradually diverge from the upstream commercial product.
For developers who were building integrations and tooling on top of the open source codebase, the calculation changes. Without source access, you are back to treating it as a black box, which means depending entirely on whatever API surface the company decides to document and maintain.
Forks Are the Honest Answer
The constructive response to this kind of relicensing is a fork, and the track record of community forks in this space is actually reasonably good when there is institutional backing.
Valkey is the strongest recent example. Within weeks of the Redis relicensing announcement, Valkey had commits from Amazon, Google, Ericsson, and Oracle engineers. It was accepted into the Linux Foundation. By mid-2024 it had already achieved near-parity with Redis 7.2 for most use cases, and several major Linux distributions switched their default Redis package to Valkey. OpenSearch followed a similar trajectory, with AWS funding substantial development and the project becoming genuinely competitive with Elasticsearch for many workloads.
The scheduling space does not have the same concentration of hyperscaler interest as databases and infrastructure tooling. A Cal.com fork would need either a well-funded company to back it or an unusually active community. The last open source version of the codebase is the natural starting point; whether anyone picks it up in a sustained way remains to be seen.
The Lesson That Keeps Not Being Learned
What is frustrating about this pattern is not that companies make the decision to close their source. Running a software business is hard, and the economic pressures are real. What is frustrating is the framing that usually accompanies it.
The announcement posts typically describe the change as a necessary step to ensure the project’s long-term sustainability, as if the community that built around the open source version should be grateful that the company is surviving at all. This gets the relationship backwards. The community’s contributions, advocacy, and labor are part of what built the company’s valuation in the first place. Treating open source as a growth hack and then revoking it when the economics shift is not a neutral business decision. It is a specific kind of trust withdrawal.
This does not mean companies should stay open source to the point of bankruptcy. It means the framing matters, and the tech industry would be better served by founders who are honest from the start about what their open source commitment actually covers. A project that says “we are open source until we need to monetize more aggressively” is a different thing than one that positions itself as the open alternative to proprietary incumbents.
Cal.com spent years building community equity on the second framing. The announcement is the first framing, arriving late.
Where This Leaves the Ecosystem
For developers evaluating scheduling infrastructure today, the lesson is operational: treat the open source status of any VC-backed project as a current snapshot, not a guarantee. If your architecture depends on the ability to self-host, audit, or fork a piece of software, verify that the license explicitly permits it and factor in what happens when it changes.
AGPL is more protective than MIT or Apache 2.0 for networked software precisely because it requires derivative works served over a network to also be open source. It is not a perfect shield against relicensing, but it does make the transition harder and the community’s rights more explicit. Projects like Gitea, Authentik, and Plane have chosen it for this reason.
The BSL and SSPL licenses occupy a middle ground: they look like open source but are explicitly not approved by the Open Source Initiative. They give companies more control while maintaining the appearance of openness. When a project moves to one of these from a permissive license, it is worth being precise about what changed: the code may still be readable, but the freedoms that define open source are gone.
Cal.com’s move is the latest data point in a long argument about whether venture capital and genuine open source are compatible at scale. The evidence is accumulating that for most companies in most markets, they are not, and the community that gets built on the open source promise is the one that pays the cost when the economics resolve.