As you might have heard I decided to step down from my maintainer positions in KDE, especially KWin. Unfortunately I had to read very weird things about it and so I think it’s time to write about what it means that I am no longer maintainer of KWin.
First of all: I’m not leaving KDE. I’m still contributing in form of code, bug management and reviews. And I intend to continue to do this.
Second of all: I did not step down as maintainer because of the VDG or the usability group. I understand that my mail read like this, but it’s not the case. That I would step down as maintainer was inevitable and I’m sure it didn’t come as a general surprise to my fellow Plasma and KWin hackers. Personally I decided to step down as maintainer once the Wayland port is finished years ago. In my opinion KWin reached that state about two years ago. I continued to be maintainer to prepare for a good hand over. I deliberately reduced my involvement and passed responsibility to others. This was a long process and worked great in my opinion. As an example I want to point out the new and awesome blur effect introduced in 5.13. My first comment on the phabricator code review was that I’m not going to review it, but leave it to others. I think the result is great and I’m very happy how this worked out.
Over the last year I thought a lot about passing on the torch for maintainership. I realized that I contribute less and less of code but are at the same time blocking many changes due to me reviewing the code and giving a nak or through inactivity by just not reviewing the code at all. In KDE we have a saying: “Those who do, decide”. I realized I’m not doing enough anymore to decide. This results in the timing of me stepping down: I once again nak’ed a change and afterwards realized that I cannot do this. Either I need to actively veto a change I consider wrong and by that anger those who do or step down as maintainer. I decided that I don’t want to be the grumpy old conservative who is against progress and thus did the only logical consequence. It was inevitable, I would have stepped down as maintainer in the next half year for personal reasons anyway, it was just a little bit sooner to help those who are currently working on improving our products.
For KWin this means a significant improvement. A maintainer who is not responsive to reviews is not helpful to the project. By stepping down I give others the possibility to accept changes and nobody needs to wait for me to acknowledge changes. This is especially important for new contributors who we want to integrate better. Also for me personally it is a great improvement as it takes away a lot of burden for not reviewing the code. I now feel way more relaxed to do code changes I’m interested in and chiming in to reviews where I feel like I want to say something. And at the same time I can ignore other review requests as I know there will be a good review on them and it won’t depend on me. Also KWin is currently in a great position to step down as maintainer. We have more developers working on KWin than we had for years. KWin is in a great shape and I’m very positive about the future.
I read a few comments where users expressed the fear that the quality of KWin would suffer by me stepping down. I feel honored that users think I acted positively to the quality. Personally I am quite certain that the quality of KWin won’t suffer. As example I present you the 5.13 release with more user visible changes in KWin for years and me hardly contributing anything to that. Also KWin has an awesome test suite which would catch regressions.
On the other hand I read some disturbing comments about NVIDIA support getting improved by me stepping down as maintainer. Let me assure you that I never blocked any change which would be NVIDIA specific. In fact I encouraged NVIDIA to implement the changes required to get EGL stream working in KWin. Unfortunately NVIDIA has not contributed such patches.
Now a few words on how I maintained KWin. My aim as maintainer was to hand over the code to the next maintainer in a better shape than how it was when I became maintainer. I hope that I could contribute to this aim and many of my decisions as maintainer were motivated by that aim. I learned what went well in past KWin and tried to apply the lessons from it. I considered KWin as a standalone product inside KDE Plasma and judged changes from the perspective of a window manager. One of my highest rules was: no workarounds! No workarounds for broken applications, no workarounds for broken drivers and no workarounds for Plasma. No matter how many users a software has, KWin won’t add workarounds. This applies to software such as Spotify, Chromium and even GTK. If the applications or toolkits are broken, they need to be fixed, so that it works in all window managers and not just in KWin. With the time I found workarounds, e.g. for Netscape Navigator. Of course such workarounds don’t make sense, but clutter the code and negatively affect all users. Or there were workarounds for kdesktop and kicker (the KDE 3 panel, not the Plasma 5 menu). KWin is older than Plasma and I expected that Plasma would evolve and change (which did happen with Plasma 5, Plasma Active and Plasma mobile). KWin needs to be flexible enough to handle such evolution without having to rely to workarounds. Thus if something was needed we did the proper solution instead of finding fast workarounds. I think that the refusal to add workarounds helped the product KWin to achieve the level of quality we have today. Of course it results in disappointed users – as an example the NVIDIA users who would like to have a better experience – but in the long term all users benefit from the strict and hard line I used to maintain KWin.
I also learned that the number of options is a problem in KWin. We have optional features with even more optional features. Over the years I noticed that most of the breakage is in such areas. By trying to do too much we degraded the usability and quality of KWin. I reacted to this by making KWin more flexible and allow users to influence how they like to have KWin without having to carry the code in KWin. The result is KWin scripting, scripted effects, Alt+Tab QML switching themes and in general moving all of the UI elements to QML. This allowed us to streamline KWin and provide a high quality for the areas we offer, but at the same time give users the full flexibility to adjust KWin as they need. Simple by default, powerful when needed.
On the other hand this of course did not go well with all users. Many users requested features and my general response was: no. Any addition to KWin should go through scripts and be maintained by users. Of course not every user understood why they should fork an effect just to get another option. Or why I said no to a contributed patch. But in the end I think this helped to keep the quality high and have KWin in a maintainable state. In that sense I understand that not every user appreciated how I maintained KWin. The hard rules I applied in bug reports unfortunately created tension and the community working group had to step in more than once. For those users hoping that they can get their pet bugs resolved now that I stepped down as maintainer: I’m sorry to disappoint you. I still go through the bug reports and will continue to manage them the way I did as maintainer as long as my successor decides to apply different rules for maintaining KWin.
Last but not least a few words to my criticism on the VDG and usability project. First of all I need to apologize for mixing this in my mail about stepping down as maintainer. I should have raised my concerns at a different time as this was unfortunately received as I stepped down due to conflicts. I’m somebody who speaks up when he feels things go wrong. Given the way how I maintained KWin as explained above this creates tension with the usability project. My aim is to not implement every feature request and move the responsibility to users while the usability project tries to implement everything which makes users happy IMHO. This is obviously a clash of cultures and due to that I very often had to take an opposite position to what the usability project tried to achieve. I raised my concerns quite often. For me it was personally difficult to hold up such a position over a long time. Due to that as explained in my mail I lost motivation to review changes. My mail was mostly to explain why I lost motivation and I think to those in Plasma who know how I maintained KWin and what my aims are this was understandable. I was very unhappy on how this got communicated in some news postings and social media. As all those internal information were missing. I urge users to keep project internal discussions to the projects.
What I want to point out is that I really appreciate the work the usability project and also the VDG are doing. They are super enthusiastic and try to bring our software to the next level. I do not disagree with their work. The criticism I expressed in my mail was focused on the process and the transparency on how decisions are made. That’s where I personally see the need for improvements. What’s quite important to me is to point out again that those two projects are not responsible for me stepping down as maintainer.
Thank you.