Ein Projekt der Größe und des Umfangs wie KDE kann nur erfolgreich sein, wenn es eine große Anzahl an Entwicklern anziehen kann. Um eine große Anzahl an Entwicklern anziehen zu können, die ihre wertvolle Freizeit ohne Hoffnung auf Bezahlung im klassischen Sinne der KDE-Entwicklung widmen, muss die Entwicklung Spaß machen. Wir haben gelernt, dass es immer "etwas zum Spielen und zum Herumexperimentieren" geben muss. Gleichzeitig muss es aber auch immer eine lauffähige Implementierung des Projekts geben. Dies ist die wichtigste Lehre, die man aus Beobachtungen anderer Projekte ziehen muss.
Nach unserer Erfahrung ist es kein sinnvoller Ansatz, eine (möglicherweise brilliante) Blaupause für ein Projekt vorzugeben und die Entwickler dann zu bitten, sich mit der Entwicklung abzuplagen, ohne ihnen Raum für Kreativität, die Umsetzung eigener Ideen und Verbesserungsvorschläge zu lassen.
Es ist erforderlich, zu jeder Zeit eine lauffähige Implementierung des Projekts zu haben — diese kann man vorzeigen und demonstrieren. Auch wenn diese Implementierung noch so fehlerhaft und unvollständig ist, so kann dadurch doch die Implementierung konstant verbessert werden, auch wenn dies zur Folge hat, dass mit der Zeit Code entfernt und neugeschrieben werden muss, da sich bisherige Entwürfe als unbefriedigend herausgestellt haben. Zugegeben, aus der Arbeitsweise von KDE ergibt sich eine gewisse Ineffizienz.
Die maximale Effizienz geht dabei zwar verloren, aber das Gesamtergebnis ist weit überzeugender, da sich KDE durch eine große Anzahl an Entwicklern einen gewissen Grad an Ineffizienz leisten kann. Welcher Weg ist besser? 100 Entwickler, die begeistert und motiviert das Projekt nach und nach verbessern oder 5 Entwickler, die strikt nach der Blaupause arbeiten und dadurch sehr effizient sind? Die Gruppe von 5 Entwicklern wird sich schnell langweiligen, da kein oder nur sehr wenig Platz für die Entfaltung eigener Ideen ist und sie werden aus demselben Grund keine weiteren Entwickler für die Sache gewinnen können.
Das KDE-Projekt ist ein Internet-Projekt, dessen Entwickler Software-Ingenieure sind, die Teile ihrer Freizeit der Weiterentwicklung von KDE opfern. Daraus folgt das Fehlen klassischer Hierarchien. Im Gegensatz zu den Beschränkungen eines Unternehmens oder einer Firma ist es bei KDE unmöglich, Aufgaben einzelnen Entwicklern aufgrund des Ranges zuzuordnen. Kein Entwickler würde ein Unterprojekt annehmen nur weil das Projektmanagement ihm dies zugewiesen hat.
Da klassische Hierarchien und Machtstrukturen fehlen, die man üblicherweise in Software-Häusern vorfindet, muss die Entwicklung jederzeit Spaß machen um Projekte erfolgreich werden zu lassen. Respekt und Ansehen eines Entwicklers basieren schlicht auf bisherigen qualitativ hochwertigen Beiträgen zum KDE-Projekt und nicht auf künstlichem Status oder Rang. Wir sehen die deutliche Abwesenheit einer richtigen Hierarchie als eine einzigartige Chance und einen Wettbewerbsvorteil an, der die Existenz eines großen Ideen-Reservoirs ermöglicht, in dem sich die besten Ideen durchsetzen und ungeachtet ihrer Herkunft realisiert werden.