Vishesh.tex

\chapterwithauthor{Vishesh Handa}{Who Does the Work Decides}

\authorbio{Vishesh Handa started his KDE contributing days in early 2010 when he tried to understand the semantics behind the Nepomuk project. He eventually started maintaining it, then killed it, and started maintaining most of KDE's search and metadata infrastructure. When he worked on KDE professionally, he also hacked on KDE Frameworks, KRunner, Plasma and various applications.}

\noindent{}Open Source products targeting users are a rare thing. Even rarer are the ones not dominated by a business or specific purpose. KDE is one of those projects that satisfies both those criteria and is therefore quite a unique place.

Most user-facing products have a company behind them. This company often controls the entire product, and works on all parts of it - marketing, distribution, evolution, and development. I have purposely put development at the end, because normally the other parts are what drives the development.

In KDE, we have an organization that helps with certain administrative and legal matters - the KDE e.V. However, they intentionally do not steer the development in any significant way. This results in an inversion of the classical model. We call this mode a "meritocracy" and it is one of the core principles of the KDE Community:

\begin{quote}"The person who does the work decides"\end{quote}

This meritocracy results in many interesting consequences. It has resulted in a community where developers have far greater power because they are ultimately the ones who bring the ideas into light. For a developer, this is great. It has built a strong community centered around technical excellence, and we developers have a lot of autonomy. This coupled with the amount senior members try to mentor the newcomers has created a delightful place to learn and improve as a developer. Also because the developers call the shots - they have to take an active role in all other areas and this makes them grow. It is a kind of Elysium that developers love and still get to work on user facing software.

However, this does not lead to a cohesive product that has a direction and really makes an impact. The product development side where we try to understand the needs of a user and rapidly iterate based on the business requirements and the market are lost. It is even incredibly difficult to figure out how we should market our products as developers and other contributors may have conflicting ideas. Our product quite often develops at minimum because of personal itches to scratch or otherwise with the hope that certain developers will lead the product development. Though it is not guaranteed that the others will follow.

It also results in other non appealing jobs often stagnating, especially proper quality assurance and documentation. We cannot just hire people for these fields.

This way of working is not unique to KDE; however, being a user facing product does compound the challenge significantly. Most other significant open source projects are built around solving technical problems. Here the developers are often keenly aware of the problems faced by the other developers, and decisions can often be made solely on technical merit. In KDE we often do not expect our users to be technically qualified.

Even with this developer controlled model, our community has managed to accomplish a lot. Our most recent desktop shell, Plasma 5, has been the result of a lot of collaboration between designers and developers. The existence of the Visual Design Group shows the developers' willingness to work with others. We have contributors spending time in creating promotional material for KDE and others organizing conferences to mentor newcomers.

For me, however, this is one half of the story. The other half is one which is well known - the evolution of KDE's identity and its interesting consequences.

In KDE we started off as a desktop environment and grew because of our role as a Desktop Environment, and now KDE means the community. However for many, including me, it is a mixture of the desktop environment, certain applications and libraries. But this is also now changing with the inclusion of projects such as Wiki2Learn. It is hard to say who KDE is targeting and figuring this out is a difficult process.

If we adopt a stricter approach we risk alienating existing projects and members while loosening the criteria also results in KDE being no different than "Free and Open Source software", but with a bit more user focus. 

These two factors - the developer controlled products, and the gradual decline of a core and actionable identity are for me some of the biggest challenges faced by KDE. It is also what makes it an exciting place.

The obvious conclusion to this is - where do we go beyond these initial 20 years?

The libraries and developer tools will most certainly survive. They suit this model where developers control the direction, specially since they directly target the developers. The desktop shell still fulfills a niche. It probably will continue, though it would be hard to say in what form, and with the world moving towards trendier technological stacks, the shell is certainly losing momentum.

The world of applications is quite different to what it was when we started. Content is what seems to matter. The applications that can help the user work with the content across multiple devices and platforms are the ones that gain more traction. KDE applications are starting to move towards other platforms and compete with the rest of the world, but it is a difficult task, and being "open" does not seem to be an important selling point. They will really need to step up and focus on non-development roles.

Overall, it has been a fun ride over the last 20 years. Many people have come and gone, and KDE’s popularity has peaked and fallen. I certainly hope the next generation of developers takes KDE further in this completely different world.