Gotta admit I found it pretty irritating, in the xz discussion of the last two weeks, that some people declared confidently "you can't pay maintainers". (cc @ehashman)
It isn't easy to pay maintainers, but it can be done: at Tidelift, we've been doing it for years. So I figured I'd write up how we do it and what we've learned. And yes, it's a HOWTO. Be glad I also avoided an FAQ ;)
@luis_in_brief@ehashman loved the post; my own take is that for many projects, the main thing that people should want to pay for is not the maintainer coding, but rather, making decisions: specifically, 90%+ of this is bug triage and code reviews. You do point out quite rightly that people should not be paying for specific features or bugfixes, but the ongoing vibe that the project is viable and can accept code contributions is much more valuable than scorecard scores
@luis_in_brief@ehashman there is often a sense among casual users that paying for maintenance means paying someone to write more code, going-concern projects with actual users, even smaller projects, almost always get more contributions of code than they can possibly manage to accept. Everybody wants to write code. Nobody wants to carefully fix all the tests and cover the last 3% of every patch and give comprehensible but tediously repetitive feedback to first-time contributors
@luis_in_brief@ehashman everyone who depends on a project wants that project to quietly continue existing. that means getting new people involved in the project, which is really, really hard. Almost all first-time contributors become one-time contributors, and to get the 1% of people who will develop enough of an interest to actually become a maintainer, you need a well-maintained on-ramp that the other 99% will fall off of, which makes the maintenance of that ramp incredibly discouraging.
@luis_in_brief@ehashman But if you don't maintain that ramp well enough (timely, polite, friendly code reviews; clear triage feedback; a comprehensible website; up to date documentation; governance that includes a clear process for inducting new members; ways to recognize contributors) then instead of a 99% bounce rate you get a 100% bounce rate. in the moment the difference between those is almost impossible to notice; but in the long term, it's existential
@luis_in_brief I don't agree with everything, but that is ok. Because this is exactly the HOWTO to pay maintainers. I am not sure it will help that much (for different reasons) but I do agree that it is how to do it :) Thank you for writing this. I never managed to make one as good as this one.
@luis_in_brief Oh, and by the way, your "new call-to-action" at the bottom is broken :) (it seems like a cross-reference failure), and there are a ton of console logs coming from the floating sidebar. :D
@Di4na yeah, I feel like “amount paid” is almost a whole separate FAQ or something. More is better, obviously, but there is some nuance below that top line.
@luis_in_brief@ehashman Tidelift have been sending me a monthly check for years now. Not big enough to compare with salary, but big enough to split 50/50 with a co-maintainer and buy myself some indulgence like a new monitor every few months.
Right, now I'm going to go around throwing this Shannon Mattern rticle at everyone again. (This is specifically about the built physical environment but the lessons from it are extremely relevant and the parallels obvious IMO.)
@luis_in_brief@ehashman other pain points wrt accepting money as maintainer (1) paid to work on OSS full time, but some projects out of scope for the $day job so get sidelined. taking payment to work on any of those is a tricky conflict of interest to resolve (2) concern around possible tax reporting liabilities that could be created for a recipient, especially with cross-border payments. they would have to be a large enough value to cover accountant fees to make it worthwhile contemplating
@ehmatthes good question. Suspect it's probably in the 3-5 range (which, numerically, covers the overwhelming number of projects) but depends on factors like geography of participants and how socially close they are. (One of my favorite stories is two co-maintainers who had never been able to physically meet until we brought them together.)
Add comment