The announcement from the Cal.com team adds another name to a list that has grown steadily since MongoDB invented the Server Side Public License in 2018: commercial open-source projects that tried open source as a growth strategy and concluded it was not working. But Cal.com’s situation differs from the HashiCorp and Redis cases that get cited in these discussions, because the competitive dynamics are different in kind, not just degree.
What Cal.com Was Trying to Do With AGPL
Cal.com, formerly Calendso, built an open-source scheduling platform to compete with Calendly, HubSpot Meetings, and enterprise scheduling infrastructure. The codebase runs on Next.js, Prisma, tRPC, and PostgreSQL, and the GitHub repository accumulated tens of thousands of stars, making it one of the more prominent self-hosting-first SaaS alternatives of the early 2020s. The company raised a $25 million Series A in 2022 with the intent of building a sustainable commercial product on top of the open codebase.
The choice of AGPLv3 for a SaaS competitor is deliberate. The GNU Affero General Public License differs from the standard GPL in one critical respect: network use counts as distribution. Under the GPL, a company can run modified GPL software as a web service without releasing those modifications, which is precisely what cloud providers do when they host open-source databases as managed offerings. AGPL closes that loophole. Modify AGPL code and deploy it as a service, and you must publish those modifications.
For database and infrastructure tooling, this matters. The AGPL, or its conceptual equivalents in the SSPL and BSL, was designed to make cloud-provider free-riding legally costly. The original maintainer captures some of the value that would otherwise flow entirely to a managed service provider.
The Problem: Scheduling Competitors Do Not Need the Code
The threat model AGPL addresses is a cloud provider forking your code and running it as a managed service. That threat is concrete for Redis, Elasticsearch, Vault, and PostgreSQL. It is mostly theoretical for a scheduling SaaS product.
Calendly does not need Cal.com’s codebase. Google Calendar’s booking features do not need Cal.com’s codebase. Microsoft Bookings, HubSpot’s meeting scheduler, and Notion Calendar do not need Cal.com’s codebase. These competitors built their own implementations using their own engineering teams, because scheduling logic is not so complex that forking an existing implementation offers a meaningful advantage over building from scratch with full control. The AGPL prevents competing cloud deployments of Cal.com’s exact codebase. It does nothing to prevent competitors from writing their own scheduling logic, integrating with the same calendar APIs, and offering a functionally identical product.
This is the asymmetry that separates Cal.com’s situation from the infrastructure database cases. MongoDB’s SSPL was designed to prevent cloud providers from running MongoDB as a managed service. AWS’s response was DocumentDB: a MongoDB wire-protocol-compatible database built independently rather than forked from MongoDB’s code. The license barrier was circumvented not by violating it but by not needing the code in the first place. Cal.com faces the DocumentDB problem across its entire competitive landscape, and no license addresses it.
The Comparison That Keeps Getting Made
The HashiCorp-to-BSL move in August 2023 followed a specific provocation. HashiCorp’s announcement identified cloud providers packaging Terraform as a managed service, capturing revenue without contributing back upstream. The Business Source License they adopted allows continued open-source use while blocking competing managed service providers for a defined period.
The Redis relicensing in March 2024 had an equally specific antagonist. AWS ElastiCache had built an enormous managed Redis business while contributing essentially nothing upstream. Redis Ltd.’s dual license triggered three forks within weeks: Valkey under the Linux Foundation, Redict, and Microsoft’s Garnet. All three restored the BSD license. Valkey’s momentum has arguably surpassed the original project’s in community terms.
Both cases share a structure: the maintainer identified a specific category of free-rider running the original code as a competing service, constructed a legal barrier, and watched the community fork to restore the original terms. The forks succeeded because the code was valuable enough that the community had strong incentives to maintain it independently.
Cal.com’s situation does not map cleanly to this structure. There is no obvious managed Cal.com service built on the codebase that is capturing revenue from enterprise customers who would otherwise pay Cal.com directly. The competitive pressure comes from well-resourced SaaS companies who built from scratch. A license change cannot affect them.
What the AGPL Did Accomplish
The AGPL did accomplish something for Cal.com, though not competitive protection from its main rivals. It built a community. Open-source scheduling software with full self-hosting support attracted developers who wanted calendar infrastructure they could audit and control, enterprise security teams that needed to inspect the code before deployment, and contributors who built integrations with tools the core team had not prioritized.
That community is real, but it is a different asset than competitive moat. The question Cal.com has apparently concluded: does the cost of maintaining a public codebase, including the competitive visibility it gives rivals into product decisions and the engineering overhead of supporting a public API surface alongside a commercial product, justify the community benefits at this stage? The answer they have reached is no.
What Closing the Source Changes
If the shift to closed source is not primarily about blocking specific free-riders, the practical changes are different from the HashiCorp and Redis cases.
Closing the source removes competitive feature visibility. A public repository makes every design decision, integration, and product direction readable before it ships. Competitors, enterprise evaluators, and even journalists can track a project’s direction by watching commit history. A private codebase does not eliminate this entirely, but it removes the clearest signal.
AGPL also creates procurement friction that has nothing to do with Cal.com’s competitors and everything to do with its customers. Enterprise legal teams routinely flag AGPL dependencies the same way they flag GPL dependencies, with concern about whether internal use or modification triggers copyleft obligations downstream. Whether that concern is legally well-founded in a given deployment scenario is often beside the point; it generates delays and sometimes deal failures. A proprietary commercial license with clear terms eliminates that conversation.
The argument for this move is that the open-source distribution advantage for a SaaS product is smaller than assumed at the outset, and the maintenance costs are higher. Community is real, but it does not automatically translate to enterprise revenue sufficient to fund continued development at the pace required to compete with Calendly and Google.
The Community Cost and What Comes Next
The communities that form around open-source SaaS alternatives are not incidental to the project’s growth. People contribute to Cal.com because they want scheduling infrastructure they can trust to remain independent of a vendor’s commercial decisions. Going closed source is precisely the kind of commercial decision they built the self-hosted version to insulate themselves against.
Whether Cal.com ships a self-hosted version under a proprietary license, maintains a community edition with delayed features, or fully withdraws the code from public access matters considerably for those users. The projects that navigated this transition without significant community backlash mostly kept some self-hosting path available, even under commercial terms. The projects that tried to fully gate the self-hosted experience found that the community forked the last open version and maintained it independently.
Cal.com had enough contributors and enough community investment that a maintained fork is plausible if the transition is handled in a way the community perceives as adversarial. The company’s long-term success in the enterprise scheduling market likely depends more on how they handle the existing community than on the specific license terms they choose.
The broader question this raises is about what open source actually accomplishes as a growth strategy for a product-market-fit SaaS company. It works for developer acquisition and early distribution. It generates goodwill and produces integrations. Whether the community benefits translate to enterprise revenue at a scale that justifies the sustained cost of maintaining a public codebase is a question each company has to answer for its specific market. Cal.com has answered it, and the answer tells you more about the limits of the AGPL-as-moat strategy in SaaS than it does about open source as a category.