Can you provide more detail about how your system worked? Based on the name (bountyoss) it sounds like it was more based on bounties rather than ongoing funding for maintenance and support?
Yes, I was thinking that bounties could be used for maintenance. Developers would post proposals for bug fixes and features. These proposals could stay open indefinitely, and there was no limit on the number of proposals a developer could post. At some point, the thinking went, the total bounty that users had pledged to a proposal would reach a point sufficient to prompt the developer to accept the bounty and start development. There was a fairly elaborate (i.e., probably over-engineered) process for acceptance of the work product, in which contributors could vote on it, their votes being weighted by their contributions, and the developer had three chances to obtain their approval.
I tried to design the system so that a business that was using some piece of open-source software and wanted something done to it could justify spending the money. I don't know that I succeeded in that, but it was a goal, and I think that any system like this would have to appeal to businesses in order to succeed. I did not see it as being like Patreon or even Kickstarter; I saw it as a B2B site, where both sides were engaging in transactions for business reasons and needed their interests protected.
both sides were engaging in transactions for business reasons and needed their interests protected
Yeah, I struggled with this part. As a security guy, I prefer to create systems which are hard to exploit; but there's a point where it becomes too heavy-weight. If you're contributing $100 into a pot towards some code being written, how many hours are you going to want to spend to verify that the code being submitted is actually good?
I think a monthly subscription model solves part of the problem, since people who don't do good work would lose their sponsors over time. I'd also be inclined to say that people can cancel their sponsorship at any time and not pay for the past month -- which could be abused (sign up as a $10,000/month sponsor, ask for a feature, then cancel your subscription) but I think it's better than the alternative.
> As a security guy, I prefer to create systems which are hard to exploit
Yeah, me too. BountyOSS would even send contributors cryptographically signed receipts, which they could forward to developers to give the latter a way to check that BountyOSS wasn't skimming off more than our advertised share of the proceeds.
> If you're contributing $100 into a pot towards some code being written, how many hours are you going to want to spend to verify that the code being submitted is actually good?
Well, it depends. Maybe you needed that bug fix badly. My sense was that it would be sufficient to provide an approval process whereby, if a contributor didn't go to the effort to test the work product properly; the other contributors collectively approved the work (so the developer got paid); and then this contributor later discovered a flaw that was critical for them, they would at least feel that they had the opportunity to test it and it was their own fault they failed to do so. The site as built gave users 10 days to test the code and cast their votes; I could imagine adjusting that upward (and maybe even scaling it by the bounty amount, on the theory that large amounts of work take longer to test).
I think the reality, most of the time, would be that only the most demanding contributors would really invest much testing effort, but that's all you would need anyway. (The fact that their votes are weighted by their contributions is another incentive to pledge a substantial amount if the functionality is important to them.)
Not sure what I think about the subscription idea. That seems a lot like a support contract; and then what's the added value of having this site in the middle of the transaction? The attraction of the bounty model is that there's a good answer to that question: the site, with its approval process, performs an escrow-like function (though one must be careful with that word so as not to run afoul of laws governing escrow providers; I convinced myself at the time that my site was in the clear on this, but IANAL and YMMV).
Not sure what I think about the subscription idea. That seems a lot like a support contract; and then what's the added value of having this site in the middle of the transaction?
"A lot like a support contract" is precisely what this is intended to be. The reason for having the site in the middle is that the vast majority of open source software developers don't have a clue about how to negotiate and manage a support contract.
When I first started thinking about this, I started at "we need to make it simpler for open source developers to sell support contracts" -- it was only a few weeks later that I decided that it might make a lot of sense to combine "support contract" with "some people will simply want to contribute, whether they get anything back or not".
I came to suspect, by the way, that a site like mine would be useful primarily for a particular kind of open-source project: one large and mature enough to have a significant user base -- a significant commercial user base -- yet not so mature that it already does most of what its users want, nor so large that it already has a well-known business supporting it. The best example of such a project I can think of offhand is D. It might be interesting to ask Walter Bright specifically what he thinks about this or would want in such a site.
I also think it's important to understand what the value is for contributors. I think we both have the same observation here: one thing an open-source developer has to sell is their choice of what to do next. Imagine a developer using an OSS package and trying to get their manager's approval to spend money to get some bug fixed or some new feature; they have to have a good answer to the question, "why are we spending this money?". After all, it's possible that if they just wait long enough, the fix or feature will appear anyway. And I think generally, the answer is that by offering to pay, they influence the developer's choice of what to spend their time on; this gives them an incentive to offer an amount related to the cost, to them, of not having the fix or feature.
