Cal.com alienating its developer community

Diving deeper into

Cal.com

Company Report
risks alienating the developer community that drove its initial 47,000 GitHub stars and organic enterprise pipeline
Analyzed 7 sources

This is really a distribution risk, not just a licensing debate. Cal built awareness the cheap way, by letting developers discover the code on GitHub, self host it, file issues, and then carry it into work when a company needed SSO, workflows, routing, or support. Once the production code moved private in April 2026, that loop weakened, because the community can still use Cal.diy, but contributions no longer improve the commercial product directly.

  • The fork is substantial enough to matter. The Cal.diy repository is public, MIT licensed, community maintained, and still shows roughly 45,000 stars and more than 13,000 forks, which means the original developer audience did not disappear, it now has an alternative place to gather.
  • The lost motion is top of funnel conversion. Open source scheduling used to let an engineer test the product in a real stack, then ask procurement for hosted or enterprise features later. Cal.diy removes enterprise features like SSO, org controls, workflows, and insights, but it preserves enough core scheduling infrastructure for many self hosted users.
  • There is precedent for community fallout after license tightening. HashiCorp moved future releases to BSL in August 2023. Elastic moved Elasticsearch and Kibana off Apache 2.0 in 2021. Redis shifted core Redis to source available licenses in March 2024. Each case protected commercialization, but also pushed parts of the community toward forks or alternatives.

Going forward, Cal has to replace community led adoption with product led and sales led distribution. That means turning Cal.diy into a feeder rather than a rival, while making hosted features and enterprise support valuable enough that companies still graduate from self hosting instead of stopping at the fork.