I hear you. This feels very similar to the early days of OSS licenses. They were terrible and scary until a few big companies finally came out and said OSS licenses weren't (all) terrible or scary. Then accepting OSS licenses became a norm. I'm hoping the OSMF or something like it can change the norm for Open Source sustainability.
I'm not saying it'll happen, but many people told me Microsoft would never accept Open Source, and I proved them wrong. :)
We used to say the same thing about Open Source licenses, and that changed. The long-term hope is that enough projects adopt the Open Source Maintenance Fee, or something like it, that it becomes the norm for companies to support the Open Source projects they depend upon.
And you can say that will never happen. But the only way it will _definitely_ never happen is if we don't try... and choose to keep burning out Open Source maintainers.
Why? It's not specific to the WiX Toolset at all. Other projects can (and some have) adopt the Open Source Maintenance Fee with no changes (or they can change if if they want).
WiX is just the first project to use the OSMF because I need a project to "debug" an issues in OSMF system. As we get all the issues resolved, we may see the OSMF be adopted widely... or not.
There aren't 2 classes of participants. The OSMF only talks about two but there are plenty of spaces for contributors to participate. And it's possible people will choose to participate less, but I haven't seen that happening yet. Contributors that like working on a project just work on a project. I've not seen any complaints about maintainers getting the paid because the contributors just drop in and drop out when they feel like it. They don't work on all the "chores" in the project to keep it running. If a contributor does do "chores" then they are probably more like a maintainer and probably should be part of the maintenance fee. But... this hasn't been a problem.
And, yes, you are very correct that finding balance is very challenging. However, I feel that the OSMF suits the bill quite well, at least for projects of a shape and size that I'm familiar with.
Oh, sure there are some. There were some before. It's Open Source after all. That's kinda' the point. :)
If more consumers choose to take on the work of maintaining their own fork because of the OSMF, that's okay too. I believe we are more likely to get contributions if more developers are in the code instead of just consuming binary builds. That's another small reason why I believe the OSMF can work.
Legal in many companies of different sizes, from Microsoft to tiny ones, have all evaluated and approved of the OSMF EULA. Now, it's fine if someone says I don't want to deal with the EULA. But, in that case, my project didn't mean that much to them in the first place.
I'm listening to concerns and adapting. As noted above, so far, it's gone very well.
Oh, I (would and do) expect we'll see our download numbers (nuget.org and GitHub both track those) decrease. Or maybe consumers will choose to stay on a version before the OSMF was introduced longer. So, we'll kinda' be able to tell.
Simplifying the payment process for procurement is my focus in OSMF (after I get some work done at my day job) to minimize any friction.
Many arguments here are extremes with the assumption that everything is a hard lines that cannot be crossed. That's not generally how the real world works (there are some hard lines in the world) and the parties involved can communicate and do communicate.
Overall, the OSMF is working very well right now. There are still a couple of wrinkles to iron out (like invoicing). It's also early. :)
So far the only hard conversations with accounting are how to pay by invoice (since GitHub Sponsors invoice handling is a bit wonky). Those that pay by credit card have pretty universally been, "Oh, this is easy. Done."
> You can "circumvent" this license by building the software yourself, or having someone else build the software.
Correct. By design. The software is Open Source. That's the whole point.
Well, we've had a few CVEs to work around Windows vulnerabilities, and one of our own making. :( We've also improved the integration with modern Windows build systems. Now adding some features to the language to make it easier to use for simpler installation packages (still more work to do).
In this day and age, it's very hard for software to sit idle.
This is something companies track. Honestly, tracking payments is one of the most important tasks for the procurement teams in a company. They have tools and if the OSMF becomes common, it'll be standard practices for them too.
I 100% agree with you, and I applaud your efforts.
However, my experience is that procurement teams will not pay unless they are required to. Once they are required to, that's what they do. Charity, good will, and responsible citizenship are not arguments to move a procurement team.
But legal... the legal team is very effective at moving the procurement team.
> If an author uses a license that makes big tech pay, they will not pay.
That's not my experience.
> But, of course, if the project has started with this license, it never would have gotten to the point where several big companies were using it.
That is very possible. We'll have to wait to see if any projects start with a maintenance fee then become popular.
> "hey do you want to set a norm of commercial users paying to use your software?"
My ideal would for the norm to shift such that companies think, "We're using this Open Source project, are we already paying the maintenance fee?" I don't know if that will actually work out but I know that if we don't try it will not.