Dont think this is as cut and dry as you make it out to be. The emergence of cloud providers + hosted solutions and the ongoing disappearance of on premise computing means its increasingly hard to figure out a business model for infrastructure tech. Multiple database companies with excellent products (Rethinkdb et al) have faced significant challenges commercializing software that is open source. We need credible monetization strategies for building infrastructure level open source software. I do not fully agree with the Commons clause implementation, but I understand the need for it to exist and welcome efforts in this area.

DISCLAIMER: Views expressed in this post are my own and do not represent my employer in any way.

If you read the shutdown blog post for RethinkDB, licensing was not among their problems. Instead, they were market positioning, reputation, and developing products suitable for their market in a timely fashion. In other words, business execution.

Believe it or don't, no license, no matter how clever, will allow you to be financially successful if you blow the business execution.

Let's turn this on its head: what was the business plan that RedisLabs re-invented itself under? Was it a good business plan? Is is vulnerability to Amazon/MS that made it fail, or was the plan flawed from the start?

I would very much like to see those companies succeed. But when a company forces me to choose between their survival and the survival of Open Source as an institution, my choice is made.

Hyperbole for hyperbole: When an institution can't respond to urgent needs, or privileges one side of a balance over the other until it tips, there is nothing you can do for it.

I've read messages on OSI's mailing list that if you have to ask how your're going to make money making open source, you're the wrong person to make open source, and ought to make proprietary software, instead.

> The emergence of cloud providers + hosted solutions and the ongoing disappearance of on premise computing means its increasingly hard to figure out a business model for infrastructure tech.

The fact that open source works to the benefit of the largest providers of software-related services by commoditizing software itself is not new with the rise of the cloud as a new and popular domain of software-related services. And the source available and free non-commercial and selective commercial use, but negotiate a separate license for commercial use that we want to monopolize model is not an innovative solution to that problem, and generally isn't all that successful of a solution, especially as a switch for software which already has open source versions available that third parties can fork and commercially exploit even after the change.

Licensing choices dont exist in a vacuum, they are made with a business climate in mind. I think many projects picked liberal licenses in a climate where the assumption was that you could make your money selling integration / consulting on top of the software. I think we are no longer living in that world. In this new cloudy world we need to find a way to fund the development of infrastructure software (databases / debuggers / libraries etc).

> I think many projects picked liberal licenses in a climate where the assumption was that you could make your money selling integration / consulting on top of the software. I think we are no longer living in that world.

The anti-consulting provision in th Commons Clause license pretty clearly indicates that it's crafters do think that we are living in that world, and that (as numerous people have observed for at least a couple of decades) the advantage in that market with open source isn't necessarily with the developer but often with the entity with the most developed professional services organization and relationships.

> In this new cloudy world we need to find a way to fund the development of infrastructure software (databases / debuggers / libraries etc).

I don't think that's actually a problem, nor do I think that, to the extent it is a problem, the Commons Clause really addresses it in any general way. Software with such a clause ab initio simply would not get wide adoption in “the cloudy world” you refer to; what the Commons Clause aims to solve is the problem of ”how to capture revenue via technical lock-in after first building broad adoption through the attractiveness of open source when you as a development firm haven't developed the capacities that would leave you well positioned to capture associated services sales with open source”. But it doesn't seem all that likely to be successful in more than the short term, since it incorporates the main problems of classic proprietary software in the cloud domain.

Some experiences of open source rest on the OSD, but not all. If your experience does, that doesn't invalidate your experience. But your experience doesn't invalidate others', either. Browbeat or excommunicate all the heretics, I think you'll find yourself preaching to a much smaller choir.

Granted: OSD, or rather the OSI-approved license list, rules in enterprise procurement at a particular and fairly common level of sophistication. At the same time, I've had conversations with sponsoring companies, prolific contributors, investment types, and others, mentioned OSD, received blank stares, explained, and then heard they don't care. Not relevant. Does not resonate. Different experiences.

I have never seen any good evidence to back your claim of a quiet OSI majority, except if you count open source consumers as an inevitable majority over open source producers, and ascribe the former to OSI. My own direct experience of open source licensing news and work has been a constant drumbeat of interest in refining and expanding licensing models. HESSLA. Fair Source. Now Commons Clause. Experiments. They're coming faster and faster.

Many of the folks advancing those proposals, like the one linked here, are also creating relevant software. From their point of view, claims that their work is "destructive" ring hollow, since they're constructing lots of code for others to use. They're especially irked by criticism in consumer-centric terms, like those of the OSD. After all, the OSD isn't a _license_ compatibility guide, but an _institutional_ compatibility list. It doesn't tell you which code you can get into an open project. By corporate handbook fiat, it tells you which code you can get into your company.

What's the point of preaching to a larger choir, if they don't speak the same language? You're just straining your voice in vain.

HESSLA and Fair Source both clearly state they are not open source, so I don't see how they go against rectang's point; the problem is not the existence of different models, but muddling the language to conflate them with the preceding one. That's essentially an EEE attack, and it's no wonder that existing OSS developers refuse to participate in it.

We invoke "open source" in many more ways and places than dry terms like "express patent license" and "copyleft license". The latter have near-zero community, marketing, or ideological meaning. They aren't the names of movements to identify with.

The push and pull between what doing open source is and what open source is supposed to mean has always gone two ways. If the status quo serves your needs, it's natural to cast "open source" as a rigorously bounded definitional category in the vein of "copyleft", and to downplay its social aspects. From a frustrated developer's point of view, it's natural to cast "open source" as a community first and foremost, and elide theory.

One point of view says, "We have this great definition to reference and rely upon, and you're trying to skim value and prestige off it." The other says, "We have all these people to celebrate and work with, and you're trying to claim their support while ignoring their needs."

Two extremes.