On your last point -- whether a FOSS project is set up to be able to do anything useful with $800 varies a lot, I think. If it's something put out by a consulting company or by a one-man-band independent or even by a student, sure. But a lot of FOSS projects are either worked on mostly by people on a big-company payroll (in which case their time is spoken for already and the bigco doesn't care about your $800), or else hobby/spare time stuff for somebody whose day-job is unrelated (in which case they're in it for other reasons and preferring not to spend four hours of their free time pair-programming with a stranger is an entirely reasonable choice).

Basically unless you're already making a living by the accumulation of a lot of that kind of $800 transaction, the hassle involved in accepting just one of them as a one-off makes it not worthwhile (tax questions, potential conflict of interest with existing employer, dealing with people as paying clients rather than as people one can simply say 'no' to, etc...) And there's a massive chasm between "maybe once in six months somebody offers you $800" and "enough money coming in to quit the day job".

The $800 was just an example number. In some cases I've asked "how much to get you to just pair-program with me using your library for four hours" then our business is concluded. It's a deal that I felt would be very low hassle -- however, I guess the supply-side didn't think so. (for reference I've been coding and consulting around open-source stack for like 20+ years). I've been on both sides of these cut-and-dry type of deals.

However, the more common scenario when consulting -- and I'm sure many are nervous about this type of play-out -- is the client drags the deal on and on and on...and argues about the price...and pays late...and has endless change requests...and is surpirse that ECRs cost money...and needs just one more meeting about $THING..and...and...and.

I've always assumed that's why we've been rejected...how can someone tell we're NOT LIKE 90% of the consulting buyers and mostly know what we're doing and have a straight-forward deal?

> It's a deal that I felt would be very low hassle -- however, I guess the supply-side didn't think so.

Were they administratively prepared to accept payments? For instance, did they have business bank accounts, invoicing, tax numbers, record keeping - if not, then it would be a hassle to do all that in order to receive a once-off payment for a days work, even if the rate is generous. Indeed, they'd need to "go commercial" to make the hassle worthwhile. So it may not be as cut-and-dry as you thought.

Even with those tax issues aside, there’s quite a few projects on OpenCollective (for example) that have raised tens of thousands of dollars and haven’t spent it. I think for some portion of successful open-source developers, there’s a significant mental hurdle associated with taking cash for themselves even when it’s the click of a button away.

>Oddly, I've found some other FOSS projects that I wanted to get some help with -- and led with "I'll pay you to pair-program with me for like four hours and answer my dumb questions" -- I was surprised to be turned down: "we don't want to make this commercial, just file a bug" -- do you want a new bug or do you want $800?

I've had multiple experience trying to pay FOSS developers where they wouldn't even accept a donation.

The rationale seems to be that they don't want the increased responsibility that comes with offering a paid service.

> The rationale seems to be that they don't want the increased responsibility that comes with offering a paid service.

This is a really big deal. There's a step change in responsibility that happens from "offering free project you do whatever" to "you're paying me for a service." Even if that service is just consulting, it's still a big difference in responsibility. When it's free you can always walk away whenever you want, even if you were just in the middle of fixing something up.

Yep, I can vouch for this. I work on the Redux JS libraries, entirely volunteer. I spend a _lot_ of time maintaining them, but I'm mostly able to do that because I can _choose_ to do that work when I feel like it, with no outside pressure. Adding financial obligations would likely cause a lot of additional mental overhead I don't want to deal with.

Besides, in my case at least, I spend so much time working on Redux stuff as it is that money really couldn't even make me do more than I already do anyway :) The only thing I can think of that would qualify would be getting paid a full salary to do maintenance full-time, and I don't want that either. I like building other stuff for the day job, and Redux stuff in my free time.

On the last case: I have received requests for consulting on my FOSS library, which I turned down because while I would love to live from it, I am currently employed in an exclusive contract and I don’t want to figure out how to declare this income to the tax office.

It is a bit of a pickle, either go full consulting on your FOSS product (which might not be realistic), or work in something unrelated for someone else, getting something in between is hard.

"Exclusive contract" is often not merely a problem with income declaration, it may legally require that you can only get payed for your work if the exclusive employer explicitly permits this specific incident.

You could file a bug/feature request and then pay a dev internally to work on implementing it. It would amount to much the same thing.

Paying the maintainers is waaaaay different than paying your own employee. Both are good, but the second is already quite common, while the first would be fairly uncommon (and encourage the maintainers a lot more!)

It doesn't have to be different; your own employees are developers and can learn to become just as effective at contributing to any given project (and after time, many different projects) if you ask them to and provide them with time to learn.

I don't think that's entirely how it would work.

As an open source maintainer I would much rather you pay me than pay your own developer - because no matter how talented they are, if they're doing the work I'll need to spend a huge amount of my time discussing the work with them, reviewing their code and generally being a now-unpaid engineering manager to help shepherd their efforts!

As a hypothetical employer of said hypothetical developer, I wouldn't want them to dive straight into the code; I'd want them to demonstrate an understanding of the business and technical problem we face internally, develop some ideas (preferably ones that generalize to other users of your software), and discuss those potential solutions with you.

The ideal goal would be to have someone on my own staff who understands and can improve the project's codebase, with your blessing, and who contributes towards the resilience of your project by way of adding numbers (and I'd be happy if they respond to Q&A, within reason, as part of your community, because it's part of my business' dependencies).