Remix.run Logo
Remix clone Hacker News
new | show | ask | jobsGithub
▲ trjordan 2 days ago

I love the innovation. The basic idea here appears to be:

- 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.

▲orochimaaru 2 days ago | parent | next [-]

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.

▲nine_k 2 days ago | parent | next [-]

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).

▲derefr 2 days ago | parent | next [-]

> 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.

▲thayne 2 days ago | parent | next [-]

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.

▲elsjaako a day ago | parent | next [-]

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.

▲derefr 16 hours ago | parent | next [-]

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?"

▲robmensching 19 hours ago | parent | prev [-]

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. :)

▲robmensching 2 days ago | parent | prev | next [-]

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.

▲monocularvision 2 days ago | parent | prev [-]

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.

▲robmensching 2 days ago | parent | next [-]

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.

▲jononor a day ago | parent | prev [-]

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.

▲robmensching 2 days ago | parent | prev | next [-]

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.

▲entuno a day ago | parent | prev [-]

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.

▲robmensching 20 hours ago | parent [-]

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.

▲robmensching 2 days ago | parent | prev | next [-]

> 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.

▲huslage 2 days ago | parent | prev | next [-]

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.

▲mikestorrent 2 days ago | parent | prev [-]

> 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

▲nine_k 2 days ago | parent | next [-]

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

▲robmensching 2 days ago | parent | prev | next [-]

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.

▲acedTrex 2 days ago | parent | prev [-]

I mean enterprise vault has some really important features that open source doesnt. That could be a good direction to throw money at.

▲robmensching 2 days ago | parent | prev | next [-]

> 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. :)

▲bgwalter 2 days ago | parent | prev | next [-]

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.

▲liotier 2 days ago | parent [-]

> 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.

▲bgwalter 2 days ago | parent [-]

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.

▲liotier 2 days ago | parent | next [-]

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.

▲evanelias 2 days ago | parent [-]

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.

▲ChrisMarshallNY 2 days ago | parent | prev [-]

> "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.

▲bayindirh a day ago | parent | prev | next [-]

> 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.

▲sokoloff a day ago | parent [-]

> 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

▲bayindirh a day ago | parent [-]

It's here: https://rock-solid.curl.dev/

It's a different, official curl version with commercial support from curl team themselves.

▲liotier 2 days ago | parent | prev | next [-]

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...

▲prinny_ 2 days ago | parent | prev | next [-]

> 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.

▲ozim 2 days ago | parent | prev | next [-]

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.

▲ozim a day ago | parent [-]

To add: But you mustn’t forget it. You become responsible forever for what you’ve tamed.

▲mendelmaleh 2 days ago | parent | prev | next [-]

The existing software stays absolutely FOSS. The development of it is absolutely not free.

▲robmensching 2 days ago | parent [-]

This right here is the bottom line.

The OSMF's goal is to keep the software FOSS and the maintainers involved.

▲samrus 2 days ago | parent | prev | next [-]

> 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

▲matheusmoreira a day ago | parent | prev [-]

> 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.

▲johannes1234321 2 days ago | parent | prev | next [-]

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 ...

▲robmensching 2 days ago | parent | next [-]

> 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.

▲snickell 2 days ago | parent | prev [-]

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.

▲calibas 2 days ago | parent | prev | next [-]

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.

▲hbn 2 days ago | parent [-]

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.

▲LtWorf 2 days ago | parent [-]

But why call it open source if it's no longer open source?

▲nevon 2 days ago | parent | next [-]

It is open source. The code is still available under the same license as before. They are just charging for binary builds.

▲LtWorf 2 days ago | parent [-]

Oh ok, I had misunderstood then.

▲samrus 2 days ago | parent | prev [-]

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

▲majkinetor 2 days ago | parent | prev | next [-]

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.

▲samrus 2 days ago | parent | next [-]

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

▲robmensching a day ago | parent | prev [-]

There are models out there like this. Look around the term "Fair Source" and I think you'll find them.

▲msgodel 2 days ago | parent | prev | next [-]

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.

▲robmensching 2 days ago | parent | prev | next [-]

You really nailed the essence of the idea/solution.

▲mytailorisrich a day ago | parent | prev | next [-]

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.

▲constantcrying 2 days ago | parent | prev | next [-]

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.

▲robmensching 2 days ago | parent [-]

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.

▲jackdawipper 2 days ago | parent | prev [-]

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.

▲robmensching 2 days ago | parent | next [-]

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.

▲jackdawipper 14 hours ago | parent [-]

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.

▲ 14 hours ago | parent [-]
[deleted]
▲xoac 2 days ago | parent | prev [-]

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.

▲mopenstein 2 days ago | parent [-]

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.