I came across this a few months ago when I was evaluating open source installer options for my own open source project. I have no issue with charging for binaries while the source is available under an OSI license, but this from the README rubbed me the wrong way:
"To ensure the long-term sustainability of this project, use of the WiX Toolset requires an Open Source Maintenance Fee. While the source code is freely available under the terms of the LICENSE, all other aspects of the project--including opening or commenting on issues, participating in discussions and downloading releases--require adherence to the Maintenance Fee.
In short, if you use this project to generate revenue, the Open Source Maintenance Fee is required."
I'll give the benefit of the doubt and assume this is just a difficult concept to succinctly explain in a short paragraph. But that summary - that revenue-generating use requires payment - feels misleading to me. Under their license, nothing stops me from creating my own build from source and using it per the terms of the MS-RL license, including for commercial purposes. So to me it feels like a scare tactic to coerce commercial users into becoming sponsors for the project.
I certainly understand the challenges faced by open source maintainers today, but the specific approach taken here just doesn't feel ethical to me. I ended up passing on WiX for that reason even though I'm not a commercial user.
Isn't it just a clear statement that they aren't going to give commercial users support for free?
I know you are saying it isn't clear, but your quote literally includes the statement "While the source code is freely available under the terms of the LICENSE".
Start-ups and smaller companies that are extremely cash strapped are willing to take an opensource project, compile it themselves, turn it into deployment artifacts and manage that whole lifecycle. There is a threshold where paying someone to manage and certify the lifecycle of tools is more valuable than keeping it in house.
This is pushing those enterprise customers that are just using and updating binary releases because they don't want to take on the compliance risks of first-party support to pay for official versions.
I agree with your point. In the name of promoting basic numeracy:
"""
Sign up for GitHub Sponsorship and create the tiers:
Small organization (< 20 people): $10/mo
Medium organization (20-100 people): $40/mo
Large organization (> 100 people): $60/mo
"""
You are beyond 'cash strapped' if $10/month for something as fundamental as this breaks the bank. The fully loaded cost of a single US software developer is already above $100/hour.
One nice thing about GitHub sponsorship is that there is only one bill for the sponsor, and one can support NN projects/creators there. I think it is even bundled with the regular Github invoice?
Sure, but that also doesn't scale reasonably and is entirely a facile argument. My original comment supports organization paying this price instead of dealing with internal compliance burdens. Looking at one of the package lock files for a previous company I still occasionally contract for, there are 9400 dependencies referenced.
So in the name of promoting basic numeracy, and taking into account the realities of scale. Matching that cost for those dependencies (this is a >100 person company) would be $560k per month. That gets you minimal support, just a guarantee that you can submit issues. No guaranteed security maintenance, compliance, or governance of the project.
You can spin up a very strong developer team for forking and maintaining an internal copy of opensource projects at that cost and a lot of large companies do just that. Should they contribute those changes back? Sure if that made sense.
A lot of time in my experience that internal copy is stripped to the bones of functionality to remove the surface area of vulnerabilities if the useful piece isn't extracted into the larger body of code directly. It's less functional with major changes specific to that environment. Would the upstream accept that massive gutting? Probably not. Could the company publish their minimal version? Sure but there are costs there as well and you DO have to justify that time and cost.
Would a company in-house the support and development of a tool over $40/month? Absolutely not, for a one-off case that's probably fine. If you want to meaningfully address the compensation issue from enterprises, opensource single-project subscriptions aren't going to be the answer.
I would LOVE to see more developer incentive programs, but one-by-one options aren't scalable and most projects don't want to provide the table-stakes level of support required of any vendor they work with. It's not optional for those organizations, its law and private contracts.
Note that the package.lock file is not the place to look for your OSMF dependencies. That file will list your project's dependencies and all of their dependencies and so on and so on. You want to look at the list of packages in your package.json file. That will almost certainly be an order of magnitude (or two) smaller.
For example, IIRC, GitHub (all of GitHub) calculated they had 660 direct dependencies. That's still a lot but it's not 9400. :)
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.
The number of publicly visible forks does not represent the number of organizations compiling their own binaries and internally mandating the use of such binaries.
Mind you, I never implied that there are thousands or hundreds of such cases. But there are some.
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.
If you read the comments on the GitHub issue, the guys seems more than reasonable. My understanding is that they want you pay if you are making money. My guess if you are just a one-person show with a just-started product, they probably won't care much.
> I'll give the benefit of the doubt and assume this is just a difficult concept to succinctly explain in a short paragraph.
It is challenging to describe the concept succinctly, especially as there are lots of varied expectations people have about how Open Source projects work. I'm definitely open to suggestions on how to improve the text.
I think they're trying to say that if you are talking to them on behalf or a revenue generating entity, then you better pay them to talk to them about the project.
feels like a pay to interect iff one of the parties interacting is a profit making entity
"To ensure the long-term sustainability of this project, use of the WiX Toolset requires an Open Source Maintenance Fee. While the source code is freely available under the terms of the LICENSE, all other aspects of the project--including opening or commenting on issues, participating in discussions and downloading releases--require adherence to the Maintenance Fee.
In short, if you use this project to generate revenue, the Open Source Maintenance Fee is required."
I'll give the benefit of the doubt and assume this is just a difficult concept to succinctly explain in a short paragraph. But that summary - that revenue-generating use requires payment - feels misleading to me. Under their license, nothing stops me from creating my own build from source and using it per the terms of the MS-RL license, including for commercial purposes. So to me it feels like a scare tactic to coerce commercial users into becoming sponsors for the project.
I certainly understand the challenges faced by open source maintainers today, but the specific approach taken here just doesn't feel ethical to me. I ended up passing on WiX for that reason even though I'm not a commercial user.