Having both written & maintained open source software, and negotiating (commercial) support and development contracts, I find myself thinking about this issue every couple of months.
A few thoughts:
Bounties are a problem since each is basically a tiny contract (what to deliver, what it'll cost, when, etc) in itself, so they need to be haggled over, ie. there's a nontrivial transaction cost to each. In practice, you get a crossbreed between a graveyard of ignored stuff and a race-to-the-bottom wishlist amounts - FIX THIS URGENT MULTITHREADED PROGRAM FOR $15 PLZ I'M PAYING YOU! I'd rather do open source obligation-free than that.
Monthly donations (like Evan You's Patreon campaigns that dvnguyen mentioned) can work, but from the client standpoint, it's not really clear what you gain ("if this breaks tomorrow, who I'm gonna call?"), so while theoretically nice, in practice there's not a lot of uptake.
As Colin mentions in the post, if there's a large company (or a few) that use the software and see the value, they can be persuaded to support it via explicit support contracts with the developer(s) or just hiring them (I think redis is a success story here). But many projects don't have such large companies as users (or they don't know that they have!).
Another issue that I think we always stumble in these discussions is the pricing and talking about value, esp. in context of open source software. My strong opinion (feel free to disagree is): in open source, the software itself is a commodity, and its PRICE is $0. If you don't like that, don't do open source. However, there's no question that the software has a VALUE that's over $0 (otherwise why'd anyone use it). But the value of the software is not only in the code, and as patio11 always reminds us (in the context of business discussions), determine your value and charge based on value, not on cost (ie. amount of effort needed to write the code).
The value is that the company developers are faster (increase/multiply their value). The RISK to the company is that the developers will have to spend their time maintaining, fixing, updating, the software if there's no external vendor to do it (the "who am I gonna call?" problem), which will decrease the developers' productivity, ie reducing the software value (perhaps below zero). So, removing this risk should have business sense to the company.
Borrowing from risk management, we can try to estimate the probability of it happening ("how often does the code need to change", "how often bugs that should be fixed are found", not "what is the probability of open source dev burning out" since that hides the externality - developer's labor), and the cost ("if we have to maintain it ourselves, how much time (ie. money) would we spend"). It's more of a ballpark estimate rather than a rigorous calculation, but for many highly used projects, a reasonable figure can be estimated. This figure, then, is the amount the company could reasonably be expected to pay each month.
So the company is not paying for the software. They're paying for their piece of mind - to minimize risks inherent in their use of unsupported software. I am convinced this argument is MUCH easier to sell to the companies than social or moral obligations.
On the developer side we want a steady, stream of income, so combining the two might mean a (tiered) subscription based model. For $0 (free) you use the software but the developer has absolutely no obligation to ever listen to your bug reports or feature requests. For $X (monthly), you can expect the bugs to be fixed (and prioritize which should go first), up to a specific limit in amount of hours worked, but the developer has the sole discretion over the new features to be implemented. There can be multiple tiers ($X, $Y, $Z... for different amounts of work).
The limit in amounts worked is there to set expectation of what exactly the company gets for their money, ie. what to do if the company asks for more work (bugfixing) than you'd be happy doing for the subscription amount. For $X, it's Y hours of developers time (non-refundable retainer). $X could be set based on the calculated risk above, an Y (hours) is based from the dollar amount and a hourly consulting rate that the developer could ask for when doing a real retainer contract.
An example: let's say I'm a proud developer of libwidget, an indispensable library for managing widgets in a nosql database. There's dozens (respectable, but not high) of companies using my code. I do a few updates a month, mostly bugfixes. If I disappear each company would probably need to spend an hour of their developer time each month maintaining this, let's say that'd cost them $100. Let's also say my target retainer rate is $100/hr, so this ends up being an hour of my time. (To clarify, the rate would be lower than the usual consulting rate since there is a possibility that no work will be needed in a month).
Based on the above, I'd set up a subscription plan that says: for $100/mo, you can file bugfixes (private or public), and I will spend up to 1hr per month fixing those issues (if there are more of them, I'll let you prioritize). If more work is needed, I can either set up a larger plan, or agree to do extra work for $Z ($Z > $X), or any combination of the above.
Something like this would, I believe, scale nicely from almost no work (and getting a few bucks a month for coffee and ice cream :) to being basically fully employed in support of your work (and being paid fairly for it), while making everyone clear about what they can expect from you as a open source dev.
As a footnote - many companies budget for a year, so offering year subscription may work as well, or better (since it'll be almost the same to the company financial-wise, and they'll know they have you on support for the next 12 months). Or you can pull an oldest trick in the book and price-differentiate yearly and monthly fee so that the yearly fee looks like a better value for money. The yearly fee makes the subscription model even more smooth and with less surprises than the monthly-based one, so it's useful to keep in mind.
Great thing about this is that it's possible to do with existing infrastructure for monthly subscriptions (say, Patreon for subscriptions, github for issues, email or a separate private bug tracker for private "technical support"). But if a platform that nails this approach would appear, I'm betting in itself it'd be a $1B+ company (think GitHub for - gasp - git hosting - actually, no, wait - GitHub why haven't you done this already ?!?).
A few thoughts:
Bounties are a problem since each is basically a tiny contract (what to deliver, what it'll cost, when, etc) in itself, so they need to be haggled over, ie. there's a nontrivial transaction cost to each. In practice, you get a crossbreed between a graveyard of ignored stuff and a race-to-the-bottom wishlist amounts - FIX THIS URGENT MULTITHREADED PROGRAM FOR $15 PLZ I'M PAYING YOU! I'd rather do open source obligation-free than that.
Monthly donations (like Evan You's Patreon campaigns that dvnguyen mentioned) can work, but from the client standpoint, it's not really clear what you gain ("if this breaks tomorrow, who I'm gonna call?"), so while theoretically nice, in practice there's not a lot of uptake.
As Colin mentions in the post, if there's a large company (or a few) that use the software and see the value, they can be persuaded to support it via explicit support contracts with the developer(s) or just hiring them (I think redis is a success story here). But many projects don't have such large companies as users (or they don't know that they have!).
Another issue that I think we always stumble in these discussions is the pricing and talking about value, esp. in context of open source software. My strong opinion (feel free to disagree is): in open source, the software itself is a commodity, and its PRICE is $0. If you don't like that, don't do open source. However, there's no question that the software has a VALUE that's over $0 (otherwise why'd anyone use it). But the value of the software is not only in the code, and as patio11 always reminds us (in the context of business discussions), determine your value and charge based on value, not on cost (ie. amount of effort needed to write the code).
The value is that the company developers are faster (increase/multiply their value). The RISK to the company is that the developers will have to spend their time maintaining, fixing, updating, the software if there's no external vendor to do it (the "who am I gonna call?" problem), which will decrease the developers' productivity, ie reducing the software value (perhaps below zero). So, removing this risk should have business sense to the company.
Borrowing from risk management, we can try to estimate the probability of it happening ("how often does the code need to change", "how often bugs that should be fixed are found", not "what is the probability of open source dev burning out" since that hides the externality - developer's labor), and the cost ("if we have to maintain it ourselves, how much time (ie. money) would we spend"). It's more of a ballpark estimate rather than a rigorous calculation, but for many highly used projects, a reasonable figure can be estimated. This figure, then, is the amount the company could reasonably be expected to pay each month.
So the company is not paying for the software. They're paying for their piece of mind - to minimize risks inherent in their use of unsupported software. I am convinced this argument is MUCH easier to sell to the companies than social or moral obligations.
On the developer side we want a steady, stream of income, so combining the two might mean a (tiered) subscription based model. For $0 (free) you use the software but the developer has absolutely no obligation to ever listen to your bug reports or feature requests. For $X (monthly), you can expect the bugs to be fixed (and prioritize which should go first), up to a specific limit in amount of hours worked, but the developer has the sole discretion over the new features to be implemented. There can be multiple tiers ($X, $Y, $Z... for different amounts of work).
The limit in amounts worked is there to set expectation of what exactly the company gets for their money, ie. what to do if the company asks for more work (bugfixing) than you'd be happy doing for the subscription amount. For $X, it's Y hours of developers time (non-refundable retainer). $X could be set based on the calculated risk above, an Y (hours) is based from the dollar amount and a hourly consulting rate that the developer could ask for when doing a real retainer contract.
An example: let's say I'm a proud developer of libwidget, an indispensable library for managing widgets in a nosql database. There's dozens (respectable, but not high) of companies using my code. I do a few updates a month, mostly bugfixes. If I disappear each company would probably need to spend an hour of their developer time each month maintaining this, let's say that'd cost them $100. Let's also say my target retainer rate is $100/hr, so this ends up being an hour of my time. (To clarify, the rate would be lower than the usual consulting rate since there is a possibility that no work will be needed in a month).
Based on the above, I'd set up a subscription plan that says: for $100/mo, you can file bugfixes (private or public), and I will spend up to 1hr per month fixing those issues (if there are more of them, I'll let you prioritize). If more work is needed, I can either set up a larger plan, or agree to do extra work for $Z ($Z > $X), or any combination of the above.
Something like this would, I believe, scale nicely from almost no work (and getting a few bucks a month for coffee and ice cream :) to being basically fully employed in support of your work (and being paid fairly for it), while making everyone clear about what they can expect from you as a open source dev.
As a footnote - many companies budget for a year, so offering year subscription may work as well, or better (since it'll be almost the same to the company financial-wise, and they'll know they have you on support for the next 12 months). Or you can pull an oldest trick in the book and price-differentiate yearly and monthly fee so that the yearly fee looks like a better value for money. The yearly fee makes the subscription model even more smooth and with less surprises than the monthly-based one, so it's useful to keep in mind.
Great thing about this is that it's possible to do with existing infrastructure for monthly subscriptions (say, Patreon for subscriptions, github for issues, email or a separate private bug tracker for private "technical support"). But if a platform that nails this approach would appear, I'm betting in itself it'd be a $1B+ company (think GitHub for - gasp - git hosting - actually, no, wait - GitHub why haven't you done this already ?!?).
Just my $0.02 :-)