AI has been a mixed bag for the open source world. Some developers are using it to write faster, catch bugs, and review patches more efficiently. Others are watching the same tools get turned against the codebases they maintain.
Cal.com, a popular open source scheduling platform and one of the more well-known self-hostable alternatives to Calendly, has found itself in the second camp. After five years as an open source project, the company has announced that it is switching to a closed-source model, citing the growing threat of AI-powered vulnerability scanning.
What happened?
The co-founder of Cal.com, Bailey Pumfleet, has addressed why they went down this path, saying that AI has changed what it takes to exploit an application. Earlier, finding vulnerabilities meant real expertise and some serious time investment.
But today, an AI model can be directed towards a public repo and do the same job systematically without needing much manual labor.
He also cited a specific case to back this up, where AI tooling reportedly found a 27-year-old vulnerability in the BSD kernel and had working exploits ready within hours.
But, yeah, closed source it is. 😅
Another thing worth knowing is that the production codebase had already been drifting away from what was publicly available. Core systems like authentication and data handling had both gone through significant rewrites, making the public repo and what actually runs in production two fairly different things by the time this announcement came.
Does it make sense?
Cal.com isn't wrong that AI can be used to hunt for vulnerabilities in open source code. That's documented and real. But the provided argument treats AI purely as an attacker's tool, which is a selective reading of the situation.
Take the Linux kernel, for example. We recently covered how Greg Kroah-Hartman, the Linux stable kernel maintainer, has been running what looks like AI-assisted fuzzing on the kernel through a branch he calls "clanker," using it to identify bugs and patch them proactively.
There's even an official policy in place that governs the use of such AI tools for contributions.
Then there's the older argument that closing your source doesn't actually make you more secure. It just means fewer eyes on the code. Open source projects benefit from anyone, anywhere, being able to spot and report problems.
Heartbleed and Log4Shell were both found by external researchers precisely because the code was auditable. This just shows us that a private codebase doesn't prevent vulnerabilities; it just reduces the chances of catching them before someone with bad intentions does.
What's next?
For self-hosters and developers, Cal.diy is what's on offer. It's available now under the MIT license, with the documentation covering installation via Docker, Vercel, Railway, Render, and a handful of other platforms.
The project is described as "strictly recommended for personal, non-production use," with a "use at your own risk" disclaimer throughout. It is community-maintained, with no official backing from Cal.com.
Feature-wise, Cal.diy covers the personal scheduling essentials like event types, calendar integrations, video conferencing, webhooks, and API access.
But a fair bit is missing. Teams, Organizations, SAML SSO, SCIM directory sync, Workflows, Routing Forms, and the Insights Dashboard are all absent from the community edition.
If you're running Cal.com for anything commercial, the Cal.diy documentation steers you back to the paid product pretty explicitly, saying that "for any commercial and enterprise-ready scheduling infrastructure, use Cal.com."
All of that made me wonder, whether AI was the catalyst or the perfect scapegoat for a closed-source transition. Anyway, I like yapping like this every so often; don't mind me.
from It's FOSS https://ift.tt/6yPsNXn
via IFTTT
Tidak ada komentar:
Posting Komentar