I'm not talking about RedHat, I'm talking about the perspective that "FSL / BUSL aren't effective enough". They solve the problem. O'saasy is just freeware at the end of the day, FSL creates more open source, and BUSL often has (though unfortunately the license doesnt require it).
The idea that FSL ~= Closed Source is entirely wrong and misunderstands the value that an open distribution gives. We have 10s of thousands of customers that run Sentry self-hosted. We regularly get contributations back to our core service - both in code and (what we prefer) other artifacts like feedback.
We were "Single Origin Open Source", which is extremely common whether people like to believe it or not. Its the entire premise of the sustainability issue in the industry. Thats not just an issue for commercial entities, its also most of the big open source software people rely on. In our case though we have a great business model that makes it entirely sustainable, and now have built a solid licensing mechanism around it that protects that, while ensuring our community is still successful.
These same issues around single origin open source are why we started the no-strings-attached funding mechanism via Open Source Pledge (https://opensourcepledge.com), why we push Fair Source (https://fair.io).
Maybe others will find defensible models, but I'm skeptical. I also respect Adam, but last I understood it the model they were going after sounded pretty similar to trademark protection (which doesnt work).
Just want to say, absolutely this. Its an awfully confusing way to say: "if you make money, compile your own binaries or pay us". Have a feeling the confusion and FUD it causes will create more harm than good unfortunately.
No, its complicated and scales to servicing every customer in the world. Thats not the same thing.
Doesnt mean the complaints about self-hosted arent valid, but "literally has to scale to the most insane volumes of data" and "is not good software" are two different things.
We're building a cloud service at the end of the day - its a lot easier to optimize a multi-tenant install than it is a single-tenant install, and that complexity shows up in the self-hosted repo. Can't really avoid it.
If you - or anyone reading this - ever ends up in a situation where we came off as aggressive send me a direct email and I will take care of it. This is not something we believe in at Sentry, and while you cant manage everything, its important to us that we never become "of those companies" like so many other successful companies become.
We enable self-hosting because not everyone can use a cloud service (e.g. government regulation), otherwise we probably wouldn't even spend energy on it. We dont commercialize it at all, and likely never will. I strongly believe people should not run many systems themselves, and something that monitors your reliability is one such system. The lesson you learn building a venture backed company, and one that most folks miss: focus on growth, not cost-cutting. Self-hosting for many is a form of cost-cutting.
We do invest in making it easier, and its 100% a valid complaint that the entire thing is awful today to self-host, and most people dont need a lot of the functionality we ship. Its not intentional by any means, its just really hard to enable a tiny-scale use-case while also enabling someone like Disney Plus.
Sentry runs large workloads and Postgres isn't a bottleneck. We have also never employed a DBA. Most users never need to shard their database, and at most can just partition datasets by tables for _extremely_ high volume workloads.
You just have to consider architecture and optimize things that are slow, just like any other software. Nothing is free at the end of the day, and nothing else gives you the flexibility that Postgres does, particularly these days with its growing high value extensions.
When you offer a subset of the product as open, and a subset as not open, its not open source. Pretty simple math for me.
This is not a comment on "which" OSI license they used for the open part, but I will not support people calling Open Core broadly Open Source, as its not.
This is the problem with the definition. If the product is trurly open source, call it that. If its not, thats ok, but don't. Core has no real definition.
I definitely would never call GitLab Open Source. I can't comment as much on the others. Sidekiq is actually how I think the world should work: its open source, and then they sell Sidekiq Pro. One is Open Source, one isnt. The issue is most people don't operate that way.
GitLab Community Edition is Open Source, GitLab is not. Cal.com isn't open source, but is the Cal product? I'm not sure. Given I started Sentry I can at least use it as an analogy. Early days Sentry was open source, but getsentry.com was not (which was our billing infra). No one would have called Sentry Open Core, because no part of "Sentry" was closed source. That's not true for most Open Core.
Postgres is not operated by the same people as Neon or Amazon, thats a fundamental difference. I was also not suggesting commercial cannot benefit Open Source (and would in fact quite the opposite).
In general I was not commenting if they're opposed, but suggesting an Open Core project is Open Source is not truthful. "Core" is a meaningless term, and if we suggest any Open Core project is Open Source, I can easily academically argue that the majority of businesses are Open Core, thus Open Source, and we'd all agree that's not true.
This project is Open Core, and thats fine, but Open Core is not inherently Open Source, and if we're going to care about that term in some contexts (e.g. with Fair Source) we need to care about it in all contexts.
I just wanna remind folks that Open Core is not the same as Open Source. I didn't look at specifics, but I was triggered by this comment:
> Some people call our strategy "open-core" and that's technically right. Still, I'd rather say that we have two pieces of software: one that is open-source and another that is not. I think that's more honest because we're not trying to hide the fact that we're selling a non-open-source version of our software.
I'm not morally opposed to open core software - and any version of more open source is valuable open source to me - but I think its important we do not conflate the two, just as we need to not conflate other approaches like source available.
You have nailed their issues - packaging and their revenue model. If you align this well with your target audience the license would have not been a problem for them. Wrote about this a bit here: https://cra.mr/open-source-is-not-a-business-model/
No ones saying Fair Source is better than Open Source, but in your analogy one protects the commercialization of a project, and the other does nothing to protect the creators.
The clarity of what is and isnt permitted is something we'll be looking to make sure is enforced via the license, at least in FSL's sake. The intent is that if you're commercializing by say, providing support or integration services, that its totally valid. What's not valid is hosting a competitive offering using the source code. That is, with FSL you cannot spin up the project and sell it as a cloud service, but you can provide professional services to customers using said product.
If you decided to build something that tried to sneaky leverage the business model that funds development, that its so closely related to what the company would do, and then the company does it... well, don't do that? You'd be stuck on the old version. Thats the price you pay for trying to be sneaky. The license is effectively encoding a set of values/ethics in how people should run businesses, particularly when building on top of other peoples businesses. I think this is totally fine, so whenever people bring up these hypotheticals I just shrug them off, as they're an academic edge case that all but a handful of individuals will never need to care about them.
Also generally speaking, the case you're describing sounds more likely to be an integration say between your service and their service, or more specifically, your code and their service (say an integration between Sentry annd MyCoolTicketTracker). You could still sell that integration just fine, as its your code, not the FSL code. What you couldn't do is sell a cloud service that was MyCoolTicketTracker, that funnels to a privately hosted Sentry, and then exposes the functionality of Sentry into MyCoolTicketTracker. At that point you're commercializing Sentry itself, not your services.
1. You have a burst of errors - typically this happens first month when people dont understand their volume, or they had a runaway bug.
2. We rate limit/throttle you for your billing period. We also provide some tools that we'll eat various cost for periods of time (such as Inbound Filters and Spike Protection).
3. You never have to "contact sales", but you're certainly welcome to email support, and they almost always will forgive your volume.
It sounds like you want us to pick up the cost, which sure, sounds great as a customer, but we're trying to build a long term sustainable business. We can't just accept infinite data and not charge for it. All of that costs money, and while in some less common scenarios you can dedupe client side (we do), mostly they have to hit our servers, and that has a cost associated.
What's the concern here? The pricing is transparent, and yes we've adjusted it over the years to be more in line with our costs. We still charge you per error just like we have since I started the business, and we're very honest about that. If you scrolled down you would see a full transparent pricing calculator for all of our product offerings.
wrt Enterprise, you seem to not be the target person. Its primarily about access to humans. Terms, liabilities, SLAs, services, etc. If you are FAANG scale, yes it is about price negotiation as well. When you are in the buying cycle at a company that needs these kinds of things you are well accustomed to this kind of thing.