The bounty puzzle

My mind may be a little warped at the moment from spending time as a programmer for client driven projects and the associated perils, but every time I think about open source bounties something in the back of my brain starts squealing painfully.

I mean, these things just seem like a potential minefield to me. And I don’t mean legally, in the sense of people suing each other over bountified things that did or did not happen or bounties that did or did not get paid. I just mean in the sense of an enormous amount of sweat and blood spilled over the details of when the task is complete.

Consider the kind of features that are being bountied, for example parental control for Ubuntu. There are so many ways that one might not like an implemented solution to this problem, both reasonable and petty:

  • it might not completely control the users’ access in any one of a number of ways (doesn’t block IM, is missing some porn websites, doesn’t block use of alternate proxies…);
  • it might not be written in a programming language you favour;
  • it might manipulate packages or user settings in a way that is contrary to the way the rest of the distribution works;
  • you may disagree with its author about what parents might want to control;
  • it might have an unusable GUI, or one that you claim is unusable; or
  • it might have security flaws you can drive a truck through.

Moreover, upstream might have their own set of reasonable or petty objections, ranging from "I wanted to do that myself, it sounds fun, so I won’t use your solution" to "cleaning this up so that it works for us is going to be months of work" or "it has security flaws you can drive a truck through." And any or all of these might be the end of the project in a normal situation. But when some small amount of money is added, there’s a whole new fight on about what constitutes a completed bounty for the purposes of payment.

Even with companies, which are fairly motivated to be profitable, and even with specifications longer than the Bible, these fights can end up costing more person hours than the total value of the project. With bounties maxing out at USD500 or so, I’m willing to bet that the review time alone will cost more than the value of the bounty in all but cases so trivial that writing the code is faster than writing the specification anyway.

But the main problem for me is that doing client driven work now without a very clearly defined relationship between myself and the client (I’d like the armies of the undead to be involved, but failing that, serious review of the specification before coding begins) just gives me the willies. I’d rather take my chances with scratching my itch and hoping that the community agrees that it’s worth applying the patch than have the community try and assume a client relationship with me, let alone someone peripherally involved in the community who wants me to do the work of getting the feature that they personally want added.

There’s a problem here to be solved. It’s the old nasty one: what does a good specification (one where the specified task can be judged complete with as little ambiguity as possible) look like, and how does one write one?