The Sustainability Wall: What Cal.com's Pivot Tells Us About Open Source Business Models

Cal.com, the open source scheduling platform built as a self-hostable alternative to Calendly, announced it is going closed source. The Hacker News thread accumulated hundreds of comments within hours, split between people feeling betrayed and people shrugging because they saw it coming. Both reactions make sense, and neither is particularly useful for understanding why this keeps happening.

This is not an isolated event. It is the latest instance of a pattern that has been playing out for years across the infrastructure and tooling space, and it points to a structural problem that neither open source advocates nor commercial software vendors have solved.

The Pattern Has a Name Now

The licensing pivot has become common enough that it deserves a taxonomy. There is the full relicense, where a project abandons an open license entirely for a proprietary one. There is the license narrowing, where a project moves from a permissive license like MIT or Apache to a copyleft license like AGPL or the Server Side Public License (SSPL). And there is the source-available model, where code remains readable but usage rights are restricted, typically via the Business Source License (BSL) popularized by MariaDB.

HashiCorp’s 2023 Terraform relicense to BSL triggered enough community backlash to produce OpenTofu, a community fork under the Linux Foundation. Redis changed its license in 2024 to a dual license combining the Redis Source Available License (RSALv2) and SSPL, which prompted AWS, Google, and others to fork the project as Valkey. Elasticsearch made a similar move in 2021, prompting AWS to fork it as OpenSearch.

MongoDB introduced SSPL in 2018 specifically to prevent cloud providers from running MongoDB as a service without contributing back. Akka, the actor framework for the JVM, moved to BSL in 2022. Sentry moved to BSL in 2019. The list is long and it is getting longer.

Cal.com fits this pattern, though its position is slightly different from infrastructure software. A scheduling platform is not typically embedded in cloud provider offerings the way a database or infrastructure tool is. The pressures are real but they manifest differently.

Why Scheduling Is a Hard Business

Cal.com was founded by Peer Richelsen and Bailey Pumfleet and launched around 2021 as an open source Calendly alternative. The value proposition was clear: self-host your scheduling, own your data, integrate with your own infrastructure. The GitHub repository attracted tens of thousands of stars, and the project built a genuine community around it.

The business model, as with most open core companies, depended on a hosted version where the company could monetize the operational burden it was absorbing on behalf of users who did not want to run their own instance. This is not a bad model. It is the model that sustains Plausible Analytics, Posthog (which uses a hybrid approach), Mattermost, GitLab, and many others.

The problem is that scheduling is a saturated market. Calendly has network effects, enterprise relationships, and years of product polish. Google Calendar has scheduling features baked in. Microsoft has FindTime and the broader 365 ecosystem. Notion has its own calendar features now. The self-hosted angle attracts a specific audience, but that audience is also the audience least likely to pay for the hosted version, because they chose to self-host specifically to avoid recurring SaaS fees.

This creates a structural squeeze. The open source version serves the price-sensitive, technically capable users. The commercial version competes against well-funded incumbents for the enterprise market. The community builds features, files issues, and occasionally contributes PRs, but the operational and support costs fall on the company.

The Contributor Problem Is Real

One argument that appears frequently in these licensing debates is that open source contributors are unpaid labor and companies benefit from that labor without adequate reciprocation. This is true in aggregate but misleading as a business argument for any specific project.

For most application-layer open source projects, the contributor base is composed primarily of the company’s own engineers, occasional drive-by fixes from users who hit bugs, and a small number of sustained external contributors. The Bus Factor of most nominally open source company projects is low. The contributions from the community rarely shift the trajectory of the product in meaningful ways, because the roadmap is driven by commercial needs.

This is distinct from something like the Linux kernel, PostgreSQL, or GCC, where the contributor base is genuinely distributed and no single company controls the direction. For those projects, the open source governance model works because the incentives are aligned across many actors. For a VC-backed startup with a specific product vision, open source is more of a distribution and credibility strategy than a genuine governance model.

The honest version of what most open core companies are doing is: use open source to acquire users and build trust, then monetize the subset who need managed hosting, compliance features, or enterprise integrations. When that conversion funnel does not generate sufficient revenue, something has to change.

What Closed Source Actually Solves

Going fully closed source solves a narrow set of problems. It eliminates the possibility of competitors forking and competing directly. It allows the company to monetize features that were previously available for free. It removes the implicit obligation to maintain a public codebase and engage with the community’s expectations.

What it does not solve is the underlying market position problem. If Cal.com was struggling to convert self-hosters into paying customers, that conversion problem does not disappear when the source is closed. Users who chose Cal.com specifically for the self-hosted option will leave. The community that was a marketing asset becomes a source of negative sentiment. The SEO value of being a visible open source project diminishes.

The companies that have navigated this transition successfully, like GitLab, did so by maintaining a meaningful open source tier while aggressively building enterprise features that justified the commercial tier. GitLab’s Community Edition remains genuinely useful for small teams. The Enterprise Edition features are scoped to problems that enterprises actually have: compliance, audit logs, fine-grained permissions, support contracts.

The companies that struggled tend to be those where the open source version was the product, and the commercial version was just the hosted version of the same product. When users can run the full product themselves, the managed hosting option competes on operational convenience alone. That is a thin moat.

The Licensing Landscape Is Getting Complicated

SSPL, BSL, and the various source-available licenses occupy a contested space. The Open Source Initiative does not recognize SSPL or BSL as open source licenses. That matters because the open source label carries real weight in procurement decisions, in developer community participation, and in the overall trust relationship between a project and its users.

BSL in particular has an interesting design: it converts to an open source license after a specified period, typically four years. This gives companies a window of commercial exclusivity while eventually returning the code to the commons. It is a reasonable compromise, though the four-year window is long enough to matter commercially, which is the point.

For users evaluating infrastructure dependencies, the proliferation of novel licenses creates real friction. Legal review cycles exist for a reason, and every non-standard license adds to that burden. There is an argument that the ecosystem would benefit from a smaller number of well-understood license options rather than each company crafting bespoke terms.

What This Means for the Next Round of Open Source Startups

The pattern that is emerging is that open source works well as a go-to-market strategy for developer tools, infrastructure, and platforms where the buyers are technical. It works less well as a business model for application-layer software competing in consumer-adjacent markets.

If you are building a database, an observability stack, a build system, or a developer platform, open source gives you distribution, community trust, and a path to enterprise sales. The technical audience evaluating your software will kick the tires, find the limitations of the free tier, and sometimes convert to paid.

If you are building a scheduling tool, a CMS, or a project management application, you are competing with products that have years of polish and enterprise relationships. The open source advantage is smaller, and the cost of maintaining the community’s expectations is higher relative to the commercial return.

Cal.com’s decision is rational given those economics. Whether it is the right long-term move depends on execution details that are not visible from the outside. But the fact that it keeps happening, across companies with different products, different markets, and different license starting points, suggests the structural problem is not going away.

The open source funding landscape has produced models like Open Collective, GitHub Sponsors, and foundation-based governance for projects that want to stay independent of any single commercial entity. For projects that started as company products, those paths are rarely viable. The incentives that created the project are also the incentives that make it hard to transfer governance.

What would actually help is a clearer distinction, maintained consistently, between open source software that is a community project and open source software that is a marketing strategy for a commercial product. Both are legitimate. Conflating them creates the recurring cycle of communities feeling betrayed when a company optimizes for its commercial interests, which is what companies do.