Basically, my understanding is that as long as the software is released under an open source license it is not possible to require a payment for its use or to limit distribution. If you wish to do that you need to relicence.
(To my understanding, this is similar to Microsoft’s “trick” for discouraging VS Code forks: VS Code and many of its core extensions are open source, but their builds are not.)
Those two are not the same, see https://www.gnu.org/philosophy/selling.html
You can also try to charge $10000 for a gold plated CD copy of the Linux kernel without having committed a line yourself.
"With free software, users don't have to pay the distribution fee in order to use the software. They can copy the program from a friend who has a copy, or with the help of a friend who has network access".
But you can definitely have an opensource project that is not available free of charge from any official source. Your clients can redistribute for free or not, but you are not required to just let the whole world have your code directly from you.
The license even says you may redistribute the binary you acquire from them:
> User may redistribute the Binary Release received under this Agreement, provided such redistribution complies with the OSI License (e.g., including copyright and permission notices).
Yep. It turns out a lot of companies are willing to pay for maintenance but they aren't willing to pay for charity. The EULA is what activates the internal corporate mechanisms to make that happen.
In this case, it sounds like they're charging a fee for their pre-compiled binaries and possibly using an end user agreement to restrict redistribution. But since the source is available, anyone could compile it themselves and share the binary, unless the license specifically forbids that.
Realistically, though, many people who want the software will just pay for the convenience of the official binary rather than go through the hassle of compiling it or finding someone else who did. So, while the situation is a bit unusual, it doesn't seem like a major issue in practice.
For instance, if I'm an organization that wants to use this open source project for free, I can download and build the code, but not download a GitHub generated release binary.
You might be free to compile your own from shared source code, however.
Depends also on the license used ofc.
To the specifics, it's not a software license fee -- they aren't selling access to the software. It's a "maintenance fee", to fund the project. So the license of the code isn't a problem, you can (still) choose to license that under whatever terms are available.
From their FAQ[0]:
> Q: What if I don’t want to pay the Maintenance Fee?
> That’s fine. You can download the project’s source code and follow the Open Source license for the software.
> Do not download releases. Do not reference packages via a package manager. Do not use anything other than the source code released under the Open Source license.
> Also, if you choose to not pay the Maintenance Fee, but find yourself returning to check on the status of issues or review answers to questions others ask, you are still using the project and should pay the Maintenance Fee.
I think this is going to hard against the "economy of gift" and isn't going to play well in the end. If they were hosting their own forum / mailing list, charging to access the community would make sense. But the forum is hosted by a company that gives it away for free. The people posting are posting freely (and may not be associated with the project). Some of the people posting answers are members of the project, but some are not. If the maintainers get an answer from someone else are they obligated to pay the answerer a maintenance fee?
I would limit this to "if you find yourself asking about an issue or posting an issue", since those are points where you are looking for help not just from the community at large, but from the maintainers in particular.
Maybe it's a play like any of those license less open source projects, corporations will be so horrified to use your software they'll stay away, but hobby devs won't really worry about it.
>If you distribute any portion of the software in compiled or object code form, you may only do so under a license that complies with this license.
>each contributor grants you a non-exclusive, worldwide, royalty-free copyright license to reproduce its contribution, prepare derivative works of its contribution, and distribute its contribution or any derivative works that you create.
I'm not sure how their rules comply with their own license, and I truly don't think they do. They're granting additional restrictions to a binary they're distributing (if you download this give us money). They're just hoping to scare some contributors into handing over some cash.
Maybe some licenses do allow for this, but the one they chose for Wix almost certainly does not.
I don't think there is a silver bullet. But I do think we can do better than we are today supporting the sustainability of Open Source projects. The OSMF is an attempt to do just that.
The enforcement itself seems to be tough to manage.
Note: A few Open Source projects have already added the OSMF. I've not yet followed up to see how it is going for them.
The repo doesn't allow opening issues. Maybe the author reads here... (long shot)
Sure, there is great value in having a free (in both senses) operating system, but at the same time the year of Linux desktop is a running joke.
To be blunt, money motivates people to do the work they otherwise would not do. It's soul crushing to run the 400th manual test. It's not sexy to work on a lot of the bugs that affect real users, so, when there's no money in it, the work tends to focus in areas of passion and feature development.
Maybe if we all sent $1 to open source projects we use, there'd be enough funding to hire QA people and engineers to fix things like Ubuntu's suspend/resume on my Lenovo laptop, you know?
For one thing, it will eat away at the reasons you like open solutions in the first place. If it became normal/expected to pay for open source software, businesses would control a lot more open source software.
> when there's no money in it, the work tends to focus in areas of passion and feature development.
But when there is money in it, the work tends to focus on quarterly revenue.
> funding to hire QA people and engineers to fix things like Ubuntu's suspend/resume on my Lenovo laptop, you know?
Surely the money you gave to Lenovo would cover that? Like there must be $1 in each laptop they sell that could have gone towards even documenting the hardware so some nice developer can implement a working driver/whatever. Really, it's not the Ubuntu or Linux people that need to be paid to solve that problem, Lenovo is free to submit a patch whenever the hell they want to, they just don't want to.
Only because individuals would presumably open LLCs
> But when there is money in it, the work tends to focus on quarterly revenue.
I don't think the choice is between "John works on this project 11pm - 1am on the days he feels like it" and "John wants to IPO his company". I'm advocating for "John works on this project 3 days of the week because people pay him a small fee for using his project".
> Surely the money you gave to Lenovo would cover that?
The money I gave to Lenovo went to Microsoft for an OEM license to the pre-installed Windows OS. When I download Ubuntu and install that on my laptop, Lenovo couldn't be bothered to see if closing the lid suspends the laptop or not.
Should Lenovo write drivers for my custom kernel as well? As a business, why should Lenovo bother to implement resume capabilities for an OS that is a rounding error for their consumer line of laptops?
In particular, governments traditionally already allocate resources for the common benefit (their main function really), in public research and public science, public infrastructure, etc.. I think this is just another very significant extension of that.
Also companies benefit greatly from OS/(and OSHW in the future?), and frequently maintain private tools at significant costs. Open source can be seen as a coordination mechanism where everybody can (or rather, should) cooperate to lower costs and benefit everyone (basically, their whole industry or rather society gets more efficient) :)
This is the downside of not owning both software and hardware. The integration is lacking. I already gave money to Lenovo when I bought my laptop, and clearly they're not going to support Ubuntu. Maybe if I gave money to Ubuntu, they would support this hardware. It's worth a try, because leaving it at "sucks" is not acceptable.
Also, the timing was never raised as an issue by anyone in the community. If there had been significant pushback, I would have definitely re-evaluated the timing.
The launch went really well though.
TBH, enforcing maintenance fee for anyone who makes revenue feels unfair.
There are other open-source libraries that has dual-license with some kind of GPL variant and a commercial license. but there's at least some threshold.
Imagine indie developer or someone who wants to try and create something but without much revenue (eg 1k / year). so 10% of your revenue goes to the installer of your product...
I'm all in sponsoring open-source and investing in software but part of being sustainable is making it accessible. so maybe that indie developer who used WiX for their indie project ended up going to 100k/year and now can contribute. But if originally it was capped, they might choose other solution that fits the "indie" tight budget better.
You can always download the source and build the software yourself, or acquire the binary from another person willing/able to build it. The fee only applies to binary distribution from the project itself, and support from the project.
If you went to 100k/year and still a solo dev, that's just 0.12% of your ARR. The percentages here are meaningless; $10/month should be doable for anyone that wants to run a business, even someone solo.
I have terrific news! You can start your own open source project that people use to make money and don't contribute back to.
>Imagine indie developer or someone who wants to try and create something but without much revenue (eg 1k / year). so 10% of your revenue goes to the installer of your product...
I have terrific news! That indie developer can create their own installer or start their own open source project that others can make money off of and not contribute back to.
>I'm all in sponsoring open-source and investing in software but part of being sustainable is making it accessible.
I have some bad news here. 99% of people aren't all in on this. We see time and time again that even mission critical open source projects struggle to get people to fund it. The projects that do tend to survive are the ones that build businesses around the project. It's very rare to have an open source project be well funded solely for existing with no business around it. Of course there are exceptions, but that model has failed near completely. That's the reality.
I think you've missed my point.
The problem (imho) is when actors that can easily pay, are avoiding it. And that's where a threshold of revenue (and also different tiers), feels more fair (again, from my perspective).
Anyway, you may want to take a look at nsis, at least when I needed an installer for a windows application many years ago, it worked fine for me. It doesn't produce an .msi but on the other hands it's fast.
Another meanwhile somewhat out-of-date option is squirrel, but it offers a auto-updater, which is very useful.
In this case you can install your product yourself.
"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.
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".
"In short, if you use this project to generate revenue, the Open Source Maintenance Fee is required."
Perhaps I'm being too semantic, but I don't feel that is an accurate representation of the license terms involved here.
I guess it's treating 'if you are generating revenue and need support you're gonna be demanding as hell' as implicit?
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.
* Last count the WiX Toolset had 589,719 loc but 444,936 if you skip comments and whitespace.
* This is the point, maintaining successful (and often non-trivial) projects requires a good bit of work.
"""
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.
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.
For example, IIRC, GitHub (all of GitHub) calculated they had 660 direct dependencies. That's still a lot but it's not 9400. :)
If you’re a founder doing your own finances, well every additional little monthly charge even if it’s just $1 is quite annoying:
Filing and reconciling 12 receipts takes say 1 hour per year, what if you’re using 20 dependencies? That’s an extra 3-5 days per annum of admin.
To be pedantic, it can be $0 if the developer is you yourself, or your friends, wives, husbands and other relatives.
feels like a pay to interect iff one of the parties interacting is a profit making entity
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.
Here is their sponsorship page: https://github.com/sponsors/wixtoolset
- Nobody wants this to be closed source. The code is freely available, and you may do with it as you want. The marginal cost to distribute the code is 0, after all.
- The maintainers, as people, don't want to do charity work for companies. Their time is limited, and if they're going to support revenue-generating activities, they want a cut of the revenue.
So even if this doesn't get perfectly enforced (and it won't), that's fine! The maintainers are now free to respond to complaints with "you need to pay us for us to care." Companies that pay get some level of support; hobbyists get the same experience. Only the companies that ignore this warning will see the consequences, and it's particularly effective for reports where the author leans on "but there are a huge number of important users [to me] that are affected." Pay up if it matters!
It strikes me as a pretty clean solution to a pretty common strain of open-source headache, _especially_ as AI-generated code/reports/etc. are on the rise.
Obviously this needs to be worked up a bit so not to maintain N forks but it can work.
As an open source project no one is forcing you to maintain it. Every fix you put in is something that you do of your own volition. No company can force you to accept a PR or work on it. I think FOSS developers often get stressed about this but unless you personally have financial motivations around what you’ve written you can tell people to fuck off. Yeah they can complain, but you have zero obligation to fix.
The sponsorship seems to introduce a business model around what is FOSS, then it’s not FOSS anymore. The entire purpose of FOSS is anybody can copy and repurpose what you’ve built. They can fork it, take it in a different direction and create a business off of it. Depending on the license you’ve explicitly agreed to that.
This sentiment is going to be unpopular but I think the outrage is unwarranted.
It looks a bit similar to the RedHat model: they release open-source software (Linux kernel is GPL2), but you may want to buy their binary releases and support.
Not so rarely companies would not mind paying a small amount to help support the OSS projects they depend on. This may give CTOs an easy way to expense such support, even though becoming a GitHub sponsor is more involved than many would like; I hope Wix will introduce even easier options (Open Collective, its own non-profit, etc).
meanwhile I've been trying to find a way to give Hashicorp some money for over a decade of depending on their tools, but their products simply are too good to need the enterprise versions!
At some point we need something like a "certified B corporation" for "certified ethical fair-trade Free Software using corporation" where an independant body audits and makes sure you're donating to a sufficient % of the open source projects used in your production SaaS
Also, wasn't there an uproar when Terraform turned slightly less free? https://news.ycombinator.com/item?id=37081306
I feel like there should be an exception carved out to this policy, if the submitter of an issue is offering to create (or, as a corporation, dedicate their own engineers' time to creating) a PR to resolve the problem the issue describes.
As a maintainer of a few OSS projects myself, I see my fair share of "choosing beggars" (i.e. people who don't mentally model others' motivations, and so use github issues to essentially say "I got this for free, but it's not perfect for me, so can you please improve it in ways X/Y/Z to better suit my needs?" — without any consideration of whether their suggested improvement would ever benefit anyone else.)
But if an issue's submitter offers to create a PR, then this makes it very clear that they're not operating in this mindset; and in fact, they're being quite considerate! By describing a real problem, and then offering to create a solution to that problem, they:
1. make sure that we actually want to solve this problem (i.e. that we don't think of their problem as a WONTFIX / something that doesn't belong upstream)
2. give us the opportunity to take over solving the problem ourselves, if we think it's some kind of highly-critical and finicky work
3. give us the opportunity to participate in / constrain / steer the design of a solution, before it gets developed (rather than just having code dropped in our laps and having to fight it into an entirely different shape)
And it often doesn't even matter if the developer in question really has the skill and experience to develop the proposed solution entirely on their own. To me, a dev who creates a half-baked PR that we can then help shepherd over the line over the course of weeks/months of back-and-forth with them in the PR thread, is someone clearly in the process of developing that skill and experience, and potentially becoming an active contributor to the project — or maybe even a future maintainer. This sort of willingness to engage in a non-drive-by way is incredibly valuable.
OTOH, as a maintainer, if a company finds a bug that would impact a lot of users, I would want them to report it, regardless of their payment status.
But saying something like "Issues from paying customers/donors have higher priority" is kind of vague, and doesn't provide any concrete value to the payer. So I'm not really sure what a good balance would be.
If a company reports a bug in a clear and helpful way, it's probably going to get looked at anyway.
Also, if a company cares enough about Wix to bother finding and documenting a bug, they should be willing to pay $60 for the software.
So this is only a problem in the case where a company finds a bug, decides to report it, refuses to pay a minimal fee, and the maintainers are strict enough with themselves to ignore it because of the source. That feels unlikely to me.
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. :)
As you say, I don't think anyone's going to demand money to look into an (easily-replicated) bug.
A bug is, by definition, a blemish in your code quality with real-world implications; something that, even if affects no one, still feels slightly embarrassing/pride-stinging to have hanging around in your codebase. (And if the bug does affect even just one person, then it can also feel like your software is like a child or pet of yours who has accidentally done something bad to that person out of ignorance. You feel the need to re-educate your software to do better.)
In either case, you'll likely accept anything that's truly a bug into your issue tracker (rather than closing it as a WONTFIX) regardless of who submitted it, or how it got there. You might keep deprioritizing it once it's in there, but you won't close it.
But a feature request — no matter how obvious it is, or how many people want it — is different. The maintainers of a piece of code decide the direction the code evolves in; and if they never want to support some feature, that's their perogative.
Maybe you just hate the feature! Maybe it'd force the code into a less-elegant architecture! Maybe the code exists entirely to scratch your own itch, and you're not going to implement anything that isn't part of your own workflow! Doesn't really matter in the end.
It's these cases, I think, where putting money on the table would obviously sway that kind of decision. "Of all the directions you could freely choose to evolve the code... how about a little incentive to choose this one?"
I wholly agree with the sentiment of your comment and we're still learning.
Note: At this time, my project (WiX Toolset) does not require the OSMF for PRs. If there is a README that says we do, then I probably need to fix it.
PSA: Do NOT use the issue tracker to report a CVE. That makes everyone's life difficult. Go through the correct channel.
Yes, very good recognition. The Open Source Maintenance Fee follows several of the paths RedHat paved long ago.
> This may give CTOs an easy way to expense such support
I'm finding it actually gives the CTOs (or someone a bit lower in the chain) the _requirement_ to pay like they always wanted to before. Said another way, in the past, many devs/leads/managers would say, "Oh, I'd like to sponsor this project but I can't get through procurement." With the OSMF, now they have the forcing function to help them through. This is not hypothetical, I've had companies tell me exactly this.
> becoming a GitHub sponsor is more involved than many would like;
GitHub Sponsors is great... except for a few very real cases where it is not. This is on my radar to improve over time.
Others who want you to scratch their personal itch ? Offer professional services or maybe ignore them if you have anything better to do !
You may like your itch scratching device as it is - that it has a pile of CVE to its name doesn't bother you while you sip your tea, scratch your back and listen to the wind in the leaves...
Basically, the fork now controls the narrative over your own work.
If you are completely immune to public opinion, it might work. But the more you invested in the project, the more famous it is, the harder it gets.
Open source started in an altruistic environment and has become slavery. Perhaps someone who was active in the 1990s will point out that it was a narrative even back then, at least it didn't feel like it.
How is it bad ? How does it force you to do anything ? It doesn't even interfere with your thing, which will keep scratching the itch your built it to scratch.
That is the whole beauty of free software: no one has any leverage on your project - any cooperation is voluntary !
I've heard so much "you should do this", "you should conform to this standard", "why don't you help me make this thing the way I want it ?", "your thing keeps me from making money with it" etc. Well buddy, I'm grateful for your opinion, and now I'll go do the thing with the people with whom I found shared goals.
One of the things that I have been encountering, more and more, is the "GIGO" principle (Garbage In, Garbage Out).
Some of the code that I get from coding agents and chat LLMs, is laughably bad. It works, but only because the example has five different approaches to solving the issue, and only two of them work, etc.
I just spent the last two days, working around junk that I got, for implementing WebAuthn. I have it working now, and am grateful for the example, but I'd never ship the code I was given as an example.
Absolutely true. For maintainers willing to abandon their project because they tire of maintaining it, this is a totally viable alternative. Just ignore everything you don't want to do.
However, the maintainers I know care deeply about their project and making it useful. However, when their project becomes successful, the scales tip, and maintenance becomes a real burden. They could just walk away or ignore things that are failing. Or they could set up a Maintenance Fee and those making money using the project's binary outputs can help offset that burden.
It's one more tool in the Open Source Sustainability toolkit.
> The sponsorship seems to introduce a business model around what is FOSS, then it’s not FOSS anymore.
That's not true. I worked very hard with our lawyers to make everything copasetic with OSS and FOSS.
> I think the outrage is unwarranted.
I've seen no outrage. Actually, I've seen quite a bit of support for the idea, I've heard a number of good clarifying questions, I've a few complain that this is bad for OSS or something. It's been surprisingly great actually. :)
The OSMF's goal is to keep the software FOSS and the maintainers involved.
Once you say „I am not fixing it” there will be lots of people who will stop participating in community and project might die.
Sure but thats not the spirit that built the modern software world. Our globabl information infrastructure heavily heavily relies on OSS and that has open source devs assuming some responsibilities. If not from others then just their own sense of self respect and engineering pride.
The only issue was that companies were exploiting that and demanding the exact labour that benefits them. Which is bullshit. And this might solve that
True, but if you want people to use your software you can't ignore the issues they raised, especially if they are valid and not some niche use cases, otherwise the project may come off as poorly maintained.
> FOSS developers often get stressed about this
> you have zero obligation to fix
I agree with you but would like to carve out an exception to the rule: folks who condescendingly reply with "PRs welcome" to people instead of just saying "no, I won't be working on this because [reason]".
Should someone who was told that actually show up later with the code in hand, I'd say they are very much owed respect and serious consideration at the very least. I'll fall just short of saying their code should be merged in by default. This is a completely avoidable moral responsibility, one that maintainers often inadvertently bring upon themselves by daring others to do their work for them.
No major F/OSS license (MIT, (A)GPL, Apache) talks about money. You can sell the software, sell the support, and sell the source code (GPL requires bundling code with the software, not putting it everywhere).
When it comes to Free and Open Source Software, everybody talks about sustainability rightfully, and many people say "sell support, or priority support".
I think this is the right way and balance. Code is there, free. If you earn money from this, help us. If you use it personally, please enjoy.
RedHat does in a more heavy handed way, says "Pay to play", which works for them (because of the missing parts are filled with Rocky and Alma). Proxmox and Nextcloud does this, and says, "Pay if you need help from us".
IIRC, libpcsc requires a fee for "testing card readers for compliance". Library is GPLv3, on the other hand.
Many Free Software libraries get sponsorships to be able to survive. Even curl has a "bulletproof" version for enterprises which you can't download without paying.
"Free Software" doesn't mean "no charge", "open source" software doesn't mean you can take it, run with it, and drag the developers behind you as you please.
As a Free Software fan and advocate, I think Wix's balance is perfect. If you earn money, please help us. That's perfectly fine, and makes sense in their case.
Kudos for hitting the right balance. They got a "+1" from me.
What is the curl bulletproof version? I only see the free open-source license version: https://curl.se/docs/copyright.html
It's a different, official curl version with commercial support from curl team themselves.
In other words, they're operating like a normal business.
And famously WinRar which will nag you to upgrade every time you open it but doesn't actually force you to buy it, but expect enterprises will if they don't want to risk lawsuits.
* This can make it harder to recruit further contributors as there is a two-clays system of contributors. Paid and unpaid. "Why should I fix a bug for free, while others earn the money?" * Accepting money make sit a business transaction, if I accept somebody's money they have demands towards me. Then I got to work on it.
But of course the volunteer free model has sustainability issues ...
We'll see. I haven't seen any reduction in contributions (not that the project gets lots of contributions because we're the same as every other Open Source project, most consumers just consume). Also, note that the fee is just for maintenance. I've seen near 0% contribution rate for all Open Source projects to "maintenance chores". Those just don't fall into the "scratch your own itch" class of problems.
> Accepting money make sit a business transaction, if I accept somebody's money they have demands towards me. Then I got to work on it.
True, but I've been committed to my project for over 25 years and I want to continue to improve the project. The fee has really helped keep that motivation up (aka: sustainable). The reaction has been mostly positive which is also a plus. :)
> But of course the volunteer free model has sustainability issues ...
Agreed. I think the OSMF is a good way to tackle exactly that issue.
1) a bunch of people who contributed one or two PRs, but it took the maintainers more time to review/merge the PR than the dev time contributed
2) a much smaller set of people who come back and do more and more PRs, eventually contributing more time than it takes to review their work
A major existing reason to review PRs from class 1 "once or twice" contributors (perhaps the main reason?) is that all class 2 "maintainer-level" contributors start as class 1.
I agree there's an awkward middle ground here, now you have to define where the boundary is between class 1 and class 2, but I think if you were able to graph contribution level you'd find there's already something of a bimodal distribution naturally in many projects anyway.
FOSS is destroyed the moment that is introduced to the mix. Its like political sells - begin pushing a small degree, they wont notice the temperature as it rises over time until its closed source and corporate.
This is how you kill off FOSS, or your project. "corporate creep" I call it.
The software is still open and free.
But in your scenario you're just super angry you didn't figure out to make money off your work.
I'm gonna go out on a limb and suggest that you never, ever contribute to FOSS and instead just buckle down and focus on selling your blobs.
Note: I'm not saying you're an entitled consumer, but I interviewed many maintainers of successful Open Source projects. The number one issue for all of them was entitled consumers.
but what I see causing far more problems in the OSS community is greedy patreon gatewallers who poach all they can from the devs, then put it behind a patreon wall and charge money for it. Them and corporate swooping in are a bigger problem than whining on a github issues board.
What they should have done is saying "If you aren't a sponsor we do not care about your issues." Right now clicking the download button is a violation of their EULA, which is probably something you want to avoid when trying to get companies to give you money.
If you want commercial users to pay then pick a license that makes it so, it can still be source available and free (as in freedom and/or cost) to non-commercial users.
> The maintainers are now free to respond to complaints with "you need to pay us for us to care."
If you are a maintainer of an open source project you don't have to care about complaint and you can absolutely say that you need to charge for your work in reply to requests. In fact that has always happened.
Instead, they've generated an enforcement nightmare by solely relying on an EULA.
> Q: How long do I have to pay the fee?
> You pay the Maintenance Fee as long as you use the project.
What does that even mean? I built one-off apps for small businesses that I never touch again or maybe every 5 years.
Okay, at least paying perpetually for something I don't use anymore is out of question but if I open a solution for a fix I have to check all 80 packages what their current license is and pay them for the month?
No thank you, I'll rather pay for a commercial solution or use something free with a sane license. With a commercial offering at least it's opt-in when I download a new version.
For me that's basically a subscription fee for one-time download.
Not a WiX user, but that's my issue with it too. E.g., AutoMapper, a popular mapping library for .Net recently changed their license from Free to a Subscription. We use it heavily, and may be willing to pay - however: we are still using the same version as of 2 years ago, because there are no new features we care about and there's no need to put in multiple days of work to upgrade "just because".
I miss the one-time-payment option for such things.
If an author uses a license that makes big tech pay, they will not pay. They will just not use the software. We already see a similar dynamic with AGPL.
It's easy to fall into a trap of thinking "I have several big companies using this software. If I had charged a reasonable license fee, I'd be making $100k/yr on this project." 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.
This is why we very rarely see successful GitHub projects that have asked for payment from the beginning. If a maintainer wants to make money on a GitHub project, the far more common path is: 1) release the software with a free and unencumbered license; 2) wait for people to adopt your software because it's free; and finally 3) once people have adopted your software because it's free, then ask them to start paying you.
In fact, in the early stages of an open source project, if someone opened an issue that said "hey do you want to set a norm of commercial users paying to use your software?" it would be rational to say no! You don't want to scare off big tech engineers. Better to wait until they're already using the software.
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.
The OSMF is my attempt to find out.
https://github.com/wixtoolset/wix?tab=License-1-ov-file#read...
Also, the exact wording is:
"a EULA on binary releases (including those published to GitHub and NuGet.org) requires payment of the Maintenance Fee"
I'm not a lawyer, but doesn't that mean that I can compile the code myself to circumvent the Maintenance Fee, and give the binaries away for free?
For issues and discussion, sure that's essentially moderation. But surely you can't make a EULA that says you can't click on a github provided feature unless you agree to some arbitrary third party's rules.
> but doesn't that mean that I can compile the code myself to circumvent the Maintenance Fee, and give the binaries away for free?
Yep. Now you are responsible for the ~500K lines of code. Totally allowed by the license. Enjoy your fork! :)
After the bugs are worked out, then I'll recommend it more widely and we'll see if it catches on then. I've had a number of maintainers express interest and inquire about how it is going.
>For any file you distribute that contains code from the software (in source code or binary format), you must provide recipients the source code to that file along with a copy of this license, which license will govern that file.
So your nuget package and github release would be a binary distribution, what license applies? It's the reciprocal license, not your attempt to attach a maintenance fee for clicking download license.
And this clause doubles down
>If you distribute any portion of the software in source code form, you may do so only under this license by including a complete copy of this license with your distribution. If you distribute any portion of the software in compiled or object code form, you may only do so under a license that complies with this license.
Your license essentially explicitly disallows you from doing what your trying to do. Will anyone test you for $10/m or just using a competitor? Maybe not.
This also goes horribly against the spirit of open source software, if every small package on a Linux distro did this it'd cost tens of thousands at least to even launch the OS. But the attempt to backdoor downloads from a package repository is what I find most heinous here.
The OSMF EULA has been through a few lawyers now. If you're a lawyer, we're happy to have the discussion on the Open Source Maintenance Fee's Discussion forum.
> So your nuget package and github release would be a binary distribution, what license applies?
If I understand your question correctly, the EULA applies to the binary distribution.
> Your license essentially explicitly disallows you from doing what your trying to do.
No. The source code is available, and there are no restrictions placed on your use of the source code.
> This also goes horribly against the spirit of open source software,
I disagree, but the OSI doesn't say much about it specifically. The FSF, however, explicitly calls out the idea of paying a fee for the convenience of acquiring the software. This is straight in line with the FSF.
> if every small package on a Linux distro did this it'd cost tens of thousands at least to even launch the OS
No, because you only pay the Maintenance Fee for the software you directly depend upon. And if you don't use the Open Source project to make money, you don't pay anything. These catastrophic scenarios you are drawing up are not the reality.
This would then be a checkbox in the settings of the repo “only sponsors can create issues? Yes/no”
As I understand it, this is something that the OSMF enforces - not sponsor, no issue creation.
I was wrong and Rob was indeed not an MS employee??
At the point you require payments, users can have expectations and requests, which turns your project into a job.
The license agreement doesn't change? But you don't get support unless you pay the maintenance fee? So if a user reports an exploit, Wix won't fix it unless the reporter pays the maintenance fee first?
Or if some corporate user has a great idea for a new feature, Wix will ignore it until a paying user requests it?
It seems obvious that this is nonsensical. OSS authors have always been able to pick and choose what PRs they accept or what issues get their attention. They have always been able to charge for support. How is this maintenance fee any kind of innovation?
I don't mean this as a criticism of Wix. I think it is awesome that they develop tools with open source licenses. And I think it is perfectly fine for them to charge support fees. Just like it always has been for all open source projects.
If a would-be contributor feels locked out, they can fork. This is not a new idea. Obviously, forking is a pretty big commitment that will require financial backing. So any rational party considering forking should also consider paying the author for their attention. Even if you have the pockets of an Amazon, it would probably be better all around to fund the original author than to set up a competing fork. Of course there will be the occasional LibreOffice, io.js, OpenTofu, neovim. If you can actually pull off a split like LibreCAD, more power to you. io.js made its point and made nodejs healthier.
This has always been a huge advantage to open source software. You can benefit from the community. You can contribute to the community (code, art, docs, money, ideas, whatever). Kudos to Wix for participating. Best wishes for their future.
Alternative: https://github.com/oleg-shilo/wixsharp/
Surprised downloading releases is in there, I'm not a lawyer but I'm pretty sure this goes against it's own license on the source code, specifically:
>each contributor grants you a non-exclusive, worldwide, royalty-free copyright license to reproduce its contribution, prepare derivative works of its contribution, and distribute its contribution or any derivative works that you create.
At the very least it's confusing, and if anything, comically easy to bypass and literally forces someone to automate a github mirror that builds new releases. Your essentially enforcing the existence of a fork. They even provide the github actions necessary to do so in their repo already...
You must have incredibly good analytics to know exactly what companies are using your nuget package. Did you embed a phone home?
But it is easy to tell when an installation package is built by the WiX Toolset (or any other tool) when you know where to look.
Checking whether it's their own compile or official binaries is also simple if they use an extension like the official Util one, which many do: It embeds a binary that implements the custom action, which is signed by FireGiant.
As for turning this into analytics / statistics, I imagine you could just download every MSI from winget and just check if they contain a FireGiant-signed extension dll.
This isn't all that uncommon -- usually open source licenses only apply to the source.
> comically easy to bypass and literally forces someone to automate a github mirror that builds new releases. Your essentially enforcing the existence of a fork. They even provide the github actions necessary to do so in their repo already...
Yeah, cloning and building software is something that is straightforward for software developers to do. Traditionally people would clone software to their own machine, but you can use GitHub or whatever tools you want to work with the source. I'm not sure if I would call this a "bypass" -- this is the typical way FOSS software has always worked, and it's part of the reason why FOSS is popular :)
Any other packages you know of that are open source but have a trap license where if you download it through the package manager you owe them money? :)
Plus the license mentions the binaries have to be distributed with the same license. Attaching a "if you click this download button you owe us $10000" button doesn't seem very typical to common FOSS values :) I'd say a big reason FOSS is so popular is the free and open source nature :)
It's pretty common in Google Play and the Apple App Store. The only difference here is that payment is on the honors system.
> Plus the license mentions the binaries have to be distributed with the same license.
Sure, but there's nothing in that license that says you can't ask for money for the binaries. The only requirement of distribution in the license is:
> (A) Reciprocal Grants- For any file you distribute that contains code from the software (in source code or binary format), you must provide recipients the source code to that file [...]
It doesn't say: "if you distribute source, you must distribute binaries"
You are free to ask for money for the binaries. Now, due to the terms of the license, anyone else could distribute that binary. But it doesn't require you to do it for free.
> Attaching a "if you click this download button you owe us $10000" button doesn't seem very typical to common FOSS values :) I'd say a big reason FOSS is so popular is the free and open source nature :)
FOSS distributions have been commercially sold for many decades. I bought my first copy of Linux. FOSS has traditionally only applied to source code and any related activities have long been left open for commercial opportunity. This is how FOSS companies afford to operate.
Rob Mensching was supposed to monetize WiX by offering $5,000/yr enterprise consulting & support services. I guess that's not enough.
So the actual "byzantine incomprehensible mess" (which is indeed the correct description) is the MSI format and Windows Installer, not WiX.
> Our primary goal with the WiX Toolset was to provide access to the full power of the Windows Installer. Given the adoption by extremely large software projects, I think we've done pretty well toward that goal. We're slowly turning our attention to simplifying the toolset to make it easier to use for simpler projects. But that's only been a focus for the last couple of years, so not a lot has come about, yet. But the Files element is a huge upgrade.
There is definitely more we can do to make simpler things simpler. :)
That was definitely its appeal to people who didn't want to pay anything for setup installation tools. But that definitely wasn't our only appeal or even our primary appeal. The WiX Toolset unlocked access to the Windows Installer in ways no other installation build tool does. If you didn't need that power then there were absolutely a lot of sharp edges and "missing features" to make your life easier. But if you had hard installation problems, those sharp edges were sometimes the weapons you needed to solve the problem.
> Rob Mensching was supposed to monetize WiX by offering $5,000/yr enterprise consulting & support services.
I don't monetize WiX for $5,000/yr. I monetize my team and my decades of experience building software installation packages of all shapes and sizes. With this "WiX Developer Direct" program from FireGiant (my company), you get monthly office hours directly with me to discuss whatever you want, you get SLAs for answers to tickets and guaranteed bug fixes so that your development team is never blocked. You also get an annual code review of your code by us and access to some high-end tools we develop. It is a high-touch offering and my customers dig it.
> I guess that's not enough.
That's not the case at all. The XZ Utils incident showed that Open Source sustainability is a huge problem and I was compelled to try to do something to address it. I don't think the Open Source Maintenance Fee is the only solution for sustainability, but I think it's a pretty good one for projects like mine. The WiX Toolset is the first project to adopt it because I need a real project to help work out all of kinks in the OSMF concept. Everything is working very, very well.
This fee only governs the binaries compiled directly by the company. You can "circumvent" this license by building the software yourself, or having someone else build the software.
Right now I can click the download button on their github build, what then? They do not even link to to the EULA there, yet the EULA stipulates that this exchange requires me to pay money to them. The github statement stipulates that paying money requires me to first pay the maintenance fee, which is not part of the EULA, why? What is the point.
Here is a tip: If you want to make money, make it easy to give you money. Right now any legitimate company has to fear walking into legal troubles with this. Can you imagine how the discussion with accounting is going to go?
> 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.
However, I personally believe—perhaps naively—that the charity could be directed toward all humans in a more direct and obvious way. For example, when a project is released under a license, businesses that use it to make money would donate a small percentage of their profits—say, 1%—to a global fund: the "Decentralized Universal Kindness Income" (DUKI /dju:ki/). The business behind the main contributors would be exempt from this donation, or could choose a reduced percentage. This gives them an advantage when big companies use their project to compete against them (the reason why Redis changed its license).
The benefits are clear. Contributors would receive greater global recognition for their efforts—especially from those outside the tech industry—while businesses that donate would gain access to a wealth of open-source resources (if enough high-quality DUKI-licensed projects exist), also earning respect as a marketing strategy. They would likely gain a competitive advantage compared to those who do not.
I've called this concept the “DUKI License.” At its heart, it’s the MIT License with one simple addition: a profit-sharing requirement. Unfortunately, I don’t have the power to market it, and still unsure how it would be received by the very people who steer the open-source world—the project founders and core maintainers
Yeah, Open Source projects don't work like that in reality. It's far more consumers take what they want and demand what is missing.
In this day and age, it's very hard for software to sit idle.
Source code is frozen in time. Especially as the software world moves faster, software depreciates in value / rots over time. Separately and equally importantly, depending on the use, the same source code can be a fun hobby or be the centerpiece of a giant business.
This model lets open source flourish while reflecting those realities. From what I see, a business has the option of using the software without paying - they of course wouldn’t get maintenance. They could keep people on staff supporting it or just get support this way - and this way is far cheaper.
Let’s see how it plays out! Could become industry standard.
So far it isn't easy going: what reason is there for paying developers who already give us their work for free? Who do we even pay, if there are multiple maintainers? etc. So far I've come up with "goodwill" and "responsible citizenship" (i.e. maintain the ecosystem that sustains you), and I'm drawing a blank on that last question...
It is assumed that the developers will continue to give something for free, but that will not be true forever. With support, it will be true for longer.
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.
How can one simultaneously be paid for maintenance and also be free of liability? And should someone forking an open source project now be treated as a criminal for interrupting someone’s livelihood?
Finally, it feels that paying a recurring subscription is against the ethos of the “open source forefathers” so to speak. Open source software originated from a world where we paid once for software, like DVDs, not like Netflix. And I would have hoped the world has realised this was a bad idea and is trying to circle back, not undo the path backwards.
Perhaps that's fine in the eyes of the maintainers! But I say this every time someone says they want to restrict commercial use while still being Open Source: just slap AGPL on it. It's radioactive to enterprises; I've never worked anywhere that allowed us to use AGPL code in commercial products. Then, charge for a commercial license.
To say it another way, legal is cool with it, the challenge now is making it easy for procurement.
yoavm•1d ago
thinkmassive•1d ago
90s_dev•1d ago
digianarchist•1d ago
I've had the displeasure of using Wix and it's an incredibly complicated and poorly documented platform that had us reaching for paid competitors in order to get our installer shipped.
I realized shortly after that it's not really Wix's fault. Windows is squarely to blame for the mess that is writing a workable Windows installer. The paid competitors had a lot of the same issues as the open source frameworks.
tempodox•1d ago
Be glad of that. Anything where Microsoft aren't involved is a plus. Microsoft is one of those things you don't want to depend on.
jhot•1d ago
That said it was still somewhat ugly: msbuild the application, potentially copy in some dll's that weren't included in the output, use WiX's "heat" tool to generate installer files from the build output, use a xslt to transform that output to match how we installed shared libraries and such, build the installer with generated files, run automated ui tests and filesystem validations.
At the time installshield, advanced installer, and a few other tools I tried did not have the same flexibility to generate installers and automatically pick up file changes like WiX (without opening up a UI).
I'm so glad I haven't had to think about the nightmare that is MSI in over a decade.
robmensching•23h ago
WorldMaker•1d ago
The history of WiX is that it started internally at Microsoft. IIRC it was a project under the Office organization originally. It's generally considered the first big open source success of Microsoft in spinning a project out to open source community ownership and paved the way for almost every later open source project at Microsoft.
I've got a feeling Microsoft doesn't want to support it anymore because they see it as completely legacy today. WiX is one of the better/cheaper/harder ways to build an old school MSI file. MSI installers are an ancient archive format (the old CAB format) wrapping an ancient and dying DB format (the old JET database engine) and a lot of the complexity of the WiX toolkit is just a reflection of the complex legacy of the old terrible MSI output format. Today Microsoft suggests using MSIX which looks a lot more directly like the better/simpler input to a (well crafted greenfield) WiX project, it's a plain ZIP file with XML metadata.
Cadwhisker•1d ago
https://github.com/microsoft/MSIX-Toolkit
robmensching•23h ago
I worked in Office in 1999 when I created WiX but it definitely was not an "Office project". It wasn't until I left Office for project in Windows Server that Office adopted the WiX Toolset (to replace their custom system). The interaction with Office was always interesting.
> I've got a feeling Microsoft doesn't want to support it anymore because they see it as completely legacy today.
I think that's probably fair. The problem is that nobody has created an installation technology that is as fully featured as the Windows Installer. There are a lot of warts to the Windows Installer. It was designed to support floppy disks for goodness sake, but they were the last team IMHO that took the installation problem seriously. That's why MSI hasn't been replaced in 25 years.
> WiX toolkit is just a reflection of the complex legacy of the old terrible MSI output format.
Our primary goal with the WiX Toolset was to provide access to the full power of the Windows Installer. Given the adoption by extremely large software projects, I think we've done pretty well toward that goal. We're slowly turning our attention to simplifying the toolset to make it easier to use for simpler projects. But that's only been a focus for the last couple of years, so not a lot has come about, yet. But the Files element is a huge upgrade.
WorldMaker•20h ago
truemotive•20h ago
richrichardsson•15h ago
So much this. I was interested in using WiX, but it's just impenetrable for a noob, and any "beginners" guides were either hugely out of date or just assumed you understood what GUID you should be using and if it was important or not to change the example they gave. Quickly gave up. :(
robmensching•7h ago
I made the huge mistake of believing that the community would help with documentation. I knew working with the internals of the Windows Installer would be challenging for most developers, but I really thought they'd help share what they learned and contribute to the documentation. Almost no one did. So, I've picked it up as a task we're doing at FireGiant... but there is a lot to do and it will take time.
msgodel•1d ago
servercobra•1d ago
amelius•1d ago
arthens•1d ago