Open Source Maintenance Fee(github.com)
github.com
Open Source Maintenance Fee
https://github.com/wixtoolset/issues/issues/8974
259 comments
Anybody should be able pay up for the feature/support and it should be closed source until some threshold. That could take years or months depending on the interest/income. Eventually it will become open source. Otherwise, everybody will wait for someone to pay for the thing they want.
Obviously this needs to be worked up a bit so not to maintain N forks but it can work.
Obviously this needs to be worked up a bit so not to maintain N forks but it can work.
I think thays fine. Thats within the spirit of FOSS. The issue has always been companies demanding fixes because it affects their users, and those companies cant afford to wait. So now they can pay to have the devs spend a bit more time to get their fix out. This works
There are models out there like this. Look around the term "Fair Source" and I think you'll find them.
I was under the impression a number of open source projects already worked this way. There seemed to be a small industry of essentially consultants maintaining Busybox that way for example although maybe I misunderstood the situation.
I have mixed feelings about this. I’m not a Wix user so this is a general comment on the substance of this.
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.
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.
AFAICT, the fee applies if you're using binary releases, or if you open issues, and are also generating revenue from the project. Apparently you can grab the sources and build the binaries yourself (as per the OSS license), never ask for support (by reporting issues), and still have to pay nothing, even in a commercial setting.
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).
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).
> companies would not mind paying a small amount to help support the OSS projects they depend on
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
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
You can open https://www.hashicorp.com/en/pricing and contact their sales department!
Also, wasn't there an uproar when Terraform turned slightly less free? https://news.ycombinator.com/item?id=37081306
Also, wasn't there an uproar when Terraform turned slightly less free? https://news.ycombinator.com/item?id=37081306
Oh, I've been through the sales process. The trouble is that everything I've ever NEEDED has been free, and everything I might concievably want is locked behind a fairly high price threshold that I can never justify.
They need some way for folks like me to get our companies to pay like $5k a year ARR for something that makes it more useful without going the full enterprise route.
They need some way for folks like me to get our companies to pay like $5k a year ARR for something that makes it more useful without going the full enterprise route.
I mean enterprise vault has some really important features that open source doesnt. That could be a good direction to throw money at.
Yes! There are many Open Source projects my company depends on (like Astro, Vue, and Vite for our web sites) that I would love to pay a Maintenance Fee to encourage the maintainers to keep on keeping on. For all Open Source projects that we depend on and accept sponsors, we do pay the $10 "fee" even if they don't require it.
> or if you open issues
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.
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.
It's complicated. Reviewing a PR takes time and effort, and the maintainer may not want to do that for a feature that mainly benefits a company that isn't paying the maintenance fee.
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.
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.
I guess the point is if someone discovers a bug and opens a PR to fix it, then that person is, in a way, also a maintainer. They are “paying” for the maintanence of the project in time and effort.
No. A maintainer is someone who maintains the project. Fixing a bug is a great contribution and makes you a contributor to the project. But you need stick around the project for a while, fixing issues that keep the project running and doing tasks that aren't necessarily required for your use of the project to become a maintainer.
I would only say that they have become maintainers if they consistently do so, over time. Including helping out in areas which is not directly useful to them. And thinking about the whole picture, not just individual features and bugs. And also putting in the time when it is needed, even though other obligations are pulling at them.
Of course it is somewhat of a continiuum. And it always starts with being a contributor. So that is on the right path.
100%. We're still learning here. I also don't expect every project to choose the same policy on how they tackle issues/PRs when requiring an Open Source Maintenance Fee.
I think this is one of those issues that only exists in theory, not in practice.
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.
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.
You sound like a very reasonable person. :)
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. :)
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. :)
Careful with your wording, as I think you're slipping the goalposts a bit: the thing this "Open Source Maintenance Fee" is pushing back against here wasn't specifically bug reports. It was issues — a more general category, which, besides bugs, also contains feature requests. (And that, I think, is where this problem does exist "in practice.")
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?"
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 completely agree! My comment about bugs was only in response to the parent poster mentioning that they would want a company to still report bugs that affect a lot of users.
We're still working through the best way to talk about issues and PRs. This is an area where I expect maintainers to differ in how they apply the OSMF (every maintainer I've spoken to is 100% behind requiring payment for binaries).
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.
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.
And also an exception for reporting security-related issues. Because if you try and charge people money to responsibly report security vulnerabilities, then they'll just end up taking the full disclosure approach, which is probably not what you want.
Oh, definitely. CVEs have a special place to be reported in GitHub.
PSA: Do NOT use the issue tracker to report a CVE. That makes everyone's life difficult. Go through the correct channel.
PSA: Do NOT use the issue tracker to report a CVE. That makes everyone's life difficult. Go through the correct channel.
Red Hat does not charge you to open issues on open source projects and never will. Their business model does not hinge on deriving value from core open source principles.
> It looks a bit similar to the RedHat model
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.
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.
Scratch your own itch. Anyone thinks you are making a mighty nice itch-scratching machine and wants to make it better ? Welcome, let's cooperate !
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...
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...
Users and companies can force you to continue to work on your project. Otherwise they'll fork it, make it worse, blame you for bugs they introduced in the fork, say that the original project wasn't that good, etc.
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.
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.
> Users and companies can force you to continue to work on your project. Otherwise they'll fork it, make it worse, blame you for bugs they introduced in the fork, say that the original project wasn't that good, etc.
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.
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.
It is good for you to feel that way, others increasingly view it as a narrative endorsed by big tech to get free labor and "AI" training material.
> "AI" training material
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.
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.
If it solves your problem, why would you care about what other people do with it ? Free software isn't charity, just a way to find allies - usage by other people is a side effect which doesn't cost anything to the project and is entirely irrelevant apart as some input for the user-to-ally pipeline.
Have you ever spent a huge amount of unpaid time to create an innovative, successful open source project and then had it forked in this manner? If not, I don't think you can accurately predict how this feels. Especially if the forker takes credit for your work, raises large amounts of venture capital, and uses their fork in a way which directly competes with your original project.
> As an open source project no one is forcing you to maintain it.
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. :)
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 existing software stays absolutely FOSS. The development of it is absolutely not free.
This right here is the bottom line.
The OSMF's goal is to keep the software FOSS and the maintainers involved.
The OSMF's goal is to keep the software FOSS and the maintainers involved.
No one is forcing you to maintain it … but successful projects have community and people who rely on the project who somehow trust the dev.
Once you say „I am not fixing it” there will be lots of people who will stop participating in community and project might die.
Once you say „I am not fixing it” there will be lots of people who will stop participating in community and project might die.
To add: But you mustn’t forget it. You become responsible forever for what you’ve tamed.
> As an open source project no one is forcing you to maintain it.
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
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
> Yeah they can complain, but you have zero obligation to fix.
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.
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.
> No company can force you to accept a PR or work on it.
> 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.
> 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.
> The sponsorship seems to introduce a business model around what is FOSS, then it’s not FOSS anymore.
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.
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.
> Even curl has a "bulletproof" version for enterprises which you can't download without paying.
What is the curl bulletproof version? I only see the free open-source license version: https://curl.se/docs/copyright.html
What is the curl bulletproof version? I only see the free open-source license version: https://curl.se/docs/copyright.html
It's here: https://rock-solid.curl.dev/
It's a different, official curl version with commercial support from curl team themselves.
It's a different, official curl version with commercial support from curl team themselves.
This doesn't seem terribly innovative to me, they've gone from giving away a product to selling a product.
In other words, they're operating like a normal business.
In other words, they're operating like a normal business.
Well, it's a "free if you're not generating revenue" model which is similar to JetBrains' recent "free for non-commercial use" releases of their IDEs, and I believe Docker does something like that too.
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.
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.
But why call it open source if it's no longer open source?
They dont charge for the source. They charge for paying more attention to your issues, and for compiling the code for you. If you compile it yourself and do some of the work to resolve the issues (planning or an outright PR) then you wont pay anything
It is a tough thing. I want to focus on the negatives from two perspectives, as you wrote some positive:
* 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 ...
* 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 ...
> This can make it harder to recruit further contributors as there is a two-clays system of contributors.
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.
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.
Free software community participants, contributors, can feel discouraged with the diving the whole community in strictly 2 class of only Maintainers vs. Consumers and then demand something like an Open Source Contributors Fee. All those investigative and reporting work about software behavior issues, hard to reproduce issues, bugs only in specific environment or specific circumstances, sharing experience, helping each other and so on, let alone fixing some issues on their owns and posting PRs.
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.
I think many open source projects already experience two buckets of contributors which maps nicely to the two class distinction inherent in this model:
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.
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.
You really nailed the essence of the idea/solution.
pull back the layers. This is the usual masking of the facts.
A rose by any other name... is after money.
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.
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.
FOSS is destroyed with overly permissive licenses that allow entities with a lot of capital to productize software as closed source while giving back the original author/maintainer exactly 0.
How does that scenario alter free and open source software?
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.
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.
My experience is that FOSS is being destroyed by entitled consumers.
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.
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.
Yea that is actually more a symptom of post-war generations, so isnt exclusive to OSS. Ask any employer how its going with their new young staff members.
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.
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.
[deleted]
I take back my previous comment since I can't now edit it. I was wrong. I think the approach makes sense. There is nothing wrong with getting paid by commericial interests. Its the difficult side of FOSS where finding balance between the two worlds is kind of hard to achieve in a perfect way.
I appreciate that "edit". :)
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.
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.
after further consideration, I actually think I am wrong in this case. It's really just looking for fair payment in exchange for work provided to those that are commercial interests or who can afford to pay it. Which is totally fair and my point doesnt apply here.
They totally have the wrong approach. The EULA is completely bizarre and the implementation even worse.
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.
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.
I disagree. The EULA is an extremely elegant solution to activate an organization's legal team to help their procurement team sponsor Open Source projects.
Keeping downloads/installation behind EULA seems controversial (with all the discussed pros and cons). But prohibiting (or even making it illegal?) to open an issue seems to disrupt how free software communities work. Of course you are free to delay feedback for e.g. 2 weeks (see free access to lwn.net) or not to answer at all or to mark such an issue and move it to discussions but not to limit feedback to your project in such a way.
You should read the EULA. You'll find it doesn't say anything about the issue tracker.
The EULA is actually a very standard software license that basically says if you use the software and you make revenue, you need to pay the fee.
The EULA is actually a very standard software license that basically says if you use the software and you make revenue, you need to pay the fee.
Anything that activates an organization's legal team is a great way to get developers to look for alternatives. No one wants to involve legal.
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.
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.
This strikes me as a problem with the widespread dogma that it has to be open source (OSI approved license). It doesn't.
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.
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.
This has nothing to do with Wix, the platform for building websites. It's about "WiX Toolset" - https://wixtoolset.org/
Ahh, thank you! I assumed it was Wix. They produce a ton of really high quality React Native libraries.
Huh, they were talking about https://www.wix.com/
That's probably what they meant, wix.com does have a bunch of react native libraries on github:
https://github.com/orgs/wix/repositories
> The most powerful set of tools available to create your Windows installation experience. Open Source since 2004!
Funny enough, I came across WiX the other day when I was looking into windows installers like msix, nsis, etc. Eventually settled on self-contained exe (and it's only 1.4 mb, woo!) but seeing the name wix took me back, I vaguely remembered it from around 2005 or so when I was first trying to make "real" windows programs (as opposed to visual basic ones). Took 20 years, but I finally did it, and written entirely in C, too! Anyway yeah, different wix than the popular one. Tom, you may want to rename this post.
It's shocking to me that Microsoft aren't heavily involved with the project considering it's one of the fundamental frameworks for releasing software on Windows.
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.
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.
> Microsoft aren't heavily involved
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.
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.
I've been out of the windows world for about 10 years or so, but before that I was the one tasked at my company with streamlining our installers from a CI/CD perspective. I do agree that WiX is complicated and you really have to dig through the docs and do a lot of trial and error, but at the time I couldn't find any alternatives that allowed for the automation that I could achieve with WiX.
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.
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.
Yeah, the build system integration was always one of the core benefits provided by the WiX Toolset. I know you're not working with MSI any longer, but in recent versions of WiX Toolset we _finally_ nailed down how to include files in the .wxs file using the new `Files` element in a way that wouldn't break other MSI features (like patching).
> It's shocking to me that Microsoft aren't heavily involved with the project considering it's one of the fundamental frameworks for releasing software on Windows.
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.
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.
For reference, here is the MSIX Toolset code repository:
https://github.com/microsoft/MSIX-Toolkit
https://github.com/microsoft/MSIX-Toolkit
> IIRC it was a project under the Office organization originally.
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.
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.
I appreciate the primary source corrections and expansions!
This guy definitely has used WiX. What a nightmare!
[deleted]
> it's an incredibly complicated and poorly documented
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. :(
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. :(
I'm not sure you're still interested but our Quick Start is much, much better and rolls straight into our tutorial. Now there is still a lot of work for us to do but it's better.
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.
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.
Oh I remember these guys! One of my first internship projects was modifying a wix installer for some internal corporate software.
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.
"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".
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".
I personally think this last sentence from my quote makes it unclear:
"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.
"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.
It could add 'and expect active support FROM US' and be more accurate.
I guess it's treating 'if you are generating revenue and need support you're gonna be demanding as hell' as implicit?
I guess it's treating 'if you are generating revenue and need support you're gonna be demanding as hell' as implicit?
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.
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.
Yes, just a couple of minutes setting up a Github action on a fork, and you're good to go.
Yep, and now you have about half a million lines of code* to maintain as well. Have fun with it!*
* 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.
* 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.
You can always just merge in the latest changes from the upstream project with a click or too. No need to maintain it on your own.
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.
"""
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.
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.
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. :)
For example, IIRC, GitHub (all of GitHub) calculated they had 660 direct dependencies. That's still a lot but it's not 9400. :)
OSMF could got name like WiX Toolset Maintenance Fee. Similar to how the Apache License got its name.
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.
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 only object is that monthly fees are super annoying. I'd much prefer an annual :shrug:
You can pay annually. GitHub Sponsors allows that.
It’s $10/mo and then like 15min/$50/mo in everyone’s time in admin chasing down and filing receipts, reconciling to bank statements, etc.
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.
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.
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?
> The fully loaded cost of a single US software developer is already above $100/hour.
To be pedantic, it can be $0 if the developer is you yourself, or your friends, wives, husbands and other relatives.
To be pedantic, it can be $0 if the developer is you yourself, or your friends, wives, husbands and other relatives.
They actually provide the github action they use to build the releases in their repo already, so you could likely get this done in under 5 minutes.
And that's what a number of organizations have set up since March.
No. Not really. There are 406 forks, and ~10 were created in the last 5 months. The other people on this thread are more correct.
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.
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 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.
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
feels like a pay to interect iff one of the parties interacting is a profit making entity
> 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.
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.
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.
Here is their sponsorship page: https://github.com/sponsors/wixtoolset
Here is their sponsorship page: https://github.com/sponsors/wixtoolset
Yeah, that's basically it.
Not commenting on the substance but on the https://opensourcemaintenancefee.org/ homepage itself. It only works in dark mode and is unreadable in light mode.
The repo doesn't allow opening issues. Maybe the author reads here... (long shot)
The repo doesn't allow opening issues. Maybe the author reads here... (long shot)
you have to pay the fee to submit issues, obviously ;)
Heh, funny. My goal was to funnel questions and comments into a single location: the Discussion forum.
Oh, snap! That's bad. It's fixed (thanks to a random contributor :)
Thank you!
[deleted]
>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.
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...
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...
Absolutely true, but that isn't what happened (at least, not yet). Most companies found the fee reasonable and worth it to have us maintain the project and not have to fork it.
>Most companies found the fee reasonable and worth it to have us maintain the project and not have to fork it.
You must have incredibly good analytics to know exactly what companies are using your nuget package. Did you embed a phone home?
You must have incredibly good analytics to know exactly what companies are using your nuget package. Did you embed a phone home?
If this is about WiX, I think it’s easy to just spot their installers in the wild.
I was specifically talking about the companies paying the Fee and the feedback I got from others who don't use the WiX Toolset but understand Open Source and the problems facing maintainers.
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.
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.
WiX usage is easy to check, just open an installer with Orca, and you'll see a bunch of WiX artifacts.
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.
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.
The license snippet you quoted means that they have given YOU the right to copy, change (or compile), and redistribute, distribute anything you've created from it. Nothing about that implies contributors are required to give you binaries.
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 :)
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 :)
[deleted]
>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 :)
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 :)
> 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? :)
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.
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.
Not a lawyer so confused about how requiring a fee to get the binary is in practice compatible with open source licenses, which grant the right to redistribute said binary. I.e. even if the project itself does not want to give me a copy of the binary, anyone who has obtained that binary can lawfully gice it to me.
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.
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.
You can sell open source software and you can charge for binaries and add additional terms on the binaries that restrict distribution. This is how RHEL works. But what you can't do is prevent someone who acquired the source from distributing the source and their own binaries. Which is how Rocky Linux works.
Thanks, I think this is my answer re. binaries. I suppose it also depends on the original license (I think something like the 3-clause BSD license does not allow restricting binaries, for instance).
I think the distinction being made here is between the source code (which is remaining open source) and the binary (which is effectively becoming proprietary). Users would no longer have a right to redistribute the binary, since it would no longer be open source.
(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.)
(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.)
> license it is not possible to require a payment for its use or to limit distribution
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.
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.
Of course you can sell copies. My point is exactly this part of the article you've linked:
"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".
"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".
You can charge for the source code too, just not separately.
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.
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.
[deleted]
You're correct, but I guess they're banking on their users preferring to get the binaries straight from the source instead of through an unaffiliated third party. There are also other benefits to paying, such as being able to file issues against the official repository. Seems like a pretty reasonable compromise to me, to be honest.
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).
https://github.com/wixtoolset/wix/blob/main/OSMFEULA.txt
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).
https://github.com/wixtoolset/wix/blob/main/OSMFEULA.txt
> I guess they're banking on their users preferring to get the binaries straight from the source instead of through an unaffiliated third party.
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.
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.
If it is actually under an open source license then you are correct. They can charge for the right to download it from their servers but they cant stop someone from then redistributing it. Anybody redistributing could also charge if they wanted to.
There are many different open source licenses, and what counts as "open source" can depend on your definition. In theory, you could write a license that makes the source code freely available but restricts binary distribution, or excludes certain groups or use cases from using the software (like not allowing AWS to resell it as a service). Some would argue that's no longer truly open source, but legally, you can add almost any condition to your license.
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.
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.
I watched the video on the open source maintenance fee page (https://opensourcemaintenancefee.org/) and it explains that the fee is for 1) people/orgs who make revenue from the open source code AND 2) want to interact with the GitHub project (e.g. open issues). You can however 1) make revenue from the open source code, but not interact with the GitHub project without paying the fee.
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.
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.
Probably dependent on jurisdiction - whilst practically, having the binary means you can share it, that's not legal without license to do that (in UK) as even though it's open source the copyright still exists on the binary (and because sharing is copying).
You might be free to compile your own from shared source code, however.
Depends also on the license used ofc.
You might be free to compile your own from shared source code, however.
Depends also on the license used ofc.
For one thing, I don't think they think they have a silver bullet here. I think they want some financial support and if some users of the project pay the fee that will be some success.
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.
[0] https://opensourcemaintenancefee.org/consumers/faq/
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.
[0] https://opensourcemaintenancefee.org/consumers/faq/
> > 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.
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.
I would encourage you to read through the first couple pages of the Open Source Maintenance Fee website. I think you'll see there are a lot costs you're not taking into account.
I can't imagine that clause in particular is actually compatible with githubs own eula. It's hard to believe github would be okay with people attaching additional licenses to make use of any of their features. Could I throw a $10 fee to use git clone too?
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.
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.
I really don't think they can limit who can download their releases with their license.
>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.
>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 they think they have a silver bullet here.
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.
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.
Hi, I realise I'm replying to a comment from over a week ago, but I happened across this and now I'm here.
I don't think you got what I intended with my comment. You may have missed the "they think" in the sentence you quoted, it was a bit dense. In any case, it sounds like you agree with me, if not what my comment conveyed. I agree with you.
(I also think my bullet metaphors might have touched and I merged 'bulletproof contract' with 'silver bullet'.)
I don't think you got what I intended with my comment. You may have missed the "they think" in the sentence you quoted, it was a bit dense. In any case, it sounds like you agree with me, if not what my comment conveyed. I agree with you.
(I also think my bullet metaphors might have touched and I merged 'bulletproof contract' with 'silver bullet'.)
Ahh, in that case, I think we are in "violent agreement". :)
Open-source projects often function like a system of charity and honor. The honor goes to the contributors, while the charitable benefits flow to those who can use it to generate revenue. This model works well for both parties and indirectly benefits humanity.
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
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
I like the idea. But it is missing something to actually get money out of companies, I think?
Because even when there are people in a company that are nominally willing to pay, there is usually so much friction/hassle to actually get money out of a company - that it most often ends up not happening for open source. Unless there is something that "forces" them.
Yeah. My experiences with the OSMF is that companies won't pay for charity, but they will comply with licenses.
Hmm, companies often use GPLed software without complying with the license (for eg Vizio is being sued right now), so I wonder why the OSMF situation is different.
Some percentage will not comply. Either in bad faith or just lazyness/incompetence/accident/whatever. But as long as that number is relatively low and a decent chunk pays "their dues", it is not really a problem.
Hah - Legal at my company wouldn't respond to this by forcing us to pay. They'd take one look at that bizarre EULA and tell us to stop using the product entirely. I suspect this is what will happen in most cases.
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.
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.
This hasn't been the case as of yet. We've had many large companies just pay the sponsorship. Honestly, the problem is not the EULA, it's the need for more flexibility in invoicing than GitHub Sponsors provides today.
To say it another way, legal is cool with it, the challenge now is making it easy for procurement.
To say it another way, legal is cool with it, the challenge now is making it easy for procurement.
Honest question: how would you know if companies stopped using the product as a result of this change? Presumably the only ones you'd hear from are ones that managed to get through the process far enough to complain about procurement (which is definitely another issue, pretty sure GitHub Sponsors doesn't do net 60...)
right, we wouldn't mention it at all. no way legal would approve it, so we'd just move to something else.
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.
I'm listening to concerns and adapting. As noted above, so far, it's gone very well.
I'm not criticizing, mostly complaining about how poorly legal teams still perform in this capacity
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. :)
I'm not saying it'll happen, but many people told me Microsoft would never accept Open Source, and I proved them wrong. :)
I hope you continue to prove them wrong. It takes people taking a stand to do that, I admire that.
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.
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.
I guess I'm not smart enough to understand [edit: the hype around] this.
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.
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.
The license of the source code doesn't change. The license of the official binaries (which the official nuget packages contain) did change.
I thought the license was still owned by Microsoft?
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?
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?
Yes, the repo readme says the code is open source but the fee is required for using the repo's issues and releases features.
I'd be surprised if the github EULA allows you to just attach rules to who can click the releases button.
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.
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.
The code is owned by the .NET Foundation (long story) not Microsoft.
> 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! :)
> 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! :)
The WiX installer is a byzantine incomprehensible mess. Its only appeal was that it was free. If I have to pay, I'd rather have a commercial product that is supported and easier to use.
Rob Mensching was supposed to monetize WiX by offering $5,000/yr enterprise consulting & support services. I guess that's not enough.
Rob Mensching was supposed to monetize WiX by offering $5,000/yr enterprise consulting & support services. I guess that's not enough.
WiX basically lets you directly write the internal data structures used by Windows Installer to run the MSIs. Just in XML instead of some ancient binary database that is used in the MSI files to store things.
So the actual "byzantine incomprehensible mess" (which is indeed the correct description) is the MSI format and Windows Installer, not WiX.
So the actual "byzantine incomprehensible mess" (which is indeed the correct description) is the MSI format and Windows Installer, not WiX.
I mentioned this in another response:
> 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. :)
> 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. :)
> Its only appeal was that it was free.
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.
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.
It seems like it would be much less complicated to write this/enforce this if they just made you pay a subscription fee for access binaries and the issue tracker.
Instead, they've generated an enforcement nightmare by solely relying on an EULA.
Instead, they've generated an enforcement nightmare by solely relying on an EULA.
Yeah, though it's tricky because they want to retain free access & support for users who use the project but do not generate revenue.
The worst part for me is:
> 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.
> 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.
> 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.
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.
The problem is, if its one time payment, companies will just leech off of it indefinitely. It'd be great if companies were contributing, but its gotten to the point where you have to assume heavy bad faith from everyone involved
I am starting to think that the open source licenses need to be updated to specifically exclude large tech companies and force them to pay.
Big tech companies use open-source software primarily because it is free and unencumbered.
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.
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.
> 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.
The OSMF is my attempt to find out.
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.
[deleted]
Just want to say, absolutely this. Its an awfully confusing way to say: "if you make money, compile your own binaries or pay us". Have a feeling the confusion and FUD it causes will create more harm than good unfortunately.
Creating a private distribution point and private issue tracker definitely would be an option, and it would make enforcement much easier. But I believe it would also make us more distant from the community. I really wanted to create a system where the Open Source project can stay the same and be sustainable at the same time.
I 100% support this. I wish more open source maintainers would take steps like this sooner rather than feeling stressed and undervalued and burning out. It seems very cheap for what it is.
Yes! Exactly. You're not alone with this sentiment. :)
I haven't fully read it yet, but it would be great if GitHub had "bounties" where users could submit an issue/request with a bounty attached.
I think the issue with bounties is that to do a proper bounty program you want a third-party escrow agent that can decide when the issue/request has been addressed sufficiently to warrant paying the bounty. I don't think GitHub wants to be directly in that business as a third-party escrow agent hiring people to review issues/requests versus changelogs, but they probably could find ways to help people find such third-parties in the Sponsors flows.
Moreso: what if someone fulfils it in a fork.
What GitHub could enforce is that someone creating an issue is a sponsor.
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.
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 feel what we need is not this, but rather a cultural change among the corporate consumers of open source. I'm arguing for this at my employer: that we set up a fund to support open source libraries that we rely on for our products, with a regular payout for products that we are using.
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...
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...
For me the most compelling argument here is that you are paying to continue to rely on the stated assumption.
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.
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.
Some open source projects have paid benefits for donors, like a private chat and/or issue tracker. Combine that with a very basic EULA/SLA, and it becomes nore easily justifiable as a business expense.
I think this could help lead to the corporate change you're hoping for.
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.
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.
That ticket was opened in March 2025 with enforcement starting in April 2025. Pretty short notice.
you could stay in the last version from what i can tell
The window was definitely smaller than I would consider ideal. But the OSMF only applied to WiX v6 (released in April) and later. So, all the older versions would not be impacted.
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.
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.
Can we adjust the title to say Wix Toolset or remove that part altogether?
Looking at the comments, seems it might be a headache to manage this at open source level.
The enforcement itself seems to be tough to manage.
The enforcement itself seems to be tough to manage.
Honestly, thus far it's been a relative breeze. I expected the need to work out "bugs" as the idea is new. My hope is that after we address the bulk of the issues that actual consumers have raised about the OSMF, it'll be relatively trivial for other projects to pick up in the future.
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.
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.
I've always treated WiX as one of those "finished" projects that never needs updating. I'm still using some old version from 10-20 years ago. What could they possibly be still changing? Didn't it just work already?
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.
In this day and age, it's very hard for software to sit idle.
Thanks. Perhaps I'd better finally update :)
As harsh as it may sound, the Wix Toolset is such a steaming pile of garbage and waste of everyone's time who have had the misfortune to work with it that their best monetization strategy would be to charge for proper documentation and working examples, instead of playing games like "you can't view issues without paying us". Easily on of the worst pieces of software I've come across.
Alternative: https://github.com/oleg-shilo/wixsharp/
Alternative: https://github.com/oleg-shilo/wixsharp/
For me, Wix was never truly an OSS project (sure, technically/formally, it is). It's for me just an MS developer workplace in disguise. As MS, it looks nicer and you don't have to support so much.
I was wrong and Rob was indeed not an MS employee??
I was wrong and Rob was indeed not an MS employee??
He started the project while he was still at Microsoft, but since left and continues to work on it independently.
Brilliant idea.
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.
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.
I understand why they do this. It's sometimes hard to find motivation for a project when there is no revenue, regardless of amount.
Honestly, open source software should come with a price. I think the "starving artist" approach is detrimental long-term.
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?
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?
While I love the idea of a better deal for free and open source software developers, I don't think a sales/transactional model will actually solve the problem at scale.
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.
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.
> businesses would control a lot more open source software
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?
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?
Personally, I give to projects I use (and ones that need most help), and I'm happy that say my younger self or people with no conditions can still use it without paying. I think there should probably be better coordinated efforts in this direction, from say companies to governments. But meanwhile individual donations are already pretty powerful if even a small % of people that can donate do.
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) :)
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) :)
Canonical and Lenovo both make lots of money already. Sucks that Lenovo doesn't think supporting Linux on your laptop is important.
> Sucks that Lenovo doesn't think supporting Linux on your laptop is important.
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.
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.
Yeah life isn't great over here in Ubuntu on Asus Land. It's ok, but my laptop is dead when i pick it up way more than it should be.
Linux and laptops have always been a develops combo ime. Honestly at many issues as i have with my Asus, it's the best Linux laptop experience I've had yet
Linux and laptops have always been a develops combo ime. Honestly at many issues as i have with my Asus, it's the best Linux laptop experience I've had yet
I was under impression that Lenovo laptops actually work pretty good with Linux.
So how does this play out for large companies? Let's say Alphabet, they pay $60 once per month, no many how many of their developers use the product? Probably large companies should introduce some sort of registry to keep track of this.
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.
Here's the consumers FAQ of the underlying initiative (the Open Source Maintenance fee):
https://opensourcemaintenancefee.org/consumers/faq/
https://opensourcemaintenancefee.org/consumers/faq/
Do any other projects use this too? Is this just Wix Toolkit?
I have seen some other projects show interest and a few have adopted it. I've not checked in with any of them. The Open Source Maintenance Fee is pretty new, and I've not been promoting it for use by other Open Source projects (yet) because I want to resolve any "OSMF bugs" using my project (WiX Toolset).
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.
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.
Some licenses might allow you to distribute binaries with extra restrictions, but the one you chose almost certainly doesn't.
>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.
>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.
> Some licenses might allow you to distribute binaries with extra restrictions, but the one you chose almost certainly doesn't
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.
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.
Is the OSMF EULA compatible with the GNU GPL family of licenses?
It should be. The goal was to make it compatible with all OSS and FOSS licenses.
This sucks out the joy of Open Source development, which is freedom to do anything, change anything and not responsible for anyone else.
At the point you require payments, users can have expectations and requests, which turns your project into a job.
At the point you require payments, users can have expectations and requests, which turns your project into a job.
In this case the joy was already sucked out a while ago by entitled users.
It sounds like you maintain a successful Open Source project. :)
So what guarantees I get as a consumer of this product? Since I'm paying for it, then all the consumer protection laws should apply and in case of a faulty product I can sue. Is that not the case?
If only this was voluntary and automated by an Open Source service provider, so that I only have to pay one monthly fee and all the FOSS that is detected to be in-use on my machine is funded.
If the OSMF takes off, I could definitely see something like this taking off.
[deleted]
That's the stupidest thing I've ever heard in my life.
This is absurd. Seriously, read the EULA: https://github.com/wixtoolset/wix/blob/main/OSMFEULA.txt
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?
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?
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.
> 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.
what stops another party to start a wixtoolset-binary project and just distribute the compiled versions?
I’m sorry but I can’t help to hate it. It feels like the start of a kind of capitalist cancer, eating its way through the ecosystem, taking away the freedom of maintainers and turning them into slaves for maintenance fee-payers, and eventually goodware into crapware.
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.
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.
Open source software used to be an implementation of the principles of communism - everyone contributes whatever they can and uses whatever they need, and money is not necessary anymore. It seems that now people are starting to turn to a capitalism?
> everyone contributes whatever they can and uses whatever they need
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.
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.
Open source shouldn't have fees, it's one step away from a subscription
I've used WiX for a specific project in my work when I've needed MSI.
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.
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.
> 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...
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.
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.
> Small organization (< 20 people): $10/mo
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.
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.
>TBH, enforcing maintenance fee for anyone who makes revenue feels unfair.
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 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.
> We see time and time again that even mission critical open source projects struggle to get people to fund it.
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).
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).
That is my point! We have to live in reality and in reality that does not happen. This dev is trying to get some sort of compensation for their efforts because the reality is the status quo is not working for them. We can "in a perfect world" all we want but we don't live in a perfect world.
Not sure why you were downvoted, but I agree with you.
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.
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.
> so 10% of your revenue goes to the installer of your product...
In this case you can install your product yourself.
In this case you can install your product yourself.
- 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.