Great thought exercise but I feel it's more focused on how developers would like to get paid, versus how people with money would like to pay them. It's telling that the proposed system confers no meaningful rights to the sponsor -- his support grants him only the right to open issues which the developer may choose to consider.
I don't think that would pass muster with most purchasing/procurement people. They would rather just license a piece of software with a clear-cut usage agreement and get a support entitlement. The business value is all in knowing what the software/vendor will deliver and having some guarantees if things go wrong. I meet IT people with purchasing authority _all the time_ who think open source is cool, they love the concept and the values, they know there's great software out there, they're just baffled that they can't buy it and get the type of support they need to replace that decrepit proprietary system that charges 6-7 figure annual license fees. The big open source vendors -- RedHat etc. make tons of money on these situations already, but there's much more to be made and you could argue they aren't returning enough to the devs.
Anyway, the proven money is in selling support contracts, and perhaps if you could pay to have some real influence over feature/bugfixing priorities there would be a market for that as well.
Developers often don't realize that all widely adopted software benefits from having a support team. The support team deals with as many customer inquiries as they can for you, and they inform you about how the software is really being used in the wild. I think there would be a place for some sort of "technical support done for you" service where an open source developer can just hand off the responsibility for support contracts to someone else, and that someone else splits the revenue with the dev.
There's tons of money in the world right now for anyone who familiarizes themselves with a popular open source project and then learns how to do the sales & support for it. It's just that the devs don't want to deal with this stuff.
It was always my intention that this could in some manner encompass "support contracts" in a way that companies could pay for. I think I mentioned the possibility of tiered pricing; one tier might be "$1000/month, guaranteed reply to issues within 24 hours". I don't know enough of how corporate software support contracts work to flesh out the details here.
There's a lot of variability, but yeah, that's the right general idea.
Support contracts basically come down to providing higher levels of insurance in exchange for charging (potentially exponentially) higher premiums. You CAN guarantee that you'll fix issues. That might raise the monthly commitment to $10K, or even $100K. There are companies which will pay those premiums because it's worth it to them and they might be paying even more to someone like IBM.
You just have to have a really good support org and make them believe that they're going to get what they need, since that sort of commitment doesn't come lightly. An open source project also needs to consider on whether they're giving up too much autonomy by doing this sort of deal, but the opportunities are out there.
I think the idea of having a rider on the support contract which basically says "you get to vote on the next feature we develop" is a very interesting compromise. Basically no proprietary software vendor offers something like that, you're at their whims, if they decide to spend all their dev time on features that lock you in and then they double your licensing fees, tough luck, you have no recourse. If you went to procurement and told them, hey we'll never do that because if enough of our big customers got together they could vote against that work and we'd have to cancel it, it would blow their minds. It would be the ultimate form of insurance against single vendor lock-in. Who knows how much you could charge for that, because most corporations understand very well how much it costs them many millions of dollars to be locked into some proprietary vendor, they just don't see a good alternative.
So cool to get a response from the founder of Tarsnap btw!
I usually use "guaranteed to respond to the issue within one business day" which gives extra leeway for the weekends/holidays, with the additional provision that I need to give advance warning for things such as vacations, etc..
Most customers I've dealt with seem perfectly fine with that.
The crucial part here is to be careful (as you were) and not say "guaranteed fixing of issues within X".
As a data point, with DB Browser for SQLite (used to be known as "SQLite Browser"), which is reasonably popular (150k+ downloads/mo), we're trying a different approach.
We're making a "Cloud" platform for storing and sharing SQLite databases, with GitHub style forking/merging/social bits & integrating it with the next version of DB Browser for SQLite. Initial dev server online here showing the concept:
It seems like data scientists, universities, and government bodies will find it useful as it meets some needs they have which are completely unaddressed by anything else.
So, we're intending to generate revenue through this to support developing both DB Browser for SQLite and DBHub.io itself, though it's too early stage to say exactly how/what/where/etc yet.
Our initial hope ;) is that GitHub style public == free, private == $ will work. We'll find out over the next few months as we start putting real servers online, measuring usage, and figuring out possibilities from there.
I don't think that would pass muster with most purchasing/procurement people. They would rather just license a piece of software with a clear-cut usage agreement and get a support entitlement. The business value is all in knowing what the software/vendor will deliver and having some guarantees if things go wrong. I meet IT people with purchasing authority _all the time_ who think open source is cool, they love the concept and the values, they know there's great software out there, they're just baffled that they can't buy it and get the type of support they need to replace that decrepit proprietary system that charges 6-7 figure annual license fees. The big open source vendors -- RedHat etc. make tons of money on these situations already, but there's much more to be made and you could argue they aren't returning enough to the devs.
Anyway, the proven money is in selling support contracts, and perhaps if you could pay to have some real influence over feature/bugfixing priorities there would be a market for that as well.
Developers often don't realize that all widely adopted software benefits from having a support team. The support team deals with as many customer inquiries as they can for you, and they inform you about how the software is really being used in the wild. I think there would be a place for some sort of "technical support done for you" service where an open source developer can just hand off the responsibility for support contracts to someone else, and that someone else splits the revenue with the dev.
There's tons of money in the world right now for anyone who familiarizes themselves with a popular open source project and then learns how to do the sales & support for it. It's just that the devs don't want to deal with this stuff.