"Critical" projects and volunteer maintainers [LWN.net]

"Critical" projects and volunteer maintainers

Posted Jul 13, 2022 22:44 UTC (Wed) by Paf (subscriber, #91811)
Parent article: "Critical" projects and volunteer maintainers

There is a problem here, in that while some companies doing this are extremely wealthy and could probably do whatever, many many organizations - I’m sure the vast majority - with dependencies on FOSS don’t have anything like the money to pay for maintenance of all their dependencies.

These are deep, deep stacks with many pieces. Most companies involved have no realistic prospect of paying or wanting to pay - that’s part of the point of FOSS, I think? We focus on free is in freedom but free as in beer is part of the idea too (for some of us anyway?). Perhaps then it’s just those that want to ask for stuff that should pay? That’s more reasonable.

But it’s all very hard. It seems certain only the largest companies and those with very tigh needs for a particular project will ever help pay?

to post comments

"Critical" projects and volunteer maintainers

Posted Jul 13, 2022 23:48 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] (8 responses)

many many organizations - I’m sure the vast majority - with dependencies on FOSS don’t have anything like the money to pay for maintenance of all their dependencies.

They may not have the money to pay the full maintenance cost of all their dependencies, but they shouldn't need to. After all, the chances are they aren't the only ones using it. That's pretty much guaranteed if it makes it into the top 1% of downloads. What might help is if the package archive created something like a tip jar. Users could donate money to specific projects if they know those projects are important to them, or they could just donate some money to the service as a whole and it would automatically be apportioned among the projects they download, with maybe a little bit diverted to the archive to keep the whole thing running. If every company donated a nominal amount each month- maybe equal to the coffee budget for their programming team- it would add up.

You could even set it up so the amount the maintainer received was related to their promised service level. Projects dumped on the server with no promise of future support would get nothing. Ones that promise only that the maintainer will get to it when they have the time would get a little bit, and ones that can promise rapid turnaround on bug fixes would get a lot, at least by comparison. It would let developers who don't want to make any promises do so, while developers who hope to make some money from their projects would have an incentive to promise (and deliver) better response. It would even give companies an incentive to open source their own libraries in hopes of recovering some of their development and maintenance costs.

"Critical" projects and volunteer maintainers

Posted Jul 14, 2022 3:43 UTC (Thu) by dasyatidprime (guest, #102159) [Link] (1 responses)

I know that Tidelift has been attempting to set up something like this as a broader thing, but I've never interacted with them directly. Anyone with more experience feel like commenting on how they're doing?

"Critical" projects and volunteer maintainers

Posted Feb 23, 2024 14:24 UTC (Fri) by LtWorf (subscriber, #124958) [Link]

I checked the revenue that they promise to maintainers who enrol (and promise to abide to their rules about maintenance).

It seems that even critical pypi projects would get 0€, and things in the top 50 downloads would get a few hundreds per year.

Didn't seem worth to me to invest the time to enroll.

"Critical" projects and volunteer maintainers

Posted Jul 14, 2022 7:32 UTC (Thu) by himi (subscriber, #340) [Link]

> You could even set it up so the amount the maintainer received was related to their promised service level.

Isn't this kind of model opening up the "tip jar" operator to some level of responsibility for actually /tracking/ the responsiveness of projects? Quite apart from raising questions of where the money goes to, as well as probably a whole host of other questions and challenges that are probably going to make it all horribly impractical.

Running something like this really doesn't seem like it would be viable for any but the largest and most well resourced archive maintainers, or for many other organisations that might be interested in supporting maintainers and developers. And the organisations that /could/ do it might not be ones that the community would trust very much with such a role, like Google or Microsoft (or even Mozilla or the FSF).

Clearly /something/ needs to be done to ensure better resourcing for open source maintainers and developers, but I'm not sure this model would be very practically useful.

"Critical" projects and volunteer maintainers

Posted Jul 15, 2022 18:49 UTC (Fri) by samroberts (subscriber, #46749) [Link] (4 responses)

Renumeration is fine, but its not a solution for all situations.

I've some 10 or 20 year old projects that are moderately widely used, written in languages I don't use anymore. I'm not maintaining them, and a tip jar won't entice me to do so, I have a job, and at least for ruby, the modern package tooling is so different now, I don't know how to use it.
I spent countless enjoyable hours on them, but those days are past. A couple have enough interest that I've managed to transfer maintenance to a couple other people. One should never be used again, but gets a 3million downloads a week... (no kidding). I've no idea how to get the popular upstream projects that have it as a many levels down dependency to get rid of it, and I've tried. I could just add a deprecation warning to it, so every consumer would see the warning, but that seems pretty hostile, and deleting it seems even more hostile. I really wish there was better deprecation mechanisms, and softer crowbars to get downstream consumers to move on.

I suspect that the author of the lockfile project mentioned in the article is in a similar position, unable to convince people to stop using the project, and no amount of money is going to make it easier.

"Critical" projects and volunteer maintainers

Posted Jul 15, 2022 21:10 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]

Remuneration isn't the solution to every problem, but it can certainly help with specific situations. For example, no amount of money might entice you to revisit your old projects, but it might help attract a new maintainer. That might be because they're a user of your project or a complete mercenary who's doing it only for the tip money. Either way, having a new maintainer would be a good thing. Providing a reward for taking over unmaintained projects that others depend on is a potential benefit of having some kind of money available.

"Critical" projects and volunteer maintainers

Posted Jul 16, 2022 3:19 UTC (Sat) by pabs (subscriber, #43278) [Link]

Money could help convince people to work in migrating projects away from deprecated dependencies too.

"Critical" projects and volunteer maintainers

Posted Jul 16, 2022 20:09 UTC (Sat) by NYKevin (subscriber, #129325) [Link] (1 responses)

For Python, you can set a Trove classifier to mark the project as inactive. Then, the end users who care will at least be able to audit for those in a reasonably automated fashion (i.e. without a human having to read and understand your README file). I don't know whether any other languages support such a concept, however.

"Critical" projects and volunteer maintainers

Posted Jul 22, 2022 15:32 UTC (Fri) by deltragon (guest, #159552) [Link]

Composer (for PHP) has a similar thing, were unmaintained packages will warn you on install.

"Critical" projects and volunteer maintainers

Posted Jul 14, 2022 11:09 UTC (Thu) by kleptog (subscriber, #1183) [Link] (3 responses)

It's unfortunate that that no micropayments system ever really got off the ground. At my work we use hundreds, maybe thousands of packages (especially if you include NPM). I've toyed with the idea of having my work donate to projects we depend on, but which ones? Debian is an easy one, and Python is used a lot, but what about the many many small packages used indirectly? Those are the ones that need support but it just isn't easily done, and perhaps impossible. You'd possibly spend 10 times the amount on administrative overhead than that you'd actually donate.

If it were as simple as simply donating some money to an entity with a list of packages to distribute to it might have a chance of happening.

(Of course, as soon as you start talking about money you get the discussion of how to divide it. Should big projects get more than small projects? Should active projects get more than idle feature complete ones? You'd probably have to provide options there too.)

What I try to do is to, if I find a bug, try to write a useful bug report and if possible include a patch. I feel it's the least I can do.

"Critical" projects and volunteer maintainers

Posted Jul 14, 2022 12:45 UTC (Thu) by kpfleming (subscriber, #23250) [Link] (2 responses)

That entity exists, and its name is Tidelift :-)

"Critical" projects and volunteer maintainers

Posted Jul 14, 2022 14:22 UTC (Thu) by kleptog (subscriber, #1183) [Link] (1 responses)

Really? I've browsed through the webpage and I can't work out what they're doing. They're certainly selling a solution, but it's not clear to me what the problem being solved is.

The pricing is clearly aimed at very large businesses, not your run-of-the-mill SME.

"Critical" projects and volunteer maintainers

Posted Aug 1, 2022 20:11 UTC (Mon) by Wol (subscriber, #4433) [Link]

Maybe the Linux Foundation should set up a trade association. If I have a bunch of important dependencies, I sponsor a developer in the association - preferably for one of things that's important to me.

Other companies do the same thing.

But the deal is, if I have a problem with another project, I talk to my developer. Hopefully the developer of the other project is also part of the association, and they fix my problem for me.

You won't then need that many companies involved and - certainly for companies and coders that join - the companies get good support and the coders eat :-)

Cheers,
Wol