Seems like it's just being used as a convenient pretense to back out of open-source.
I mean, they were a COSS startup using the AGPLv3, so checks out. :)
Cal.com is going closed source
81–90 of 337 posts
Re: Cal.com is going closed source
#82Saaspocalypse is coming for cal.com
Re: Cal.com is going closed source
#83Drew Breunig published a very relevant piece yesterday that came to the opposite conclusion: https://www.dbreunig.com/2026/04/14/cybersecurity-is-proof-o... Since security exploits can now be found by spending tokens, open source is MORE valuable because open source libraries can share that auditing budget while closed source software has to find all the exploits themselves in private. > If Mythos continues to find e…
This is an economically sound conclusion. It also means that you need to extract enough value to cover the cost of said tokens, or reduce the economic benefit of finding exploits. Reducing economic benefit largely comes down to reducing distribution (breadth) and reducing system privilege (depth). One way to reduce distribution is to, raise the price. Another is to make a worse product. Naturally, less valuable softw…
> I suspect we'll see more 'open spec' software, with actual source generated on-demand (or near to it) by models. Then all the security and governance will happen at the model layer.
So each time you roll the dice you gamble on getting a fresh set of 0-days? I don't get why anyone would want this.
Re: Cal.com is going closed source
#84I get the mentality but it feels very much like security through obscurity. When did we decide that that was the correct model?
Security through obscurity is only problematic if that is the only, or a primary, layer of defense. As an incremental layer of deterrence or delay, it is an absolutely valid tactic. (Note, not commenting on whether that is the rationale here.)
Re: Cal.com is going closed source
#85Earlier quoted context omitted.
I agree it's a shit tactic, but one thing I can say for those running software businesses is that it's not an equivalent linear increase on both sides. It's asymmetric, because # of both attackers and the amount of attack surface (exposed 3rd party dependencies, for example) is near infinite, with no opportunity cost for failure by the bad actors (hackers). However a single failure can bring down a company, particula…
Sure, I can see that to a degree. And there definitely is a bit of chaos during the transition period as everyone scrambles to figure out what the landscape looks like now. I could understand if they decided to temporarily do less-frequent code releases, or maybe release their code on a delay or something, while they wait for the dust to settle. But I don't think permanently ending open source development is the righ…
Agreed! There must be a way to maintain the principles and benefits of open-source; the alternative, which is that all software becomes a black box, is antithetical to the same security that that choice supposedly aims to achieve.
I think companies make decisions like this from a tactics level, not realizing that by doing so they are not only alienating their customers but misunderstanding the basic (often unconscious or unspoken) social contract upon which their very existence is predicated.
Calendly already existed. Cal came along and said, ok, but what if the code were out in the open -- auditable, self-hostable. Then you wouldn't have to worry about lock-in, security, privacy, etc, in the same way. Now they are removing that entire aspect of their value prop. It may be the only thing that caused a good portion of their customers to adopt in the first place.
Re: Cal.com is going closed source
#86Earlier quoted context omitted.
hey cofounder here. since it takes my 16 year old neighbors son 15 mins and $100 claude code credits to hack your open source project
It only takes 20 minutes and $200 to hack a closed source one too though. LLMs are ludicrously good at using reverse engineering tools and having source available to inspect just makes it slightly more convenient.
Very true, but that is still a meaningfully higher cost at scale. If, as people are postulating post-Mythos, security comes down to which side spends more tokens, it is a valid strategy to impose asymmetric costs on the attacker.
Re: Cal.com is going closed source
#87Earlier quoted context omitted.
This is an economically sound conclusion. It also means that you need to extract enough value to cover the cost of said tokens, or reduce the economic benefit of finding exploits. Reducing economic benefit largely comes down to reducing distribution (breadth) and reducing system privilege (depth). One way to reduce distribution is to, raise the price. Another is to make a worse product. Naturally, less valuable softw…
> I suspect we'll see more 'open spec' software, with actual source generated on-demand (or near to it) by models. Then all the security and governance will happen at the model layer. So each time you roll the dice you gamble on getting a fresh set of 0-days? I don't get why anyone would want this.
You already do this with human-authored code, just slowly.
Project model capabilities out a few years. Even if you only assume linear improvement at some point your risk-adjusted outcome lines cross each other and this becomes the preferred way of authoring code - code nobody but you ever sees.
Most enterprises already HATE adopting open source. They only do it because the economic benefit of free reuse has traditionally outweighed the risks.
If you need a parallel: we already do this today for JIT compilers. Everything is just getting pushed down a layer.
Re: Cal.com is going closed source
#88Monumentally dumb given their codebase is already public and the type of security issues that exist in software are usually found in the oldest code. But also, and more importantly, cal.com launched coss.com last year, open source is (ostensibly) their DNA. How could they do a complete 180 on something so fundamental and think that wouldn’t worry customers, much more so than their codebase being public? I cannot even begin to understand this. Surely there must be more to the story?
Re: Cal.com is going closed source
#89Earlier quoted context omitted.
That’s a non-trivial cost for commonly severely underfunded open source projects
Cal.com is not a severely underfunded project, it raised around $32M of VC money.
It's not a "project" though; the business Cal.com Inc raised that VC money. Their open source repo did not raise the money.
Did they ever promise to keep their codebase FOSS forever, in a way that differs from what they're already doing over at cal.diy? If not, I don't see why it would be reasonable to expect them to spend a huge amount of money re-scanning on every single commit/deploy in order to keep their non-"DIY" product open source.
Re: Cal.com is going closed source
#90Earlier quoted context omitted.
Reducing your attack surface as much as possible via obscurity.
Going closed source is making the branch secret/private, not making it obscure. Obscurity would be zipping up the open source code (without a password) and leaving it online. Obscurity is just called taking additional steps to recover the information. Your passwords are not obscure strings of characters, they are secrets.
If there is a self-hosted version at all, then the compiled form is out there to be analysed. While compilation and other forms of code transformation that may occur are not 1->1, trivially reversed, operations, they are much closer to bad password security (symmetric encryption or worse) then good (proper hashing with salting/peppering/etc). Heck, depending on the languages/frameworks/other used the code may be hardly compiled or otherwise transformed at all in its distributed form. Tools to aid decompiling and such have existed for practically as long as their forward processes have, so I would say this is still obscurity rather than any higher form of protection.
Even if the back-end is never fully distributed any front-end code obviously has to be, and even if that contains minimal logic, perhaps little more than navigation & validation to avoid excess UA/server round-trip latency, the inputs & outputs are still easily open to investigation (by humans, humans with tools, or more fully automated methods) so by closing source you've only protected yourself from a small subset of vulnerability discovering techniques.
This is all especially true if your system was recently more completely open, unless a complete clean-room rewrite is happening in conjunction with this change.