Hacker News Reader

Very well said.

I maintain an open source project which is used by a few hundred companies, and I also sell a couple commercial products which enhance the functionality. I don't accept donations since I much prefer to offer well-defined commercial products instead of ill-defined donation benefits.

Despite this, I've still had users who insist I should accept donations, often claiming that I would make some absurdly unrealistic amount of money if I did so. In one case the user kept arguing with me and demanding to know more reasoning as to why I didn't want to accept his donation. Of course these same users are absolutely not interested in the well-defined paid products and always offer weird mental gymnastics as to their thinking.

I just can't relate to or understand this behavior. Do these people burst into random businesses in real life and say "Hello, I love your store but don't want to buy any of your products! I demand to know why don't you have a GoFundMe?"

I understand why you structure things the way you do, but I can speak for myself in a hypothetical scenario where I had money (now) to donate to an open source project that offers paid features. I might be concerned about paying for the paid features, because if I become reliant on them and then my capability to pay for them changes in the future, I'm now in an unfortunate position of having to re-write the features I've grown dependent on, or rewriting other parts of my codebase to remove the reliance on those features (a big refactor later can be more costly than planning properly in the first place)

I might then prefer to just use the open source version, and donate when I can, to avoid accidentally becoming dependent on something that I'm not confident of my ability to afford later.

That's a good point, and I can somewhat understand that perspective for some types of software, especially projects geared at individual developers or very small companies.

For infrastructure tools that are typically adopted by an entire org or company though (as my products are), the situation is less understandable to me, even in the scenario where the user is a small bootstrapped company or solo dev.

I mean, my own company is small and bootstrapped, and I still pay for a number of commercial products because they provide benefit to my business or my own productivity. If I ever can't afford them in the future, that would probably indicate there are deeper existential problems with my business besides needing to rewrite some code to avoid use of those commercial products :)

Also, personally if I wanted to give money to open source software but was unsure about the future affordability of doing so, I would especially focus on donating to open source projects that are actively soliciting donations in the first place -- rather than arguing with a business owner over their lack of interest in donations, which is what some users have done in my case.

I’m an open source maintainer that asks for donations with a basic “Buy me a cup of coffee” link.

IMHO the person donating already got something in return which is the free software + the good feeling of having donated.

I don’t offer anything in return for a donation because I also don’t want those strings attached and I feel at that point it’s no longer a donation. If I offer something in return it turns into sponsoring or simply buying services/access.

> I don’t offer anything in return for a donation because I also don’t want those strings attached and I feel at that point it’s no longer a donation

Couldn't agree more. The scope creep of this term hurts both parties. If there are expectations, call it a sponsorship program and state them clearly what it entails.

This is a take I have seen and don't hear often.

I depended on a FOSS project once that was mostly done by one maintainer, and would sometimes send feature or fix patches upstream. Once I sent an e-mail that I could give him hundreds of dollars for some bug bounties - his program would improve and he would make some money out of it. He said thanks but no, he made enough in his day job and only had limited time to maintain the program.

I think your experience may be different from the psychology-of-obligation issue that the GP describes.

For someone in a stable, salaried job that pays reasonably well (assuming USA level or the better paid parts of Europe), it rarely makes financial sense to accept "hundreds of dollars" for a complex task.

That's due to the amount: "Thousands to tens of thousands" would likely get a different sort of response, assuming it sounded like a reliable offer, not a gamble.

Most FOSS bounties pay terribly if counted by the hour. I'm guessing the bounties came to "hundreds of dollars" for several days (at least) work on the developer's part, because so many other FOSS bounties do? They would have to take formal vacation from their day job to do that work, or extend their working hours to focus exclusively on your issues across many evenings or weekends, at cost to their personal life? They would have to change the way they file taxes to accomodate this payment outside the regular flow of salary? Or, if they work in a job paid by the hour already and with flexible hours, they would be getting less accepting your bounties than they make at work?

The burdens and typically low pay make it a net negative to accept small FOSS bounties, for a reasonably well-paid salaried worker, just on the basis of economic rationality. The psychology of feeling obliged to finish the project after agreeing to do it is just one more burden.

> They would have to change the way they file taxes to accomodate (sic) this payment outside the regular flow of salary?

This affects my end as well - I was monetizing their product, and could probably justify an unsolicited bug bounty as external work. I don't know what the status of an unsolicited donation would be, I would have to ask my accountant.

The main premise is that some FOSS projects turn down smaller donations. In my case for a bug bounty, in GP's case a more general donation. When people discuss the need for FOSS donations, these cases aren't always mentioned.

In this specific case for me, the upstream was already fixing bugs in the tree, (as was I), and upstream was monetizing their product as well, so I thought it might work out well for everyone. At the end of the day I felt better about it anyway, because I was monetizing and using their product, and I did make an offer. I wound up contributing back with feature and bug patches (the bugs I could figure out how to fix).

I don't think funders should get any more say in or influence the direction of a project than anyone else. That should be up to the maintainer, of course taking advice from the users and contributors to the project. Funders are simply buying sustainability of the project, and that should be enough for them. This is how it works in projects like Inkscape, Krita or Debian.

I view it as two separate categories; donations & support contracts.

Donations are a thank-you payment for the code as it exists today. If someone finds it useful or includes it in their commercial product, give me a donation to reflect that thankfulness. It doesn't get you anything in the future, it is a payment for what exists today as-is today.

If someone wants a guarantee of future work, whether features, bugfixes or support, that requires a support contract with a much higher payment and more formal terms. In that case, they can influence the future direction but it'll cost orders of magnitude more.

Sounds like a great way to not have funders

I know a lot of large Patreons exist without any benefits at all, or with the benefits being a 20 word update every month.

> None of this is well-specified.

I'm not saying doing this would be trivial (and you'll definitely want to engage lawyers to help do it), but if you do take support contracts it will have to be well-specified in the terms of the contract.

So the answer to all those questions is that it'll be whatever you and the contracting party want them to be as part of negotiating the contract. The more they ask in terms of speed, guarantees, availability, they more you'll make them pay for the support. If there are things you don't want to do, make the price so high nobody will pay it (or if they do, then hire out the work since they paid you so much for it).

At the same time I think there exists an opportunity to bring the ordering and structuring function of transactions to the open source marketplace.

And I don't think the donations are subscription model really works for the reasons you enunciate meaning that everything is too unspecified, yet there are definite implicit expectations of some sort of transaction or exchange. The non-specified nature contributes a lot I think to inefficiency as well as to stress for both sides of that marketplace. It's only one of the factors that makes changes in open source currently not ideal.

With current models, even if you do specify it it acts maybe in a sort of way like a patreon model which doesn't really make sense in open source which has almost unlimited number of discrete continuously redefining tiny tasks.

The way I see payments working is more as a formalization of your choice to say yes or no to things so basically like okay here's sort of like my minimum fee or here's what I'm quoting to take a look at this. There's no guarantee that you know the entire issue that is unspecified and that could balloon into multiple future directions is going to be solved by this but here's the amount which I need right now to take a look at the next step.

Some people might view that as a way for them to make money or extract value or get reward for themselves out of their projects that is sort of tied realistically to the actual demand that people are prepared to put their money where their mouths are.

Whereas other people might see it simply as a way ensure they do not get overwhelmed by allowing the market to decide priorities, and provided down regulator or gatekeeper on the amount of incoming work. The filtration function happens before the requester even makes the request ideally because then once the expectation for the transaction occurring sometimes is established requesters may think more about steps they could take themselves other than operating in a more depending on demanding way. Possibly anyway.

For the creator, you can formalize your no by putting a price in front of it saying it'll cost you this much for me to take a look at it. But the thing is the person who made the request isn't the only person looking at that issue presumably and they don't have to be the one that pays that through.

Anyway I just just an experimental idea. The real interesting thing and where the meat is here is like how do you structure these sort of micro transactions, that sells problems on both sides of that marketplace. In other words you're allow developers to exercise more control over their incoming workflow which is a key driver of happiness you provide the opportunity for them to get rewarded for their open source efforts in a way that's actually tied to specific toss rather than a nebulous sort of funders model or sponsors model, and you provide a bit more like clarity and definition for requesters you know to think well is it really worth it to me to to make this request and how much am I prepared to kind of you know put up to have this creator I take a look at the next step for me.

I think there's multiple ways you could configure bringing the ordering and structuring function of transactions to the open source community. The above is just Possibility.