That's exactly how this read to me too. Ultimately, the whole article is written by a company that does AI vulnerability scanning, and it's to try and get you to sign up for their service.
As it mentions in their article, Strix actually scans the Cal.com codebase and reports vulnerabilities to us. But the reality is, they actually miss so many vulnerabilities that other platforms do find. There's no one platform that seems to be able to reliably find all vulnerabilities, and so simply adopting AI scanners just isn't enough.
We've run an extremely profitable business for five years, raised a seed and a Series A, and grown at 300% a year sustainably while being open source.
Going closed source actually hurts our business more than it benefits it. But it ultimately protects customer data, and that's what we care about the most.
I think if it ultimately protects customer data in a significant way, I would be for it.
Are you able to share any more detail on how you determined this is the best route? It would be a significant implication for many other pieces of open source software also if so.
(And I say this is someone who just recommended cal.com to someone a few days ago specifically citing the fact that it was open source, that led to increased trust in it.)
I think if you are committed to switching back to open source as soon as the threat landscape changes, and you have some metric for what that looks like, that would be valuable to share now.
I would like to see the analysis that you're referencing around open source being 5-10x less secure.
That's absolutely our plan. We have bug bounty programs, we have internal AI scanners, we have manual penetration testing, and a number of other things that enable us to push really hard to find this stuff internally rather than relying on either the good people in the open source community or hackers to find our vulnerabilities.
As I mentioned above, we actually do run these AI scanners on our code, but the problem is it's simply not enough. These AI scanners, including STRIX, don't find everything. Each scanning tool actually finds different results from the other, and so it's impossible to determine a benchmark of what's secure and what's not.
> As I mentioned above, we actually do run these AI scanners on our code, but the problem is it's simply not enough. These AI scanners, including STRIX, don't find everything. Each scanning tool actually finds different results from the other, and so it's impossible to determine a benchmark of what's secure and what's not.
Yeah, but with closed source it's cheaper for the defender than for the attacker - the defender can scan their sources and their PRs as well as the compiled output. The attacker can only scan the compiled output, and they have to perform repeated scans.
I think it makes it all the more apparent that writing EAL4 code with as little design competence as possible was taking advantage of some strange scarcity economics.. It's now even easier to make something with endless technical debt and security vs backwards compatibility liability but is anyone going to keep paying for things that aren't correct and to the point if some market participants structure their agent usage toward verifiable quality and don't actually have more cost any more?
We actually run AI scanners on our code internally, so we get the benefit of security through obscurity while also layering on AI vulnerability scanning, manual human penetration testing, and a huge array of other defence mechanisms.
"Security through obscurity" is a term popularized entirely by the long-standing consensus among security researchers and any expert not being paid to say otherwise that this is a bad idea that doesn't work
The AGPL is more to clear up confusion and try and limit people ripping off our software.
Open source definitely isn’t a growth strategy for us. We’re huge open source fans, and do actually believe in what it stands for. We’re open source for a number of other reasons, such as longevity, privacy and genuine passion for OSS software (I’ve wrote more about this in other comments here).
However, yes, we are a company that is VC-backed, and so we have to make some decisions that are for the business side of things, and switching to AGPL is one way of cutting down on people trying to create rip off versions of our product.
Folks can still rip off/sell your software (even as a managed service) with the AGPL, as long as they share the source code of their version of cal.com
All we need is a name and email for your guest. All data is being handled in a way that’s secure and private (we’re open source, you can check the code that touches your calendar), plus for internal security we are SOC 2 compliant and 99% of the way HIPAA compliant.
You surely could be hacked, and while it unfortunately could be said about pretty much anything, this particular case doesn't seem to justify passing PII to the second party.
I figured it out, basically, the start-time is constrained by the end-time, which is why I couldnt change the start-time until I changed the end-time first. It wasnt obvious at first, but makes sense. That said, i do wonder if a better UI control would make the operation more obvious.
First is longevity. Especially considering we’re a startup, if a huge company is evaluating using our product, they’re going to wonder if we’re going to disappear in a few years. Open source doesn’t disappear: https://cal.com/blog/longevity
Secondly is that we’re a developer focused product, and so making it open source for hobbyists to play around with is a great way to introduce people to our product with the hopes that one day they’ll build their next company using our scheduling (so it does help as a sales channel, although definitely not the primary reason)
Also transparency and privacy. Users know how their data is being handled, which for me personally is a huge plus. I want to know what the software is doing if I’m giving it access to my calendar.
There are a few other reasons too, maybe I’ll write something on the Cal.com blog
As it mentions in their article, Strix actually scans the Cal.com codebase and reports vulnerabilities to us. But the reality is, they actually miss so many vulnerabilities that other platforms do find. There's no one platform that seems to be able to reliably find all vulnerabilities, and so simply adopting AI scanners just isn't enough.