Hi, After a long and ambivalent discussion during the last weeks the project "Dunc Tank" (short DT from now on) has recently started. We consider that to be a major change to the Debian project culture: For the first time Debian Developers are paid for their work on Debian by a institution so near to the project itself. While we disagree with DT for the reasons outlined below, we want to state that this is not against the two people who should now benefit From it. We do trust Andreas and Steve that they do the best they can and only intend to do something good for Debian. With this mail we would like to summarize our thoughts about the DT project and the idea behind it. We also want to raise some questions we still consider unanswered and open: - Why were the release managers (RMs) chosen as beneficiary for this experiment? There are several areas within the Debian project that we consider equally important and full-time work there could benefit the project way more. Especially since it is clear now that we currently can not keep the scheduled release date, even with DT paying our RMs. - What exactly are the release managers being paid for? There surely must be more than a simple "Stay at home, work on Debian" in their contract. - How does DT want to know whether the release managers stick to their part of the agreement? - How is the success of this "experiment" measured? (For the release as well as for the entire project) - How do these measurements make sure that the observed consequences are based on the experiment? - How is it planned or is it even possible to compare the consequences of the experiment with a state of the project without this experiment? - What actions have been taken to ensure that potential negative outcomes of the experiment won't affect the Debian project? - Has it taken into account that several developers who have spent large chunks of time on Debian before got demotivated to continue their work? - How do these measurements try to compare positive and negative effects on the release as well as the Debian project itself? - During the discussion before the experiment it was said that the living costs of the release managers are to be paid. Additionally it was said that it is "providing a reasonable amount of money to cover living expenses" and later on, that this is "below the average" they could get elsewhere. However, the official donation site mentions US$ 6000.00 for each release manager. We do consider this to be neither just "living costs" nor "below average", not even by applying common taxes and insurances one has to pay. On what grounds has this amount been calculated?  https://www.pubsoft.org/pubsoft.py/project?proj=Dunc-Tank-etch-rm Although DT claims to be separate from Debian, we still feel that we are entitled to an answer to our questions, since after all, we are the people DT is experimenting with! After this set of questions let us comment on DT and present our opinion about statements made by DT supporters and board members. One claim of the DT people is that this "is only an experiment". Yet this whole affair already hurts Debian more than it can ever achieve. It already made a lot of people who have contributed a huge amount of time and work to Debian reduce their work. People left the project, others are orphaning packages, the NEW queue is rising, system administration and security work is reduced, DWN is no longer released weekly and a lot of otherwise silent maintainers simply put off Debian work and work on something else. While some of these actions simply tend to happen, all the listed points are explicitly due to DT. Compared to possible benefits one may see - e.g. releasing near a time we promised to release at - in our opinion this is not worth the trouble DT already got us in. Another bad feeling introduced by DT is that of a two-class project. Until DT, Debian has been a completely volunteer-based project. Today there are two paid Release Managers, opposed to all other project members. This creates a set of two "uber-DDs", in contrast to all the other nearly 1000 Developers and many more maintainers, whose work seems to be considered less important for Debian. It is ridiculous to set a deadline and then to create a project to pay those two people who set the deadline, but ignore the huge amount of work other people put into Debian. It is not as if those two Release Managers are now doing all the work that needs to be done, it is expected that they go and "direct" other people to do the work for the release. So why don't we pay all of them also? Aren't they worth the money? Another statement we heard repeatedly from DT supporters is that "DT is a separate project and not Debian". We do think that this is, at best, a joke. The DT board consists solely of the current Debian Project Leader, his assistant and other high-profile Debian Developers, working on a Debian related project. This simply can't be seen as something separated From Debian and the public has already proven that it doesn't consider it a totally separate project. We also heard a lot of sentences like "this happens since years, DT is nothing new". We do acknowledge that people get paid for work on Debian issues since years. We do not have a problem with this fact per se, quite the opposite is true. The big difference between DT and any random company paying people to work on Debian is that companies usually pay people to work on stuff they benefit from, for example a programmer that enhances a program in Debian and also happens to be the package maintainer has the permission to maintain the package in Debian during its work time. Or some system administrator that can enhance packages in Debian which then also benefits his work (like fixing bugs he then doesn't have to fix on every package upgrade). The important point here is that it does not involve an employer <-> employee situation within Debian, which DT is now introducing. So, to summarize DTs effects on Debian: It has demotivated a lot of people who now either resigned, simply stopped doing (parts of their) Debian work or are doing a lot less than they did before DT was started. The freeze got delayed and getting the release out on schedule has become nearly impossible. We are unable to see any good virtue in this "experiment". The heated discussion DT has consumed an incredible amount of time and energy that could also have been used in a much more productive way. This was probably expected from the DT initiators but didn't keep them from setting off this discussion at such an important time - shortly before the release. Why they didn't introduce DT *after* the release, or much much earlier in this release cycle, when there is/was time and a lengthy discussion would not have taken otherwise needed time is not understandable. Having said all this and also risking yet another flamewar, let us make a last request for now: Please have a healthy discussion, let the DT people answer these questions, tell them (or us) if they (or we) made wrong assumptions or something, but please do not flame. Signed by: Jörg Jaspert, ftp-master assistant, DAM, DebConf Organizer Alexander Schmehl, Debian Developer, press, event manager, DebConf Organizer Alexander Wirt, Debian Developer Daniel Priem, New Maintainer Martin Würtele, Debian Developer Gerfried Fuchs, Debian Developer Patrick Jäger, User Otavio Salvador, Debian Developer Joey Schulze, Debian Developer, Security, DWN, DSA, press, promoter Felipe Augusto van de Wiel, New Maintainer Sam Hocevar, Debian Developer Pierre Habouzit, Debian Developer Julien Danjou, Debian Developer, Stable Release Manager Peter Palfrader, Debian Developer Julien Blache, Debian Developer, promoter Christoph Berg, Debian Developer, QA, NM front-desk Holger Levsen, New Maintainer, DebConf Organizer Some public statements from Debian people: Holger Levsen:  rather say no without reasons than say nothing Julien Danjou:  My way to have etch released on time Gerfried Fuchs:  All Praise Dunc-Tank! Joey Schulze:  Debian is a failure,  Where's the fun gone?,  Debian Weekly News Julien Blache:  Dunc-Tank and "living expenses"  http://layer-acht.org/blog/debian/#1-37  http://julien.danjou.info/blog/index.php/2006/09/20/334-my-way-to-have-etch-released-on-time  http://alfie.ist.org/blog/2006/09/21  http://www.infodrom.org/~joey/log/?200609210757  http://www.infodrom.org/~joey/log/?200609220755  http://www.infodrom.org/~joey/log/?200610250942  http://blog.technologeek.org/2006/10/25/32 -- bye Joerg <elmo> [..] trying to avoid extra dependencies on gnumeric is like trying to plug one hole in the titantic with a bit of tissue paper"
Description: PGP signature