> So people can argue it doesn’t work, but so far we only have evidence to the contrary and Sentry is quite successful
So, RedHat has also been successful?
GP says that some companies don't find FSL aggressive enough, despite it having worked nicely for Sentry. And that's similar to the point Adam makes: That Open Source (per OSI not FSF) is a development model not a business model. Companies that don't want/need to prioritize collaboration tend to use FSL / BUSL / etc; but those licenses aren't really going to significantly change their development or business (other than prevent competition from using it as-is, but now the code is out there anyway [0][1]), and so they might as well go close source (and Lockdown the code, too).
> issue is these are mostly academic points of view
Both, commodotizing competition (through OSS) and using OSS as Go-To-Market aren't academic PoVs, I don't think.
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).
Thanks for the links. I read those and some more from your blog. I've also been to a Chad Whitacre talk about Sentry's OSS approach at a conference this year.
I don't think we're disagreeing at all. I quoted Adam to drive the point that tech shops that value collaboration will tend to prefer OSI-approved licenses. That doesn't seem to be the case for Sentry:
[Sentry is] single-source. That is, [the Company behind it] are the authors and maintainers of the software, and [does] not expect the community to provide us with contributions. We still allow it, and are thankful, but we consider it our duty to develop our software.
At the other end of the "single-source" spectrum is SQLite which is closed to collaboration but is dedicated to public domain and requests a fee for "Warranty": https://sqlite.org/copyright.html
It does seem like Sentry wants control over distribution, but by the way of license? Adam proposes something similar (and I guess that's the reason he's okay with "Fair Source", like a few others too who want to unchain the idea and go beyond OSI / Open Source [0]):
[Sentry wants] to allow people to self-host our software.
> I also respect Adam, but last I understood it the model they were going after sounded pretty similar to trademark protection (which doesnt work).
A counter example: The Android Open Source Project is OSS, and is firmly gate-kept by Google via trademark and other collaborative arrangements like the Open Handset Alliance and Linaro. That said, this is the happy case. Sentry clearly had a different experience with bigger tech shops (GitLab?) trying to monetize its offering without contributing anything back, which (tbh) sounds super terrible.
To me, there seem to be pathways to both succeed & fail with OSI-approved licenses (probably you'd argue... one'd fail more than succeed), and these licenses on their own are neither the only condition nor a sufficient one for business build around them to stumble and falter. That said, I get your point that "Fair Source" gives "single-source" projects a fighting chance, like it did for Sentry. I'd also have thought that the OSI-approved AGPLv3 (your reservations about copyleft notwithstanding) is enough to keep big shops from leeching from other high-quality mostly single-source projects... but may be I was mistaken (given MongoDB / Elastic / Redis / CockroachDB didn't think so; even if, Elastic & Redis switched back to including OSI-approved license, specifically the AGPLv3).
I guess I’ve got a lot of resentment for when I suddenly paid for 100k reserved errors suddenly that I didn’t remember asking for. I probably figured out I have control about it at some point and that’s why I decided to not do the Schlepp of changing the error reporting on all these small projects.
So while I can actually corroborate that your cheapest plan has not changed my takeaway is that changes to billing just make people unreasonably resentful. At least me.
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.
Despite my earlier comment, the way Sentry approaches open source is at least a little better than the majority, so its good that you at least provide an escape hatch that means heavy integration with Sentry isn't a complete vendor lock.
On your second point, you're right that self-hosting is cost cutting, but I found that when a business is growing, the features that sentry offers are more of a nice to have along the way, not quite critical to its success (No point capturing errors if no-one's using your bloody thing). Its easy to rack up that monthly bill with nothing but nice to have hosted services.
What I'd love to have is dumb versions of tools to self host initially when the requirements (and traffic) is very low. Kibana for example is a pig to self host, at one point it was taking up 25% of our production capacity. I found Loki is much better for simple cases in the beginning.
Good example that strikes a balance is Grafana / Prometheus. Its practically impossible to run a software shop without them, and everywhere I worked went through the same phases: Chuck a set of random containers in prod -> Deploy helm chart -> Migrate to Thanos -> Move to hosted Grafana when user/teams management gets out of hand.
Benefit is that absolutely everyone is familiar (and even likes) your tooling, I hope that's enough of a reason to give away a simpler offering.
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.
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.
I would argue that they are not in any way exclusive of each other or opposed to each other.
An open source project can be built upon and extended by anyone, and that includes its creators.
We don’t say that an open source project is diminished because some third party productizes it and makes money. PostgreSQL is not diminished by neon or rds.
No, we continue to judge the project on its own merits. If it continues to offer value, to be compelling, well-supported, and stack up well against alternatives, then we keep using it. We don’t think “it doesn’t have all the features of rds, so screw postgres”.
If the commercial side of the project takes away from the oss side and the oss project goes downhill as a result, then that certainly is a frustrating and disappointing outcome. But when both sides are thriving, it’s a fantastic win-win.
The maintainers get to focus their full attention and passion on the project. The community gets better and better software. And people who are willing to pay for advanced or niche use cases get their problems solved too.
Summing up, the problem is not with the whole model of open core, but with specific projects and companies that get it wrong.
There’s no fundamental reason why the oss side and the product side have to be at odds. It’s just freemium, and there are countless successful and beloved freemium products out there who figured out how to get the balance right.
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.
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.
> 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.
I guess this is where I get hung up on this topic. To me, there's no real distinction between Sidekiq's open-source core and proprietary features vs GitLab's. One has their proprietary code closed-source, while the other has it source-available in a monorepo. Functionally though, I don't see the real distinction. If Sidekiq can call itself Open Source by you, then why can't GitLab? They're both doing the same thing in the end, if you really reduce it down to its core (pun intended?).
I think we had a similar discussion before Fair Source launched i.r.t. ELv2 sharing some similarities here. I argued ELv2's license keys are yet another way of accomplishing the same thing, just differently: separating proprietary code from the core (ignoring the non-compete for the sake of this conversation).
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.
Well the tricky bit is that AFAIK most of these companies have or at least had a full product that was indeed FOSS but then have a cloud offering which is open core.
Provided that the open source product is a close-enough subset of the open core cloud offering I think it's fine to take the easy route of just calling yourself open source although it's certainly a gray area.
There is a distinct Postgres entity which doesn't upsell, that's true. But looking at https://www.postgresql.org/community/contributors/ it seems like most of the actual people are employed to work on Postgres by companies who sell, among other things, proprietary Postgres derivatives and tooling. Maybe if one company came to dominate the list we'd be in trouble..
Open core and open source are orthogonal. Open core is a description of what part is open source. Just because the entirety isnt open source doesn't mean the part that is somehow isn't.
At least that's the idea OP is trying to communicate, which makes sense to me.
I disagree. For an open core product the core is actually open source. You can fork it, change it, distribute it. It may have an OSI approved license. You can't do that with a source available product.
Furthermore, you can't even talk about the open core as a part of the closed source product, because the open core application is invariably a whole in and of itself. You could theoretically fork it, improve on it and it could have a life on its own as a 'fully' open source product. You can even make it incompatible with the closed version.
> You can fork it, change it, distribute it. It may have an OSI approved license. You can't do that with a source available product.
Small correction: under popular source-available licenses like the FSL, BUSL, and ELv2, you can fork, modify, and redistribute. These licenses are usually just concerned with cloud competition, which is none of those things. You can still fork, modify, and redistribute your changes, with no copy-left strings.
Still not Open Source like AGPL, but just wanted to clarify. :)
True, I'm not sure I would say these are source-available, but I'm a bit out of touch regarding the jargon around these clauses that guard against cloud competition.
There's a big difference between 'you can look at the source but not use this product in the way it is intended if you make money by doing so' (production use), and 'you can use the source in any way you like, also for production, but not to compete with us'. I've always understood 'source-available' to mean the former because it used to be like that, and the latter to be a slightly restrictive version of open source. Historically, the latter variant also emerged out of competition with the big clouds (mostly AWS), from projects that used to be truly open source, whereas a lot of what I think are source-available licenses come from vendors that were fully closed before or would be if there was no demand to see the source (for example, for security purposes).
They say they have a closed source hosted offering, and an open source self-hosted offering.
It's fair to call the overall approach something like 'open core' or 'source available', but when you offer the open core under a license like AGPL, it think it's pretty hard to claim that isn't open source.
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.
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/
Whereas, for example, trademark protections have shown to fail easily.
So people can argue it doesn’t work, but so far we only have evidence to the contrary and Sentry is quite successful.