As a journalist at Computerworld Australia:
The Dunc-Tank project has been the topic of much debate in the Debian community since it was launched in September last year. Aimed at overcoming Debian's notorious delays in meeting its scheduled releases, Dunc-Tank collected donations to test the effect of funding on open-source software development.
It has now been more than a month since the scheduled release of Debian 4.0, codenamed etch. However, even with Dunc-Tank's funding, etch is yet to be seen.
Liz Tay speaks with Debian Project Leader and Dunc-Tank mastermind Anthony Towns to find out what happened.
How did the Dunc-Tank experiment come about?
Dunc-Tank was a project to see if we could put some funding into Debian release management so that it would be more likely to come out on time.
It was originally going to be an internal thing within Debian, but there was a lot of controversy as to whether the release was a suitable thing to be funding alone, or whether it should have been a more general thing, so that anyone could apply for funding.
So rather than spend six months debating it and working out a really good way of doing it, we figured that since the release was due in just a couple of months, we'd go ahead with an external project and once we'd done that, we could have some actual results [and] some information about whether these things work and what sort of problems actually come up.
The particular thing that inspired this [Dunc-Tank experiment] was about three months before the December 4th release date -- that had kind of been bandied around a bit casually, Steve Langasek, who is one of the release managers, was basically working 18 hours a day on his day job to do PHP coding, and he wasn't having enough time after that to look into some of the release critical issues that we were having.
I thought if we could get Steve being able to spend some dedicated blocks of time, rather than having to compromise with his work and stay up late, or not getting any sleep overnight, or whatever, then that might have a good influence. So we talked to the release managers to see if that would be practical, and it turned out that it was for them.
Why has etch not yet been released?
The long term release goal was about 18 months, which was December last year. To pick a date out of the air, the release managers chose December 4th. Not everyone in Debian thought that setting a release date at all was a good idea. Not everyone had even heard of the December 4th release date; it had been in a few announcements but Debian releases have been getting longer and longer, so when you have a release announcement, no one believes it anyway, so it just doesn't get taken into account.
It's hard to say quite why the deadline was missed. There were a few issues, one of which was the kernel packaging to remove firmware that we had some general resolutions from before; that only managed to get done on January 5th this year. So about a month after we were hoping to release. That, in turn, was a requirement for the next installer release candidate, which will hopefully be the final one, and that will then require about a week or two of testing to make sure it's okay.
That supports some of the arguments that the release managers aren't the ones that need to be funded; it's the people doing some of the work that's problematic - like removing firmware and working on the installer - perhaps we should have dedicated some resources to helping them out.
On the other hand, the release managers do a lot of work on fixing up the actual release critical bug count. What we can see in the graphs tracking these problems is a real improvement from 200 to 100 release critical bugs when Steve was working full time on it, and an improvement of about 100 to 75 or 50 while Andi [Barth] was working on it.
Do you think Dunc-Tank has been successful as an experiment?
There was a definite effect [of funding] on it [etch], and there were some other indirect effects as well, such as the Dunc-Bank project, in which a group of people, mostly from France, didn't like the idea of paying people at all and set up a project that would work with Debian's guidelines and try and improve Debian, but in such a way that Dunc-Tank would fail and wouldn't release on time.
They decided to do some really thorough testing of the release and find more bugs that would then have to be fixed, because if you don't find bugs in advance you can't fix them, and so you might release on time, but with bugs.
So they found the bugs in advance, and said, 'oh, we know about these bugs, and etch can't be released till they're fixed'. This forces us to release a better product, but later, which is what the Debian community tends to focus on anyway.
So while we've had Steve fixing all these bugs, we've also had a lot more being filed, and so I think we've had a real improvement in the QA process and that's from people who specifically don't like the project so it's hard to say if that's a failing or a success, and whether it's possible to repeat that at all.
There was some debate within the Debian community about whether Open Source projects should be funded at all. Does money corrupt Open Source?
It definitely can be a corruption. One of the really great things about Debian is that people volunteer to it and then are able to work on doing things the way they think is right, rather than towards deadlines they don't believe in, or just getting a quick thing out that kind of works but you know is going to fail in the long term. That kind of makes it more fun to work on, which encourages the whole volunteer spirit which is much cheaper than trying to fund people.
There have been estimates in the past that the contributions to Debian are worth $40 million or more than that just in lines of code measurement. And if you've got a volunteer project that can generate that much work just by having people enjoy the work they're doing, then that's fabulous and you don't want to change that into a commercial arrangement where people are only doing it for the money, and you need to generate all this money just to pay them to not do as good a job.
So it [money] can corrupt, but I think in this case we've managed to avoid it by being very careful about people we've paid to do it. They were paid for a month - they still haven't actually received the money because we've had various problems getting the charity stuff set up - and they're still working just as hard right now, but they've obviously had to go back to work on their day jobs, so they have a bit less time than they did during October and November.
If money is a disincentive to doing a good job, how do you think this reflects on the Open Source community?
I think that really applies to everyone - you find a good job then suddenly it becomes a 9-to-5 thing, and you have to get up in the morning every morning to go and do it, and then you start looking at the clock and whatever else.
So you need to make sure you have the right incentives; it's not just about throwing money at someone and have them enjoy their work. And for the open source community, I think it's really demonstrated it's [the community] got a lot of strength, because even people who did feel that money was corrupted ended up forming the Dunc Bank project. And even in trying to oppose it, it really helped the project release a much better product.
When you can have people who are working in direct opposition to each other end up essentially working together to produce something better, that seems really amazing.
