Don’t get me wrong but if virtually all modern software infrastructure lives on top of open source and they’re mostly fine then I’d imagine that you can make a scheduling webapp secure independent to if it’s OSS or not.
It’s OK if there’s another reason for this transition, just be transparent about it and don’t treat your users as children.
They don’t owe you a complete list of reasons why they’re close sourcing their software. They are not a publicly traded company and no one (customers) actually cares if the product is open source or not.
I've always used and advocated for Cal.com because it's open source. I understand you need to make money and this is no longer the GTM, but don't lie about it.
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.
Open Core locks important part of a product away behind a proprietary license. If you build on it you need to hope that the company will hang around. If it ever goes away you have to hope that they do the right thing a relicense it.
Whether that part is important depends on how you use that product. A lot of open core models specifically target enterprise users with their premium features.
Likewise, the risk only applies to the premium feature set. If those are that crucial to your operation, you would assess that risk more or less in the same way that you assess a proprietary product - because that is what it is.
For example, if all the security features are essential to your work and you pay for the ultimate version, then Gitlab is more or less a closed source product for you. However, if you are a big company and use self-hosted free version of gitlab to have a cheap inner source hosting for all employees, then it is exactly as if you use an open source product.
There are more nuances of course in a real assessment, but basically the open part is open source and the closed part is proprietary. Very simple.
hey cofounder of cal.com here. the plan has always been to: 1. start and go fast with a mono repo and trpc fullstack api to understand and learn the fastest. once we knew what we need, we were able to build an external facing API. we wanted to be very clear to externals that using our “trpc api” is with caution due to undocumented breaking changes. a lot of companies have an internal API + external API (built later)
going closed source does not mean we are not fighting fire with fire
we are using a handful of internal AI vulnerability scanners for months now
being open source simply reduces risk by 5x to 10x according to several security researchers we are working with https://cal.com/blog/continuous-ai-pentesting-vulnerability-...
reply