success in terms of usage doesn't necessarily lead to success in these ancillary efforts - take for instance docz which is the project in question, its very main selling point is that it's simple enough you don't need support and it generates output without dependencies that is trivial to package or serve yourself

and yet there's mention of lots of people pressuring him to add new features or fix issues.

So i say, OSS developers should actually have a standard set of ultimatums for all projects ; namely, pay up, or don't get any support that the developer doesn't feel like providing.

also, tenuous conditions are inherent to that model - typically you have a couple people paying a few dollars and asking for the moon every other day, and you already said "yes"

doing that sort of thing solo is certainly not for everybody, the overlap of people good at producing software and good at customer management + PR is extremely slim

if you were only paid a few dollars, why would you say yes to it? I'm not suggesting that you accept any "donation" amount and agreeing to a blank cheque for features.

I'm saying you ask for some 20-30k per feature request that takes approx. 1 month of work. And if the requesters of such feature can't pay this, then cannot afford to request (basically i'm using a contractor rate above, but you substitute the level of pay you intend to make).

I myself had something like this in mind decades ago, thinking of providing a web/platform/service to barter such deals, but it never made it past the design stage before I was convinced it was a fool's errand - and that was even before I started doing contract work

I'd be interested to listen if you can provide detailed real-world examples of how do you see this working

In this bit:

> I'm saying you ask for some 20-30k per feature request that takes approx. 1 month of work. And if the requesters of such feature can't pay this, then cannot afford to request (basically i'm using a contractor rate above, but you substitute the level of pay you intend to make).

how do you envision this negotiation taking place? coders, let alone younger ones and/or OSS-attracted ones, typically suck at this, on the following levels:

1- all work takes "a bit of effort" to "a weekend hackathon" to "two weeks™" - both on the client end, as technical challenges are often invisible to the client, and on the proud coder end who tends to overpromise a lot (combination of overconfidence, wanting to "give the best deal", and other psychological factors)

2- people are used to dark patterns and seeing concrete figures puts off a lot of people and has a strong impact on the perception of projects - also, the internet is worldwide and in most of the world a moderate pay will be seen as greedy or astronomical

3- judgement on whether the work is done, or ongoing, or satisfactory - this will always lead to some friction, and most people don't want to deal with it; coders gravitate to jobs where this shit work is done by someone else, typically on lower emoluments, leaving the higher rate for himself (we're usually a "he" let's face it)

From these, 1 is (roughly) the inner challenge, 2 is the outer challenge and 3 is the structural challenge. Perhaps 3 is the strongest of the 3, as it essentially boils down to the business model competing with a more traditional, tried-and-tested company/employee paradigm. Since a good coder commands a good pay these days, the traditional model needs to suck a lot to a lot of people before the coder (let alone the project lead coder or the CTO/CEO coder) is better off outside of "the system"

perhaps I should finish up some write-up and then open a discussion, but who'd read it heh

long story short, these OSS-with-tips arrangements will remain in the hobby/side-gig range for most people, except if you hit gold somehow in a superstar economy; I don't see this changing in the foreseeable future