Paying people to work on open source is good

I don't see how it is irrelevant: you ask if they still count, and the answer is yes, because they contribute rather heavily to OSI-approved code, so they'd count regardless.

The real question is, would we consider MongoDB or my former employer, HashiCorp's products, presently open source projects?

In the latter's case, the answer from the community at large has been to fork (edit: not always successfully), giving a fairly good indication as to the answer...

(Whether this is as a result of the act of relicensing the code base or as a result of the license choice probably cannot be fully understood without parallel universes... I'm sure someone would complain and potentially fork if they had relicensed, e.g., from MPLv2 to AGPLv3--another OSI license, but a more restrictive one--though probably nobody would care enough to fork if they had suggested e.g., MIT instead, because the MIT is more permissive.)

However, developer categorization into OSI/non-OSI buckets is rather meaningless.

What we've by and large found is that Linux businesses (regardless of license model, even fully proprietary) can usually find funding, due to the large number of companies willing to pay for support & contract development on it. Many more businesses have been successful here: vendors like RH, Canonical, SUSE, Oracle, and even Microsoft and AWS, but also many smaller vendors & independent developers who make smaller livings and profits.

What's been harder has been the non-Linux Open Source/Free Software business model.

And that's what needs to be solved, one way or another. Perhaps that's committing up front to a license (if you want to use the BUSL, so be it, but don't expect the community to be happy if you do so after your project becomes successful).

But more likely, its by raising awareness and making sure people at the top of the organization (board members, shareholders) understand the value of OSI licenses and how their companies can benefit from it. And on the flip side, how changing the terms of contracts afterwards can cause problems. :-)

If we're going to ignore the "official" meaning of open source, then let's take a step back to consider why open source is worth supporting in the first place.

Open source guarantees to me, the user, that competition among vendors will be possible and fair in the future. This is exactly the point that many "fake OSS" licenses try to take away. Okay, maybe it's possible to fork for personal on-prem use, but god forbid someone creates a competing hosted solution that gives any customer more choice. Furthermore, these pieces of software are fucked the day that the company folds, or gets acquired by a malevolent buyer.

Open source guarantees a baseline level of respect towards me, the end user. By letting anyone fork a project that's gone too far in the wrong direction, I know that my software will continue working in the short run and of it's important enough, a competing alternative will emerge that continues without one-sided money or data grabs.

There's nothing inherently wrong with having someone from Microsoft or Google work on open source software, or any VC-funded company that will without fail turn against their users sooner or later. However, if a controlling majority of developers is employed this way, it provides an opportunity for what elsewhere is known as regulatory capture. If Microsoft's goal is to make people dependent on proprietary GitLab and VS Code Marketplace offerings, and Google's goal is to provide the greatest possible amount of ads and tracking to the largest possible user base, it does not matter if the software is open source or not. The end result is the same, I'm left without viable alternatives and big business gets to do with us whatever the hell they please.

Especially when this software becomes ubiquitous and entrenched, paying developers to work on company-controlled OSS instead of community-driven, user-respecting OSS is a net negative for everyone in the long run.

I'm only interested in OSS in so far as it protects my interests as an end user, and/or our common interests as a society, now and in the future. The collaborative aspect is nice, but that's not the reason that we should ask for better compensation for maintainers.

The "Open Source" label as such is indeed meaningless per se, and it doesn't always protect me either, as seen with BSD+MIT software allowing cryptographically-enabled control of devices that I nominally own, or GPL being useless when there is no actual distribution of software involved. That said, I have yet to see a case of non-OSI "open source" that doesn't try to tilt the playing field in biased, controlling and long-term unsustainable or user-hostile ways.

If you can't build a business on a level playing field, perhaps it's in everyone's interest that your business and software dies, or retreats into lower-intensity hobbyist maintainership, instead of leading everyone into a hard dependency on your oh so well-intended monetization of originally useful software. Then at least someone else can take a shot at doing it better.

> The debate would be for a new meaning of the term open source, which has already been established.

Yes, that's what I'm saying, that people are interrogating whether that (inarguably) already established (arguably) "true meaning" is a good one.

I'm certainly sympathetic to the frustration people feel at new debates popping up over definitions that they feel are already perfectly good. But it's not up to you or anyone else individually; the way people use language broadly evolves all the time. It's useful to advocate for why the existing definition you prefer is the right one, but less useful to primarily focus on "we already have a definition of this, that's the only thing it could ever possibly mean!".

The kickstarter model is awesome and should be used more but it clearly doesn't fully solve the problem. It works great for kickstarter because kickstarter projects aren't public goods (if you pay the money you get the thing you paid money for). In general it doesn't make as much sense for open source because you get the same thing whether you pay or not (unless you're the tiebreaker), so your incentive to pay is limited.

Even businesses care about the distinction between OSI-approved and SSPL/BUSL licensed code bases. In the latter, they often cannot host services that use BUSL licensed code which puts risks on the business. Some examples:

Do they need to consult with a lawyer to understand if their particular use case is acceptable?

If not now, then how do they know when that threshold is met?

When the service is offered for revenue?

Or only when offered directly to customers?

What about if theirs is a consulting-structured business e.g., IBM or Collins, where any internally service provided to another team is billed and paid for internal to the company (even though its not paid for by an external customer)?

Can they hire developers to contribute to the code when the upstream is unresponsive to their bugs/features? Or, if they have to integrate with other custom internal infrastructure/tooling? Are they free to remix these tools into larger projects of theirs?

It is possible to separate the moralizing aspects of these licenses and articulate concerns strictly in business cases that make them unsuitable for OSI and thus not "open source" in spirit.