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 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
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.
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
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
I only pay for hosted software that gives me the freedom to easily leave and lose no features.
Disclosure: I'm the CEO of NeetoCal.
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. ;)
I would only pay for something open knowing I have the freedom to self host if I ever need to.
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.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.
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.
------
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.
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 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?
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.
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