Live data from Hacker News

Cal.diy: open-source community edition of cal.com

github.com

21–30 of 75 posts

Re: Cal.diy: open-source community edition of cal.com

#21
post #8

From the docs, "It is strictly recommended for personal, non-production use." Wow what a 180 from just a year ago when their blog said, "For companies that handle sensitive information, deploying open-source scheduling software on-premises can offer an extra layer of security. Unlike cloud services controlled by external vendors, on-prem installations let teams maintain full ownership of their infrastructure. " ¹ I j…

I think this is less a bait and switch and more just a legal liability shield. They're not saying you 'cant' use it that way. They just don't recommend you do, and they won't support you at all for doing so. Which I think is completely fair. Also, these two things aren't in contradiction. Deploying on prem does offer more security, but then it's up to you to use it correctly.

This actually makes me wonder if cal.com has had a security breach in their hosted offering that they are not disclosing.

Re: Cal.diy: open-source community edition of cal.com

#22
post #11

Earlier quoted context omitted.

https://cal.com/blog/cal-com-goes-closed-source-why

I'm unpersuaded by the assertion that closing the source is an effective security bulwark. From that page: > Today, AI can be pointed at an open source codebase and systematically scan it for vulnerabilities. Yeah, and AI can also be pointed at closed source as soon as that source leaks. The threat has increased for both open and closed source in roughly the same amount. In fact, open source benefits from white hat s…

How are LLMs at reading assembly? I assumed they’d be able to read assembly about as well as any other language…

Is there such a thing as a closed source program anymore?

Re: Cal.diy: open-source community edition of cal.com

#23
post #11

Earlier quoted context omitted.

https://cal.com/blog/cal-com-goes-closed-source-why

I'm unpersuaded by the assertion that closing the source is an effective security bulwark. From that page: > Today, AI can be pointed at an open source codebase and systematically scan it for vulnerabilities. Yeah, and AI can also be pointed at closed source as soon as that source leaks. The threat has increased for both open and closed source in roughly the same amount. In fact, open source benefits from white hat s…

The HN discussion on the announcement is just 90% posts of the theme "if a student can brute force your FOSS for $100, they can do you proprietary code for $200" and "if it's that cheap to find exploits, why don't you just do it yourself before pushing the code to prod?"

I believe that the reason the chose to close the source is just security theater to demonstrate to investors and clients. "Look at all these FOSS projects getting pwned, that's why you can trust us, because we're not FOSS". There is, of course, probably a negative correlation between closing source and security. I'd argue that the most secure operating systems, used in fintech, health, government, etc, got to be so secure specifically by allowing tens or hundreds of thousands of people to poke at their code and then allowing thousands or tens of thousands of people to fix said vulns pro bono.

I'd be interested to see an estimation of the financial value of the volunteer work on say the linux or various bsd kernels. Imagine the cost of PAYING to produce the modern linux kernel. Millions and possibly billions of dollars just assuming average SWE compensation rates, I'd wager.

Too bad cal.com is too short sighted to appreciate volunteers.

Re: Cal.diy: open-source community edition of cal.com

#24

Wait, I didn't even realize Cal.diy is owned by Cal.com. It seems like they're trying to get ahead of the open source community forking by doing this themselves

How curious. Are they trying to throw security shade on running open source? Very odd.

Re: Cal.diy: open-source community edition of cal.com

#25
post #11

Earlier quoted context omitted.

I'm unpersuaded by the assertion that closing the source is an effective security bulwark. From that page: > Today, AI can be pointed at an open source codebase and systematically scan it for vulnerabilities. Yeah, and AI can also be pointed at closed source as soon as that source leaks. The threat has increased for both open and closed source in roughly the same amount. In fact, open source benefits from white hat s…

The HN discussion on the announcement is just 90% posts of the theme "if a student can brute force your FOSS for $100, they can do you proprietary code for $200" and "if it's that cheap to find exploits, why don't you just do it yourself before pushing the code to prod?" I believe that the reason the chose to close the source is just security theater to demonstrate to investors and clients. "Look at all these FOSS pr…

> Millions and possibly billions of dollars just assuming average SWE compensation rates

Yeah, and average kernel devs are not average SWEs

Re: Cal.diy: open-source community edition of cal.com

#27
As a former cal.com advocate, I am now going to be switching my two companies to cal.diy or a similar alternative and canceling my cal.com subscriptions.

I am now actively rooting for cal.com to go out of business now as a cautionary tale for any company thinking about taking open source projects proprietary.

FOSS || GTFO

Re: Cal.diy: open-source community edition of cal.com

#28
post #8

Earlier quoted context omitted.

I think this is less a bait and switch and more just a legal liability shield. They're not saying you 'cant' use it that way. They just don't recommend you do, and they won't support you at all for doing so. Which I think is completely fair. Also, these two things aren't in contradiction. Deploying on prem does offer more security, but then it's up to you to use it correctly.

This actually makes me wonder if cal.com has had a security breach in their hosted offering that they are not disclosing.

It seems to be more that they're using "security" as a reason for going closed source, so this is just sticking with the story.

Re: Cal.diy: open-source community edition of cal.com

#29
Here is a simple trick: do accept plenty of open source contributions as-is, without any kind of copyright assignment nor requiring to sign anything that grants power to relicense.

There you go, guaranteed community ownership of the code, best face and "good will" as promised by choosing a FOSS license to begin with, and future rug pulls averted.

Seeing it from the other side of the fence: if you see that all contributors are required to cede controlling power into a single hand (except certain Foundations, yadda yadda), it's not proper Open Source in spirit, only in form; and closeups are just a change of mind away.

Re: Cal.diy: open-source community edition of cal.com

#30
post #11

Earlier quoted context omitted.

I'm unpersuaded by the assertion that closing the source is an effective security bulwark. From that page: > Today, AI can be pointed at an open source codebase and systematically scan it for vulnerabilities. Yeah, and AI can also be pointed at closed source as soon as that source leaks. The threat has increased for both open and closed source in roughly the same amount. In fact, open source benefits from white hat s…

How are LLMs at reading assembly? I assumed they’d be able to read assembly about as well as any other language… Is there such a thing as a closed source program anymore?

Not only are they good at reading and writing machine code now, they are actively being used to turn video game cartridge dumps back into open source code the community can then compile for modern platforms.

There is no moat anymore.

Post reply on HN