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-rele
ased-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://blo
g.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"
|