No pun intended, but I wrote a blog post about this a couple weeks ago called Funding Open Source by Rethinking the Assumption at https://supportedsource.org/blog/funding-open-source-by-reth...

By rethinking the assumption (of a free price) we can keep a lot of the benefits of open source, but also have a model that just might solve the funding problem, by having end user companies pay. It's what I'm calling Supported Source.

If you run a project and are interested, get in touch.

The alternatives are two things: dual-licensing or just charging for the open-source software. These are fully open-source where they have no risks of proprietary software but risk loosing profit due to freeloaders or knockoffs. The latter option, charging for OSS stuff, threw me as I thought it wasn't allowed per some of the license but an OpenSUSE employee pointed out it's basically what they do. Some others do, too, including one person whose company does custom jobs for other firms plus GPL's anything they make. You basically make it available for people to grab but just keep charging corporations for it anyway. They don't know the difference as they're paying for specific benefits.

What's your thoughts on these OSS options?

EDIT: Wait, yeah it was Quinn with Fair Source. I've been too busy to get back to him but I see all of us having a more extended discussion on these things in future when things stabilize for me. :)

Interestingly enough, similar models seemed to be more common back in the dark ages of computing before terms like Open Source and Free Software were really a thing, particularly on minicomputers and mainframes. It made its way to the "microcomputer" world in more limited fashion, then sort of slowly died out. But I think there may still be something to the notion of a license that, while not remotely meeting the definition of "free software," still gives you access to the source.

I'll be honest, though; I think FOSS advocates have a tendency to (perhaps unconsciously) downplay how important "free as in beer" has been for the adoption of a lot of major software projects. An internet in which Apache, MySQL, PHP, and other major free software projects were released with commercial "source included" licenses would probably look very different.

I have my own thoughts about RethinkDB's failure as a commercial entity, but despite having actually been inside, I have pretty limited insider knowledge. Perhaps we should have been trying to push an "enterprise edition" with guaranteed support much earlier, following the "charging for OSS stuff" line you mentioned; as others have said, maybe we just didn't have enough avenues through which to give us money. (It's hard not to notice that MariaDB's .com site is essentially page after page of ways to give them money, for instance.)

I think a combo of paid with source and closed-source extensions can still get lots of success. We're already seeing it with enterprise editions for features that basically only enterprises use. That keeps them from crippling the main, OSS product which costs less. I also envision giving free licenses to people that contribute lots of code, docs, testing, etc. One way is to simply not charge businesses below a certain revenue amount or only to charge a support fee tied to cost of delivering support. As they grow, so does the software house like in the royalty model.

Profit? Sure.

Longevity? Not even close.

Things like the Spice3 circuit simulator and the Magic VLSI editor can continue to exist and run 30+ years later solely because they are open source.

However, is MCP actually running directly on modern hardware or is it being emulated through multiple layers?

Of course, you can use my own argument against me that the ports of Spice 3 and Magic to modern hardware are hardly the same program as 30 years ago.

The same reason for a lot of what's in open source. See PHK's A Generation Lost in the Bazaar for some truly unimpressive stuff.

"However, is MCP actually running directly on modern hardware or is it being emulated through multiple layers?"

x86 is emulated on a custom RISC machine. So does it matter when saying whether x86 is a proprietary ISA that still dominates desktops? MCP is proprietary software whose apps keep running for decades regardless of what hardware they're running on. Like other mainframes, the AS/400, whatever. I hope you're not looking for loopholes around the fact that proprietary software can last decades if it's mission critical, supported, and hard to move off of. It can and does in quite a few cases.

"Of course, you can use my own argument against me that the ports of Spice 3 and Magic to modern hardware are hardly the same program as 30 years ago."

I can't since I don't know enough about them. The mainframe and futureproof markets for software try to maintain backward compatibility with stuff you don't change. So, the part the app runs on is probably the same with who knows what underneath. Sometimes that part is ported, emulated, virtualized, etc. Varies. API and software above stays the same.

Now, (a) and (b) work for some use cases, but I'd argue that it's limited, especially usecase (a) because it still allows any 'customer' to use your software for commercial work without contributing anything back other than attribution. What would be nice is some kind of ecosystem around a license I mentioned above, where predefined percentages (that ideally can be set by each license owner) trickle upstream to support their project. Like an appstore for OSS libraries and software where you can register your software and the licenses you offer - if your app is free you don't need to pay anyone upstream, otherwise you keep (1 - x - y - z) if you used other OSS with this model that have predefined cuts x, y and z.

https://www.gnu.org/philosophy/selling.en.html

You can do that without a copyleft for BSD types to keep your proprietary extensions secret & harder to copy. Doing it for either is a good way to make profit or just raise development funds.

Regarding percentages, I think that's an interesting idea but worry about scale. Systems nowdays are getting big and full of components. More complex, but useful, software might get less market share due to penalty of high price. Maybe institute a cap for upper limit of a single component's license. Might be specific to the component or in general. Personally, Im leaning towards simple, annual licenses integrator pays per component. Might get each free for a year per startup so they can make some money. Crowdfunding, nonprofits, or corporate sponsors could help larger ones get started.

I don't quite follow I have to say. The distribution part of software can be rather trivial for niche markets where there aren't any big vendors around - with GPL I'd have to assume that I can only sell once and then the customer will just redistribute it - whether free or not - to whoever wants it, at the very least within his/her organisation.

> Systems nowdays are getting big and full of components.

I think it would actually encourage to have a nice long thought about what dependencies you want to introduce. Market would probably sort that out rather well, and things like the node.js dependency hell would not happen in such an environment. You'll first start with a language that comes with a rich standard library in the first place.

Edit:

> You can do that without a copyleft for BSD types to keep your proprietary extensions secret & harder to copy. Doing it for either is a good way to make profit or just raise development funds.

Yes, to me also this seems to be the best way forward with commercialising OSS without going the service route.

Many enterprises won't buy something at all unless there's a price attached presented by a company they think will be around a while and help them with any customization. This market is less likely to trust a competitor to Windows Server or Exchange if it's being offered for $50. ;) Plus you can point out it's better to buy the real thing supported by developers that invented it instead of cheap knockoffs. Call them cheap knockoffs.

So, there's some risk but it can be done. Best model is having some proprietary addons, though.

"I think it would actually encourage to have a nice long thought about what dependencies you want to introduce. "

I thought about this as I wrote it. The reason I didn't add it is because you'd have two, competing solutions: FOSS community that mixed and merged no matter the size; shared source community where things cost more as complexity went up. I figured the latter would be largely boycotted if former was available. The former has so far been fine for vast majority of freeloaders. I doubt that would change. The latter could become a niche market with low complexity a differentiator, though.

"Yes, to me also this seems to be the best way forward with commercialising OSS without going the service route."

It's what I'm going to do. If money rolls in enough, I'll also submit select improvements and/or donations back to the source projects. Just on principle.

would be proprietary software you don't have to reverse engineer

>[AGPL + another] still allows any 'customer' to use your software for commercial work without contributing anything back other than attribution

How so?

AGPL doesn't have any mention of commercialization - you can use it as an end user in any context for free, but you will have the same issues with selling derivative works due to copyleft. For software that's actually just software and not a service, say media production, it means that *GPL software will forever remain tools for hobbyists.

I continue to be amazed at the number of startups where I have to google around for pricing. (This is excepting those folks who want you to call for a quote, of course.)