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