Martin Flöser Steps Down As Maintainer Of KDE's KWin

[smitty3268]

I think this was the right decision. Reading through his explanation, it's clear that he was becoming frustrated by having to justify saying no as maintainer, but that's the most important part of it. Not just saying no - explaining why it's such a bad idea that it can't be accepted, and helping provide a way forward that works for everyone. Providing no explanation just spreads the frustration around to everyone else.

Having not worked with the VDG, I don't think anyone here can really properly evaluate if his criticisms are accurate or not. Certainly some of what he says sounds unfortunate, but it's difficult for an outsider to judge if he's overstating his case or not. I do think there is a valid argument to focus on making the majority of your userbase happy while ignoring the 1% who moan the loudest, but I also think that a focus on bug-fixing and polishing over core new features is absolutely needed as well.

Hopefully kwin as a project keeps humming along without too much disruption due to this.

[Guest]

Finally, talking about users complaining more loudly about how they think things should be, they don't value good developers either. A project isn't meant to cater to everyone and there's a development and maintenance burden for trying to make it do so. Developers are usually keen on accepting patches for functionality individuals want, but not on doing the work themselves. That's not laziness, that's good time management.

This doesn't make any sense. The developer is building a product. It might be a free product but it's still a product that people use. If an overwhelming majority of your product's users want a feature, how is ignoring them "good time management"?

A number of users isn't an indicator of quality, but rather a reflection of the market you're catering towards. If you try to cater to everyone, you may net more users, but you compromise the direction of the project, those users may not stay that long either, and you can end up with something you don't even want to use yourself.

Again, this doesn't make any sense. It might make sense for niche apps – say a sea diving app is going to naturally have less users than a calendar or a todo app but when comparing within the same category the number of users absolutely is an indicator of quality. Quality meaning the software product as a whole and not the "beauty" of your class hierarchy or the indentation of your code.

The way I see it, the problem of many FOSS projects is that their developers and maintainers don't treat them as products. This often directly results in disgruntled designer contributors and disgruntled users.

[ngraham]

darclide, you have a level of knowledge about these internal projects that makes me think that you're a KDE person I already know. Is that so? I'm Nate Graham BTW.

In the KCM redesign project, we have consciously avoided removing features. That was not the goal at all. It's a visual and UX overhaul, not a feature removal party. The only feature I'm aware of us removing is the tinting feature from the Icons KCM, because in the porting process it was discovered that the feature was actually broken and would be difficult to fix, and a lack of bug reports indicated that nobody was actually using it. We discussed the matter, and reasoned that users could get the same functionality in other ways already through custom icons and custom icon themes. Again I'm not aware of any other lost features off the top of my head. Can you enlighten me?

Again, we do NOT want to remove features and customizability. The goal isn't to turn Plasma into GNOME. What we're trying to do is get the best of both worlds: good defaults, attractive presentation, and high usability, all the while keeping the advanced features that our users love. Sometimes this does mean hiding them a bit, but we are NOT removing them. Making our KCMs simpler by default doesn't mean that we've actually removed any features, just that we're trying to make them easier to use.

I would still appreciate a specific list of gripes because that's actionable for me; I can try to help fix them. I can't do anything with generalities.

[ngraham]

darclide, your familiarity with our internal projects makes me think that you might be a KDE person I already know. Is that the case? I'm Nate Graham, BTW.

I want to reassure you and others that we are NOT trying to remove features for the sake of design. In fact, we are consciously trying to keep them while also improving defaults and presentation. The new KCMs definitely look and feel simpler, which is by design, but under the hood all of the features should be still there. This project was all about UX, not removing features. The only feature I'm aware that we removed during this process was the tinting feature in the Icons KCM, because during the porting process we discovered that it didn't work and would be troublesome to fix. Apparently it has been broken for four years, and we had not gotten a single bug report about it. From this we reasoned that nobody used it, and we aw that the functionality is already basically available via other means anyway, so we felt comfortable removing the UI for it. For everything else, all the features you've come to know and love should still be there.

Our Kirigami apps have indeed been guilty of feeling too mobile-ish in the past when run on the desktop, and that's why I've been pushing fairly hard to improve that situation for the past 6 months. Compare Discover from Plasma 5.13 with Discover from 5.11, for example. Convergence means that it works well on every form factor, not that they all look like a big dumb phone app. In the cases where that's not the case, I want to know about it so I can help make it better.

Therefore, I want to repeat my call for specifics. Generalities aren't actionable. If you can tell me specific examples where you think we're removed features or prioritized form over function, I'm happy to take a look and see if any course correction is needed. You might find we're actually in agreement.

[Sho_]

Yeah, how could it… your mail https://mail.kde.org/pipermail/plasm...ne/086122.html just has "Stepping down as maintainer" as headline…

That's the thread subject authored by Martin. You'll notice all the mails in the thread have this subject.

[xiando]

Stop putting form in front of function, don't remove separators and the likes just because it makes the UI look less crowded, don't drive off developers and instead try to find compromises with them, don't make half of KDE look like mobile apps that someone dragged to the desktop (a lot of concepts just don't work with mouse and keyboard, or not as efficient) and so on, the list is very long.

This so much - basically avoid all of the above mistakes that resulted in the disaster known as GNOME. Don't blindly remove a feature because a few buttons used by the feature make the GUI look a bit cluttered. A fancy good-looking UI for doing close to nothing because all functions have been removed isn't helpful.

https://phabricator.kde.org/T8707 makes me think there's little hope, though. The VDG people's post read like children with ADHD hammering on their keyboards. I also find it concerning that they whine and declare that people who don't want to use the proprietary botnet Telegram software have no say. There's this botnet OS called Windows 10 for people who like software like Telegram. The VDG people should look into it and perhaps switch to it and not bother people coding free software alternatives.

[cynical]

Snowflake can't handle some words, hum?

Weird, I thought the thread was about a desktop environment, or design, or maybe even software.

[ngraham]

I keep trying to write a response saying that we are absolutely not removing features (just improving the default presentation) but they seem to get stuck in moderation forever, or eaten by the forum software.

[ngraham]

I want to reassure you and others that we are NOT trying to remove features for the sake of design. In fact, we are consciously trying to keep them while also improving defaults and presentation. The new KCMs definitely look and feel simpler, which is by design, but under the hood all of the features should be still there. This project is all about UX, not removing features. The only feature I'm aware that we removed during this process was the tinting feature in the Icons KCM, because during the porting process we discovered that it didn't work and would be troublesome to fix. Apparently it has been broken for four years, and we had not gotten a single bug report about it. From this we reasoned that nobody used it, and we aw that the functionality is already basically available via other means anyway, so we felt comfortable removing the UI for it. For everything else, all the features you've come to know and love should still be there.

Our Kirigami apps have indeed been guilty of feeling too mobile-ish in the past when run on the desktop, and that's why I've been pushing fairly hard to improve that situation for the past 6 months. Compare Discover from Plasma 5.13 with Discover from 5.11, for example. Convergence means that it works well on every form factor, not that they all look like a big dumb phone app. In the cases where that's not the case, I want to know about it so I can help make it better.

Therefore, I want to repeat my call for specifics. Generalities aren't actionable. If you can tell me specific examples where you think we're removed features or prioritized form over function, I'm happy to take a look and see if any course correction is needed. You might find we're actually in agreement.

[ngraham]

I want to reassure you and others that we are NOT trying to remove features for the sake of design. In fact, we are consciously trying to keep them while also improving defaults and presentation. The new KCMs definitely look and feel simpler, which is by design, but under the hood all of the features should be still there. This project was all about UX, not removing features. The only feature I'm aware that we removed during this process was the tinting feature in the Icons KCM, because during the porting process we discovered that it didn't work and would be troublesome to fix. Apparently it has been broken for four years, and we had not gotten a single bug report about it. From this we reasoned that nobody used it, and we aw that the functionality is already basically available via other means anyway, so we felt comfortable removing the UI for it. For everything else, all the features you've come to know and love should still be there.