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

"Critical" projects and volunteer maintainers

Posted Jul 13, 2022 23:48 UTC (Wed) by rgmoore (✭ supporter ✭, #75)
In reply to: "Critical" projects and volunteer maintainers by Paf
Parent article: "Critical" projects and volunteer maintainers

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.

to post comments

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