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[1]
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?
[1] 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: [2] rather say no without reasons than say nothing
Julien Danjou: [3] My way to have etch released on time
Gerfried Fuchs: [4] All Praise Dunc-Tank!
Joey Schulze: [5] Debian is a failure, [6] Where's the fun gone?, [7] Debian Weekly News
Julien Blache: [8] Dunc-Tank and "living expenses"
[2] http://layer-acht.org/blog/debian/#1-37
[3] http://julien.danjou.info/blog/index.php/2006/09/20/334-my-way-to-have-etch-released-on-time
[4] http://alfie.ist.org/blog/2006/09/21
[5] http://www.infodrom.org/~joey/log/?200609210757
[6] http://www.infodrom.org/~joey/log/?200609220755
[7] http://www.infodrom.org/~joey/log/?200610250942
[8] 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"
Attachment:
pgp38Bwq17y9g.pgp
Description: PGP signature