Open Source Maintenance Fee

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

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

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.

> 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

> 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

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

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

This right here is the bottom line.

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

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

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

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.

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

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

This guy definitely has used WiX. What a nightmare!

That's probably what they meant, wix.com does have a bunch of react native libraries on github: https://github.com/orgs/wix/repositories

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?

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.

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.

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

The only object is that monthly fees are super annoying. I'd much prefer an annual :shrug:

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.

And that's what a number of organizations have set up since March.

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

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.

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.

If this is about WiX, I think it’s easy to just spot their installers in the wild.

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