Cal.diy: open-source community edition of cal.com
github.comFrom 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...
I think this is less a bait and switch and more just a legal liability shield. They're not saying you 'cant' use it that way. They just don't recommend you do, and they won't support you at all for doing so. Which I think is completely fair. Also, these two things aren't in contradiction. Deploying on prem does offer more security, but then it's up to you to use it correctly.
It being open source also allows you to actually have a read of the software and guarantee things yourself, which is the harder better path anyway.
This actually makes me wonder if cal.com has had a security breach in their hosted offering that they are not disclosing.
It seems to be more that they're using "security" as a reason for going closed source, so this is just sticking with the story.
Fair point.
But the OSS license already absolves them of responsibility. This might just be to set the tone that security fixes won't be prioritized to the standard that they used to be.
You seem really confident that an OSS license would protect them from liability… what is that confidence based on?
It's a straightforward MIT license: https://github.com/calcom/cal.diy/blob/main/LICENSE
> IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Just because a license says you are not liable for anything doesn't mean a court will always uphold that.
if the license can't shield them, do you think that a blog post might?
This is good , switching from viral license to more corporate friendly licensig
I still remember when they launched here. "Opensource Alternate to Calendly" was their post title.
What do you want, it’s hard to resist VC money and “the enterprise offering”
Not impossible though, I run a directory of open-source alternatives and rarely do you see what Cal.com did. Projects gets abandoned yes, but a pure bait and switch like this really grinds my gears. This is from someone who is self hosting Cal.com right now and now they are going to strip even more features.
Are you really claiming you would rather the project get abandoned?
Problem is using opensource as GTM strategy, to get developer contribution, traction and then say fuckoff.
are they actually removing features from the open source version?
Their docs say cal.fyi won’t have team features but my self hosted one does. They are a bit hacky. I think they also said they will stop publishing a docker image and that’s what I use to self host. I think I might just build an alternative over the weekend.
That's why I'm worried about Laravel taking on a huge sum.
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
Seems to be mostly vibe coded.
It is vibe-coded by people from Vates, the company maintaining https://github.com/xcp-ng
Their internal IT infrastructure runs self-hosted OSS wherever possible. I don't think cal.rs is a toy project, they know the perils and headaches of doing open source.
Yes, sadly. :(
Who gives a shit. Cal.com is written by hand and the code is absolute garbage. Of all people that should be luddites I never imagined software engineers would be the most pointlessly staunch advocates of that philosophy.
LLM-assisted is different from vibe-coded. Weird how you're so defensive about it, though
You might want to look up what Luddism was all about. Hint: it's not about being anti-technology, but about fairness.
sadly it's one of the strictly viral license AGPL , i prefer the more permisive one
people are claiming cal.com did a bait and switch
AGPL (specially if you take external contributions) is the one license where one can't do a bait and switch
If anything, if people are concerned about companies doing a 180 on open source, they should demand more AGPL, not less
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
Bonus: if you pick cal.zone you can have fun with pizza puns.
Perfect recipe to launch a cheesy saas.
Swiss as a service?
Your guess is as gouda's mine
I'm surprised cal.zone is not taken already
It still isn't taken but it's now $20k.
It has been $20k for a while now and I’ve admittedly been looking for excuses to buy it
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.
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
How curious. Are they trying to throw security shade on running open source? Very odd.
My guess is that they're hoping they can expose their security bugs and performance issues on the cal.diy and then roll the fixes for those into their paid version. Free development hours for their main product.
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.
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.
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?
I'm unpersuaded by the assertion that closing the source is an effective security bulwark.
From that page:
> Today, AI can be pointed at an open source codebase and systematically scan it for vulnerabilities.
Yeah, and AI can also be pointed at closed source as soon as that source leaks. The threat has increased for both open and closed source in roughly the same amount.
In fact, open source benefits from white hat scanning for vulnerabilities, while closed source does not. So when there's a vuln in open source, there will likely be a shorter window between when it is known by attackers and when authors are alerted.
The HN discussion on the announcement is just 90% posts of the theme "if a student can brute force your FOSS for $100, they can do you proprietary code for $200" and "if it's that cheap to find exploits, why don't you just do it yourself before pushing the code to prod?"
I believe that the reason the chose to close the source is just security theater to demonstrate to investors and clients. "Look at all these FOSS projects getting pwned, that's why you can trust us, because we're not FOSS". There is, of course, probably a negative correlation between closing source and security. I'd argue that the most secure operating systems, used in fintech, health, government, etc, got to be so secure specifically by allowing tens or hundreds of thousands of people to poke at their code and then allowing thousands or tens of thousands of people to fix said vulns pro bono.
I'd be interested to see an estimation of the financial value of the volunteer work on say the linux or various bsd kernels. Imagine the cost of PAYING to produce the modern linux kernel. Millions and possibly billions of dollars just assuming average SWE compensation rates, I'd wager.
Too bad cal.com is too short sighted to appreciate volunteers.
> Millions and possibly billions of dollars just assuming average SWE compensation rates
Yeah, and average kernel devs are not average SWEs
I think it's more prosaic, OSS is great for building a userbase but not great at generating revenue. So just wave the OSS flag while you build a userbase, then pull out whichever flimsy excuse seems workable at the time when you want to start step two of your enshittification plan.
The only thing new here is the excuse.
How are LLMs at reading assembly? I assumed they’d be able to read assembly about as well as any other language…
Is there such a thing as a closed source program anymore?
Not only are they good at reading and writing machine code now, they are actively being used to turn video game cartridge dumps back into open source code the community can then compile for modern platforms.
There is no moat anymore.
They are REALLY good at it.
A much better argument would be "if you can point the AI to scan it for vulnerabilities, why not do that yourself and fix the vulnerabilities"?
If you believe they really did it for security, I have a very nice bridge to sell you for an extremely low price ...
Look, tech companies lie all the time to make their bad decisions sound less bad. Simple example: almost every "AI made us more efficient" announcement is really just a company making (unpopular) layoffs, but trying to brand them as being part of an "efficiency effort".
I'd bet $100 this company just wants to go closed source for business reasons, and (just like with the layoffs masquerading as "AI efficiency") AI is being used as the scapegoat.
Who says I believe it? ;)
I'm just choosing to focus on the substance of the argument itself, which I think is risible regardless of who makes it and why.
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
You might want to double-check the cal.diy maintainer before your wish is granted..
The maintainer of the OSS fork being the company does not matter to me. Their product is proprietary now which means they are no longer worth giving money too.
I only pay for hosted software that gives me the freedom to easily leave and lose no features.
If you are looking for an alternative then please take a look at NeetoCal https://neeto.com/cal . It's closed source though.
Disclosure: I'm the CEO of NeetoCal.
Never heard of Neeto. It's a no-brainer (imo).
I perceive and classify your business model as a product optimization race-to-the-bottom model, if it makes sense. Have you considered or are currently working in the Field Service Management (NeetoService) space? Perhaps an ERP (NeetoERP)? Honestly curious because they're both sorely needed.
Thanks again for your AMA-ability. ;)
Closed source software has no value anymore. If I like your UX and it is proprietary, I will just ask an LLM to clone it.
I would only pay for something open knowing I have the freedom to self host if I ever need to.
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?
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.
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
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.
> Adoption of the OSS version must not have been very high, otherwise I would have expected a Valkey / OpenTofu style, community-led fork.
I'm guessing battle-tested reliability isn't a priority for calendaring/scheduling web services, unlike Redis/Valkey.
It's probably cleaner for anyone looking to adapt the source code to point an LLM at it to extract some specs and tests, then build a new one from scratch.
Good grief that codebase is absolute hell, almost too good of an example of accidental complexity.
It is total dogshit. I looked at it once and i was very much not impressed.
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.
are there notable open source forks or open source cal competitors that go for the "just keep it simple" vibe?
Thunderbird showed up in the last thread: https://github.com/thunderbird/appointment