baileypumfleet

That's exactly how this read to me too. Ultimately, the whole article is written by a company that does AI vulnerability scanning, and it's to try and get you to sign up for their service.

As it mentions in their article, Strix actually scans the Cal.com codebase and reports vulnerabilities to us. But the reality is, they actually miss so many vulnerabilities that other platforms do find. There's no one platform that seems to be able to reliably find all vulnerabilities, and so simply adopting AI scanners just isn't enough.

We've run an extremely profitable business for five years, raised a seed and a Series A, and grown at 300% a year sustainably while being open source.

Going closed source actually hurts our business more than it benefits it. But it ultimately protects customer data, and that's what we care about the most.

That's absolutely our plan. We have bug bounty programs, we have internal AI scanners, we have manual penetration testing, and a number of other things that enable us to push really hard to find this stuff internally rather than relying on either the good people in the open source community or hackers to find our vulnerabilities.

As I mentioned above, we actually do run these AI scanners on our code, but the problem is it's simply not enough. These AI scanners, including STRIX, don't find everything. Each scanning tool actually finds different results from the other, and so it's impossible to determine a benchmark of what's secure and what's not.

We actually run AI scanners on our code internally, so we get the benefit of security through obscurity while also layering on AI vulnerability scanning, manual human penetration testing, and a huge array of other defence mechanisms.

The AGPL is more to clear up confusion and try and limit people ripping off our software.

Open source definitely isn’t a growth strategy for us. We’re huge open source fans, and do actually believe in what it stands for. We’re open source for a number of other reasons, such as longevity, privacy and genuine passion for OSS software (I’ve wrote more about this in other comments here).

However, yes, we are a company that is VC-backed, and so we have to make some decisions that are for the business side of things, and switching to AGPL is one way of cutting down on people trying to create rip off versions of our product.

All we need is a name and email for your guest. All data is being handled in a way that’s secure and private (we’re open source, you can check the code that touches your calendar), plus for internal security we are SOC 2 compliant and 99% of the way HIPAA compliant.

It’s decorative. Maybe we’ll make it interactive in the future, that could be cool

The other comments are right: the full availability page once you get within the app will let you set whatever hours you want.

We will fix this ASAP though!

Hey - one of the cofounders here.

There’s a lot of reasons why we’re open core.

First is longevity. Especially considering we’re a startup, if a huge company is evaluating using our product, they’re going to wonder if we’re going to disappear in a few years. Open source doesn’t disappear: https://cal.com/blog/longevity

Secondly is that we’re a developer focused product, and so making it open source for hobbyists to play around with is a great way to introduce people to our product with the hopes that one day they’ll build their next company using our scheduling (so it does help as a sales channel, although definitely not the primary reason)

Also transparency and privacy. Users know how their data is being handled, which for me personally is a huge plus. I want to know what the software is doing if I’m giving it access to my calendar.

There are a few other reasons too, maybe I’ll write something on the Cal.com blog

Hey - one of the cofounders here.

We’re experiencing our biggest spike in signups yet (see cal.com/open for the data), so our database got overwhelmed for a second. Rest assured, we’re on it :)

Hey - one of the cofounders here.

That’s a great question. When you connect your calendar with most scheduling apps, there’s really nothing stopping most of them from doing malicious things behind the scenes with your data. You don’t really know if they’re just querying your availability, or actually pulling specific event data.

With Cal.com, that’s different. Since day one, I built it to only check free/busy times and that hasn’t changed. Also, as it’s open source, you can literally go on GitHub and verify what I’m saying, as well as comb through every line of code that touches your calendar.

It’s the same principle that keeps something like the Linux kernel free of malicious software. There’s enough contributors from around the world that audit and review the code, that you can ultimately trust that there’s nothing malicious going on behind the scenes.

Also just to clarify, with how most major providers’ permission systems work, it’s scoped that we can only access your calendar data, and not contents of your email and such.

Hey - one of the cofounders here. It’s exactly this.

I totally get the point that’s being made, but to be able to have a product which is good enough to sell, we have to be able to cater to the hundreds of features that customers tell us we need.

Everything we build is entirely community and customer demand driven, so effectively all of these features are in place to support every different use case that customers require as part of their scheduling needs.

We are looking at ways to make the app simpler, with the advanced options still readily available for those who need it. For example, some of our advanced features are hidden as apps which you install to be able to see their options. However if anyone here has further ideas, feel free to create a ticket on GitHub. We’d love your input!

I've tested it on Chrome, Firefox and Safari and all three work. We've removed the animations regardless. Does it work now?