Cal.diy: open-source community edition of cal.com (github.com)

Cal.com has always had an open source community edition, I've been using it for some time. Is this just a rebrand of that line?

It’s curious what they said in the email they sent me about the OSS version.

------

A few important changes to note:

We will no longer provide public Docker images, so your team will need to build the image yourselves.

Please do not use Cal.diy — it’s not intended for enterprise use.

From the docs, "It is strictly recommended for personal, non-production use."

Wow what a 180 from just a year ago when their blog said, "For companies that handle sensitive information, deploying open-source scheduling software on-premises can offer an extra layer of security. Unlike cloud services controlled by external vendors, on-prem installations let teams maintain full ownership of their infrastructure. " ¹

I just cannot trust a company that does a bait and switch like this.

¹ https://cal.com/blog/open-source-scheduling-empower-your-tea...

are there notable open source forks or open source cal competitors that go for the "just keep it simple" vibe?

Wait, I didn't even realize Cal.diy is owned by Cal.com. It seems like they're trying to get ahead of the open source community forking by doing this themselves

I just installed calrs, a recent alternative to cal.diy. It absolutely rocks! The only downside is that it requires me to activate STARTTLS as force-TLS-SMTP isn't supported (I had to check the source code). It’s young, very promising, and honestly, I don't know what I could ask for more.

I also replaced Radical with rustical, and I gained free push updates.

https://cal.rs/ and https://github.com/lennart-k/rustical

And if you wanna try it out. https://cal.ache.one/u/ache

Can someone who's looked at the security of these systems give a bit more context on that?

The thing that's always concerned me with them is questions of "what level of access is required to the system(s) actually hosting my calendar data?" and "if this vendor is compromised, what level of access might an attacker in control of the vendor systems have?" Obviously this will vary by what kind of access controls backends have (e.g. M365, Google Workspace, assorted CRM systems, smaller cloud providers, self-hosted providers, etc.).

Edit: basically, with a lot of these systems, what's expected to be the authoritative data provider/storage?

Good grief that codebase is absolute hell, almost too good of an example of accidental complexity.

As a former cal.com advocate, I am now going to be switching my two companies to cal.diy or a similar alternative and canceling my cal.com subscriptions.

I am now actively rooting for cal.com to go out of business now as a cautionary tale for any company thinking about taking open source projects proprietary.

FOSS || GTFO

Here is a simple trick: do accept plenty of open source contributions as-is, without any kind of copyright assignment nor requiring to sign anything that grants power to relicense.

There you go, guaranteed community ownership of the code, best face and "good will" as promised by choosing a FOSS license to begin with, and future rug pulls averted.

Seeing it from the other side of the fence: if you see that all contributors are required to cede controlling power into a single hand (except certain Foundations, yadda yadda), it's not proper Open Source in spirit, only in form; and closeups are just a change of mind away.

Tempted to buy cal.zone or cal.sucks just to add the paid features to cal.diy. They even made a list!

  Teams, Organizations, Insights, Workflows, SSO/SAML, and other EE-only features have been removed

cal.ws is $630 on Namecheap... the tokens required to build this are cheaper than the domain.

It rubs me the wrong way that it says it's "the open source community edition". Who decided this was the one? How of the community is Claude? Why open source and not free software?

Maybe I'm being critical but the copy gives me the ick

Edit: I just realised this is by cal.com. I'm leaving my comment intact, if anything it adds to my ick

[dead]

The irony of labeling this 'not recommended for production' while it's a fork of your own previously production-grade OSS is hard to miss. Feels less like a community edition and more like a liability shield. Curious how long before an actual community fork ends up being the thing people self-host.

All I want is an opensource site that syncs my different calendars across one another... I have yet to find a reliable, easy to use one. Now with AI, I might just have to send the wife off for a weekend with the girls and vibe code it myself.

PSA: their Github repo history still includes the old, un-castrated codebase, and (IANAL), there's nothing in the license forbidding you from still using it.

Adoption of the OSS version must not have been very high, otherwise I would have expected a Valkey / OpenTofu style, community-led fork.

Same code but with enterprise features stripped out. So much for that "we're going closed source for security"...

If you don't find the open source model sustainable and you've really tried, sure, go closed source, we'll understand. But please don't lie to everyone that it was all about security.