iTWire: How do you feel about ideas like the Dunc-Tank which Anthony Towns thought up - the idea of paying some people to work on things to keep to release schedules?

BG: It's really interesting because that was not the first time in the project's history that people had been paid to do work on behalf of the project. In fact, I've helped over the years, when I was DPL, in the years before that, arrangements have been made for various people to be paid to do work on behalf of the project that I thought was important, or that my employer thought was important.

What was interesting about the Dunc-Tank experiment was just how much noise it generated within the project. I have spent quite a bit of time trying to think about what it was that caused that to happen and why was it that that it generated so much noise - and why other successful instances of paying people to accelerate work in some parts of the project hasn't generated so much noise. I think it had to do with the degree of visibility.

It bothers me a little bit. I don't like the notion that its easier to pay people to work on the project when you don't talk about the fact that you're paying them and yet that seems to be the lesson that came out of the Dunc-Tank experiment. I haven't tried to draw any huge conclusions from that about what we ought to do about the future.

There continue to be a substantial number of key contributors in the Debian project who are allowed, if not directly supported, to do work for the project as part of their day jobs. I personally have a hard time figuring out where to draw the line between these different kinds of compensation. I'm thrilled that several times in the past, when there was some specific activity, whether it was achieving LSB compliance or getting past certain transition activity like when we trying to get the Itanium IA64 architecture well supported by Debian, HP paid quite a bit of money to several groups of people to get it done.

I was a little disappointed that what came out of that whole experience (Dunc-Tank) wasn't a crisp understanding of how we should do this in the future. What we got instead was a very clear example of "here's a way to not do it."

CONTINUED