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 exploits so long as you keep throwing money at it, security is reduced to a brutally simple equation: to harden a system you need to spend more tokens discovering exploits than attackers will spend exploiting them.
An app like Cal.com can be vibe coded in a few evenings with a Chrome MCP server pointed to their website to figure out all the nooks and crannys. The moat of Cal.com is not the code, it's the users who don't want to migrate.
The real answer is they are likely having a hard time converting people to paid plans
Exactly, that's why most Saas companies are in a very tough position.
You have to bring value that goes beyond the source code and hosting, otherwise your clients are going to vibe code a custom solution instead of paying you.
> otherwise your clients are going to vibe code a custom solution instead of paying you.
How many things do you want to be responsible for? How many vibe coded projects do you want to maintain?
I think this line of reasoning is overblown. Just because you can doesn't mean a significant number of people will. I think the 3D printer comparison is apt.
Same story as always, writing the code in the easy part. Requirement gathering, analysis, consensus, direction, those are all the hard parts. Enterprises have a business to run and don’t want to run a software shop on top of everything else.
The story is usually that businesses don't want to commit to indefinitely expending their limited efforts maintaining software which isn't part of the company's core competencies. Most of the cost and effort of software happens after the first release is delivered.
> Enterprises have a business to run and don’t want to run a software shop on top of everything else.
It sounds like you mostly understand here. The biggest part of "running a software shop" they want to avoid is responsibility for support, bugs, fires, ongoing maintenance, and legal issues, of post-release software.
Dave's Pizza around the corner doesn't make a social media app, not because Dave can't figure it out, not because he can't vibe code one, not because he can't contract someone to do it, but because running a social media site isn't a core competency of Dave's Pizza. Instead, Dave uses existing social media sites, and focuses his efforts and passions on making pizza.
So I work in enterprise tech. consulting, my current project is with a large, global, chemicals company (it wouldn't be right to call out my client by name). This client is extremely competent from their multiple enterprise architects down to their analysts, they're a pleasure to work with. One of the business requirements could be met by a very simple in-house developed and hosted API, it's a perfect use case for GenAI assisted coding too. There's no magic, it's a problem solved over and over already. However, they don't want to touch inhouse dev with a 10 foot pole for the reasons we're both talking about. They don't want to support it, extend it, back it up, monitor it, and all the other things that have to happen after the code is done. They're perfectly happy to buy licenses from a saas so if anything goes wrong they can tell the CTO "it's not me, it's them". And when the CTO says "why doesn't it do this too!?!" they can say "i'll call our rep and ask".
saas value to an enterprise is more than just the functionality provided and I think that is lost on a lot of the heads down software devs here.
They are, and always have. Looking over "software engineer" roles in my local area, I see folks at companies in a variety of industries: finance, health, logistics, health care, and the local power utility, all well outside the software industry.
Most enterprise companies don't develop everything in house, but usually do have a varied mix of in-house infrastructure, IaaS and PaaS solutions, and SaaS products. Large organizations across varied industries often have multiple internal dev teams, and the availability of increasingly sophisticated AI tools is going to enable the same teams to be effective at more, and more complex, projects. AI will definitely start shifting make-or-buy decisions, especially for mature, commodity use cases, to 'make'.
I don't think it's much cheaper. Writing some code to do some CRUD has always been easy. Getting to a proof of concept is definitely quicker. But creating something that can be relied upon in production? That's as difficult and time consuming as it has ever been.
Yup. I've explained it as okay, some software is free as in beer and others are free as in speech. DIY software is free as in yacht.
It sounds nice, but now you have something that takes an enormous amount of time and effort to use and maintain, plus you need to have someone with the skills to run it.
They won’t, because specialization is a key aspect of capitalism.
This is why companies outsource anything. Google, Inc. is big enough to own farms and ranches to grow the food eaten in its cafeterias. They could make trucks to transport that food. They could operate factories to make cutlery, etc. Why do they instead choose to pay layers of margins to layers of middlemen?
Absurd example? How about Apple? They outsource production of their chips, instead of capturing the margin they are currently gifting to their partners. Why?
Delta Airlines doesn’t operate oil fields or even refineries even though a major cost of their operations is jet fuel. Why?
Once you can reason through these very simple examples, you will understand why enterprises are unlikely to walk away from SaaS.
s/Delta/United/ or s/Delta/Southwest/ or s/Delta/Lufthansa/. Or if you prefer, s/refinery/oilfield, or s/refinery/pipeline. Or even s/refinery/farm/ because Delta also buys food in vast quantities (I would not be surprised to find they have interests in ag producers that offset a small % of their food purchases, which does not diminish the argument).
Delta also does not make airplanes, jet engines, seats, radios, GPS, glass, or even wires. They don't distill the spirits they serve on their flights. They don't own and operate a satellite Internet capability. They don't even make movies for in-flight entertainment.
The point is that Delta, like most successful firms, outsources key aspects of core service delivery.
The second article you linked says plainly that the refinery is an offset/hedge. QED Delta still outsources the vast majority of its fuel costs. (They could, for example, own large swathes of the Permian and do E&P as well. They choose to leave that to others.)
Vertical integration has been a common practice in industry for 150 years.
Yes, very few firms fully control their upstream supply chains, but very few conversely produce nothing but their core market offering in-house. Most companies are somewhere in between, doing some things in-house, and obtaining other things from vendors.
Most large firms have in-house software dev teams responsible for at least some portion of their development work. I know software engineers locally working, variously, at banks, pet supply distributors, power companies, soft drink bottlers, and many other non-tech industries. And AI can and will extend these teams' capacity to internally manager larger segments of their companies' tech stacks.
> How many vibe coded projects do you want to maintain?
here comes the next SaaS idea - vibe coded services as a service. You tell what service you want, may be point out a couple examples, and you get that service vibe coded and hosted for you for a small monthly fee!
I agree with the other poster that mention this is likely a publicity stunt but all it's really showing is that VC is still incredibly stupid with their money. All the more reason to seize it from them then properly fund useful software and not subsidize vanity projects for stanford grads.
About the friction, not the capabilities...I haven't switched off my biz calendar/appointment provider I'm paying for even though I've kinda outgrown it.
Email is actually a excellent example of something with network dependence. Changing email providers requires that you change your email address too (unless you own and use your own domain). An address change causes friction from having to update the network of contacts and services which used your old email address.
For many use cases, maintenance doesn't matter. At this point, using LLMs to one-shot a tool/service for a single use or time-limited use case is becoming more appealing than signing up with some vendor, even for free.
May be trying creating one and see how much effort and time is required to clone such a functionality to a proper working state! Something for personal use can be created in about 5-10 days, but even then the skill that is required and the amount of tokens to burn, hosting and security etc, will easily kill. This is exactly the thought process of many, but it will surely kill many opensource contributors. I've stopped committing anything to any open source repos as a personal choice. I do not want to train a LLM which will eventually create more slop and headaches since for me, time is the only important factor which holds the maximum value! Nothing else!
At risk of self promotion, I think more people should adopt something like the Ship of Theseus license (https://github.com/tilework-tech/nori-skillsets/pull/465/cha...). It's not obvious if this will patch the clean room hole in licensing, but I'd rather see it play out in court than assume opensource is just fully dead
I am incredibly skeptical that license is legally meaningful. (but obligatory IANAL.)
Generally speaking it is very very difficult to have a license redefine legal terms. Either this theseus copy is legally a derivative work or it isn't, and text of a license is going to do at most very very little to change that.
> It's not obvious if this will patch the clean room hole in licensing, but I'd rather see it play out in court than assume opensource is just fully dead
IANAL, but I don't think there is any "clean room hole in licensing": licensing is downstream of copyright law, and clean-room reverse engineering, if done properly, results in products that do not infringe the copyright of the originating work to begin with, so the license therefore never applies to them.
The "Ship of Theseus" license you've linked to attempts to define for itself what constitutes a derivative work, but what is and is not a derivative work is determined by copyright law itself, and there's no concept of imposing licensing conditions on works that your copyright never extended to in the first place.
Simply put, if something isn't infringing your copyright under the criteria established by the law, then your permission was never needed to do it in the first place, so the conditions under which you would or would not be willing offer that permission are irrelevant.
If someone spends years using your software and they have learned a mental model of how your software works, they can build an exact replica and there is nothing you can do about that since there is no copy you can sue over. Said user is also allowed to use AI tools to aid in the process.
What you want is an EULA, which is a contract users explicitly have to agree with. A license file only grants access or the right to copy, it doesn't affect usage of your software.
"AI slop is rapidly destroying the WWW, most of the content is becoming more and more low-quality and difficult to tell if its true or hallucinated. Pre-AI web content is now more like the golden-standard in terms of correctness, browsing the Internet Archive is much better. This will only cause content to go behind pay-walls, allot of open-source projects will be closed source not only because of the increased work maintainers have to do to not only review but also audit patches for potential AI hallucinations but also because their work is being used to train LLMs and re-licensed to proprietary."
Replace AI with "open source and Linux", and "open source" with "Windows" in the statements. That's what Microsoft's PR team would have said about open source and Linux about 20 years back in the 2000s.
After the unsuccessful FUD era, now Microsoft is running away with Linux by running its Windows alongside via WSL to combat MacOS Unix-like popularity, and due to Linux and open source dominance in the cloud OS demographic.
Even worse, in that Microsoft's FUD was mostly right. The joke about Open Source being communism played out straight - FOSS pretty much destroyed the ability to make money on software products, accelerating transition to SaaS models where you can carefully seek rent from the shelter of your secure company servers (later, cloud), and that is in large part responsible for modern surveillance economy - as it turns out, some SaaS segments decayed to "free with ads", where - much like with OSS and locally-run software - you cannot compete on price with free.
This conclusion makes more sense to me, but maybe I'm too naive.
The media momentum of this threat really came with Mythos, which was like 2 or 3 weeks ago? That seems like a fairly short time to pivot your core principles like that. It sounds to me like they wanted to do this for other business related reasons, but now found an excuse they can sell to the public.
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 software is not a desirable outcome. So either you reduce the cost of keeping open (by making closed), or increase the price to cover the cost of keeping open (which, again, also decreases distribution).
The economics of software are going to massively reconfigure in the coming years, open source most of all.
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.
> 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.
Next, you double click the Excel icon on the desktop, and instead of having Excel installed or a spec of Excel, you have a cloud service with thirty years of Usenet, Quora, StackOverflow, Reddit, PHPBB comments and blog tutorials about how people use Excel, and you wait a few moments while approximately-Excel is rederived from these experiences.
You’ll accept the delay because by then it happens faster than Microsoft can make a splashscreen and window open from a local nvme drive. And because you can customise Excel’s feature set by simply posting a Reddit comment where you hallucinate using a feature that Excel doesn’t have and waiting a couple of days.
[although it can be difficult to find the real Reddit to post on as your web browser will tend to synthesise the experience of visiting any website using a cloud AI model of every website without connecting to the real one at all. This was widely loved as a security measure and since most websites are AI written content on AI written codebases, makes less difference than you’d first think]
It's a mistake to confuse what you're seeing out of today's models with what you'll see out of future ones. We're barely out of the gate on this stuff. We'll borrow what works, and use it to bootstrap something better.
> You already do this with human-authored code, just slowly.
No I don't. I build predictable and deterministic pipelines. If I rebuild from a specific git sha, I expect the same output. If I get something different, I need to fix what's causing that.
Nothing precludes you from doing that with AI-gen code vs human-gen code. What you just described is downstream.
If you have a human authoring code, you re-roll every time they release a new version. AI just releases versions faster, and in response to different, faster-moving inputs.
> to harden a system you need to spend more tokens discovering exploits than attackers will spend exploiting them.
That can't be right, can it? Given stable software, the relative attack surface keeps shrinking. Mythos does not produce exploits. Should be defenders advantage, token wise, no?
A slight factor differentiating security systems here is involved to the advantage of defenders: Attackers have to find a whole exploit chain, while defenders only need to fix one part of it.
The point is that, as the defender, you only have to find each hole once, while the attacker can spend an infinite amount of tokens trying to find more holes, that are increasingly harder to find and might, eventually, not exist at all. The defender can do that too, of course, but being in the defense, there is value in not being able to uncover new holes (your system keeps working, ostensibly) while as the attacker that's simply how you fail.
So long as that OSS keeps accumulating features, there isn't quite the equilibrium you're imagining. If you can pin to a stable version, which continues to audited, you're fine. But if the rest of the world moves on to newer versions of the software, you'll have to as well, unless you want to own the burden of hardening older versions.
It does take a lot of work not to break things. That's why "move fast and break things" are traditionally closely coupled: it's hard to avoid breaking things without slowing down.
But why would responsible AI users -- actual engineers using it to accelerate grunt work, not vibe coders -- not use the AI tooling to increase their capacity to do all of the work it takes to avoid breaking things while still moving fast, relatively speaking?
Testing a new incremental feature against the entire extant codebase, not just the bits of it that they had the bandwidth to tackle within the deadline, seems like exactly the sort of thing well-disciplined engineering teams would use AI to do.
For one, you architect your codebase into separate layers and logical chunks that are self-contained and can be reasoned about independently. That's not always possible, but you draw as many firm boundaries as you can. You don't ever want to be in the position where you have to test an entire codebase against your new change. That's a horrible nightmare scenario.
So you don't "test as much of the codebase as you have time for", you write tests for your code and the interface between it and other systems. Maybe integration or FE tests depending on what you have.
So testing against a whole codebase is rarely the problem, and if it is, you have bigger issues.
Also, LLMs don't make mistakes like humans do. They fuck up in weird unpredictable ways that mean you kinda have to treat them like a hostile adversary trying to sneak in subtle backdoors. It slows things down.
Also, actually writing code is usually the fast and easy part. It's all the other bits -- getting the requirements, building mockups, planning, review, standing up new infra etc etc etc. LLMs can't help with most of that.
> For one, you architect your codebase into separate layers and logical chunks that are self-contained and can be reasoned about independently. That's not always possible, but you draw as many firm boundaries as you can. You don't ever want to be in the position where you have to test an entire codebase against your new change. That's a horrible nightmare scenario.
Right, all of this goes without saying.
> So testing against a whole codebase is rarely the problem, and if it is, you have bigger issues.
Read "whole codebase" as a qualitative descriptor, not a quantitative one, where the codebase as deployed is the reference point for the overall business logic flow, including where different processes interact with or block each other.
The point is to use the AI tools to ensure that new features and functionality are implemented in a way that is consistent with the technical and business constraints that emerge from the entire tech stack, precisely so that adding something new in context A doesn't break functionality in context B.
> Also, actually writing code is usually the fast and easy part. It's all the other bits -- getting the requirements, building mockups, planning, review, standing up new infra etc etc etc. LLMs can't help with most of that.
Yes, that's true, but those are the perennial challenges in doing solution design before you even get to implementation. The "break things" problem happens when solutions for context-bound problems are being implemented in ways that lead out of their context -- narrowly-focused goals are often pursued in ways that create externalizes elsewhere in the organization precisely because of the limited focus available to the people working on solving for those goals.
The point here is that there's now the possibility for the AI tools to make much broader contextual awareness available as part of the solution design and implementation phase of every narrowly-targeted goal. If the AI has a reasonably accurate model of how systems and solutions affect each other in the broader organization, it can offer predictions of how any proposed new feature might impact all of the other business functions, and do so in near real time, and ultimately head off 90% of "break things" impacts that you'd otherwise need multiple series of meetings, testing sessions, buy-ins and sign-offs to avoid otherwise. That's what would get you moving fast with much less collateral damage.
This seems similar to the lesson learned for cryptographic libraries where open source libraries vetted by experts become the most trusted.
Your average open source library isn’t going to get that scrutiny, though. It seems like it will result in consolidation around a few popular libraries in each category?
An important difference between SaaS offerings and open source libraries is that the latter have not liability. They can much more easily afford exhibiting vulnerabilities until those are fixed.
I like that LLMs have basically switched to the weapons business model. Buy our LLM so that the bad guy we'll sell our LLM to doesnt destroy your code. As a bonus, we'll give you a little head start. And if you're a small company that can't afford our LLM, too bad.
> > If Mythos continues to find exploits so long as you keep throwing money at it, security is reduced to a brutally simple equation: to harden a system you need to spend more tokens discovering exploits than attackers will spend exploiting them.
But this has always been the reality of security: it's always been fundamentally an economic question about which party has stronger incentives and greater resources than the other. The increasing sophistication of AI is available to both parties equally, so I don't see how AI in itself fundamentally changes the equation.
I wonder if we could find a way to donate unused tokens or even local compute resources to open-source projects we support. Especially for security auditing where it could probably be somewhat more asynchronous and disconnected than the open-source developers' personal tool choices.
"unused tokens" are the force driving token cost down. If everyone used all of the tokens they thought they were paying for, prices would explode. People with subscriptions that don't get out everything they can are subsidizing the system.
There are ways to use LLM service providers that leave no tokens unused, by just billing per token. Unsurprisingly, this quickly becomes much more expensive than subscriptions.
With current GPU prices, I find it difficult to find hardware to run competent models. gemma4's 26B MoE model seems to offer the best performance per megabyte of RAM, but it's not good enough to use the way one would use cloud models.
The big, impressive models all scale well for multi-customer setups because of the efficiency batching provides, but the base cost to run models like that as even a small business is incredibly high. If you can't saturate your LLM hardware almost 24/7, the time to earn back your investment is high unless you choose inferior models that are worse at their job.
I think sometimes about this, does it really make sense? Financially I mean. The is just my impressions and I'm glad to be corrected if someone has hard numbers and some experience going this route:
At the moment LLMs vendors are in market grab mode and take a loss on big subscription users, they are starting to try to move to profit but they must move carefully to not let a competitor steal their users so we will still have "cheap" tokens for a while.
Even if prices go up by a bit, they have the scale in their favor to optimize costs.
If commercial model providers go into "not competitive" territory with their prices compared to open models, wouldn't it always be cheaper to use an open models inference provider? They can take advantage of scale as well, and with no model moat, competition should keep prices honest.
And last ressort, renting GPU time in the cloud seem like a safer bet than buying a GPU to me?
“Unused tokens” are a weird, fragile concept that I wouldn’t want to build upon. You can just donate money, you know. That’s what money’s for - it’s the universal exchange thingy.
> to harden a system you need to spend more tokens discovering exploits than attackers will spend exploiting them
This is true until certain point, unless the requirement / contract itself has loophole which the attacker can exploit it without limit. But I don't think this is the case.
Let's say, if someone found an loophole in sort() which can cause denial-of-service. The cause would be the implementation itself, not the contract of sorting. People + AI will figure it out and fix it eventually.
This may be true long term but not short term. It also assumes that white hats will be as motivated as black hats – not true.
For projects with NO WARRANTY, the risk is minimal, so yes there are upsides.
For a commercial project like cal.com, where a breach means massive liability, they don’t have the resources to risk breaches in the short term for potentially better software in the long term.
> It's been a common wisdom now for decades that open source is more secure.
This is not true.
The problem rather is that the managers of many companies don't allow their programmers to apply their knowledge about security - the programmers should rather weed out new features.
I expect we're about to find that it's a lot easier to convince a company to spend money running an AI security scan of their dependencies and sharing the results with the maintainers than it is to have them give those maintainers money directly.
(I just hope they can learn to verify the exploits are valid before sharing them!)
> SAN FRANCISCO – March 17, 2026 – The Linux Foundation, the nonprofit organization enabling mass innovation through open source, today announced $12.5 million in total grants from Anthropic, AWS, GitHub, Google, Google DeepMind, Microsoft, and OpenAI to strengthen the security of the open source software ecosystem.
It’s almost cute how insignificantly small that amount is considering the companies named. Great for The Linux Foundation of course, but it still feels like they are being cheap as heck.
I would like to, but... have you tried to use thunderbird on an "older" linux laptop nowadays? Even with 8 gigs of ram, and a non-fancy memory-saving windowmanager, thunderbird is almost unusable now (large imap mbox), firefox even worse. I don't see why all that additional bloat is needed, or wanted. Please keep in mind, that a lot(!) of people are not able to afford buying new hardware every now and then anymore. And this is getting worse. First the pandemic, then the war in Ukraine, now the war in Middle-East. Shortage of ram/storage/everything (thanks ai) and massivly increased costs of energy, housing, food, insurance, everything. And in the years to come, I am afraid, that will be getting worse. Please think about it, when adding the "next cool feature", 'Keep the internet affordable'. --thunderbird user since 1.0
Regarding FF: Something is probably wrong with your install, or the websites you have open.
As a datapoint: FF + Chrome with lots of stuff open uses 2.6GB on my machine. With XFCE and a GB of other apps, it’s using about 4GB. 15 year old machine. Perf is fine.
This seems kind of crazy. If LLMs are so stunningly good at finding vulnerabilities in code, then shouldn't the solution be to run an LLM against your code after you commit, and before you release it? Then you basically have pentesting harnesses all to yourself before going public. If an LLM can't find any flaws, then you are good to release that code.
A few years ago, I invoked Linus's Law in a classroom, and I was roundly debunked. Isn't it a shame that it's basically been fulfilled now with LLMs?
After a release, attackers have effectively infinite time to throw an LLM against every line of your code - an LLM that only gets smarter and cheaper to run as time passes. In order to feel secure you’d need to do all the work you’d imagine an attacker would ever do, for every single release you ship.
No, attackers are also rational economical actors. They don't randomly attack any software just for the aesthetics beauty of the process. They attack for bounty, for fame, for national interest, etc. No matter the reason it's not random and thus they DO have a budget, both in time and money. They attack THIS project versus another project because it's interesting to them. If it's not, they might move to another project but they certainly won't spend infinite time precisely because they don't have infinite resources. IMHO it's much more interesting to consider the realistic arm race then theoretical scenarii that never take place.
The amount of time they will invest is proportional to how much usage / how high value the target is. If your release is used by no one then no one is going to attack it, but it didn't matter anyways.
The first few times it's going to be expensive, but once everyone level sets with intense scans of their codebases, "every single release" is actually not that big a deal, since you are not likely to be completely rebuilding your codebase every release
You still have to account for the non-deterministic behavior of an LLM, when do you know you have exhausted its possible outcomes for any given piece of code?
As LLMs improve and adoption grows, maintaining a FOSS project is becoming more complex and more expensive in terms of time and manpower. That part is easy to understand.
It is also become a trend that LLM-assisted users are generating more low-quality issues, dubious security reports, and noisy PRs, to the point where keeping the whole stack open source no longer feels worth it. Even if the real reason is monetization rather than security, I can still understand the decision.
I suspect we will see more of this from commercial products built around a FOSS core. The other failure mode is that maintainers stop treating security disclosures as something special and just handle them like ordinary bugs, as with libxml2. In that sense, Chromium moving toward a Rust-based XML library is also an interesting development.
Just use AI to fight AI, that's the only sensible way we can keep up. So if you're low-quality PRs, reports etc, have LLMs filter them out. Like how once upon a time we used to drown in email spam but it's now mostly a non-issue thanks to intelligent spam filters, the same needs to happen for opensource projects. Use AI to fight AI.
LLMs really are stunningly good at finding vulnerabilities in code, which is why, with closed-source code, you can and probably will use them to make your code as secure as possible.
But you won't keep the doors open for others to use them against it.
So it is, unfortunately, understandable in a way...
I'm not a security expert but can't close source applications be vulnerable and exploited too? I feel like using close source as a defense is just giving you a false sense of security.
Finding a vulnerability in a black box is drastically different from finding one in a white box. This isn’t about whether there is a vulnerability or not, but about the likelihood of it being found.
It's a meaningful difference for SaaS. Most likely an attacker doesn't have access to your running binary let alone source code, and if they probe it like a pentester would it will be noisy and blocked/flagged by your WAF.
What is being phrased as obscurity is one of the approaches to security as long as you are able to keep the code safe. Your passwords, security keys are just random combination of strings, the fact that they are obscure from everyone is what provides you the security
Decompilation and you are back to the level of security you started with. OpenSSH is open for a good reason. Please acknowledge your error. Are you AI?
OTOH, their position seems to be "many LLMs make shallow bugs" is unhelpful; same as many eyes make shallow bugs considered unhelpful.
What seems genuinely needed by the open source economy to both surface these latent vulns and tamp down finding-slop is a new https://bughook.github.com/your/repo/ that these big LLMs (Mythos, etc.) support. Mythos understands if it's been used to find an vuln, and back end auto-reports verified findings the git service can feed to a Dependabot type tool.
Even better, price up Mythos to cover running a background verifier that gets the project, revalidates the issue, before that bughook.
Meanwhile, train it on these findings, so its future self doesn't create them.
LLM like humans can find vulnerabilities in black boxes. We already established 30 years ago that open source is usually more secure than closed source and that security by obscurity doesn't work.
Every change would introduce the possibility of a vulnerability being added to the system and one would need to run the LLM scan across the entire code base. It gets very costly in a environment where you are doing regular commits. Companies like Github already provide scanning tools for static analysis and the cost is already high for them.
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.
Attackers only need LLMs to be good at randomly finding one vulnerability, whereas service providers need them to be good at finding all such vulnerabilities.
It's entirely possible to address all the LLM-found issues and get an "all green" response, and have an attacker still find issues that your LLM did not. Either they used a different model, a different prompt, or spent more money than you did.
It's not a symmetric game, either. On defense, you have to get lucky every time - the attacker only has to get lucky once.
I mean, you should definitely have _some_ level of audit by LLMs before you ship, as part of the general PR process.
But you might need thousands of sessions to uncover some vulnerabilities, and you don’t want to stop shipping changes because the security checks are taking hours to run
I think people are finding ways to either enable “pro” features and at least find the right extension points to implement them easily with LLMs. Security is window dressing.
Yeah, I don't buy it. If they don't want these security reports, ignore them and continue your path. Blaming AI is just an excuse to close source. If you don't want AI to learn from your code, too late. Add genetic algorithms and fuzzing into AI and it can iterate and learn a billion times faster, no need to learn for humans.
The real downside to Google's solution is that you have to use Google Meet. Depending on your opinion of Meet, this is either no big deal or a total deal breaker.
Hey cal.com, as a potential customer, you have just lost me.
Open source is set to profit from improved transparency in the SSDLC. With closed source, you will have to trust the software vendor instead.
I'm not sure I agree with Drew Breunig, however. The number of bugs isn't infinite. Once we have models that are capable enough and scan the source code with them at regular intervals, the likelihood of remaining bugs that can be exploited goes way down.
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.)
That, and plenty of closed-source software at least has a decent security track record by now. I haven't seen an obvious cause-and-effect of open-source making something more secure. Only the other direction, where insecure closed-source software is kept closed because they know it's Swiss cheese.
They probably lack a sufficient density of people who remember why "security through obscurity" become an infamous concept. It belongs to that family of bad ideas that's superficially appealing, especially if you're still at that stage of your career at which you think past generations were full of idiots and you, alone, have discovered how to do real software development.
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.
Right, but those capabilities are available to you as well. Granted the remediation effort will take longer but...you're going to do that for any existing issues _anyway_ right?
I understand why this is a tempting thing to do in a "STOP THE PRESSES" manner where you take a breather and fix any existing issues that snuck through. I don't yet understand why when you reach steady-state, you wouldn't rely on the same tooling in a proactive manner to prevent issues from being shipped.
And if you say "yeah, that's obv the plan," well then I don't understand what going closed-source _now_ actually accomplishes with the horses already out of the barn.
Or internalize the cost if they all decide the hassle of maintaining an open source project is not worth it any more.
I'm not aiming this reply at you specific, but it's the general dynamic of this crisis. The real answer is for the foundational model providers to give this money. But instead, at least one seems to care more about acquiring critical open source companies.
We should openly talk about this - the existing open source model is being killed by LLMs, and there is no clear replacement.
I don't think this really helps that much. Your neighbor could ask an LLM to decompile your binaries, and then run security analysis on the results.
If the tool correctly says you've got security issues, trying to hide them won't work. You still have the security issues and someone is going to find them.
If I understand correctly, their primary product is SaaS, and their non-DIY self-host edition is an enterprise product. So your neighbor wouldn't have access to the binaries to begin with.
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.
Couldn't you just spend those $100 on claude code credits yourself and make sure you're not shipping insecure software? Security by obscurity is not the correct model (IMO)
> neighbors son 15 mins and $100 claude code credits
Is that true? Didn't the Mythos release say they spent $20k? I'm also skeptical of Anthropic here doing essentially what amounts to "vague posting" in an attempt scare everyone and drive up their value before IPO.
We did consider arguments in both directions (e.g. easier to recreate the code, agents can understand better how it works), but I honestly think the security argument goes for open source: the OSS projects will get more scrutiny faster, which means bugs won't linger around.
Time will tell, I am in the open source camp, though.
Just wanted to appreciate the open-source work by Xata. I’ve been eyeing pgroll [1] for schema migrations after Liquibase license shenanigans (the only barrier for me is json-based migration instead of sql-based migrations)
I know plenty of security researchers who exclusively use Claude Code and other tools for blackbox testing against sites they don’t have the source code for. It seems like shutting down the entire product is the only safe decision here!
Just a random thought. Up until yesterday this project was open source. The code base won’t be rewritten tomorrow. More likely is that conserved parts of the source code, something like 90% will just remain the same. Particularly the core database schema around users and security are likely to stay the same.
Since the old code is already out there what’s stopping me from exploiting the software as it was?
This looks an awful lot like marketing to me, and not like real security concerns.
The real threat is not security but bad actors copying your code and calling it theirs.
IMHO, open source will continue to exist and it will be successful but the existence of AI is deterrent for most. Lets be honest, in recent times the only reason startups went open source first was to build a community and build organic growth engine powered by early adaptors. Now this is no longer viable and in fact it is simply helping competitors. So why do it then?
The only open source that will remain will be the real open source projects that are true to the ethos.
I agree with you that AI's disruption of attribution is a much bigger problem, but it's also worth recognizing that not everyone has this same motivation. It mostly affects copyleft open source licenses.
Attribution isn't required for permissive many open source licenses. Dependencies with those licenses will oftentimes end up inside closed source software. Even if there isn't FOSS in the closed-source software, basically everyone's threat model includes (or should include) "OpenSSL CVE". On that basis, I doubt Cal is accomplishing as much as they hope to by going closed source.
> Now this is no longer viable and in fact it is simply helping competitors. So why do it then?
> The only open source that will remain will be the real open source projects that are true to the ethos.
Well, the second point seems like the answer to the previous question. The original model of monetizing FOSS -- support contracts, risk indemnification, etc., for an otherwise functionally equivalent product -- will still remain viable.
But those trying to thread the needle of trying to use open-source to push a "freemium" model are now going to hit a wall: if you were withholding features from the community version in order to paywall them for the premium version, and now AI has made it easy for users to add those features back without paying you, then you're screwed. The people who were going to use AI to bypass your paywall are still not going to be your customers, but you no longer have the differentiator to put you ahead of the competitors that were already closed-source to begin with for the customers who are willing to pay.
I originally deployed Cal.com because I wanted an open-source solution. But now, why would I choose a closed-source Cal.com over Calendly? If I'm forced to go SaaS, I'll probably go with the more widely used Calendly. If I'm not forced to go SaaS, I'll forego them both, and go back to something like EasyAppointments, knowing that I won't be in conflict with the authors if I choose to add my own "premium" features to it, whether with AI or by hand. All Cal.com did here was remove any chance that I'd ever pay them anything.
This certainly makes me feel better about the project I started a few months ago to replace my Cal.com instance with a smaller, simpler self-hosted tool
Very weak argument. You could have had the same speech before AI.
I would rather say that the core product is not strong and differentiated enough to resist this new age of coding, and it's an attempt to protect revenues.
I'm sorta suspicious. I don’t really think this is why they are moving to closed source. It’s true that there is more security risk, but that actually justifies being open source, because open source tooling can spend more tokens hardening itself against security vulns than closed source tooling (at least, that’s the theory). My strong hunch is they are moving to closed source because it is now trivial to copy a product with AI clean rooms. Which, tbf, is a totally valid reason to move closed source. But I'd want to see more adoption of something like the Ship of Theseus license (https://github.com/tilework-tech/nori-skillsets/pull/465/cha...) before giving up on open source entirely
> My strong hunch is they are moving to closed source because it is now trivial to copy a product with AI clean rooms. Which, tbf, is a totally valid reason to move closed source.
The "clean room" part of clean-room reverse engineering implies that there is no exposure to the original copyrighted code on the part of those doing the reimplementation, whether human developers or AI. Traditionally, if you're working of the source code itself, you have one party translate the source code back into a design document, specifying behavior, and then you have another party implement that design spec with original code.
If you already have a running copy of the software to model the behavior off of, then you don't need the original source code in the first place. So going closed source will have zero effect on the capacity of AI tools to be used for clean room reverse engineering: all you need is the runtime.
This license doesn't seem valid: a license can't redefine what qualifies as a derivative work. That's determined by copyright law itself, and if copyright law says that a clean-room reimplementation isn't a derivative work, then it isn't restricted by copyright, so doesn't need a license in the first place.
> My strong hunch is they are moving to closed source because it is now trivial to copy a product with AI clean rooms. Which, tbf, is a totally valid reason to move closed source.
Since such "clean room" implementations ostensibly do not see the source, it's arguably irrelevant whether such sources are open are not. Such implementations will happen regardless of whether the sources they're reimplementing are opened or closed.
This is completely stupid and ridiculous. Why not just use AI to patch your software? Its just as effortful as someone finding and exploiting a vuln on your system.
What's worse is your choosing to keep it buggy behind closed doors so no one can see the bugs. That's 100% the wrong approach.
Today, AI can be pointed at an open source codebase and systematically scan it for vulnerabilities.
AI also goes a long way towards erasing the distinction between source code and executable code. The disassembly skill of a good LLM is nothing short of jaw-dropping.
So going closed-source may be safer for SaaS, but closing the source won't save a codebase from being exploited if the binaries are still accessible to the public. In that sense, instead of dooming SaaS as many people have suggested AI will do, it may instead be a boon.
Today, it's easy to (publicly) evaluate the ability of LLMs to find bugs in open source codebases, because you don't need to ask permission. But this doesn't actually tell us the negative statement, which is that an LLM won't just as effectively find bugs in closed codebases, including through black-box testing, reverse engineering, etc.
If the null hypothesis is that LLMs are good at finding bugs, full stop, then it's unclear to me that going closed actually does much to stop your adversary (particularly as a service operator).
The AI companies profit hugely from open source. In fact, without open source, their most significant financial success (coding assistants) wouldn't exist.
They should provide free continued git commit security analysis for open source projects. That would increase the quality of open source projects and would inspire more projects to go open source, which is also a win for the AI companies.
This was my thought too. Your tool is great at finding vulnerabilities, and we want software to be secure for everyone, secure code should not be out of reach to those who can't afford it.
Scan everyone's code, for free. Make all code as secure as an llm can make it as a baseline.
Monumentally 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?
Coss.com reads like a half assed pivot if you look at it with today's news. It's clear cal.com isn't making enough money and going closed source is yet another attempt to fix that.
Oh wow the coss.com thing makes this so much worse. Making such an aggressive and public commitment to open source to then turn around and do something like this is a pretty rough look.
Proposition 1: The majority of a code in a modern app is from shared libraries
Proposition 2: The most popular shared libraries are going to be quickly torn apart by LLM security tools to find vulnerabilities
Proposition 3: After a brief period of mass vulnerability discovery, the overall quality of shared libraries will dramatically increased.
Conclusion: After the initial wave of vulnerabilities has passed, the main threat to open source code bases is in their own comparatively small amount of code.
Surely the argument is just to have an LLM stressing for vulnerabilities during the build pipeline before merging to main? Resulting in better security from LLMs.
One must assume this was a direction they wanted to move towards and this is the justification they thought would be most palatable.
Security through obscurity can be a good security layer, but you need to maintain obscurity. That's a lot harder than Cal.com seems to realize.
For example using something like Next.js means a very large chunk of important obscurity is thrown out the window. The same for any publicly available server/client isomorphic framework.
The founder proclaimed "Open Source is Dead" in the original tweet.
I thought this was grandiose and projecting their own weakness onto others, an extremely unappealing marketing position that may get clicks in the short term but will undermine trust beyond that.
What's preventing cal.com to run the AI researcher over their own codebase and find their vulnerabilities before anyone else and patch them all by tomorrow morning?
No worries, someone else will do that for them. Just like they explained.
And given that they will not rewrite the whole codebase in the next few days it means that security vulnerabilities are still there to be discovered by someone willing to pay the AI tax.
I am beyond convinced at this point that you either run an Open Source Project with a small revenue company (single digit millions) or run a software company that does more than 10M ARR at the least and be closed source. I know there are exceptions but most open source Software companies are providing code with heavy restrictions or teaser features and gate keep everything in their "ee/enterprise" version etc.
Juxtapose this with the fact that many HNers will decry strong copyleft FOSS licenses as not being truly "open source" - the reality is that closed source software is still full of open-source non-copyleft dependencies. Unless you're rolling your own encryption and TCP stack, being closed source will not be the easy solution that many imagine it to be.
It is with a heavy heart that I have to announce that {thing we were going to do anyway} is necessary due to AI. AI has changed the industry and we are powerless to do anything other than {unpopular decision we were going to do regardless}.
Open source means living under constant scrutiny. AI just made that scrutiny cheaper and faster. I feel this every day maintaining an open source project. The temptation to close the source is real but let’s not forget that open source is what raised the bar for software quality in the first place.
this is a big nothing. they relicensed the previous cal.com as cal.diy (MIT by the way, instead AGPL or something else) and effectively forked their own product into the "new" cal.com. anyone who cares would just use cal.diy as they were prior to this announcement with cal.com
We’d hope but they could neuter Cal.diy over time. From their chart between the differences of cal.diy and cal.com, teams are not supported. I’m self hosting Cal.com and I think I do have access to teams as of right now.
Something about a scheduling/productivity app (one of the most common vibe-coded projects people make) being the subject of this is funny to me. I wonder how many tokens have been wasted making apps like this, let alone time.
This is the future now that AI is here. Publishing is going to be dead, look at the tea leaves, how many engineers are claiming they don’t use package managers anymore and just generate dependencies? 5 years and no one will be making an argument for open source or blogging.
The article is leaking from all sides. As a wannabe hacker would find a hole in a public repo, what can the repo owner do, who knows every detail of the project and has a high interest in it, also economically?
Sounds like "security by obscurity" to me - if you think AI is so good at finding security issues - it will find them in compiled code as well. Why not using it in your favor and let it search for bugs you'd otherwise not find?
You can lock down the source and also use AI to look for bugs in it. It does take significantly more time and money for AI to find bugs in compiled code.
That said, I agree with another commenter that this seems like more of a business decision than a security one.
Isn't the joke that everything is open source if you can read assembly?
Pretty sure someone is working on an AI that reads assembly... Not sure hiding the codebase away is a viable solution!
That may be true for software that you download and install as an app, but for SaaS, there is no need to expose the code to anyone at all. Only your API endpoints are available. You can try and "black box reverse engineer" through the client code and its API calls, but that's not the same as having the server code in hand to pick apart.
In my advisory job founders always raise the question about open sourcing within the first hour of meeting me. They think that open sourcing product means transparency and developer trust which helps with early adoption. Every single founder I talked to brings up open source as a market penetration method to drive the initial adoption.
I always say to just stop with the virtue signaling led sales technique.
I despise the "we are like the market leader of our niche but open source" angle. Developer as a buyer and as a community these days in my opinion do not care about open source anymore. There is no long term value to that. The moment a product gets traction the open source elements is a constant mild headache as open source product means that they have no intellectual copyright on the core aspect of the product and it is hard to raise money or sell the company. And whenever a product gets traction they will take any excuse to make it close source again. With an open source product they are just coasting on brand. Regardless of what your personal opinion is, this has been largely true for most for-profit business.
Open source is largely is nothing more then a branding concept for a company who is backed by investors.
Will it make any difference to security? LLMs are excellent pattern matchers. The source is a sequence of tokens, the binary is a sequence of tokens. Whats the difference to an LLM?
I think people really like how it's free (runs on google app scripts) and open source.
I've personally moved onto google's free gmail calendar scheduling tool, which strangely took pretty long to come to market. Calendly stretches back to ... 2013?
Scheduling, oddly feels a little niche (maybe less so today?), when it shouldn't be. Maybe there some more opportunity there.
EasyAppointments (https://github.com/alextselegidis/easyappointments) is still FOSS. We managed our team calendars on it at a previous company, but I rolled out Cal.com due to more apparent support and sophistication at my current company. Turns out most of that sophistication turned out to be bloat: we saw successive version releases add features we didn't care about while increasingly putting previously open features, like team calendars, behind a paywall.
This move by Cal.com seems to be transparently an attempt to maintain that paywall against users who'd otherwise just use LLMs to remove it. I guess it's back to EasyAppointments, which still seems to work just fine.
There are endless closed calendar options. Cal.com being FOSS and not making us feel locked in forever was the only reason we chose it over wasting limited cycles self hosting this at Distrust and Caution.
AI can clone something like cal.com with or without source code access, so in trying to pointlessly defend against AI they are just ruining the trust they built with their customers, which is the one thing AI can never create out of thin air.
We exclusively run our companies with FOSS software we can audit or change at any time because we work in security research so every tool we choose is -our- responsibility.
They ruined their one and only market differentiator.
We will now be swapping to self hosting ASAP and canceling our subscriptions.
Really disappointing.
Meanwhile at Distrust and Caution we will continue to open source every line of code we write, because our goal is building trust with our customers and users.
TIL I learned about yet another calendar application I don't need. Someone should setup their openclaw to just write a new todo/calendar app each week; they'll be billionaires by the end of the year.
This is some truly exceptionally clownish attention seeking nonsense. The rationale here is complete nonsense, they just wanted to put "because AI" after announcing their completely self-serving decision. If AI cyber offense is such a concern, recognize your role as a company handling truckloads of highly sensitive information and actually fix your security culture instead of just obscuring it.
I mean it's not complete nonsense, but yeah, doing it for security reasons sounds like BS. I actually thought this was going to be about how AI makes it super easy for someone to steal all their code and fold it into their own competing project. I've seen a few open source projects get sideswiped by this, AI is pretty good at copying code (and obfuscating the fact that it was copied). I suspect that's the real reason but it doesn't sound as good. So they went with this half-truth.
- You know, Lindsay, as a software engineering consultant, I have advised a number of companies to explore closing their source, where the codebase remains largely unchanged but secure through obscurity.
- Well, did it work for those companies?
- No, it never does. I mean, these companies somehow delude themselves into thinking it might, but... but it might work for us.
Risk tolerance and emotional capacity differs from one individual to another, while I may disagree with the decision I am able to respect the decision.
That said, I think it’s important to try and recognize where things are from multiple angles rather than bucket things from your filter bubble alone, fear sells and we need to stop buying into it.
I have fond memories of this project. Contributing to it really helped me ramp up my dev skills and was effectively my introduction to monorepo’s in JavaScript. It was the kind of codebase I couldn’t get my hands on while working in my part of the world. Good luck going closed source.
Security through obscurity doesn't work in isolation. It doesn't work as the only solution. It is discouraged, because it can be a panacea.
But it also doesn't hurt in many instances. Holding back your source code can be a strategic advantage. It does mean that adversaries can't directly read it (nor can your friends or allies!)
Having a proprietary protocol or file format, this is also "security through obscurity" and it may slow down or hinder an attacker. Obscurity may be part of a "defense in depth" strategy that includes robust and valid methods as well.
But it is harmful to baldly claim that "it doesn't work".
Enshittification has come for VC backed open-source. AI has deemed commercial open source obsolete especially when users can point Calude Code to calcom on GitHub and ask it to make them scheduling features directly into their product. That’s what spooked Cal.
I hate how this sounds...but this reads to me "we lack the confidence in our code security so we're closing the source code to conceal vulnerabilities which may exist."
> if AI can be pointed and find vulnerabilities then do it yourself before publishing the code
At your cost.
Every time you push. (or if not that, at least every time there is a new version that you call a release)
Including every time a dependency updates, unless you pin specific versions.
I assume (caveat: I've not looked into the costs) many projects can't justify that.
Though I don't disagree with you that this looks like a commercial decision with “LLM based bug finders could find all our bad code” as an excuse. The lack of confidence in their own code while open does not instil confidence that it'll be secure enough to trust now closed.
For-profit companies using open-source software should bear that cost - that's my position.
I believe than N companies using an open source project and contributing back would make this burden smaller than one company using the same closed-source project.
users can just point Claude Code at cal on GitHub and ask it to build xyz features directly into their own product .. and most of them won't bother following the license. it's happening with so many projects in open source
Open-source supporters don't have a sustainable answer to the fact that AI models can easily find N-day vulnerabilities extremely quickly and swamp maintainers with issues and bug-reports left hanging for days.
Unfortunately, this is where it is going and the open-source software supporters did not for-see the downsides of open source maintenance in the age of AI especially for businesses with "open-core" products.
Might as well close-source them to slow the attackers (with LLMs) down. Even SQLite has closed-sourced their tests which is another good idea.
The tools are available to everyone. It's becoming easier for hackers to attack you at the same speed that it's becoming easier for you to harden your systems. When everyone gains the same advantage at the same time, nothing has really changed.
It makes me think of how great chess engines have affected competitive chess over the last few years. Sure, the ceiling for Elo ratings at the top levels has gone up, but it's still a fair game because everyone has access to the new tools. High-level players aren't necessarily spending more time on prep than they were before; they're just getting more value out of the hours they do spend.
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, particularly when they may be hosting sensitive user data that could ruin their customers' businesses or lives.
I think Cal are making the wrong call, and abandoning their principles. But it isn't fair to say the game is accelerating in a proportionate way.
Ultimately, he concludes that while in the short run the game defines the players' actions, an environment that makes cooperation too risky naturally forces participants to stop cooperating to protect themselves from being "exploited" (this bit is around 34:39 - 34:46)
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 right move.
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.
Drew 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 exploits so long as you keep throwing money at it, security is reduced to a brutally simple equation: to harden a system you need to spend more tokens discovering exploits than attackers will spend exploiting them.
Thanks - I've re-upped* that one here: Cybersecurity looks like proof of work now - https://news.ycombinator.com/item?id=47769089 (no comments yet)
* a la https://news.ycombinator.com/item?id=26998308
I have a feeling the real reason is them trying to avoid someone using AI to copyright-wash their product, they're just using security as the excuse.
An app like Cal.com can be vibe coded in a few evenings with a Chrome MCP server pointed to their website to figure out all the nooks and crannys. The moat of Cal.com is not the code, it's the users who don't want to migrate.
The real answer is they are likely having a hard time converting people to paid plans
> The moat of Cal.com is not the code, it's the users who don't want to migrate.
That's a very weak moat unless you have something else like the friction of network dependence similar to a social network.
Exactly, that's why most Saas companies are in a very tough position.
You have to bring value that goes beyond the source code and hosting, otherwise your clients are going to vibe code a custom solution instead of paying you.
> otherwise your clients are going to vibe code a custom solution instead of paying you.
How many things do you want to be responsible for? How many vibe coded projects do you want to maintain?
I think this line of reasoning is overblown. Just because you can doesn't mean a significant number of people will. I think the 3D printer comparison is apt.
Individuals and SMB might stick with Saas but those don't pay much.
Enterprise customers have the means to develop in house, those are the customers that will leave. And those are the whales of the Saas business.
They already have the means to develop in house. Why aren't they?
Same story as always, writing the code in the easy part. Requirement gathering, analysis, consensus, direction, those are all the hard parts. Enterprises have a business to run and don’t want to run a software shop on top of everything else.
The story is usually that businesses don't want to commit to indefinitely expending their limited efforts maintaining software which isn't part of the company's core competencies. Most of the cost and effort of software happens after the first release is delivered.
> Enterprises have a business to run and don’t want to run a software shop on top of everything else.
It sounds like you mostly understand here. The biggest part of "running a software shop" they want to avoid is responsibility for support, bugs, fires, ongoing maintenance, and legal issues, of post-release software.
Dave's Pizza around the corner doesn't make a social media app, not because Dave can't figure it out, not because he can't vibe code one, not because he can't contract someone to do it, but because running a social media site isn't a core competency of Dave's Pizza. Instead, Dave uses existing social media sites, and focuses his efforts and passions on making pizza.
So I work in enterprise tech. consulting, my current project is with a large, global, chemicals company (it wouldn't be right to call out my client by name). This client is extremely competent from their multiple enterprise architects down to their analysts, they're a pleasure to work with. One of the business requirements could be met by a very simple in-house developed and hosted API, it's a perfect use case for GenAI assisted coding too. There's no magic, it's a problem solved over and over already. However, they don't want to touch inhouse dev with a 10 foot pole for the reasons we're both talking about. They don't want to support it, extend it, back it up, monitor it, and all the other things that have to happen after the code is done. They're perfectly happy to buy licenses from a saas so if anything goes wrong they can tell the CTO "it's not me, it's them". And when the CTO says "why doesn't it do this too!?!" they can say "i'll call our rep and ask".
saas value to an enterprise is more than just the functionality provided and I think that is lost on a lot of the heads down software devs here.
They are, and always have. Looking over "software engineer" roles in my local area, I see folks at companies in a variety of industries: finance, health, logistics, health care, and the local power utility, all well outside the software industry.
Most enterprise companies don't develop everything in house, but usually do have a varied mix of in-house infrastructure, IaaS and PaaS solutions, and SaaS products. Large organizations across varied industries often have multiple internal dev teams, and the availability of increasingly sophisticated AI tools is going to enable the same teams to be effective at more, and more complex, projects. AI will definitely start shifting make-or-buy decisions, especially for mature, commodity use cases, to 'make'.
This is much less work (= cheaper) to develop in-house with AI now than before.
I don't think it's much cheaper. Writing some code to do some CRUD has always been easy. Getting to a proof of concept is definitely quicker. But creating something that can be relied upon in production? That's as difficult and time consuming as it has ever been.
Yup. I've explained it as okay, some software is free as in beer and others are free as in speech. DIY software is free as in yacht.
It sounds nice, but now you have something that takes an enormous amount of time and effort to use and maintain, plus you need to have someone with the skills to run it.
They won’t, because specialization is a key aspect of capitalism.
This is why companies outsource anything. Google, Inc. is big enough to own farms and ranches to grow the food eaten in its cafeterias. They could make trucks to transport that food. They could operate factories to make cutlery, etc. Why do they instead choose to pay layers of margins to layers of middlemen?
Absurd example? How about Apple? They outsource production of their chips, instead of capturing the margin they are currently gifting to their partners. Why?
Delta Airlines doesn’t operate oil fields or even refineries even though a major cost of their operations is jet fuel. Why?
Once you can reason through these very simple examples, you will understand why enterprises are unlikely to walk away from SaaS.
Delta owns and operates a refinery.
https://en.wikipedia.org/wiki/Trainer_Refinery
https://www.reuters.com/business/energy/delta-air-lines-refi...
Sigh.
s/Delta/United/ or s/Delta/Southwest/ or s/Delta/Lufthansa/. Or if you prefer, s/refinery/oilfield, or s/refinery/pipeline. Or even s/refinery/farm/ because Delta also buys food in vast quantities (I would not be surprised to find they have interests in ag producers that offset a small % of their food purchases, which does not diminish the argument).
Delta also does not make airplanes, jet engines, seats, radios, GPS, glass, or even wires. They don't distill the spirits they serve on their flights. They don't own and operate a satellite Internet capability. They don't even make movies for in-flight entertainment.
The point is that Delta, like most successful firms, outsources key aspects of core service delivery.
The second article you linked says plainly that the refinery is an offset/hedge. QED Delta still outsources the vast majority of its fuel costs. (They could, for example, own large swathes of the Permian and do E&P as well. They choose to leave that to others.)
Vertical integration has been a common practice in industry for 150 years. Yes, very few firms fully control their upstream supply chains, but very few conversely produce nothing but their core market offering in-house. Most companies are somewhere in between, doing some things in-house, and obtaining other things from vendors.
Most large firms have in-house software dev teams responsible for at least some portion of their development work. I know software engineers locally working, variously, at banks, pet supply distributors, power companies, soft drink bottlers, and many other non-tech industries. And AI can and will extend these teams' capacity to internally manager larger segments of their companies' tech stacks.
Lmao I love this flavor of the ‘tism that always surfaces in hn comment threads exactly like this. Like moths to a flame
> How many vibe coded projects do you want to maintain?
here comes the next SaaS idea - vibe coded services as a service. You tell what service you want, may be point out a couple examples, and you get that service vibe coded and hosted for you for a small monthly fee!
I think you missed the point. Being responsible for a vibe coded product means also being able to support it and handle outages etcetera.
So, no, hosting LLM output is not the same as being responsible
Sunk cost is sufficient friction for most people even without network dependence.
For a meeting scheduler site? I feel like you're overestimating the capabilities of something that is akin to college graduate project.
This company does not seem healthy at all:
https://getlatka.com/companies/calcom
I agree with the other poster that mention this is likely a publicity stunt but all it's really showing is that VC is still incredibly stupid with their money. All the more reason to seize it from them then properly fund useful software and not subsidize vanity projects for stanford grads.
About the friction, not the capabilities...I haven't switched off my biz calendar/appointment provider I'm paying for even though I've kinda outgrown it.
I wouldn't under estimate switching friction.
How much does your friction avoidance cost, if you don't mind my asking?
idk my mom still pays for her aol email account
Email is actually a excellent example of something with network dependence. Changing email providers requires that you change your email address too (unless you own and use your own domain). An address change causes friction from having to update the network of contacts and services which used your old email address.
Best business insight posted on HN. This. Your code is not your business.
For real, one of the reasons I use cal.com is because it's open source. Time to migrate.
Same. I expect in a misguided effort to save customers, they are going to lose a lot more. My two companies will be canceling over this.
Coding something vs maintaining it can be quite different things.
For many use cases, maintenance doesn't matter. At this point, using LLMs to one-shot a tool/service for a single use or time-limited use case is becoming more appealing than signing up with some vendor, even for free.
If it's got the lifespan of a short lived spreadsheet, maybe.
People can one shot to the moon, if the input and improvements can't be sustained, it goes sideways. Still an exciting space.
> An app like Cal.com can be vibe coded in a few evenings
Do it then
May be trying creating one and see how much effort and time is required to clone such a functionality to a proper working state! Something for personal use can be created in about 5-10 days, but even then the skill that is required and the amount of tokens to burn, hosting and security etc, will easily kill. This is exactly the thought process of many, but it will surely kill many opensource contributors. I've stopped committing anything to any open source repos as a personal choice. I do not want to train a LLM which will eventually create more slop and headaches since for me, time is the only important factor which holds the maximum value! Nothing else!
At risk of self promotion, I think more people should adopt something like the Ship of Theseus license (https://github.com/tilework-tech/nori-skillsets/pull/465/cha...). It's not obvious if this will patch the clean room hole in licensing, but I'd rather see it play out in court than assume opensource is just fully dead
I am incredibly skeptical that license is legally meaningful. (but obligatory IANAL.)
Generally speaking it is very very difficult to have a license redefine legal terms. Either this theseus copy is legally a derivative work or it isn't, and text of a license is going to do at most very very little to change that.
> It's not obvious if this will patch the clean room hole in licensing, but I'd rather see it play out in court than assume opensource is just fully dead
Are you willing to bear the burden of litigation?
I cannot imagine that license addendum is legally enforceable (let alone provable) in most jurisdictions on earth but it is interesting.
As long as it doesn't cost me anything, I'd like to see it play out in court and know for sure.
But that is very unlikely even if everyone adopted it, which they won't.
I mean you might as well write "any competing project will be considered infringement". It doesn't cost you anything either.
IANAL, but I don't think there is any "clean room hole in licensing": licensing is downstream of copyright law, and clean-room reverse engineering, if done properly, results in products that do not infringe the copyright of the originating work to begin with, so the license therefore never applies to them.
The "Ship of Theseus" license you've linked to attempts to define for itself what constitutes a derivative work, but what is and is not a derivative work is determined by copyright law itself, and there's no concept of imposing licensing conditions on works that your copyright never extended to in the first place.
Simply put, if something isn't infringing your copyright under the criteria established by the law, then your permission was never needed to do it in the first place, so the conditions under which you would or would not be willing offer that permission are irrelevant.
I like the spirit but I do find it a bit ironic to include it in a project where almost every commit is made by an LLM
I don't think you understand how copyright works.
Copyright can only deny the right to make copies.
If someone spends years using your software and they have learned a mental model of how your software works, they can build an exact replica and there is nothing you can do about that since there is no copy you can sue over. Said user is also allowed to use AI tools to aid in the process.
What you want is an EULA, which is a contract users explicitly have to agree with. A license file only grants access or the right to copy, it doesn't affect usage of your software.
>I don't think you understand
Whether or not this is technically correct, a comment that begins this way is unlikely to be persuasive.
Exactly this! Classic open source bait and switch.
Called this 9 months ago https://news.ycombinator.com/item?id=44559840
"AI slop is rapidly destroying the WWW, most of the content is becoming more and more low-quality and difficult to tell if its true or hallucinated. Pre-AI web content is now more like the golden-standard in terms of correctness, browsing the Internet Archive is much better. This will only cause content to go behind pay-walls, allot of open-source projects will be closed source not only because of the increased work maintainers have to do to not only review but also audit patches for potential AI hallucinations but also because their work is being used to train LLMs and re-licensed to proprietary."
Typical FUD.
Replace AI with "open source and Linux", and "open source" with "Windows" in the statements. That's what Microsoft's PR team would have said about open source and Linux about 20 years back in the 2000s.
After the unsuccessful FUD era, now Microsoft is running away with Linux by running its Windows alongside via WSL to combat MacOS Unix-like popularity, and due to Linux and open source dominance in the cloud OS demographic.
Even worse, in that Microsoft's FUD was mostly right. The joke about Open Source being communism played out straight - FOSS pretty much destroyed the ability to make money on software products, accelerating transition to SaaS models where you can carefully seek rent from the shelter of your secure company servers (later, cloud), and that is in large part responsible for modern surveillance economy - as it turns out, some SaaS segments decayed to "free with ads", where - much like with OSS and locally-run software - you cannot compete on price with free.
This conclusion makes more sense to me, but maybe I'm too naive.
The media momentum of this threat really came with Mythos, which was like 2 or 3 weeks ago? That seems like a fairly short time to pivot your core principles like that. It sounds to me like they wanted to do this for other business related reasons, but now found an excuse they can sell to the public.
(I might be very wrong here)
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 software is not a desirable outcome. So either you reduce the cost of keeping open (by making closed), or increase the price to cover the cost of keeping open (which, again, also decreases distribution).
The economics of software are going to massively reconfigure in the coming years, open source most of all.
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.
> 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.
Next, you double click the Excel icon on the desktop, and instead of having Excel installed or a spec of Excel, you have a cloud service with thirty years of Usenet, Quora, StackOverflow, Reddit, PHPBB comments and blog tutorials about how people use Excel, and you wait a few moments while approximately-Excel is rederived from these experiences.
You’ll accept the delay because by then it happens faster than Microsoft can make a splashscreen and window open from a local nvme drive. And because you can customise Excel’s feature set by simply posting a Reddit comment where you hallucinate using a feature that Excel doesn’t have and waiting a couple of days.
[although it can be difficult to find the real Reddit to post on as your web browser will tend to synthesise the experience of visiting any website using a cloud AI model of every website without connecting to the real one at all. This was widely loved as a security measure and since most websites are AI written content on AI written codebases, makes less difference than you’d first think]
It's a mistake to confuse what you're seeing out of today's models with what you'll see out of future ones. We're barely out of the gate on this stuff. We'll borrow what works, and use it to bootstrap something better.
> You already do this with human-authored code, just slowly.
No I don't. I build predictable and deterministic pipelines. If I rebuild from a specific git sha, I expect the same output. If I get something different, I need to fix what's causing that.
I can't tell if you're trolling.
Nothing precludes you from doing that with AI-gen code vs human-gen code. What you just described is downstream.
If you have a human authoring code, you re-roll every time they release a new version. AI just releases versions faster, and in response to different, faster-moving inputs.
I love using software that changes every time you compile it.
> to harden a system you need to spend more tokens discovering exploits than attackers will spend exploiting them.
That can't be right, can it? Given stable software, the relative attack surface keeps shrinking. Mythos does not produce exploits. Should be defenders advantage, token wise, no?
It’s the classic asymmetric warfare problem:
Defenders have to find all the holes in all their systems, while attackers just need to find one hole in one system.
A slight factor differentiating security systems here is involved to the advantage of defenders: Attackers have to find a whole exploit chain, while defenders only need to fix one part of it.
The point is that, as the defender, you only have to find each hole once, while the attacker can spend an infinite amount of tokens trying to find more holes, that are increasingly harder to find and might, eventually, not exist at all. The defender can do that too, of course, but being in the defense, there is value in not being able to uncover new holes (your system keeps working, ostensibly) while as the attacker that's simply how you fail.
So long as that OSS keeps accumulating features, there isn't quite the equilibrium you're imagining. If you can pin to a stable version, which continues to audited, you're fine. But if the rest of the world moves on to newer versions of the software, you'll have to as well, unless you want to own the burden of hardening older versions.
> Mythos does not produce exploits.
AI in general will, don't worry. "Move fast and break things" makes more exploits than "move steadily and fix things" does.
But doesn't AI ultimately obviate "move fast and break things" by making it easier to move fast without breaking things?
Not at all, no; AI makes it harder to not break things, and it takes a lot of work to not break things.
It does take a lot of work not to break things. That's why "move fast and break things" are traditionally closely coupled: it's hard to avoid breaking things without slowing down.
But why would responsible AI users -- actual engineers using it to accelerate grunt work, not vibe coders -- not use the AI tooling to increase their capacity to do all of the work it takes to avoid breaking things while still moving fast, relatively speaking?
Testing a new incremental feature against the entire extant codebase, not just the bits of it that they had the bandwidth to tackle within the deadline, seems like exactly the sort of thing well-disciplined engineering teams would use AI to do.
There's a couple points of misunderstanding here.
For one, you architect your codebase into separate layers and logical chunks that are self-contained and can be reasoned about independently. That's not always possible, but you draw as many firm boundaries as you can. You don't ever want to be in the position where you have to test an entire codebase against your new change. That's a horrible nightmare scenario.
So you don't "test as much of the codebase as you have time for", you write tests for your code and the interface between it and other systems. Maybe integration or FE tests depending on what you have.
So testing against a whole codebase is rarely the problem, and if it is, you have bigger issues.
Also, LLMs don't make mistakes like humans do. They fuck up in weird unpredictable ways that mean you kinda have to treat them like a hostile adversary trying to sneak in subtle backdoors. It slows things down.
Also, actually writing code is usually the fast and easy part. It's all the other bits -- getting the requirements, building mockups, planning, review, standing up new infra etc etc etc. LLMs can't help with most of that.
> For one, you architect your codebase into separate layers and logical chunks that are self-contained and can be reasoned about independently. That's not always possible, but you draw as many firm boundaries as you can. You don't ever want to be in the position where you have to test an entire codebase against your new change. That's a horrible nightmare scenario.
Right, all of this goes without saying.
> So testing against a whole codebase is rarely the problem, and if it is, you have bigger issues.
Read "whole codebase" as a qualitative descriptor, not a quantitative one, where the codebase as deployed is the reference point for the overall business logic flow, including where different processes interact with or block each other.
The point is to use the AI tools to ensure that new features and functionality are implemented in a way that is consistent with the technical and business constraints that emerge from the entire tech stack, precisely so that adding something new in context A doesn't break functionality in context B.
> Also, actually writing code is usually the fast and easy part. It's all the other bits -- getting the requirements, building mockups, planning, review, standing up new infra etc etc etc. LLMs can't help with most of that.
Yes, that's true, but those are the perennial challenges in doing solution design before you even get to implementation. The "break things" problem happens when solutions for context-bound problems are being implemented in ways that lead out of their context -- narrowly-focused goals are often pursued in ways that create externalizes elsewhere in the organization precisely because of the limited focus available to the people working on solving for those goals.
The point here is that there's now the possibility for the AI tools to make much broader contextual awareness available as part of the solution design and implementation phase of every narrowly-targeted goal. If the AI has a reasonably accurate model of how systems and solutions affect each other in the broader organization, it can offer predictions of how any proposed new feature might impact all of the other business functions, and do so in near real time, and ultimately head off 90% of "break things" impacts that you'd otherwise need multiple series of meetings, testing sessions, buy-ins and sign-offs to avoid otherwise. That's what would get you moving fast with much less collateral damage.
This seems similar to the lesson learned for cryptographic libraries where open source libraries vetted by experts become the most trusted.
Your average open source library isn’t going to get that scrutiny, though. It seems like it will result in consolidation around a few popular libraries in each category?
An important difference between SaaS offerings and open source libraries is that the latter have not liability. They can much more easily afford exhibiting vulnerabilities until those are fixed.
I like that LLMs have basically switched to the weapons business model. Buy our LLM so that the bad guy we'll sell our LLM to doesnt destroy your code. As a bonus, we'll give you a little head start. And if you're a small company that can't afford our LLM, too bad.
> > If Mythos continues to find exploits so long as you keep throwing money at it, security is reduced to a brutally simple equation: to harden a system you need to spend more tokens discovering exploits than attackers will spend exploiting them.
But this has always been the reality of security: it's always been fundamentally an economic question about which party has stronger incentives and greater resources than the other. The increasing sophistication of AI is available to both parties equally, so I don't see how AI in itself fundamentally changes the equation.
I wonder if we could find a way to donate unused tokens or even local compute resources to open-source projects we support. Especially for security auditing where it could probably be somewhat more asynchronous and disconnected than the open-source developers' personal tool choices.
"unused tokens" are the force driving token cost down. If everyone used all of the tokens they thought they were paying for, prices would explode. People with subscriptions that don't get out everything they can are subsidizing the system.
There are ways to use LLM service providers that leave no tokens unused, by just billing per token. Unsurprisingly, this quickly becomes much more expensive than subscriptions.
And that is why the only winning move is owning a GPU.
With current GPU prices, I find it difficult to find hardware to run competent models. gemma4's 26B MoE model seems to offer the best performance per megabyte of RAM, but it's not good enough to use the way one would use cloud models.
The big, impressive models all scale well for multi-customer setups because of the efficiency batching provides, but the base cost to run models like that as even a small business is incredibly high. If you can't saturate your LLM hardware almost 24/7, the time to earn back your investment is high unless you choose inferior models that are worse at their job.
Assuming one does not value privacy, sovereignty, etc.
But also the Strix Halo 128 is pretty hard to beat.
I think sometimes about this, does it really make sense? Financially I mean. The is just my impressions and I'm glad to be corrected if someone has hard numbers and some experience going this route:
At the moment LLMs vendors are in market grab mode and take a loss on big subscription users, they are starting to try to move to profit but they must move carefully to not let a competitor steal their users so we will still have "cheap" tokens for a while.
Even if prices go up by a bit, they have the scale in their favor to optimize costs.
If commercial model providers go into "not competitive" territory with their prices compared to open models, wouldn't it always be cheaper to use an open models inference provider? They can take advantage of scale as well, and with no model moat, competition should keep prices honest.
And last ressort, renting GPU time in the cloud seem like a safer bet than buying a GPU to me?
“Unused tokens” are a weird, fragile concept that I wouldn’t want to build upon. You can just donate money, you know. That’s what money’s for - it’s the universal exchange thingy.
Maybe if we reframed money as a "fungible token" people would start understanding its use again?
> to harden a system you need to spend more tokens discovering exploits than attackers will spend exploiting them
This is true until certain point, unless the requirement / contract itself has loophole which the attacker can exploit it without limit. But I don't think this is the case.
Let's say, if someone found an loophole in sort() which can cause denial-of-service. The cause would be the implementation itself, not the contract of sorting. People + AI will figure it out and fix it eventually.
This may be true long term but not short term. It also assumes that white hats will be as motivated as black hats – not true.
For projects with NO WARRANTY, the risk is minimal, so yes there are upsides.
For a commercial project like cal.com, where a breach means massive liability, they don’t have the resources to risk breaches in the short term for potentially better software in the long term.
I still need to see a single breach that ends up being a liability for the company.
It's been a common wisdom now for decades that open source is more secure. Security is just a scapegoat here.
> It's been a common wisdom now for decades that open source is more secure.
This is not true.
The problem rather is that the managers of many companies don't allow their programmers to apply their knowledge about security - the programmers should rather weed out new features.
How may open source libraries have auditing budgets?
I expect we're about to find that it's a lot easier to convince a company to spend money running an AI security scan of their dependencies and sharing the results with the maintainers than it is to have them give those maintainers money directly.
(I just hope they can learn to verify the exploits are valid before sharing them!)
Their commercial users have auditing budgets.
Does your ideal world have an easy path to citizenship?
I might like to live there.
> SAN FRANCISCO – March 17, 2026 – The Linux Foundation, the nonprofit organization enabling mass innovation through open source, today announced $12.5 million in total grants from Anthropic, AWS, GitHub, Google, Google DeepMind, Microsoft, and OpenAI to strengthen the security of the open source software ecosystem.
https://openssf.org/tag/google
"But that's Linux, how small libraries get audit budget..." fortunately LLM has eliminated the need to have small libraires in your dependency chain.
It’s almost cute how insignificantly small that amount is considering the companies named. Great for The Linux Foundation of course, but it still feels like they are being cheap as heck.
> SAN FRANCISCO
I take back the “I might like to live there” :)
This feels like it misses the point. Tokens = money. The real differentiator is time and effort.
Llm's will find your issues faster, but not necessarily more accurately than a domain expert. But experts cost money and effort takes longer to apply.
Are llm's going to reduce everyone's wages because they are cheap labour?
Security should be a non issue in the age of AI now that auditing is cheaper than ever.
I'd give them more credits if they use the AI slop unmaintainability argument.
Ha ha ha ha. I wish that were true. Getting people to patch existing, known vulns is hard enough.
Head of Thunderbird project here.
Our scheduling tool, Thunderbird Appointment, will always be open source.
Repo here: https:// github.com/thunderbird/appointment
Come talk to us and build with us. We'll help you replace Cal.com
You should add some screenshots to the readme or somewhere before a sign in screen.
Sounds like a great tool though. How much is the hosted version?
Yes, we should. Will do that today
There are screenshots in the link[1] provided in the README.md
1. https://stage.appointment.day
We added some screenshots to the repository now. Thanks so much for the suggestion!
A Docker image would be good too.
I would like to, but... have you tried to use thunderbird on an "older" linux laptop nowadays? Even with 8 gigs of ram, and a non-fancy memory-saving windowmanager, thunderbird is almost unusable now (large imap mbox), firefox even worse. I don't see why all that additional bloat is needed, or wanted. Please keep in mind, that a lot(!) of people are not able to afford buying new hardware every now and then anymore. And this is getting worse. First the pandemic, then the war in Ukraine, now the war in Middle-East. Shortage of ram/storage/everything (thanks ai) and massivly increased costs of energy, housing, food, insurance, everything. And in the years to come, I am afraid, that will be getting worse. Please think about it, when adding the "next cool feature", 'Keep the internet affordable'. --thunderbird user since 1.0
Regarding FF: Something is probably wrong with your install, or the websites you have open.
As a datapoint: FF + Chrome with lots of stuff open uses 2.6GB on my machine. With XFCE and a GB of other apps, it’s using about 4GB. 15 year old machine. Perf is fine.
Why don't you use an older version?
security reasons. since you can't controll what other people are sending to you, you always want to use the most recent as-bug-free-as-possibly version, see https://www.mozilla.org/en-US/security/known-vulnerabilities...
1. Goes to site. Clicks appointment.tb.pro link in sidebar.
2. Gives email address.
3. Is told to join the waitlist.
4. Blocks email address given at 2.
Hardly a terrific experience.
I'm curious how it blocked your email, could you share more details on what message you got? Feel free to reach out to me outside of HN.
Yeah. We need to create a docker container and make it easy to deploy for folks. We're not ready with the hosted option at the moment.
> Come talk to us and build with us
do we need an appointment :)
Thanks, looks like a great alternative
"Thunderbird, the open source Cal.com"
Love it!
This seems kind of crazy. If LLMs are so stunningly good at finding vulnerabilities in code, then shouldn't the solution be to run an LLM against your code after you commit, and before you release it? Then you basically have pentesting harnesses all to yourself before going public. If an LLM can't find any flaws, then you are good to release that code.
A few years ago, I invoked Linus's Law in a classroom, and I was roundly debunked. Isn't it a shame that it's basically been fulfilled now with LLMs?
https://en.wikipedia.org/wiki/Linus%27s_law
After a release, attackers have effectively infinite time to throw an LLM against every line of your code - an LLM that only gets smarter and cheaper to run as time passes. In order to feel secure you’d need to do all the work you’d imagine an attacker would ever do, for every single release you ship.
> attackers have effectively infinite time
No, attackers are also rational economical actors. They don't randomly attack any software just for the aesthetics beauty of the process. They attack for bounty, for fame, for national interest, etc. No matter the reason it's not random and thus they DO have a budget, both in time and money. They attack THIS project versus another project because it's interesting to them. If it's not, they might move to another project but they certainly won't spend infinite time precisely because they don't have infinite resources. IMHO it's much more interesting to consider the realistic arm race then theoretical scenarii that never take place.
The amount of time they will invest is proportional to how much usage / how high value the target is. If your release is used by no one then no one is going to attack it, but it didn't matter anyways.
The first few times it's going to be expensive, but once everyone level sets with intense scans of their codebases, "every single release" is actually not that big a deal, since you are not likely to be completely rebuilding your codebase every release
You still have to account for the non-deterministic behavior of an LLM, when do you know you have exhausted its possible outcomes for any given piece of code?
I'm not sure. An innocuous one line change like "bump version" possibly adds a million new lines of code.
This assumes that the relationship between "LLM tokens spent" and "vulnerabilities found" doesn't plateau, though.
But so do you and all your users what’s your point?
No? I can't go out and retroactively fix a bug in a version my users are using? I need to release a new version?
As LLMs improve and adoption grows, maintaining a FOSS project is becoming more complex and more expensive in terms of time and manpower. That part is easy to understand.
It is also become a trend that LLM-assisted users are generating more low-quality issues, dubious security reports, and noisy PRs, to the point where keeping the whole stack open source no longer feels worth it. Even if the real reason is monetization rather than security, I can still understand the decision.
I suspect we will see more of this from commercial products built around a FOSS core. The other failure mode is that maintainers stop treating security disclosures as something special and just handle them like ordinary bugs, as with libxml2. In that sense, Chromium moving toward a Rust-based XML library is also an interesting development.
Just use AI to fight AI, that's the only sensible way we can keep up. So if you're low-quality PRs, reports etc, have LLMs filter them out. Like how once upon a time we used to drown in email spam but it's now mostly a non-issue thanks to intelligent spam filters, the same needs to happen for opensource projects. Use AI to fight AI.
In other words, have more money to pay than your enemy.
This game will end horribly.
LLMs really are stunningly good at finding vulnerabilities in code, which is why, with closed-source code, you can and probably will use them to make your code as secure as possible.
But you won't keep the doors open for others to use them against it.
So it is, unfortunately, understandable in a way...
I'm not a security expert but can't close source applications be vulnerable and exploited too? I feel like using close source as a defense is just giving you a false sense of security.
Finding a vulnerability in a black box is drastically different from finding one in a white box. This isn’t about whether there is a vulnerability or not, but about the likelihood of it being found.
No it isn't. There is a tooling gap, and there is a skill gap, but both of those are being rapidly closed by both open and closed source projects.
LLMs, and tools built to use them, are violating a lot of assumptions these days.
It's a meaningful difference for SaaS. Most likely an attacker doesn't have access to your running binary let alone source code, and if they probe it like a pentester would it will be noisy and blocked/flagged by your WAF.
What is being phrased as obscurity is one of the approaches to security as long as you are able to keep the code safe. Your passwords, security keys are just random combination of strings, the fact that they are obscure from everyone is what provides you the security
Decompilation and you are back to the level of security you started with. OpenSSH is open for a good reason. Please acknowledge your error. Are you AI?
How do you decompile a SaaS? They're a SaaS.
OTOH, their position seems to be "many LLMs make shallow bugs" is unhelpful; same as many eyes make shallow bugs considered unhelpful.
What seems genuinely needed by the open source economy to both surface these latent vulns and tamp down finding-slop is a new https://bughook.github.com/your/repo/ that these big LLMs (Mythos, etc.) support. Mythos understands if it's been used to find an vuln, and back end auto-reports verified findings the git service can feed to a Dependabot type tool.
Even better, price up Mythos to cover running a background verifier that gets the project, revalidates the issue, before that bughook.
Meanwhile, train it on these findings, so its future self doesn't create them.
Delaying attacks is a form of valid security.
You don't need the source, the LLM has the source, it is called the binary.
LLM like humans can find vulnerabilities in black boxes. We already established 30 years ago that open source is usually more secure than closed source and that security by obscurity doesn't work.
I suspect that AI is a convenient excuse to go closed source. They have probably wanted to do that for years after leaning more commercial.
Every change would introduce the possibility of a vulnerability being added to the system and one would need to run the LLM scan across the entire code base. It gets very costly in a environment where you are doing regular commits. Companies like Github already provide scanning tools for static analysis and the cost is already high for them.
Might lead to a move away from continuous delivery back towards batched releases.
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.
Attackers only need LLMs to be good at randomly finding one vulnerability, whereas service providers need them to be good at finding all such vulnerabilities.
Write simple code. Do what you said, which is a very good idea. Test LLM security against the compiler too.
It's entirely possible to address all the LLM-found issues and get an "all green" response, and have an attacker still find issues that your LLM did not. Either they used a different model, a different prompt, or spent more money than you did.
It's not a symmetric game, either. On defense, you have to get lucky every time - the attacker only has to get lucky once.
> It's not a symmetric game, either. On defense, you have to get lucky every time - the attacker only has to get lucky once.
This! I love OSS but this argument seems to get overlooked in most of the comments here.
I mean, you should definitely have _some_ level of audit by LLMs before you ship, as part of the general PR process.
But you might need thousands of sessions to uncover some vulnerabilities, and you don’t want to stop shipping changes because the security checks are taking hours to run
[dead]
This is a weird knee-jerk reaction. I feel like this is more a business decision than a security decision.
I feel like with AI, self-hosting software reliably is becoming easier so the incentives to pay for a hosted service of an OSS project are going down.
AI is certainly getting a lot of milage as an excuse for doing bad things.
Wanna sack a load of staff? - AI
Wanna cut your consumer products division? - AI
Wanna take away the source? - AI
Well, first AI uses security to sell models. So other companies hijack their narrative for their purposes. This is how marketing works.
I think people are finding ways to either enable “pro” features and at least find the right extension points to implement them easily with LLMs. Security is window dressing.
Yeah, I don't buy it. If they don't want these security reports, ignore them and continue your path. Blaming AI is just an excuse to close source. If you don't want AI to learn from your code, too late. Add genetic algorithms and fuzzing into AI and it can iterate and learn a billion times faster, no need to learn for humans.
Their product is getting commoditized: https://workspace.google.com/resources/appointment-schedulin...
Calendar apps have been commoditized for about 15 years now but they keep growing!
The real downside to Google's solution is that you have to use Google Meet. Depending on your opinion of Meet, this is either no big deal or a total deal breaker.
I always felt it was a matter of time before Google took notice.
It has always been odd to me they didn’t have this functionality years ago. It’s been requested for a long long time
Remember when calendly went out of business?
correct. guy's doing mental gymnastics all to say he's a sellout.
Hey cal.com, as a potential customer, you have just lost me. Open source is set to profit from improved transparency in the SSDLC. With closed source, you will have to trust the software vendor instead.
I'm not sure I agree with Drew Breunig, however. The number of bugs isn't infinite. Once we have models that are capable enough and scan the source code with them at regular intervals, the likelihood of remaining bugs that can be exploited goes way down.
I 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.)
That, and plenty of closed-source software at least has a decent security track record by now. I haven't seen an obvious cause-and-effect of open-source making something more secure. Only the other direction, where insecure closed-source software is kept closed because they know it's Swiss cheese.
They probably lack a sufficient density of people who remember why "security through obscurity" become an infamous concept. It belongs to that family of bad ideas that's superficially appealing, especially if you're still at that stage of your career at which you think past generations were full of idiots and you, alone, have discovered how to do real software development.
This is not security via obscurity; it is reducing your attack surface as much as possible.
Reducing your attack surface as much as possible via obscurity.
I think cal.com is assuming LLMs are only good at hacking with the source code of the target, whether that's true I don't know
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.
Fully agree. But cal.com is SaaS-only, after they move to closed-source, there will be nothing to download.
right, they're just securing their application by making the bugs obscure. It's totally different.
Security through obscurity is still better than no obscurity...
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
Are you at all worried that the message you are spreading here is "We are no longer confident in our own ability to secure your data?"
That's exactly the message I got from the video
That's literally the message
Right, but those capabilities are available to you as well. Granted the remediation effort will take longer but...you're going to do that for any existing issues _anyway_ right?
I understand why this is a tempting thing to do in a "STOP THE PRESSES" manner where you take a breather and fix any existing issues that snuck through. I don't yet understand why when you reach steady-state, you wouldn't rely on the same tooling in a proactive manner to prevent issues from being shipped.
And if you say "yeah, that's obv the plan," well then I don't understand what going closed-source _now_ actually accomplishes with the horses already out of the barn.
> those capabilities are available to you as well
Give him $100 to obtain that capability.
Give each open source project maintainer $100.
Or internalize the cost if they all decide the hassle of maintaining an open source project is not worth it any more.
I'm not aiming this reply at you specific, but it's the general dynamic of this crisis. The real answer is for the foundational model providers to give this money. But instead, at least one seems to care more about acquiring critical open source companies.
We should openly talk about this - the existing open source model is being killed by LLMs, and there is no clear replacement.
I don't think this really helps that much. Your neighbor could ask an LLM to decompile your binaries, and then run security analysis on the results.
If the tool correctly says you've got security issues, trying to hide them won't work. You still have the security issues and someone is going to find them.
If I understand correctly, their primary product is SaaS, and their non-DIY self-host edition is an enterprise product. So your neighbor wouldn't have access to the binaries to begin with.
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.
A little harder when you don’t have the source or the binaries.
Couldn't you just spend those $100 on claude code credits yourself and make sure you're not shipping insecure software? Security by obscurity is not the correct model (IMO)
> neighbors son 15 mins and $100 claude code credits
Is that true? Didn't the Mythos release say they spent $20k? I'm also skeptical of Anthropic here doing essentially what amounts to "vague posting" in an attempt scare everyone and drive up their value before IPO.
Why not can’t you (as in Cal.com) spend that amount of money and find vulnerabilities yourself?
You can keep the untested branch closed if you want to go with “cathedral” model, even.
> since it takes my 16 year old neighbors son 15 mins and $100 claude code credits to hack your open source project
To what end? You can just look at the code. It's right there. You don't need to "hack" anything.
If you want to "hack on it", you're welcome to do so.
Would you like to take a look at some of my open-source projects your neighbour's kid might like to hack on?
Was open source any more secure before LLMs became so cheap? For those same 100$ you could have a North Korean hacking your code for a whole month.
No it doesn't. Have you been actually "hacked"?
What makes you think it'll take him more than 16 mins and $110 claude code credits to hack your closed source project?
SaaS makes that harder.
*This comment sponsored by Anthropic
Please, go ahead!
whooptie fuggin doo, then spend $200 on finding and fixing the issues before you push your commits to the cloud
It's funny that this news showed up just as we (Xata) have gone the other direction, citing also changes due to AI: https://xata.io/blog/open-source-postgres-branching-copy-on-...
We did consider arguments in both directions (e.g. easier to recreate the code, agents can understand better how it works), but I honestly think the security argument goes for open source: the OSS projects will get more scrutiny faster, which means bugs won't linger around.
Time will tell, I am in the open source camp, though.
Just wanted to appreciate the open-source work by Xata. I’ve been eyeing pgroll [1] for schema migrations after Liquibase license shenanigans (the only barrier for me is json-based migration instead of sql-based migrations)
[1] https://github.com/xataio/pgroll
Lame. "We don't want AI pointed at our code so we're going closed source". That's hilarious and a cover up.
I think them going closed source is as much related to security and AI, as work from office is related to productivity in large companies.
So not really.
I think they went closed source as there are too many decent clones based off their code and they realized it's eating up their niche.
> When we started Cal.com, we believed deeply in open source.
No you certainly didn't, otherwise you shouldn't have come up with such a meaningless excuse!
> Today, AI can be pointed at an open source codebase and systematically scan it for vulnerabilities.
So do that and fix your bugs. This post makes no sense.
I know plenty of security researchers who exclusively use Claude Code and other tools for blackbox testing against sites they don’t have the source code for. It seems like shutting down the entire product is the only safe decision here!
Just a random thought. Up until yesterday this project was open source. The code base won’t be rewritten tomorrow. More likely is that conserved parts of the source code, something like 90% will just remain the same. Particularly the core database schema around users and security are likely to stay the same. Since the old code is already out there what’s stopping me from exploiting the software as it was? This looks an awful lot like marketing to me, and not like real security concerns.
The real threat is not security but bad actors copying your code and calling it theirs.
IMHO, open source will continue to exist and it will be successful but the existence of AI is deterrent for most. Lets be honest, in recent times the only reason startups went open source first was to build a community and build organic growth engine powered by early adaptors. Now this is no longer viable and in fact it is simply helping competitors. So why do it then?
The only open source that will remain will be the real open source projects that are true to the ethos.
I agree with you that AI's disruption of attribution is a much bigger problem, but it's also worth recognizing that not everyone has this same motivation. It mostly affects copyleft open source licenses.
Attribution isn't required for permissive many open source licenses. Dependencies with those licenses will oftentimes end up inside closed source software. Even if there isn't FOSS in the closed-source software, basically everyone's threat model includes (or should include) "OpenSSL CVE". On that basis, I doubt Cal is accomplishing as much as they hope to by going closed source.
If you copy the code infringing licenses, yes, it will be harder to legally sort things out.
Otherwise, copying code and improving it with AI or with humans is the same, as long as the product improves.
I doubt that many semi-automatic AI copies can really improve a product more than the original team, for really valid products.
AI will be a filter of bad quality.
> The real threat is not security but bad actors copying your code and calling it theirs.
How has this changed?
Bad actors can rewrite it with AI and claim ownership of the result.
> Now this is no longer viable and in fact it is simply helping competitors. So why do it then?
> The only open source that will remain will be the real open source projects that are true to the ethos.
Well, the second point seems like the answer to the previous question. The original model of monetizing FOSS -- support contracts, risk indemnification, etc., for an otherwise functionally equivalent product -- will still remain viable.
But those trying to thread the needle of trying to use open-source to push a "freemium" model are now going to hit a wall: if you were withholding features from the community version in order to paywall them for the premium version, and now AI has made it easy for users to add those features back without paying you, then you're screwed. The people who were going to use AI to bypass your paywall are still not going to be your customers, but you no longer have the differentiator to put you ahead of the competitors that were already closed-source to begin with for the customers who are willing to pay.
I originally deployed Cal.com because I wanted an open-source solution. But now, why would I choose a closed-source Cal.com over Calendly? If I'm forced to go SaaS, I'll probably go with the more widely used Calendly. If I'm not forced to go SaaS, I'll forego them both, and go back to something like EasyAppointments, knowing that I won't be in conflict with the authors if I choose to add my own "premium" features to it, whether with AI or by hand. All Cal.com did here was remove any chance that I'd ever pay them anything.
This certainly makes me feel better about the project I started a few months ago to replace my Cal.com instance with a smaller, simpler self-hosted tool
https://git.sr.ht/~bsprague/schedyou
Very weak argument. You could have had the same speech before AI.
I would rather say that the core product is not strong and differentiated enough to resist this new age of coding, and it's an attempt to protect revenues.
> Today, we are making the very difficult decision to move to closed source, and there’s one simple reason: security.
(Enter name of large software vendor here) has long-since proven that security through obscurity is not a real thing.
I'm sorta suspicious. I don’t really think this is why they are moving to closed source. It’s true that there is more security risk, but that actually justifies being open source, because open source tooling can spend more tokens hardening itself against security vulns than closed source tooling (at least, that’s the theory). My strong hunch is they are moving to closed source because it is now trivial to copy a product with AI clean rooms. Which, tbf, is a totally valid reason to move closed source. But I'd want to see more adoption of something like the Ship of Theseus license (https://github.com/tilework-tech/nori-skillsets/pull/465/cha...) before giving up on open source entirely
> My strong hunch is they are moving to closed source because it is now trivial to copy a product with AI clean rooms. Which, tbf, is a totally valid reason to move closed source.
The "clean room" part of clean-room reverse engineering implies that there is no exposure to the original copyrighted code on the part of those doing the reimplementation, whether human developers or AI. Traditionally, if you're working of the source code itself, you have one party translate the source code back into a design document, specifying behavior, and then you have another party implement that design spec with original code.
If you already have a running copy of the software to model the behavior off of, then you don't need the original source code in the first place. So going closed source will have zero effect on the capacity of AI tools to be used for clean room reverse engineering: all you need is the runtime.
> But I'd want to see more adoption of something like the Ship of Theseus license (https://github.com/tilework-tech/nori-skillsets/pull/465/cha...) before giving up on open source entirely
This license doesn't seem valid: a license can't redefine what qualifies as a derivative work. That's determined by copyright law itself, and if copyright law says that a clean-room reimplementation isn't a derivative work, then it isn't restricted by copyright, so doesn't need a license in the first place.
> My strong hunch is they are moving to closed source because it is now trivial to copy a product with AI clean rooms. Which, tbf, is a totally valid reason to move closed source.
Since such "clean room" implementations ostensibly do not see the source, it's arguably irrelevant whether such sources are open are not. Such implementations will happen regardless of whether the sources they're reimplementing are opened or closed.
> because open source tooling can spend more tokens hardening itself against security vulns than closed source tooling (at least, that’s the theory)
Whose theory? That makes no sense at all. The creator can spend the same amount on tokens whether it is closed or open source.
I very much doubt that addendum would hold up to a lawyer.
This is completely stupid and ridiculous. Why not just use AI to patch your software? Its just as effortful as someone finding and exploiting a vuln on your system.
What's worse is your choosing to keep it buggy behind closed doors so no one can see the bugs. That's 100% the wrong approach.
> Today, we are making the very difficult decision to move to closed source, and there’s one simple reason: security.
It seems like an easy decision, not a difficult one.
Today, AI can be pointed at an open source codebase and systematically scan it for vulnerabilities.
AI also goes a long way towards erasing the distinction between source code and executable code. The disassembly skill of a good LLM is nothing short of jaw-dropping.
So going closed-source may be safer for SaaS, but closing the source won't save a codebase from being exploited if the binaries are still accessible to the public. In that sense, instead of dooming SaaS as many people have suggested AI will do, it may instead be a boon.
Today, it's easy to (publicly) evaluate the ability of LLMs to find bugs in open source codebases, because you don't need to ask permission. But this doesn't actually tell us the negative statement, which is that an LLM won't just as effectively find bugs in closed codebases, including through black-box testing, reverse engineering, etc.
If the null hypothesis is that LLMs are good at finding bugs, full stop, then it's unclear to me that going closed actually does much to stop your adversary (particularly as a service operator).
The AI companies profit hugely from open source. In fact, without open source, their most significant financial success (coding assistants) wouldn't exist.
They should provide free continued git commit security analysis for open source projects. That would increase the quality of open source projects and would inspire more projects to go open source, which is also a win for the AI companies.
This was my thought too. Your tool is great at finding vulnerabilities, and we want software to be secure for everyone, secure code should not be out of reach to those who can't afford it.
Scan everyone's code, for free. Make all code as secure as an llm can make it as a baseline.
Monumentally 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?
Coss.com reads like a half assed pivot if you look at it with today's news. It's clear cal.com isn't making enough money and going closed source is yet another attempt to fix that.
Oh wow the coss.com thing makes this so much worse. Making such an aggressive and public commitment to open source to then turn around and do something like this is a pretty rough look.
Proposition 1: The majority of a code in a modern app is from shared libraries
Proposition 2: The most popular shared libraries are going to be quickly torn apart by LLM security tools to find vulnerabilities
Proposition 3: After a brief period of mass vulnerability discovery, the overall quality of shared libraries will dramatically increased.
Conclusion: After the initial wave of vulnerabilities has passed, the main threat to open source code bases is in their own comparatively small amount of code.
Related ongoing threads:
Open Source Isn't Dead - https://news.ycombinator.com/item?id=47780712
Cybersecurity looks like proof of work now - https://news.ycombinator.com/item?id=47769089
Surely the argument is just to have an LLM stressing for vulnerabilities during the build pipeline before merging to main? Resulting in better security from LLMs.
One must assume this was a direction they wanted to move towards and this is the justification they thought would be most palatable.
Security through obscurity can be a good security layer, but you need to maintain obscurity. That's a lot harder than Cal.com seems to realize.
For example using something like Next.js means a very large chunk of important obscurity is thrown out the window. The same for any publicly available server/client isomorphic framework.
I'm not sure security through obscurity is a great practice?
Not to mention, I presume the core bits of Cal.com's source code are already in place and aren't going to change significantly?
Like, this feels like a business decision and not a security decision
This sounds more like a good excuse to go closed source. I feel that real reason might be revenue-related.
The founder proclaimed "Open Source is Dead" in the original tweet.
I thought this was grandiose and projecting their own weakness onto others, an extremely unappealing marketing position that may get clicks in the short term but will undermine trust beyond that.
What's preventing cal.com to run the AI researcher over their own codebase and find their vulnerabilities before anyone else and patch them all by tomorrow morning?
That's right. Nothing.
Unwilling to pay AI tax, maybe?
No worries, someone else will do that for them. Just like they explained.
And given that they will not rewrite the whole codebase in the next few days it means that security vulnerabilities are still there to be discovered by someone willing to pay the AI tax.
I am beyond convinced at this point that you either run an Open Source Project with a small revenue company (single digit millions) or run a software company that does more than 10M ARR at the least and be closed source. I know there are exceptions but most open source Software companies are providing code with heavy restrictions or teaser features and gate keep everything in their "ee/enterprise" version etc.
Security through obscurity isn't a great strategy.
Think this is a bad, bad move...
https://news.ycombinator.com/item?id=47780712
Juxtapose this with the fact that many HNers will decry strong copyleft FOSS licenses as not being truly "open source" - the reality is that closed source software is still full of open-source non-copyleft dependencies. Unless you're rolling your own encryption and TCP stack, being closed source will not be the easy solution that many imagine it to be.
Where is the Windows TCP stack source?
Let me share the press release template for 2026:
Hi {audience},
It is with a heavy heart that I have to announce that {thing we were going to do anyway} is necessary due to AI. AI has changed the industry and we are powerless to do anything other than {unpopular decision we were going to do regardless}.
Open source means living under constant scrutiny. AI just made that scrutiny cheaper and faster. I feel this every day maintaining an open source project. The temptation to close the source is real but let’s not forget that open source is what raised the bar for software quality in the first place.
Not really. Open source just means distributing the source. Either via CD or some internet based protocol.
Maybe you are referring to the whole Github thing.
I mean, by definition, open source means that the source code is available and therefore _open_ to scrutiny. Regardless of how it is distributed.
Right. But what is the problem?
* Someone lols at code. Answer: ignore them.
* Someone sees your vulns. Answer: someone is already trying to hack you anyway.
Open source is what made this AI shitshow possible in the first place.
this is a big nothing. they relicensed the previous cal.com as cal.diy (MIT by the way, instead AGPL or something else) and effectively forked their own product into the "new" cal.com. anyone who cares would just use cal.diy as they were prior to this announcement with cal.com
We’d hope but they could neuter Cal.diy over time. From their chart between the differences of cal.diy and cal.com, teams are not supported. I’m self hosting Cal.com and I think I do have access to teams as of right now.
That’s incorrect - they explained that cal.diy is missing a lot of recent changes.
Something about a scheduling/productivity app (one of the most common vibe-coded projects people make) being the subject of this is funny to me. I wonder how many tokens have been wasted making apps like this, let alone time.
I only found cal.com in the first place because I searched for an open source calendly alternative.
This is the future now that AI is here. Publishing is going to be dead, look at the tea leaves, how many engineers are claiming they don’t use package managers anymore and just generate dependencies? 5 years and no one will be making an argument for open source or blogging.
The article is leaking from all sides. As a wannabe hacker would find a hole in a public repo, what can the repo owner do, who knows every detail of the project and has a high interest in it, also economically?
Sounds like "security by obscurity" to me - if you think AI is so good at finding security issues - it will find them in compiled code as well. Why not using it in your favor and let it search for bugs you'd otherwise not find?
You can lock down the source and also use AI to look for bugs in it. It does take significantly more time and money for AI to find bugs in compiled code.
That said, I agree with another commenter that this seems like more of a business decision than a security one.
Isn't the joke that everything is open source if you can read assembly? Pretty sure someone is working on an AI that reads assembly... Not sure hiding the codebase away is a viable solution!
That may be true for software that you download and install as an app, but for SaaS, there is no need to expose the code to anyone at all. Only your API endpoints are available. You can try and "black box reverse engineer" through the client code and its API calls, but that's not the same as having the server code in hand to pick apart.
Well let’s just finish and CLOSE them off. Delete all your subscriptions, boys.
In my advisory job founders always raise the question about open sourcing within the first hour of meeting me. They think that open sourcing product means transparency and developer trust which helps with early adoption. Every single founder I talked to brings up open source as a market penetration method to drive the initial adoption.
I always say to just stop with the virtue signaling led sales technique.
I despise the "we are like the market leader of our niche but open source" angle. Developer as a buyer and as a community these days in my opinion do not care about open source anymore. There is no long term value to that. The moment a product gets traction the open source elements is a constant mild headache as open source product means that they have no intellectual copyright on the core aspect of the product and it is hard to raise money or sell the company. And whenever a product gets traction they will take any excuse to make it close source again. With an open source product they are just coasting on brand. Regardless of what your personal opinion is, this has been largely true for most for-profit business.
Open source is largely is nothing more then a branding concept for a company who is backed by investors.
> Open source is largely is nothing more then a branding concept for a company who is backed by investors.
And a religion that was invented by those who wanted to have all the world's code for free to train AI to code.
Will it make any difference to security? LLMs are excellent pattern matchers. The source is a sequence of tokens, the binary is a sequence of tokens. Whats the difference to an LLM?
I'm all for FOSS as well, but not sure I would have open sourced the commercial offering to begin with. Love the idea though, it's so bold.
This reads like a post from 1995.
"But if everyone can read the source code, they'll be able to find vulnerabilities more easily!"
No. Security by obscurity has proven wrong.
This is why CC0 and MIT matter for projects people depend on. Once you build on something with a restrictive license this is always a risk.
Chatgpt, write me a reason to make more money as a tech ceo.
Charge for api access, take a cut of the extensions economy.
How do i do that, I'm open source?
Could you not simply point AI at your open source codebase and use it to red-team your own codebase?
This post's argument seems circular to me.
Judging by the CEOs picture on LinkedIn, he's full of himself.
Good for them. I’m sure they saw the writing on the wall when Monday.com was cloned. This is the right move.
I honestly was surprised with the response I got, for what was basically a Sunday hack project: https://github.com/rbbydotdev/someday
I think people really like how it's free (runs on google app scripts) and open source.
I've personally moved onto google's free gmail calendar scheduling tool, which strangely took pretty long to come to market. Calendly stretches back to ... 2013?
Scheduling, oddly feels a little niche (maybe less so today?), when it shouldn't be. Maybe there some more opportunity there.
I guess this is an AI excuse again.
Who even uses their open source product?
EasyAppointments (https://github.com/alextselegidis/easyappointments) is still FOSS. We managed our team calendars on it at a previous company, but I rolled out Cal.com due to more apparent support and sophistication at my current company. Turns out most of that sophistication turned out to be bloat: we saw successive version releases add features we didn't care about while increasingly putting previously open features, like team calendars, behind a paywall.
This move by Cal.com seems to be transparently an attempt to maintain that paywall against users who'd otherwise just use LLMs to remove it. I guess it's back to EasyAppointments, which still seems to work just fine.
Security through obscurity has been known to be a faulty approach for nearly 200 years. Yet here we are.
This has one of the most shittiest codebase out of all. Not surprised by this move.
Security via obscurity and you get to blame AI too! What a win for their marketing team.
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. :)
Changed the license of the foss version cal.diy to MIT . Grace in disguise , now enterprise user can host cal.diy without worries of viral licensing .
That was my point. Only reason they were using the AGPLv3 in the first place was as a hush hush non-compete, and now that that doesn't matter...
Security through obscurity has always worked out so well.
AI sure is useful as a scapegoat for any negative PR inducing moves.
Cal.com is failing. This is a rugpull with an AI excuse.
I guess why fix vulnerabilities when you can just obscure them?
There are endless closed calendar options. Cal.com being FOSS and not making us feel locked in forever was the only reason we chose it over wasting limited cycles self hosting this at Distrust and Caution.
AI can clone something like cal.com with or without source code access, so in trying to pointlessly defend against AI they are just ruining the trust they built with their customers, which is the one thing AI can never create out of thin air.
We exclusively run our companies with FOSS software we can audit or change at any time because we work in security research so every tool we choose is -our- responsibility.
They ruined their one and only market differentiator.
We will now be swapping to self hosting ASAP and canceling our subscriptions.
Really disappointing.
Meanwhile at Distrust and Caution we will continue to open source every line of code we write, because our goal is building trust with our customers and users.
Security by obscurity has never been real.
thats like the funniest excuse to cash out on people's open source contributions
Saaspocalypse is coming for cal.com
TIL I learned about yet another calendar application I don't need. Someone should setup their openclaw to just write a new todo/calendar app each week; they'll be billionaires by the end of the year.
Cal.com was open source?
This is some truly exceptionally clownish attention seeking nonsense. The rationale here is complete nonsense, they just wanted to put "because AI" after announcing their completely self-serving decision. If AI cyber offense is such a concern, recognize your role as a company handling truckloads of highly sensitive information and actually fix your security culture instead of just obscuring it.
I mean it's not complete nonsense, but yeah, doing it for security reasons sounds like BS. I actually thought this was going to be about how AI makes it super easy for someone to steal all their code and fold it into their own competing project. I've seen a few open source projects get sideswiped by this, AI is pretty good at copying code (and obfuscating the fact that it was copied). I suspect that's the real reason but it doesn't sound as good. So they went with this half-truth.
Sounds backwards to me.
- You know, Lindsay, as a software engineering consultant, I have advised a number of companies to explore closing their source, where the codebase remains largely unchanged but secure through obscurity.
- Well, did it work for those companies?
- No, it never does. I mean, these companies somehow delude themselves into thinking it might, but... but it might work for us.
Risk tolerance and emotional capacity differs from one individual to another, while I may disagree with the decision I am able to respect the decision.
That said, I think it’s important to try and recognize where things are from multiple angles rather than bucket things from your filter bubble alone, fear sells and we need to stop buying into it.
I have fond memories of this project. Contributing to it really helped me ramp up my dev skills and was effectively my introduction to monorepo’s in JavaScript. It was the kind of codebase I couldn’t get my hands on while working in my part of the world. Good luck going closed source.
This seems dishonest, like someone is forcing the decision for other reasons, and they're using security and AI as a distraction.
security by obscurity doesn't work.
> security by obscurity doesn't work.
That is not true.
https://en.wikipedia.org/wiki/Security_through_obscurity
Security through obscurity doesn't work in isolation. It doesn't work as the only solution. It is discouraged, because it can be a panacea.
But it also doesn't hurt in many instances. Holding back your source code can be a strategic advantage. It does mean that adversaries can't directly read it (nor can your friends or allies!)
Having a proprietary protocol or file format, this is also "security through obscurity" and it may slow down or hinder an attacker. Obscurity may be part of a "defense in depth" strategy that includes robust and valid methods as well.
But it is harmful to baldly claim that "it doesn't work".
Enshittification has come for VC backed open-source. AI has deemed commercial open source obsolete especially when users can point Calude Code to calcom on GitHub and ask it to make them scheduling features directly into their product. That’s what spooked Cal.
I hate how this sounds...but this reads to me "we lack the confidence in our code security so we're closing the source code to conceal vulnerabilities which may exist."
LOL. Every generation has to learn anew that security through obscurity is no security at all.
Security by obscurity. Good luck. So novice.
This has to be the most bullshit reason I've seen.. if AI can be pointed and find vulnerabilities then do it yourself before publishing the code.
> if AI can be pointed and find vulnerabilities then do it yourself before publishing the code
At your cost.
Every time you push. (or if not that, at least every time there is a new version that you call a release)
Including every time a dependency updates, unless you pin specific versions.
I assume (caveat: I've not looked into the costs) many projects can't justify that.
Though I don't disagree with you that this looks like a commercial decision with “LLM based bug finders could find all our bad code” as an excuse. The lack of confidence in their own code while open does not instil confidence that it'll be secure enough to trust now closed.
For-profit companies using open-source software should bear that cost - that's my position.
I believe than N companies using an open source project and contributing back would make this burden smaller than one company using the same closed-source project.
[dead]
[dead]
[dead]
[dead]
[dead]
users can just point Claude Code at cal on GitHub and ask it to build xyz features directly into their own product .. and most of them won't bother following the license. it's happening with so many projects in open source
[dead]
You know what?
Great move.
Open-source supporters don't have a sustainable answer to the fact that AI models can easily find N-day vulnerabilities extremely quickly and swamp maintainers with issues and bug-reports left hanging for days.
Unfortunately, this is where it is going and the open-source software supporters did not for-see the downsides of open source maintenance in the age of AI especially for businesses with "open-core" products.
Might as well close-source them to slow the attackers (with LLMs) down. Even SQLite has closed-sourced their tests which is another good idea.
The tools are available to everyone. It's becoming easier for hackers to attack you at the same speed that it's becoming easier for you to harden your systems. When everyone gains the same advantage at the same time, nothing has really changed.
It makes me think of how great chess engines have affected competitive chess over the last few years. Sure, the ceiling for Elo ratings at the top levels has gone up, but it's still a fair game because everyone has access to the new tools. High-level players aren't necessarily spending more time on prep than they were before; they're just getting more value out of the hours they do spend.
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, particularly when they may be hosting sensitive user data that could ruin their customers' businesses or lives.
I think Cal are making the wrong call, and abandoning their principles. But it isn't fair to say the game is accelerating in a proportionate way.
See: https://www.youtube.com/watch?v=2CieKDg-JrA
Ultimately, he concludes that while in the short run the game defines the players' actions, an environment that makes cooperation too risky naturally forces participants to stop cooperating to protect themselves from being "exploited" (this bit is around 34:39 - 34:46)
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 right move.
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.
Haven't the SQLite tests always been closed? Getting access to them is a major reason for financially supporting them
> especially for businesses with "open-core" products.
Then good, that overengineered, intentionally-crippled crap should go away.
Take it back to linkedin!