No More Free Work from Marak: Pay Me or Fork This

Hanlon's Razor applies here, I believe, as in: "relax, not everyone is out to get you".

The open source ingestion governance process at every client I've been involved with making such decisions is completely divorced from the procurement process. Technical leads everywhere should be pushing to integrate them as a single entwined process like with closed-source software, for prioritized support of code put into operational production pipelines. As a designer, it is a huge risk in my eyes to select open source software, put millions of dollars per hour/day of 24x7x365 processing onto it, and ignore the 24x7x365 support question.

Within most big companies, getting governance sign off to onboard open source that touches production pipelines is grueling enough, and there is a culture where if procurement isn't involved from the beginning of the governance discussions as a stakeholder, procurement will hassle you to no end because they have their own liability concerns to address for the company ("how do we know we'll get the support we pay for?", "what recourse do we have if we don't?", "what are their terms?", "how do we logistically pay them?", etc.). Most employees at big corporations will choose the path of least resistance; I'm only sometimes successful at getting payment to open source teams by pointing out the risk and audit liabilities of putting into production open source with no solid support story, the inertia is so great.

When the business asks for clarification ("Wait, I thought this is open source so it's free and we don't have to pay?"), make a clear, simple case to make that when you pay a regular amount each year on par with closed-source support contracts, the key developers/maintainers respond prioritizing your support requests, with no worse or better response results on average than closed-source support organizations. Show the numbers of what is put at risk when (not if, never, ever if) it breaks, and the value of domain experts to fix the break (do not ever fall for the jibe, "Aren't you good enough a programmer to fix this open source code?" [1]). And stop with the open source proselytizing in front of the procurement people; help them get their job done, translate into terms they speak. The open source benefit within a for-profit company should never be about the pecuniary; it is faster innovation and problem-solving, forming a better overall solution delivery than closed-source alternatives. Sell procurement on how open source is a frictionless evaluation and onboarding experience compared with closed source. No more "call for pricing". No more expensive shelfware. An adopting company gets more of a guarantee it will be a fit for purpose before payment than they get from the vast majority of closed-source vendors on their master list.

On the other side, the open source community needs to meet corporations halfway if they want routine compensation for open source work. There are lots, and lots, and lots of forms to fill out. Companies really hate publishing these forms out in public, but 98% of the content in these forms ask the same questions between different companies. Start building standards for open source teams to follow of what questions to anticipate to fill out. Start creating standards of support procedures to publish to inquiring companies' procurement departments trying to gauge whether they can trust their production support to an open source team. There's lots more to add here, but in general open source teams make procurement departments really work extra hard to pay money, and procurement officers really, really hate that. It already rubs many procurement agents the wrong way that software solutions in general are not super-fungible due to the power law and network effects we tend to take for granted in the industry; they are used to a highly-asymmetric relationship where vendors come hat in hand through their doors as one of many near-identical competitors, and these procurement professionals strongly dislike vendors with strong negotiating leverage because in their world, everyone is out to get their company. Lots of open source teams who want to be paid for their work shoot themselves in the feet, multiple times, by not spending the time it takes to find out what the procurement people need and delivering that with a smile.

I've seen this discussion at the beginning of open source, and I know all the rebuttals. My favorite is, "if I wanted a business to make money, I would have set one up, DUH. I just want to code, put it out there, and get paid for it." Think of it as handshaking a protocol. We're used to UDP, TCP, HTTPS, TLS, etc., but there is an entire business language out there to interface with, consisting of just as intricate rules. They come dressed in meetings, contracts, forms, questionnaires, and so on, and are part of the story of how humans build enormous loosely-coupled organizations that still get amazing accomplishments done despite all the error faults we witness every day. If you want to access money, then you engage those protocols, just like if Grandma wants to access cat pictures, she engages the user protocols with her smartphone (log in, pick an app, etc.).

[1] One possible response is, "I'm an expert at fixing [our company]'s internal systems' problems. That open source team are the world experts at fixing [open source project]'s problems that would take me 100x more time to come up to speed, as if I was starting a new job, because it is so large and addresses such a large problem domain for us."

The only reason this ‘bargain’ existed at all in the first place was because of the GPL and other more restrictive licenses which encoded this ‘bargain’ into their verbage.

The current version of the ‘bargain’ - use MIT or BSD and expect more participation as a result - has never been the norm. The norm is corporate programmers taking whatever code they can and using it.

The norm is a cleanroom implementation of open source software written because companies would rather pay for that implementation rather than muck around in open source licensed code (I watched Oracle do this with several MySQL feature/bug fix patches).

And so here we are. Yet Another MIT License Regret.

My first interaction with the internet was in the mid-to-late 90's, first AOL then IRC (if ZithTar rings a bell, please reach out), and other than a few super-specific niche communities I also feel looking back that it was a cesspool. I was maybe 10-12 years old then but I can't ever remember a time when the internet was objectively pleasant in a broad sense.

I think Free Software was intended to receive money and replace proprietary software in its entirety.

No, trademarks are irrelevant at this point. The original author of a work retains copyright in that work, regardless of the license under which derivatives are distributed. If they have distributed their work under a lax license and then chose to stop distributing under that license, a pre-existing recipient of that code does not suddenly gain copyright. They can not claim the project as their own or lead users to believe they have copyright in the materials they are modifying and distributing other than as a derived work.

For this to come under trademark legislation, there would have to be demonstrable trade. That's hard to show in the case of free distribution.