A team the size and scope of KDE can only be successful if it succeeds in attracting a large number of contributors. To attract a large pool of contributors, who are willing to spend precious time on KDE software without hope for any remuneration in the classic sense, contributing must be fun. The KDE team has learned that there must be 'something to play and experiment with' at all times. There must be a running implementation of the project at all times. This is the central lesson learned from observations our own and other projects' history.
In our experience, presenting a blue-print for a project, no matter how brilliant it may be, and then to ask contributos to slave away without room for creativity and opportunity to actualize their own ideas is not at all viable. A running form of the project must be maintained at all times. An implementation that can be shown and demonstrated, be it yet so imperfect and incomplete, and to improve iteratively upon that implementation even if that means that over time designs need to be thrown away and rewritten due to the fact that previous designs proved to be unsatisfactory. Admittedly there is a certain amount of inefficiency associated to progressing in the way KDE does. Maximum efficiency is lost, but the overall result is far more convincing, since a large number of contributors makes a certain amount of inefficiency affordable. It is better to heave 100 excited and motivated team members improve the project iteratively than having 5 people working according to a blue print and thus in the most efficient way. The group of 5 people will be bored soon since there is little or no room for them to bring in their own ideas and they will fail to attract fellow contributors for the same reason. We also believe an added advantage of the way we work is that by actually allowing all team members to put their creativity in, the end result is in many ways superior to whatever a central management could come up with
The KDE team, existing mostly on there internet consists of dedicated contributors sacrificing their free time for the advancement of Free Software. KDE lacks classical hierarchy structure - even compared to many other Free Software projects. This is something that the team takes pride in. Contrary to the confines of a company or firm, it is impossible to assign tasks to individual contributors based on rank. No contributor would take on a job just because the project management told him to do so. In the absence of classical hierarchy and power structures typically found in software-houses, development must be fun, interesting and challenging at all times in order for the project to be successful. Respect and prestige for a contributor inside the project draws solely on previous high quality contributions to the project and not artificial status or rank. We view the conspicuous absence of a regular hierarchy structure as a unique opportunity and competitive advantage allowing for a bubbling pool of creativity in which the best ideas surface and enjoy implementation, independent of their origin.
KDE Philosophy and Core Tenets
- Get it done NOW!
- Use available tools rather than re-inventing existing ones!
- When making a suggestion, change "we should.." to "I will.."; grandiose plans are useless unless you are willing to put in the work.
- Improve iteratively.
- Start with reasonable functionality and then improve over time.