KDE 3 mismanaged by developers?

Neil Stevens, on the kde-devel list: “KDE 3 has been mismanaged by the KDE developers. The standards and
practices of the KDE development community, those held in the
successful KDE 2 series, have been abandoned. The result has been a
failed release candidate, growing developer discontent. The future,
though uncertain, is likely to bring the conclusion that KDE 3.0 was
the highest profile KDE failure to date.” Update: Please read the KDE developers’ rebuttal.

When the evidence is brought together, the current state of KDE 3.0's
development is easy to call a failure.  Release Candidate 1 and
current cvs are plagued with problems including:

1) Packages missing from the release entirely (1)
2) Rampant compile problems
3) Last-minute changes to build requirements that cannot be met by
many developers without an operating system upgrade (2)
4) Many outstanding bugs (3)

While these problems are bad enough, they in turn throw up further
obstacles to a stable release:

1) When users and developers cannot build KDE, they cannot test KDE
2) When developers are locked out of KDE builds, they cannot
contribute fixes.
3) When the credibility of the KDE release policies are called into
   question, users and developers are less likely to feel that
   testing is of value, and stop participating.

The credibility of the release policies are further damaged by the
manner in which the decisions are made.  For instance, the major
change to libtool, there was a minimum of discussion, with no
compelling bugs or reasons shown for making this drastic change.  In
cases like this, the whims of a few dictate large change for the
masses.

The only remedy left for these KDE 3.0 ailments is to apply a "hard
freeze" to the KDE 3.0 source, release a third beta, to begin allowing
serious testing of KDE in real situations.

For KDE 3.1, however, more can be done.  Having identified the
failures of KDE 3.0, we can trace the causes of these failures, and
avoid causing them again.  As was already stated, the difference
between KDE 3.0 and recent releases has been changes in the "freeze"
policies in the period leading up to the final release.


>From the time of one week before KDE 2.2, until the final release,
all
changes to the source had to be reviewed on the KDE mailing lists
(save, of course, trivial changes whose differences are included in
the log message). (4)  The justification for these changes was
explained very well by the KDE 2.2 release coordinator Waldo Bastian
in a mail to the developers (5), in which he said "[Y]ou will have to
respect release freezes" if you put your code into KDE.

In contrast, the time leading up to KDE 3.0 RC 1 is best described as
a flood of un-reviewed changes to the sources. (6)  The flood was met
with excitement, to be sure, because the flood came from a rare
opportunity for roughly 20 KDE developers to meet in person and
develop.  This opportunity was not to be passed up, but it could have
been handled differently.

If the developers in in the meeting felt that avoiding the mailing
list was the best way to maximize use of the meeting, then they easily
could have proposed a delay in the KDE 3.0 release, to allow for more
time to stabilize after the meeting, to allow for testers to catch up
with their time of great productivity.

Some have suggested a failure in the community-recognized leadership
of the KDE 3.0 release.  While Dirk Mueller is respected throughout
the community, his ability to step in and enforce the policies and
release plans that everyone agreed to in the past has not been shown.
Many in the community rely upon KDE, and as Bastian wrote, development
of the KDE release carries responsibilities as much as it does
privileges, and Mueller has not held the developers to these
responsibilities.  New leadership for KDE 3.1 is needed.

The leader's role is to gather the views of the entire KDE development
community, summarize them in the form of release plans, enforcing the
plan when it is ignored, and updating the plan when it falls behind.
The KDE releases are the legacy of the entire KDE community, and
making sure those releases are good is the responsibility of every
developer and tester.  This requires that all developers, regardless
of their social status, obey the written and unwritten rules of the
KDE development community.  A mistake by a well-known developer can
break the release as badly as a patch from a novice, and the rules
were agreed upon with this fact in mind.  Only by keeping the written
and unwritten agreements can all KDE developers and users continue to
enjoy the success they enjoy now, and KDE 3.1 needs a release
coordinator who well help the entire KDE community achieve that.

Signed,

Ryan Cumming
Charles Samuels
Neil Stevens