Il modello di sviluppo di KDE
![]() ![]() ![]() |
Un progetto della dimensione e della portata di KDE può avere successo solo se riesce ad attrarre un gran numero di sviluppatori. Per attrarre molti sviluppatori, che impegneranno il loro prezioso tempo libero sullo sviluppo di KDE senza sperare in una remunerazione nel senso classico, lo sviluppo deve essere divertente. Si è imparato che deve esserci "qualcosa con cui giocare e sperimentare" ogni volta. Questa è la lezione principale che bisogna apprendere dall'osservazione dei progetti precedenti.
Con l'esperienza accumulata, non è affatto un approccio perseguibile presentare un modello per un progetto, non importa quanto brillante possa essere, e chiedere agli sviluppatori di lavorare sodo senza lasciare spazio alla creatività e senza considerare le proprie idee. È sempre importante mantenere un'implementazione "in corsa" del progetto. Un'implementazione che può essere mostrata a tutti, sebbene sia imperfetta e incompleta, e da migliorare di continuo, anche se ciò significa che la maggior parte del tempo il codice deve essere buttato e riscritto perché la progettazione precedente risulta insoddisfacente. Evidentemente c'è una certa inefficienza nel procedere nella maniera di KDE. L'efficienza massima non si raggiuge mai, ma il risultato generale è molto convincente, dal momento che un gran numero di sviluppatori rende l'inefficienza abbordabile. È meglio avere 100 sviluppatori eccitati e motivati che migliorano il progetto di continuo che avere 5 sviluppatori che lavorano secondo un modello e che producono con più efficienza. Il gruppo di 5 sviluppatori si annoierà ben presto dal momento che c'è poco o nessuno spazio per realizzare le proprie idee e non riusciranno ad attrarre altri sviluppatori per lo stesso motivo.

Il progetto KDE, essendo un progetto basato su internet, formato da sviluppatori che sono ingegneri del software che sacrificano i loro tempo libero per il progesso di KDE, rompe la classica struttura gerarchica. Contrariamente ai criteri di un'azienda o di una ditta, è impossibile assegnare compiti a sviluppatori singoli basandosi sulle posizioni. Nessuno sviluppatore porterebbe avanti un sottoprogetto perché gliel'ha detto il capo progetto. In assenza di una gerarchia classica e di strutture di potere tipicamente collocate nelle aziende produttrici di software, per portare il progetto al successo lo sviluppo deve essere divertente. Il rispetto e il prestigio per uno sviluppatore nel progetto vengono fuori esclusivamente, come detto prima, da contributi di alta qualità e non da status artificiali o dalle posizioni. Si vede la cospicua assenza di una struttura gerarchica abituale come unica opportunità e come unico vantaggio competitivo che ci permette di avere un mare di idee tra le quali le migliori affiorano e sono implementate, indipendentemente dalla loro origine.
Filosofia di KDE e principi di base
- Fallo ORA!
- Focalizza!
- Usa strumenti già disponibili piuttosto che reinventare la ruota!
- Quando suggerisci qualcosa, cambia "dovremmo..." in "io..."; i progetti grandiosi sono inutili, a meno che sei disposto a metterli in opera.
- Migliora di continuo.
- Inizia con un numero ragionevole di funzionalità e migliora di continuo.








