Akademy: The Qt Project and KDE

The Qt Project was launched in October 2011 to foster the open development of the Qt toolkit. Qt is the underlying framework used by KDE, of course, so Akademy attendees are understandably interested in the status and progress of the Qt Project. Thiago Macieira provided that update in a surprisingly well-attended keynote—surprising because it was early on the day after a social event that stretched into the wee hours.

The Qt Project

The Qt Project is based on four principles, Macieira said: fairness, inclusiveness, transparency, and meritocracy. Fairness means that the project is open to everyone, while inclusiveness means that people can just start participating as there are no barriers in place or fees required. Transparency covers the decision-making process which is completely open. Discussions happen on the mailing list, whose participants ultimately make any decisions. When discussion takes place elsewhere, it needs to be posted to the list for others to review and comment on. Finally, a meritocracy means that contributors who have "shown their skills and dedication" are given commit rights, and are the ones who get to make the decisions for the project. That way, the most experienced people get the most deciding power, he said.

The project has seen quite a bit of activity in the eight months it has existed. Over that period, there have been 18,000 commits to the code base, with an average of 412 per week. There were some dips in the graph that he showed, for Christmas, Easter, Norwegian national day, and one that he called "Elop". The latter correlated with Nokia CEO Stephen Elop's statements that have caused concern about the future of Qt within the company. When an audience member suggested banning Christmas to increase productivity, Macieira chuckled and said that banning Elop would be more effective.

Commit numbers do not show the whole story, though. To get a sense for the community that is coming together around the project, Macieira also looked at how many different people are contributing. Over the eight months, 481 different email addresses were used for contributions—averaging 140 different email addresses per week. There are some people using more than one address, of course, but those numbers give an idea of the number of contributors to the project.

Macieira put up a flowchart describing how to contribute to the project. It looked relatively complex, with lots of "ladders and snakes", but contributing is actually fairly straightforward, he said. He pointed to the project wiki for information on what is needed. Code contributions are managed with the project's Gerrit code review instance. Using the dashboard in that tool, one can see the status of current code reviews, look at comments that have been made on the code, see the diffs for the changes, and so on.

Code that has passed review from both humans and a bot that checks for problems can then be staged from the Gerrit system. That moves the code into an integration phase where it is merged into the mainline, compiled, and tested. Two and a half hours later, contributors will get an email with the results of the integration. It is "very simple", he said, and all of the "eleven steps" from the flowchart "boil down" to this process.

KDE and Qt

Qt and KDE are "greater together", Macieira said, and he would like to see the two communities merge into one large community. Qt provides the libraries and framework, while KDE is building applications on top of that. If KDE needs new features, they can be put into Qt as there is now a "really nice way to make that happen". In the past, there had been obstacles to moving functionality into Qt, but those are gone.

He gave several examples of people working on moving KDE functionality into Qt. The KMimeType class has recently been added to Qt as QMimeType, which was essentially just moving and renaming the code. Other KDE classes have required adaptations prior to moving into Qt, including KStandardDirs and KTempDir. David Faure has been doing much of that work, but he is not alone as Jon Layt has been working on moving the KDE printing subsystem into Qt, while Richard Moore has been adding some of the KDE encryption code (e.g. SSL sockets) to Qt.

Those are just three KDE developers who have started working in the Qt upstream, Macieira said. There is a lot more code that could make the move including things like KIO (KDE I/O), the KDE command-line parser, and KDebug.

Beyond just code contributions, the project can use help in lots of areas. One can be an advocate and help spread the word about the Qt Project. Reporting bugs (and helping to fix some of them) is another area. Documentation, translations, artwork, and so on also need people to work on them; there is "a lot that you can do", Macieira said.

Developers can also start reviewing the code that is being proposed. It is easy to get started with the code review system after creating an account. What is really needed is "more people" and KDE is an obvious source for some of those people. The two projects should "work more closely to solve our objectives together", he concluded.

Asked about the filtering capabilities in the code review system to find patches of interest for review, Macieira admitted that the search and filtering functionality could use some work. There are ways to watch specific projects by a regular expression match, but overall it lacks some features that would be useful.

Another audience member asked about the statistics and, in particular, whether they could be quantified based on whether the person considers themselves a KDE developer. That is difficult to do, Macieira said, because people wear multiple hats, but there is definitely value in doing so.

The last suggestion was for a joint KDE/Qt conference. Macieira agreed that there would be "a lot of value in getting the two communities together", but that it wouldn't work for this year. He would like to see that happen next year, perhaps as part of the Qt Contributors Summit. The summit is a hands-on working conference, without presentations like Akademy has, he said, so a separate event might be the right way to go.

After years of trying to turn Qt into a more open project with a community orientation, it is nice to see that effort start to come to fruition. Given the uncertainty in the future of Qt at Nokia, having an independent project, with contributions from others outside of the company, will help to ensure the future of the toolkit. Since KDE is one of the bigger users of Qt, it only makes sense for the two projects to work closely together—exactly what Macieira was advocating.

[ The author would like to thank KDE e.V. for travel assistance to Tallinn for Akademy. ]