Development Model

A project the size and scope of KDE can only be successful if it succeeds in attracting a large number of developers. To attract a large pool of developers, who are willing to spend precious time on KDE development without hope for any remuneration in the classic sense, development must be fun. We have 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 of previous projects.

In our experience, presenting a blue-print for a project, no matter how brilliant it may be, and then to ask developers 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 code needs 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 developers makes a certain amount of inefficiency affordable. It is better to heave 100 excited and motivated developers improve the project iteratively than having 5 developers working according to a blue print and thus in the most efficient way. The group of 5 developers 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 developers for the same reason.

The KDE project, being an internet project whose developers are software engineers sacrificing their free time for the advancement of KDE, lacks classical hierarchy structure. Contrary to the confines of a company or firm, it is impossible to assign tasks to individual developers based on rank. No developer would take on a subproject 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 at all times in order for the project to be successful. Respect and prestige for a developer 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 ideas in which the best ideas surface and enjoy implementation, independent of their origin.