Akademy: KDE successes and areas for improvement

As with most conferences, Akademy offered a wide variety of interesting talks. Some of those talks have already been covered over the last few weeks, but there is still a bit more to say about Akademy. It was an energetic conference, in a beautiful city.

Akademy was broken up into a two-day conference portion followed by five days of meetings, workshops, hackfests, and BoFs. Most of the latter sessions are difficult to write about, particularly if one is helping out on a nearly full day workshop on one of those days. But a couple of the talks from the first two days stand out. In some ways, they complement each other well; one looks at some of the successes the KDE project has had, while the other looks at ways its governance could be improved.

Success stories

In the community keynote, Agustin Benito Bethencourt gave several examples of "success stories" that make him optimistic for the future of KDE. It is important to focus on successes because, in uncertain times in the software industry, those stories give the project "confidence in what the future will bring us as a community and as a free software project". He started with the example of the idea that the Qt framework should be free. When he first attended Akademy in 2005, many people were talking about a free Qt, but most people outside of the KDE community never thought it would happen. But inside KDE, "the idea remained strong", and it did eventually happen.

Now Qt has an open governance model, which came about because the KDE community "helped by pushing", he said. It is an example of "active patience", where KDE continued "making good stuff" and pushing for a more open Qt development model, which led to the desired outcome. In the future, if the project can confidently "keep pushing in the same direction", similar results can be achieved.

The KDE development process is unique, and there are "very few big companies that are as efficient as we are", Bethencourt said. Companies often say that KDE isn't succeeding, but they can rarely match it in the ability to develop new code. It is important for the project to recognize that and "to keep the efficiency that we have".

Another good sign for the future is how good KDE has gotten at incubating businesses. There are more and more freelancers and entrepreneurs in the community, with KDE-related companies springing up frequently. KDE provides the "right ecosystem", so the limits on what can be done simply disappear. It is important to "keep that wheel rolling", he said. Developers, translators, and designers will be building more new companies, and the project will be even more business-friendly in the future.

The project has always had a vision of where it is going, which is important. He recalled the days when the discussions about KDE 4 started, and when it was released he put it on a laptop. It worked, but was not perfect—over time that changed. The project has "a clear vision of where we want to go and we deliver after some time and work", Bethencourt said. That makes others want to "develop under our umbrella". Having a vision and sticking to it "will bring in outside energy".

The project also has longevity going for it. It is very difficult for a software business or a project to keep going for a long time, and KDE has been "innovating for the last 15 years". What KDE is doing now is "very different from what we were doing before", but that is a strength. There will be more changes over the coming years and if it keeps that "innovation mode", KDE has a bright future ahead of it. There is very little that can stop KDE from being here in another 15 years, he said—other than limitations that come from within the project itself.

Is life peachy?

Mirko Böhm started his talk with a reference to Mathias Klang's keynote that had come just before. Klang mentioned the "anti-homeless" benches that were installed in Tokyo to make it nearly impossible for anyone to sleep on them. Böhm said that he thinks KDE has some of those park benches, metaphorically, in that the project's governance is designed to keep in people that the project likes, but makes it "hard for those we don't [like] to join us". He wanted attendees to start thinking about "where in KDE those park benches are".

Böhm has been contributing to KDE since 1997 and was a KDE e.V. board member from 1999 until 2006. He helped organize last year's Desktop Summit, and is currently doing research on free software and intellectual property issues at Technical University Berlin.

He has heard the claim that KDE is good at sticking its head in the sand. To illustrate, he put up a flowchart with a bubble that asked "Is life peachy?". If the answer is "yes", then "go do something" (e.g. write code), but if the answer is "no", "stick head in the sand", then "go do something". That is obviously not the right way to approach things, as there needs to be a way to take action to fix the problems. Changing the "stick head in sand" bubble to "change something" and re-routing back to the question is a better way. In order to decide what the "something" is that needs change, one must first observe and then reflect on the problems.

"Is life peachy at KDE?", he asked. For the most part, it is. KDE is the largest meritocratic volunteer-driven free software project; other large projects are mostly not run by volunteers, he said. KDE has an "outstanding product", with a fairly stable contributor base. "As a community, we are pretty healthy." The KDE code of conduct has been copied by other organizations and the project serves as a role model for other communities in free software.

Most folks want to stop at that point with the idea that "everything's fine"—except that it isn't, Böhm said. There are a number of areas where things aren't "peachy". To start with, users are complaining about a lack of technical improvements in areas they care about. At times, the feedback that they are providing "does not lead to tangible improvements".

There are also complaints about a lack of transparency in the governance of the project. Böhm is concerned that contributors are leaving for "non-technical reasons". It doesn't worry him if someone leaves because they graduate and get a job, but if they are "trying to make a difference, but can't" and leave because of that, it's a problem. Similarly, the project suffers from a failure to integrate a commercial ecosystem; it is "good at pissing off companies" so that they leave. That also leads to problems getting vendors to pick up KDE and ship it with their products or distributions. When making a software product, what matters in the end is that someone is using it, he said.

Böhm and Sebastian Kügler recently scored the project using the Open Governance Index (OGI) to try to get a sense of where it ranks. They found that KDE ranked second in openness, behind Eclipse, but ahead of projects like the Linux kernel, WebKit, Mozilla, and others. That shows that the project is doing well, overall, but "we could do better", he said. His goal would be for KDE to rank first.

There are positive points about the KDE community, but some reflection on them is needed. It is a meritocracy with self-directed contributors. That means that whoever does the coding work makes the decisions. But it leaves those who don't contribute code without a voice in the decision-making. That may not be quite right, he said, as there are others that make non-code contributions who may deserve a voice.

KDE e.V. is not "just" a support organization, but is set up to "support and foster the development of KDE". It does a good job of that, but there are some problems. Only individuals are allowed to be members, not companies or organizations. Those entities can sponsor KDE e.V., but they get no vote. People can only become members of KDE e.V. by invitation, which may leave out people new to the project at times. However, those requirements (individual-only, invite-only) are necessary to protect the assets of KDE e.V. as it is set up such that each member becomes a shareholder in the company.

One of the bigger problems that he sees with KDE e.V. is that it is "secret by default". That leads to downgrades in the OGI score, but it also may give the impression that the project is being run by a secret cabal. It is often said that KDE e.V. makes "no important decisions", but he doesn't agree. Akademy was held in Estonia because KDE e.V. decided it would be, for example, and the organization decides on who gets funding for things like sprints as well. Böhm believes that the "secret by default" approach is hurting the KDE community.

Some reflection on the role of commercial contributors is also needed. Currently, there are only individual contributors, mostly volunteers. That can be contrasted with Android, where there are few or no volunteers. But in order to use all of the available effort, there needs to be some thought about how to involve companies in the community. KDE is just about the only community where companies have no voice, he said, which is "not all bad"—indeed, it may be part of why KDE is still around after all these years.

Proposals

That is "enough reflection", Böhm said, and proceeded to outline some proposed actions to rectify some of the problems he observed. First off, he would like to see KDE stop sticking its head in the sand and try to address problems that crop up. Every year at Akademy, it would be good to see improvements in the areas that have been identified. For example, he proposed that there be a corporate liaison for KDE e.V. to work with companies. He also proposed that users get a voice. There is a KDE e.V. user working group that is being formed, but it should be made more formal in order to give users some say.

The Community Code of Conduct should also be extended, he said. It currently lists the responsibilities of contributors, without covering the rights of contributors. Those two things "normally go hand in hand". Contributors' rights would cover things like the ability to influence development, which is something that is not true for companies that contribute today.

The right to be treated as an "equal among peers" is another right that should be enumerated. Currently, there is something of a divide between technical contributors and non-technical contributors that could be addressed by this right. There is an overall need to minimize discrimination within the community between various sub-groups: technical vs. non-technical, volunteer vs. companies, users vs. contributors vs. KDE e.V members, and so on.

He also proposed that KDE e.V. adopt an "open by default" approach. Always defaulting to secret discussions on a closed mailing list, even for topics that have no need for secrecy, results in less open governance. That is bad for KDE, he said. Next year at Akademy, he hopes to have a similar talk, but one that looks at what has been accomplished in these and other areas.

Well-organized, interesting, and fun

Overall, Akademy was very well done. The talks were engaging, and the location was stunning. It is always nice to get a feel for what is happening in a large development project like KDE, and Akademy provided a great way to do that. KDE is a vibrant project and its conference reflected that. Once again, thanks to KDE e.V. for travel assistance so that I could go and have an interesting—and fun—trip to Tallinn.