[input_sh]

I think every open source projects that has ever aimed to have >10 employees has taken that same route at some point: GitLab, Matomo, WordPress, Redis, MySQL, nginx, HAProxy... all incredibly useful for in most use cases completely free, but if you try to really rely on them (on a large enough scale), you will hit that paywall at some point and feel forced to pay up.

If the goal is to have <10 employees working on an open source project, then I think it's a completely different story, offering just cloud hosting with no extra features is within the realm of possibility. Keep in mind that while one sysadmin is not cheap, a company relying on multiple cloud-hosted open source tools will at some point find that one sysadmin very cheap in comparison. He'll even have time to do some other things as well. That might be a completely viable route for some "simple" open source project (Plausible and SeaTable immediately come to mind), but some open source projects are just aiming to be complex enough to need more than 10 people.

In summary, I personally believe everyone should be pragmatic enough to be fine with the "open core" model. Otherwise, there's no chance in hell we'd have so many cool, open sourced (to an extent), self-hosted tools at our disposal.

[benrutter]

I agree with your main point, but I can't resist pointing out some huge exceptions since there are some mammoth fully open projects like:

- The linux kernel

- Languages (Rust, Python)

- Airflow

- Libre Office

Either way, I think the important thing is knowing why you want something to be open source (do you want to self host? Own your data? Fix bugs? Do you have doubts that the developing company will last long?) Some of those will work great with an open core model, others won't. I think if Linux was "open core" it wouldn't get used at all, that's a lot less true of something like libre office.

[input_sh]

All completely valid counter-arguments. In my defence my perspective is very narrow towards only self-hostable open source tools. Like the types you might wanna self-host in a company anywhere between 10 and 200 employees. I don't have any knowledge of, say, open source libraries and how they operate, and the same applies to all of the exceptions you've listed except LibreOffice.

To be even more specific: I was responsible for maintaining three OpenProject installations in three completely different places. One is a small non-profit that couldn't realistically afford anything else, one is a cheap and very poorly-managed for-profit company, and one is a much larger non-profit that ultimately ended up paying for some "better" proprietary solution. The only things I could think of that those three places have in common are: I worked there, and OpenProject was used to some extent, even if only briefly. And it was never because of me! Other people have made that decision, but it was my responsibility to maintain it.

That's why I'm so opinionated in this thread.

[SahAssar]

There are clearly examples of fully open open-source with more than 10 people working on them, like linux, postgresql, etc.

[j45]

Every is pretty broad.

The pragmatism of self-hosting is key parts of the software will be missing and you may not get a comparable experience.

The issue is not charging. The issue is where key, and actually core, functionality is sitting on the paid side. The idea that "at some point" you hit a paywall is generally not true. It can border on crippleware, and might as well be shareware (still great to support small development teams).

Evolving licensing and revenue generation is key.

The reality is we wouldn't have the world we have today without open-source software, as in the totally free kind, and at some point it does need to be maintained, unless some of the few packages reach some sort of maturity.

Your point about sysadmins not being cheap is fair. I would offer a counter-balance and ask how many more things than need to be are made to be far more complex than they need to be. After all, open-source is also a place of learning, experimentation, and breakthrough, and technical debt.

Still, other projects get so much done with so little support. Restricted core features pretty much tunes out a lot of users to get over the value inertia. It's hard to call it open-source, when it's not quite open source anymore.

One license I've seen is requiring companies over a certain revenue or headcount to have to license. Even JIRA had some of it figured out with their lowest license offering, but for a ton of functionality)

AGPL is helping with some of this - the more projects evolve to partner (for example if someone wants to license the tech to be part of an unrelated project)

Maybe the product managers should be the development team.

It's far easier to financially support fully open source software even though it might not happen as much as it should. I've recently come across an excellent loom alternative in Screenity and the developer only has a few sponsors.

Packaging open source for supporting the development of the software can come in many forms.

[input_sh]

> It's far easier to financially support fully open source software even though it might not happen as much as it should.

Sorry for nitpicking, but this is the only thing you've said that I actually disagree with.

It is a hell of a fight to convince a company (or even worse, a non-profit) to pay for something that they could get for $0 by self-hosting. Symbolic, one-time gestures are possible to fight for, but a reocurring, significant amount is just not. If your open source project offers anything back in return for payment, it's a much easier sell to make. It doesn't have to be complicated or introduce a lot of overhead, it just has to be something, even it's like a very rarely relied on line of support or a logo on the homepage. Same goes for premium features, you just have to strike that right balance, which I believe we both fully agree on. Your tool has to be useful as a free, standalone product, at least up to a certain scale. I have my grudges about where that line gets drawn sometimes, but I can't hold a grudge about the exististence of such a line. It doesn't stop me from testing out your product.

It is of course a shame that we don't have to go through any of this for any fully proprietary product. It is what it is, it's just a question of whether it's worth the per-user price. There are tons of companies out there that have used an open source product for years, never paid a single dime, and then switched to a proprietary, very expensive solution.

There's also a lot of us disgruntled sysadmin/DevOps/SRE people along the way, but our powers are limited. Make it a little bit easier for us by charging for something we can't otherwise get from your free version. It's mutually beneficial for everyone involved: we do our best to give you some money (in return for something), sometimes we're succesful, and then that success usually contributes back to the fully open sourced version being better in some ways.

Individual donations are fine, I do them as well (less consistently than I'd like to; far from nothing), but convincing just one single company to pay up beats the hell out of 100 individuals. It's a fixed, agreed upon sum, usually guaranteed for a period of time by some type of a contract. There's also only one processing fee involved. It is always gonna be difficult to find that first one, but if you pull it off, the odds of your open source project "succeeding" (however you define success) increases dramatically.

[barfbagginus]

I think you sell short the promise of true open source, which gives us much more than what open core can offer, in a more sustainable way. I find it endearing that you in effect attack purists for not being thankful for unusable crapheaps like gitlab. Let's admit those projects were all relevant a decade ago , but have all become very stagnant and painful to use our maintain because of their open core fragmentation and technical debt in the open product. I know they have been replaced in my own usage and orgs.

Imagine if Linux was Open Core, and we were supposed to be thankful for even that, and pay the Linux foundation for Linux Pro if we needed a commercial grade kernel. That'd be like having to buy AT&T Unix again, right? There would be a fork in order, right? Too much has been sacrificed to accept a partly non free kernel.

But suddenly this idea comes along that the project needs to support a company on its back. And suddenly the company only cares about delivering the bare minimum open source than is necessary to annoy clients into the Enterprise version. The open product chokes, and a real open competitor appears. We migrate from gitlab to gitea, from MySQL to MariaDB, from redis to valkey, and so on.

Open source is more important than your or my company. If either open source or our company has to die, it's far better to elect for our company to die, rather than threaten open source. Likewise, any company that threatens open source with the open core model will eventually fail or fall behind genuine open source competitors.

If you build a company on open source, why not let it be fully free, selling services, support, and consulting? I think the days of Open-Washing via Open Core are coming to an end. The last 15 years have seen it betray so many previously lively communities. I strongly believe that in the future, open projects will have to be fully open to merit credit, or the community will immediately recognize them as bad actors, and standardize on a truly open alternative.