Filozofia i model rozwoju KDE
Projekt o zakresie prac i wielkości KDE może osiągnąć sukces tylko wtedy, gdy wyda się atrakcyjnym dla dużej liczby osób, które będą chciały spędzać swój drogocenny czas wolny na jego rozwijaniu, bez nadziei na wynagrodzenie w klasycznym tego słowa znaczeniu. Praca nad KDE musi być ciekawa. Nauczyliśmy się, że zawsze musi być coś do wypróbowania i przetestowania. Zawsze musi być działająca implementacja projektu. Jest to najważniejsza lekcja, która płynie z obserwacji poprzednich naszych działań.
Z naszych doświadczeń wynika, że przedstawienie samego planu rozwoju projektu, choćby był on nie wiem jak genialny, nie jest równoznaczne z pokazaniem go "na żywo". I spróbuj później zagonić programistów do pracy bez możliwości kreatywnego myślenia, bez wyzwań, bez nowych pomysłów. Jest sprawą podstawową, aby zawsze mieć działające zastosowanie, pokaz możliwości dla każdego projektu. Niech te działanie będzie niedoskonałe, niekompletne i ciągle poprawiane, nawet jeśli miałoby to oznaczać po jakimś czasie wyrzucenie całego kodu i napisanie go od nowa, ponieważ poprzednie założenia okazały się być błędne. Wydawać by się mogło, że taki model rozwoju jest nieefektywny. Być może rzeczywiście w tym miejscu mamy spadek wydajności. Jednak rezultat końcowy takich działań jest o wiele bardziej przekonywujący, ponieważ nad projektem pracuje o wiele większa liczba ludzi, z których każdy wnosi swój nieefektywny wkład, zmieniając "interes" w opłacalny. O wiele lepiej jest posiadać 100 podekscytowanych i zmotywowanych programistów, którzy nieefektywnie rozwijają projekt niż 5, którzy pracują według ustalonego planu najbardziej efektywnie. Wspomniana grupa 5 deweloperów szybko się znudzi i zniechęci, ponieważ nie będzie miejsca lub będzie go bardzo mało na wprowadzanie ich własnych pomysłów, nie uda im się także zainteresować kolegów po fachu z tegoż samego powodu.

KDE jako projekt internetowy, wykorzystujący inżynierów oprogramowania, poświęcających swój czas wolny na rozwój tego środowiska, nie posiada klasycznej hierarchii pracowniczej. W odróżnieniu od komercyjnej firmy, niemożliwym jest przydzielenie każdemu programiście zadania na podstawie jego stanowiska. Żaden programista nie napisze jakiegoś małego fragmentu kodu tylko dlatego, że zarząd tego chce. Ponieważ w KDE nie znajdziemy stanowisk i grup wykonawczych obecnych w firmach piszących oprogramowanie, praca nad środowiskiem musi być ciekawa i zabawna, aby całość miała sens. Szacunek i prestiż dewelopera w obrębie projektu bierze się tylko i wyłącznie z jego wartościowej pracy, wnoszonej do projektu, a nie z powodu zajmowanego stanowiska. W braku regularnej hierarchii wyraźnie dostrzegamy unikalną szansę i przewagę, pozwalającą na spontaniczną, swobodną wymianę pomysłów, z których najlepsze przetrwają i doczekają się urzeczywistnienia, niezależnie od ich pochodzenia.
[edytuj] Filozofia pracy
- Zrób to na JUŻ!
- Skup się!
- Użyj dostępnych narzędzi, zamiast wymyślać na nowo koło!
- Gdy coś sugerujesz, zamień "powinniśmy..." na "zrobię..."; wspaniałe, pompatyczne plany na nic, jeśli nie chcesz ich wprowadzić w życie.
- Popraw regularność pracy
- Rozpocznij od rozsądnej funkcjonalności i konfigurowalności, a następnie sukcesywnie dodawaj nowe funkcje.

