KDE struggles with feature requests

By Jake Edge
August 12, 2009

Sometimes developers have a prickly relationship with their users. Users may have unrealistic, or overly demanding, requests that can be difficult to respond to. The most vocal of these users are often unwilling to take "no"—or even "not yet"—for an answer. Some KDE developers are currently struggling with that problem, and trying to find ways to smooth the dialog between users and developers.

In a posting to the kde-devel mailing list, Pau Garcia i Quiles wondered where KDE 3 features that were missing from KDE 4 should be collected. He noted that there are various places users were complaining about these missing features (including an openSUSE web page that collects them), but no central location for KDE to track such things. His suggestion: "Can we start something like that in UserBase, for people to tell us what they miss in KDE4 from KDE3? Or have a special category in Bugzilla?"

That set off a bit of a rant from Aaron J. Seigo about user complaints:

[...] there's a certain sort of bullying going on there where certain individuals, fewer with each release i might add, feel that if they just SHOUT LOUD AND ANNOYINGLY ENOUGH AT US that we'll relent, break our designs, go back on what we're trying to do and give them what they are used to at the expense of everyone else.

[...] but i won't go back on various design decisions and throw out all the benefits we're reaping due to those decisions. i refuse to fall into some misguided knee-jerk-to-the-latest-random-user-moaning design "methodology"

Seigo also noted that the openSUSE list doesn't "mention _at all_ the actually useful features that are missing", and, that, when he commented on that wish list item, he "got yelled at by two different people on the report, completely without cause". Frustration is obvious in his posting, and he noted that it was probably not quite the response Garcia expected, but he wanted to make it clear that the current options were not working:

now, i'm all for a proper feature request system. bugzilla is not that, a wiki is not that, random emails are not that, a blog is not that. FATE, as used by opensuse, gets pretty damn close though (and it even has a kde client). one day i'll probably just say "screw bugs.kde.org for feature requests" and have someone set up a FATE install for plasma. and then we can get on to the business of proper feature request work flow.

Anne Wilson noted that the users Seigo is referring to are just a "*very* vocal minority" that "can only be ignored". She is concerned with the users who are trying to make a difference with their bug reports and feature requests, only to be treated as if they are part of that loud minority. She disagreed with Seigo's suggestion that users should either write—or pay for—the code, or just be patient:

Unkind and unrealistic. Without bug/wish reports how do you know what features people value? Again, just a kind reply of 'coming, but not yet' is not too much to ask, but often too much to get.

But, Seigo sees things somewhat differently. He points to this vocal minority as part of the reason that KDE projects aren't "paying much attention to feature requests made on bugs.kde.org". Once again, he places the blame largely at the feet of the user community:

the user community that interacts with F/OSS projects such as KDE really needs to start understanding how this all works and taking some responsibility in their actions. as developers we're expected to be paragons of behavior, but really it's cooperative between all of us. except that the user community tends to still lack a clear set of shared values and ethics when it comes to these things.

There was some discussion of changing various bug tags, particularly WONTFIX, as it is regularly misinterpreted, to try to alleviate the problem. That is unlikely to mollify the users who are most vocal, though. Trying to ensure that features and bugs closed as WONTFIX get some kind of explanation will probably help with, but not eliminate, the problem, as well. Andreas Pakulat points out that it is a social problem: "people are getting used to be able to shout, rant and moan on the net without ever being held responsible for the possible damage they do with that".

One idea that seems to be gaining some traction is to use KDE Brainstorm, which was suggested as a place to gather features by Stefan Majewsky. Aside from some usability issues that seem like they could be dealt with relatively easily, Brainstorm provides a means to discuss new (or missing KDE 3) features, while allowing users to vote on those they find most important. Seigo sees it as a starting point:

[...] it needs workflow improvements, but at least it's collaborative, it's positive, it's easy for users to use and it looks pretty. we need to improve things like brainstorm and see more systems like it.

But the problem is more than just work flow. From the postings in the thread, some KDE developers are finding it difficult to work with the user community, largely because of the behavior of a few of its members. Parker Coates is unconvinced that a tool-driven process will eliminate the problem:

[...] But even if we developed a whole plethora of tools that encourage positive contribution, respect for others, world peace, community spirit and ponies, we would still have to deal with the appearance of trolls who'll crap on everyone's parade with negativity and shortsightedness. In today's Internet culture I see no way around it, so we can't hold the community responsible for their existence. Of course every individual in the community is responsible for how they respond to and deal with such types, so maybe that's where we should be focusing our efforts

Due to the very vocal, and largely negative, reaction to the release of KDE 4 more than a year and a half ago, there is still a great deal of frustration within the project—for both users and developers. While there are certainly some important points in the developers' messages, the tone is such that they also could be taken as an indictment of all users—something that is clearly not intended.

This is a problem that certainly isn't limited to KDE, as other projects have or will run into the same kinds of problems. There is a delicate balance between ignoring the "vocal minority" and ignoring the user community as a whole. The latter could easily lead a project to completely lose touch with the needs of its users, to the point where those users end up walking away. That is an outcome both sides want to—and should—avoid. Finding better ways to handle feature requests, while avoiding the conflicts with the few who will not be civil, is a good step on that path.

to post comments

KDE struggles with feature requests

Posted Aug 12, 2009 19:54 UTC (Wed) by amit (subscriber, #1274) [Link] (18 responses)

One of the problems with the DE devs seems to be an NIH attitude towards almost everything. Instead of fixing and adapting pre-existing small-but-sufficient tools to a UI, they instead develop entire apps themselves. This leads to a bad taste as a lot of experience that went behind the apps that didn't get used and some bugs keep creeping over and over; features have to be implemented one at a time and there's only so much a few developers can do about it.

Applying the age-old UNIX philosophy of 'does one thing but does it right' and reusing existing apps for their maturity as well as features would help.

That's one point; another point is giving a similar work environment on upgrades. People generally tend to be very attached to the OS, the DE, the editor, etc., they use in the open / free software world. If some bragging rights are negated on an upgrade, they tend to take it too harshly and the developers come in for criticism.

KDE struggles with feature requests

Posted Aug 12, 2009 20:09 UTC (Wed) by BlueLightning (subscriber, #38978) [Link] (16 responses)

I hope this does not devolve into a flamefest. Perhaps to steer things in a constructive direction,
can you provide some concrete examples of your perception of NIH in KDE? Is it more about
the technologies or the apps? If it's the apps, then I'm not sure what you're expecting really fits
with the KDE philosophy of providing integration between applications.

KDE struggles with feature requests

Posted Aug 13, 2009 6:18 UTC (Thu) by amit (subscriber, #1274) [Link] (15 responses)

My comment was mostly neutral as to just desktop environments as against KDE in particular.

However, there are a lot of bugs/wishes I've filed in the KDE bugzilla requesting for some sanity in some of the apps.

As an example, kmail loses imap email; it loses mail on /tmp full, etc. The latter bug report has been open for maybe 5 yrs now.

KDE struggles with feature requests

Posted Aug 13, 2009 7:22 UTC (Thu) by mjthayer (guest, #39183) [Link] (13 responses)

I also gave up on kmail at the time (pre-4.0) when I still used KDE. But you didn't give any examples of where you thought more reuse in DEs would be appropriate, and I would be genuinely interested in hearing your thoughts on the subject.

KDE struggles with feature requests

Posted Aug 13, 2009 9:09 UTC (Thu) by amit (subscriber, #1274) [Link] (12 responses)

OK, so some KDE-specific examples:

- kmail could configure fetchmail and present a GUI around downloaded mail. fetchmail is proven, secure, etc. I don't want to rely on desktop people to implement RFCs word-by-word.

- Extend PulseAudio to make it work across platforms and actively get involved in its development instead of Phonon (cross-platform and a stable API were the arguments why Phonon was developed).

- Open up the graphics acceleration layer as a library or use compiz instead of keeping it inside KWin

KDE struggles with feature requests

Posted Aug 13, 2009 11:16 UTC (Thu) by quintesse (guest, #14569) [Link] (1 responses)

I can't comment about KMail but the other 2 points have been beaten to
death and the developers have explained a thousand times the WHYs of their
decisions. Very very short:

- Phonon - it's just a layer! The KDE devs have neither the experience nor
the time to develop a full-fledged audio subsystem. There are several
already and who knows what the future brings. Phonon is just a thin layer
which makes it easy for KDE to adjust itself to whatever the user/distro
wants and will hopefully make it future-proof.

- KWin & Compiz - The Compiz 3D effect are nice but it's not a Window
Manager. KWin is a great Window Manager but lacked 3D effects. The 2 were
difficult to integrate in a sane manner. KWin has years and years of
development behind it, Compiz is relatively new. So it was decided that
adding Compiz-like effect to KWin was the best solution.

Don't just think that because you don't like/know/understand the reasoning
behind a decision it must mean that they just did it for shits and giggles.
And like always in the FLOSS world, multiple implementations is good, you
never know what good will come out of it.

KDE struggles with feature requests

Posted Aug 18, 2009 19:35 UTC (Tue) by maco (guest, #53641) [Link]

Er...Compiz is indeed a window manager. Maybe you're thinking of xcompmgr?

KDE struggles with feature requests

Posted Aug 14, 2009 16:13 UTC (Fri) by mightyduck (guest, #23760) [Link] (3 responses)

> - kmail could configure fetchmail and present a GUI around downloaded
mail. fetchmail is proven, secure, etc. I don't want to rely on desktop
people to implement RFCs word-by-word.

This is h*rseshit. I for instance explicitly DON'T want to download my
email. I want to leave it on the server so using fetchmail is a no-no.
Which means, kmail has to speak IMAP.

KDE struggles with feature requests

Posted Aug 15, 2009 9:36 UTC (Sat) by BlueLightning (subscriber, #38978) [Link]

Indeed. If you want to know a bit more about why KMail currently is the way it is and what's
happening next, check out Thomas Maguire's talk from GCDS:

http://www.geeksoc.org/gcds/Thomas%20McGuire,%20KMail%202...

KDE struggles with feature requests

Posted Aug 20, 2009 16:41 UTC (Thu) by astrophoenix (guest, #13528) [Link] (1 responses)

fetchmail has an option to leave the mail on the server...

KDE struggles with feature requests

Posted Aug 20, 2009 17:15 UTC (Thu) by mightyduck (guest, #23760) [Link]

Sure, it can leave a copy on the server. But it still downloads
everything. The point of IMAP is to download only the pieces you really
want to read. That is first the header information and then the message
text for the messages you want to read and download multi-MB attachments
only if you want to save them locally. Also, how do you maintain message
flags on the server with fetchmail? For instance, I want to know which
messages I already replied to or forwarded, even if I connect from a
different location (from my cellphone for instance).

So, for me good IMAP support in KMail is essential and wrapper around
fetchmail is useless.

fetchmail as Kmail back-end

Posted Aug 15, 2009 23:38 UTC (Sat) by rfunk (subscriber, #4054) [Link]

As someone who's been somewhat involved (at various levels) in the
development of fetchmail over the years, I can say with some authority
that using fetchmail as a Kmail back-end would be a Bad Thing.

For one thing, at this point fetchmail is basically developed by one guy
who has limited time.

For another thing, fetchmail was never designed to be the sort of back-end
you're talking about. It was designed to pull mail from POP or IMAP, and
send it into SMTP (or equivalent). Quite different from what users expect
from something like Kmail.

Oh yeah, and one of the reasons that I'm not so involved with fetchmail
development anymore is that long ago I switched over to using Kmail
exclusively.

KDE struggles with feature requests

Posted Aug 17, 2009 13:36 UTC (Mon) by bfeeney (guest, #6855) [Link]

kmail could configure fetchmail and present a GUI around downloaded mail. fetchmail is proven, secure, etc. I don't want to rely on desktop people to implement RFCs word-by-word.

KMail is due to use Akonadi, a backend explicitly designed to support multiple DE clients (as opposed to fetchmail, which lacks the integration DEs need). Evolution or Gnome clients could equally use this backend if they chose. Qt is no longer an issue having being broken up into small libraries each licensed under the LGPL.

Extend PulseAudio to make it work across platforms and actively get involved in its development instead of Phonon (cross-platform and a stable API were the arguments why Phonon was developed).

This is exactly what the KDE 2.0 devs did. They took the best audio-server available at the time (arts), and built the DE around it. When arts failed to live up to expectations, they were stuck, and a load of hacks ensued as app writers were forced to create their own code to talk to various backends such as Xine or GStreamer.

Phonon is simply a thin layer over all audio servers. This means KDE and distributors can choose whichever audio-server they feel is best. Further, this facilitates the behaviour you sought in your fetchmail example above: the devs use an existing audio-server, instead of writing one themselves.

Open up the graphics acceleration layer as a library or use compiz instead of keeping it inside KWin

Numerous worries have been raised in the past about Compiz's stability and future (see http://lwn.net/Articles/313710/). Developers felt it would be safer to do compositing themselves. I've used both Compiz and KWin, and thus far I prefer KWin (though I've little interest in effects other than exposé and desktop cube). KWin can be used with Gnome as far as I know.

As regards a graphics acceleration layer library: that's existed for 3-4 years now. It's a part of Qt called Arthur, and is comparable to Clutter.

I should point out, this is fourth comment of this kind I've posted on lwn.net, so I can empathise with Aaron's frustrations, but I think his behaviour is pretty poor: he's a bit old to be throwing tantrums. Better to simply create a FAQ and refer users to it.

KDE struggles with feature requests

Posted Aug 17, 2009 14:10 UTC (Mon) by amit (subscriber, #1274) [Link] (3 responses)

OK, a lot of folks pointed out why my examples were bad ones.

Even then, I'd imagine:
- there would be an imap library which can be shared across projects
- my example was about the dimap support; I failed to mention that.
- procmail additions and recipes to make it support akonadi or any other backend that's used to store mail

As for phonon and kwin, the KDE community could have stepped up and taken up a greater role and say in some upstream communities rather than just saying "it might break" or "we don't want the maintenance overhead".

I'd again like to emphasize that my comments were not originally about KDE in particular but about DEs in general.

KDE struggles with feature requests

Posted Aug 18, 2009 10:49 UTC (Tue) by johnflux (guest, #58833) [Link] (2 responses)

Even then, I'd imagine:
- there would be an imap library which can be shared across projects

Heh, as the poster just above you said, KMail is currently switching to using an imap library that can be shared across projects - Akonadi.

- my example was about the dimap support; I failed to mention that.
- procmail additions and recipes to make it support akonadi or any other backend that's used to store mail

Next version will support Akonadi.

KDE struggles with feature requests

Posted Aug 18, 2009 10:52 UTC (Tue) by amit (subscriber, #1274) [Link] (1 responses)

Akonadi is the storage backend, not an imap library.

KDE struggles with feature requests

Posted Aug 24, 2009 14:01 UTC (Mon) by krake (guest, #55996) [Link]

Akonadi is not a storage backend.

IMAP servers, maildir folder or mbox file are possible storage backends
for mail in Akonadi.

KDE struggles with feature requests

Posted Aug 13, 2009 8:57 UTC (Thu) by jospoortvliet (guest, #33164) [Link]

You are right in that often new apps are developed while there already are
applications for that purpose.

But if you think about how FOSS works, it's almost inevitable. Often the
developers of the new app have little experience and were unable or
unwilling (after all, it IS about fun) to dive in the code of the existing
and often big and complex application. They considered it easier to write
a new one.
Or they just have very different design goals and ideas compared to
existing applications.
Or they don't like the community behind the existing apps.
Or they started on their own without even knowledge of the existing app,
and trow their code on the net just in case someone likes it - if ppl do
and development starts off, what can they do?

I'm not saying it's a good thing but as I said I think it is inevitable.
Luckily, in time developers do start to cooperate more and fix things. But
esp new developers will probably always do things their own way.

KDE struggles with feature requests

Posted Aug 24, 2009 11:01 UTC (Mon) by N0NB (guest, #3407) [Link]

I can think of at least one example. After KDE 4.2.2 landed in Debian Sid, I found that no equivalent to KAudiocreator existed. One of the most seamlessly integrated tools was missing. Some searching revealed a new tool, Audex, was on the way. Audex works well for my purpose, but I'm left wondering why a whole new app needed to be written.

Was the code in Kaudiocreator so crufty that writing from scratch was easier/more productive? If so, then it would explain why many apps came to an end with KDE 3.5.10. If not, then I think the Sourceforge effect kicked in where new projects with new bugs may be more attractive and exciting than contributing to an existing project that needs a bit more help.

I know that I've not dived too deeply into KDE4 as I basically use it as a program launcher and use some bits and leave others alone. I'll admit to not investigating Plasma (perhaps I should do that) to see what it may be capable of or what new paradigm it offers. Still, I do not wish to be lumped into the Internet Bully category even though I have some questions/misunderstandings of KDE4 decisions. That said, I'm not going anywhere as KDE is my DE of choice and is still much better than any other DE I've tried.

KDE struggles with feature requests

Posted Aug 12, 2009 20:00 UTC (Wed) by sebas (guest, #51660) [Link] (9 responses)

Interestingly, in the cycle between 4.2 and 4.3, about 2,000 feature requests from KDE's bugzilla haven been closed, most of which fulfilled. That's not to say that the feature request process from users to developers is failing, there's just room for improvement.

KDE struggles with feature requests

Posted Aug 12, 2009 20:13 UTC (Wed) by drag (guest, #31333) [Link] (8 responses)

It sounds like they are just getting irritated by a small number of unreasonable people.

The only solution is really to ban people who are being unreasonable or are doing other dick-ish behavior. You have to ban them and not just put filters on your personal email (or whatever) becuase your just forcing other folks to deal with them.

Sure kicking them out will piss them off and they'll try to undermine the project in other ways, but there isn't much you can do about that. Just ban them and ignore the angry blog posts.

That way when you have real problems to solve and people have something of value to contribute they won't get browbeaten and talked over by undesirables.

KDE struggles with feature requests

Posted Aug 12, 2009 21:36 UTC (Wed) by sbergman27 (guest, #10767) [Link] (4 responses)

> It sounds like they are just getting irritated by a small number of unreasonable people.

It sounds like Aaron would like to silence the critics. Well, that's Aaron. But I'm not sure it would be the best thing for KDE. In the KDE 3->4 transition, KDE went from having a ridiculous degree of configurability... to what I remember from the pre-1.0 days. Except that fancy effects have been emphasized from the very start of KDE4, to the exclusion of actual functionality. I can certainly understand, and support a resistance by the devs to the return of KDE3's menu hell. But it seems to me that its return is already well advanced. And useful functionality is still missing. I was so hoping that KDE4 would end that situation. But alas, apparently not.

KDE struggles with feature requests

Posted Aug 12, 2009 22:57 UTC (Wed) by dowdle (subscriber, #659) [Link] (1 responses)

I'd really like to find a list people have made of KDE 3 features missing from KDE 4. Anyone have a link?

I've been using KDE since the pre-1.0 days as well and KDE is so broad I'm sure there are all kinds of things I've not used so I haven't missed them... but so far as I can see KDE 4 isn't missing much of anything... and the things KDE 4 adds more than makes up for minor things missing from KDE 3.

Sometimes I have to go back to KDE 3 on older systems and it is painful.

KDE struggles with feature requests

Posted Aug 12, 2009 23:25 UTC (Wed) by mpokrywka (guest, #43229) [Link]

You can find "missing features" in posts on LWN after each KDE4 release, ie:
http://lwn.net/Articles/345220/#Comments
for example:
http://lwn.net/Articles/345268/
http://lwn.net/Articles/345465/

KDE struggles with feature requests

Posted Aug 13, 2009 0:57 UTC (Thu) by AndreE (guest, #60148) [Link]

This is precisely the sort of comment that this article is referring to.

Because there is some functionality you obviously miss, you make a sweeping generalisation about the goals of the team and the project, and completely belittle the positive elements of their design and their production

KDE struggles with feature requests

Posted Aug 18, 2009 10:52 UTC (Tue) by johnflux (guest, #58833) [Link]

> It sounds like Aaron would like to silence the critics.

There's two main types of critics. Those who are unhelpful (This sucks! What is this crap?) and those who are constructive (Here's a mockup of how I think it should look. Here's a bug report saying how to fix usability problem X. )

The first type are just plain poisonous to moral.

KDE struggles with feature requests

Posted Aug 13, 2009 10:55 UTC (Thu) by nye (guest, #51576) [Link] (1 responses)

>The only solution is really to ban people who are being unreasonable or are doing other dick-ish behavior.

But then there'd be nobody left to fix Plasma.

KDE struggles with feature requests

Posted Aug 13, 2009 21:20 UTC (Thu) by nix (subscriber, #2304) [Link]

'All progress depends on the unreasonable man, and that man is called
Aaron'? ;}

KDE struggles with feature requests

Posted Aug 17, 2009 21:26 UTC (Mon) by oak (guest, #2786) [Link]

> The only solution is really to ban people who are being unreasonable
> or are doing other dick-ish behavior.

No, no, no. Those annoying users (AU) have lots of free time, you should
take advantage of that instead of alienating them. I think a good bug
meister (BM) might interact with them like this:

AU: I WANT THIS FEATURE!!!
BM: Surely that's not the only feature you're interested about. Could you
come up with a list of _all_ the things you would want to be implemented?

<week later>
AU: Here's a (huge) list of things I'd like
BM: Implementing all this is going to take a long time, could you
prioritize them so that the features you think most important can be
implemented first?

<week later>
AU: They're now in a priority order
BM: Hmm... AU2 and AU3 in bugs X & Y seem to have different opinions
about the priorities of these features. Could you discuss with them and
come up with a prioritized list which you all can agree with?

<some months later>
AU/AU2/AU3: We've now agreed that this is the priority
BM: I see. Features C and F have been implemented in the meanwhile.
Could you check that they work as you'd like them to work? As to feature
A, we don't see how we could implement that with the current architecture
<documented here>. Do you have any ideas how that could be done?

<some weeks later>
AU/AU2/AU3: We think it should be done like this
BM: The developer is current in middle of implementing feature D, and he
thinks doing what you suggest is too hard. Could you try implementing a
prototype showing how it could be done?

<some years after ADeveloper/AD1/AD2 have forked the project>
BM: I WANT THIS FEATURE!
:-)

I.e. first make sure they're comited enough, then make them to burden each
other instead of you and if they actually can communicate with the others
and come up with something together, draw them into testing, design etc by
challenging them and giving them a chance to show their superiority (the
poor sods usually don't know how much work actually doing something is).

Hopefully they eventually do a useful contribution, most usually drop at
step 2.

KDE struggles with feature requests

Posted Aug 12, 2009 20:53 UTC (Wed) by ikm (guest, #493) [Link] (8 responses)

Don't put yourself into a position where people start to demand things from you. And if you did put yourself there, don't blame *them*.

That's my personal experience with my own oss project. You see only your own reflection.

KDE struggles with feature requests

Posted Aug 13, 2009 6:38 UTC (Thu) by k8to (guest, #15413) [Link] (4 responses)

You may have something here, but would you be interested in fleshing this out some more?

KDE struggles with feature requests

Posted Aug 13, 2009 9:34 UTC (Thu) by ikm (guest, #493) [Link] (3 responses)

Well, open source is inherently about free ride. You provide something for free for no apparent reason (at least when seen outside). So people come and start demanding things, assuming this *is* a free ride. You've made that impression, haven't you? And then it's up to you to decide whether the goal of your project (and particularly, your work) is indeed to provide free ride to strangers, or you've started the whole thing on other reasons (like scratching your own itch). Based on your decision and understandings on that, you can either start implementing stuff the others want, or declining to perform work you don't want to do. But that's your own decision, not the decision of the others. And if for some reason you desperately feel the need to implement everything others want and start to feel bad about that they are using you, it's your personal problem you have to deal with. You'd have to identify that reason and adjust your objectives.

Basically, the world would take everything you are willing to give away. Don't blame it for that. It's you who are willing to give it away, after all, no matter what your reasoning is.

See Tjebbe's post below, he's saying essentially the same thing.

KDE struggles with feature requests

Posted Aug 13, 2009 11:53 UTC (Thu) by mjthayer (guest, #39183) [Link]

> And then it's up to you to decide whether the goal of your project (and particularly, your work) is indeed to provide free ride to strangers, or you've started the whole thing on other reasons (like scratching your own itch).
And of course to decide whether providing a free ride will bring benefits to you. Having your user community like you can lead to things like more contributions and better testing (both passive and active). But you still have to know where the cost becomes higher than the benefit, and sometimes how to explain in the nicest possible way why you won't implement something (this may be more for the benefit of third parties watching the exchange than for the actual person requesting the feature - if they sympathise with you, then unless the person in question is particularly valuable you haven't lost anything).

KDE struggles with feature requests

Posted Aug 14, 2009 5:24 UTC (Fri) by k8to (guest, #15413) [Link]

Thanks. I thought you were going further with a sort an idea like: "your software design causes users to demand it to do more". I don't think 'cat' gets a lot of nonsense feature requests, for example, wheras Mozilla got tons.

The point of how you manage the product dictates the conversation you have with your users is certainly important.

KDE struggles with feature requests

Posted Aug 14, 2009 10:07 UTC (Fri) by magnus (subscriber, #34778) [Link]

You have a very good point.

It's a thin line between feeling useful and feeling used (and free SW developers usually get to taste a bit of both).

I think there is a "danger" with bug trackers and similar tools, because they make the user feel like a customer entitled to a service. Mailing lists and forums are a better fit for free software in my opinion.

KDE struggles with feature requests

Posted Aug 13, 2009 9:06 UTC (Thu) by Tjebbe (guest, #34055) [Link] (2 responses)

In my experience with oss projects (granted, they are not the biggest in the world, a handful of devs at most), that's nearly impossible; users will think of things to change or add, and will ask for them. Most will ask nicely, some will demand you fix their world yesterday.

Most important lesson for me; learn to say no. It's much easier to deny adding a feature than it is to remove an existing one. It's also easier to explain. Give them a fair chance to explain their view, and if it doesn't convince you, just say no.

KDE struggles with feature requests

Posted Aug 13, 2009 10:16 UTC (Thu) by k3ninho (subscriber, #50375) [Link] (1 responses)

I'd also like more documentation: If a reasonable feature request is refused, I'd like to know how the expert host-project developer works so that I can find a way to fit it into her (or his) workflow -- or even follow that process myself so that I can contribute. Tell me where the best place is to work with the developers and I'll come and play their game. Maybe the feature is an itch they don't realise they have and maybe we can scratch that itch together.

I think that the problem of demanding feature requests and the lack of uptake in contributors (waves hand as guilty party) go hand in hand. If a wannabe can follow the example workflow of a existing developer, that person can work with the developer and gain from the process.

KDE struggles with feature requests

Posted Aug 16, 2009 2:42 UTC (Sun) by aliguori (guest, #30636) [Link]

This sounds reasonable at first glance. It basically boils down to "make it easier for me to understand why you think I'm wrong." You are capable of figuring it out in most cases. It's often in mailing list history or documentation. It's certainly easier for the developer to explain it though because they know it immediately.

This doesn't happen because it doesn't scale well. The ratio of developers to users for most Open Source projects is very, very low. The progress of a project is limited more by the time available to the developers than the amount of work a user has to do to file a bug, request a feature, etc.

Documentation is a perfect example of where the principle of scaling by pushing work to the outer nodes applies. Documentation is best written by users, not developers. While developers can write documentation, so can users. Since users generally don't write code, it's far more efficient for the project to have users contribute documentation. It's a huge potential contributor base.

Sadly, this rarely happens. I often have people make requests/complaints about documentation. Very often, to add/remove something very specific. I also ask those people to send a documentation patch. I have yet to receive a patch like this :-/

Maybe patches are too intimidating for most users. Wikis help but only a little bit. The biggest problem with wikis is there is no proactive review.

KDE struggles with feature requests

Posted Aug 12, 2009 21:39 UTC (Wed) by khc (guest, #45209) [Link] (1 responses)

I don't think this is a problem that's limited to KDE, almost any project with a non-insignificant userbase has the same problem. This sometimes creates a cycle because troll->frustrated developers->frustrated users->more trolls->...

Maybe we should introduce a PR/support group that sits in between developers and users? Users will file bugs against a bug tracker that gets reviewed by PR/support before being forwarded to developers.

Of course, then the question become where to find such a group of people that can 1) handle the trolls 2) knowledgeable enough about the project. Even though there are always users who claim that they want to help but don't know how to code, it's almost impossible to find any who actually uphold their offers.

KDE struggles with feature requests

Posted Aug 14, 2009 10:34 UTC (Fri) by AndreE (guest, #60148) [Link]

This is a great idea, but there are certain caveats.

I feel most users like direct access to developers. That's part of the sense of inclusion OSS gives to users. Even with a brilliant PR team, it would be impossible to ignore the fact that the whole relationship with the project was being "managed"

Plus, sometimes flamefests make for great procrastination (for the readers)

KDE struggles with feature requests

Posted Aug 13, 2009 2:17 UTC (Thu) by dkite (guest, #4577) [Link] (2 responses)

Every piece of software I've ever used, invariably and immutably, was a
piece of trash. Some things worked well, many things didn't, were badly
designed or unfinished.

With free software I have the opportunity to fix the problem, or not pay
any money for the said piece of trash, or even better, free software has
created competition within software again so I have some choice at least.

I once suggested to Aaron that KDE's marketing campaign should be
something like:

Software Sucks. Free Software Sucks Less.

Derek

KDE struggles with feature requests

Posted Aug 13, 2009 6:42 UTC (Thu) by k8to (guest, #15413) [Link] (1 responses)

Compared to you, I am an optimist. I feel like there are about 3 programs I have used that I would consider "pretty good". What springs to mind to me is: irssi, vim.

Then there are maybe some 40-50 programs I've used which seem "OK".

The remaining 99%? yes. Drek.

KDE struggles with feature requests

Posted Aug 13, 2009 10:59 UTC (Thu) by nye (guest, #51576) [Link]

I also feel there are three programs I consider 'pretty good': screen, git, vim.

(The fact that screen is very buggy in Cygwin is the only reason I haven't entirely given up on the Free desktop, BTW).

KDE struggles with feature requests

Posted Aug 13, 2009 8:11 UTC (Thu) by iq-0 (subscriber, #36655) [Link] (3 responses)

Perhaps it's my perception, but "demands" and "free software" are a bit of contradiction in my book. Sure you can make suggestions, but if you really want something that bad, the free software way would be to do it yourself (fork / patch / whatever). And if you advertise it good enough and a lot of people want it, they would use your version or request that the maintainer look at this (hopefully) ready to merge piece of work you created.

Sure not everybody is a developer, but do understand that you are working with volunteers that do things that scratch an itch for them and they hope also satisfies some itch you might have. Cooperation is the key, demands just plain unreasonable, no matter how good their point might be.

F/OSS needs to listen to its users to truly succeed

Posted Aug 13, 2009 9:12 UTC (Thu) by rvfh (guest, #31018) [Link] (2 responses)

That's the root of problem. And all too often, the answer to 'I need this feature' is 'go code it yourself, then'.

There seems to be a lack of 'I want to please my users' kind of reasoning, and it seems developers only write code for themselves (I know I am exaggerating here).

This leads to the feeling that, with Linux, you have to accept whatever is there, and if, say, Bluetooth does not work anymore then tough!

If we really want Linux to succeed on the desktop, I truly believe we'll need to work a bit more for the end users, and less to scratch our own itches.

So yes, "demands" and "free software" are a bit of contradiction, but that needs to change or we'll remain a niche desktop OS, far behind Windows and MacOS...

F/OSS needs to listen to its users to truly succeed

Posted Aug 13, 2009 10:13 UTC (Thu) by ikm (guest, #493) [Link]

That's what the article was about, don't you think? As long as you don't listen to your users, you haven't got any problems with their demands. You've got your itch scratched and feel fine. But when you attempt to make "Linux to succeed on the desktop", "work a bit more for the end users", "less to scratch own itches" -- that's where problems start. Because, really, why'd you do that? Are you paid for that? Do you get something off it?

All that stuff you've advised is a must for commercial developments -- but that's because they make money on it. That doesn't work for "for fun/scratch itch" projects. They are just different. And yes, that makes them niche, exactly.

F/OSS needs to listen to its users to truly succeed

Posted Aug 13, 2009 11:21 UTC (Thu) by iq-0 (subscriber, #36655) [Link]

Different groups have different goals. Distributions have a "I want to please the enduser" goal while application developers have a "I have a vision" goal. Okay, a bit of a oversimplification but you get the point.

The "succeed on the desktop" is not really what is on the minds of the respective developers. That doesn't mean that they don't care about the quality of their product, but that quality from their perspective means something entirely different from many of the users.

And the "bluetooth doesn't work" example you give is not really something that I think any maintainer has really said: "tough cookies, go figure it out yourself". But open source developers are limited in their resources (time, money, hardware, ..) and that can lead to a "tough cookies, I can't reproduce the error and don't have (insert resource limitation) to figure it out". And from the enduser perspective that may seem like the same "tough cookie" because they aren't helped by that. But many developers do really care about their project, if only because they are proud of their achievements (when that part fails and the initial itch is gone, you've probably lost the developer).

Even in a not open source setting this happens all the time, because developers have different problems than the customers. Only in those cases there is a clearer relation between demand and (possibly) available resources. Which often results in the customer having to pay more or other things being sacrificed if that is deemed acceptable. Now try doing that math with something you don't pay for (and others don't pay either) ;-)

KDE struggles with feature requests

Posted Aug 14, 2009 5:24 UTC (Fri) by malor (guest, #2973) [Link] (18 responses)

This is another good example of the current KDE team's thinking; users are an annoyance. They're something to be exploited for free bug-testing by mislabeling releases, not the focus of the project. This despite the fact that "users" are other developers, writing the other pieces of the free software stack that the KDE people themselves depend on.

The focus of the KDE project has become the KDE project itself, not the people who use it, and I think this is a lot of the reason that GNOME gains ground with each month that passes. The GNOME team seems to realize that the other developers working in open source also have projects, that their time is valuable, and that their wishes are important. Even when they explicitly overrule requests (like with the dumbing-down of UI options), they're not doing it for their own benefit, they're doing it for their primary audience. And, as a result, it gets more and more uptake, and KDE becomes default in fewer and fewer distros.

I wonder if the KDE team will wake up and realize that those "bitching users" are the primary reason to write a desktop? If they don't, one of these days they're going to have a half-built ivory tower that not very many people are helping with anymore.

Hint for the KDE team: if you're writing a desktop, it's not about the code, it's about the people pushing the mouse.

KDE struggles with feature requests

Posted Aug 14, 2009 7:29 UTC (Fri) by nix (subscriber, #2304) [Link]

Hint to malor: if you want the KDE team to pay attention to you, casting aspersions on their motives:

They're something to be exploited for free bug-testing by mislabeling releases, not the focus of the project.

... is not the way to go about it.

KDE struggles with feature requests

Posted Aug 14, 2009 7:39 UTC (Fri) by Los__D (guest, #15263) [Link] (7 responses)

Funny, this sounds pretty much like, some people's reaction when GNOME started the big "feature pruning".

I don't think that any of the desktops feels the way you describe, but sometimes you have to make decisions, and sometimes they are not going to be popular with some of your users.

- Sometimes they might even turn out to be misguided, but I'm 99.9% sure that it's not out of some "hey, screw our users" attitude.

KDE struggles with feature requests

Posted Aug 15, 2009 10:22 UTC (Sat) by nix (subscriber, #2304) [Link] (6 responses)

KDE hasn't had a big feature pruning of the GNOME level, though. A lot of
people (including me) switched away from GNOME 2 as fast as we could,
simply because it was to a first approximation impossible to customize it
*at all* without hacking the source and recompiling. So those of us who
felt that our desktop environments should fit us, not the other way
around, jumped ship.

As far as I can see KDE hasn't done anything like as much. What they have
is customization disabled by annoying bugs or missing bits as part of the
big move of features into Qt (e.g. printing preferences, global multi-key
khotkeys and so on). If bugs like that were fixed (and there are more)
then I suspect quite a lot of the complaints would go away (one or the
other of the ones I mention were probably used by a *lot* of people.)

KDE struggles with feature requests

Posted Aug 15, 2009 10:42 UTC (Sat) by Los__D (guest, #15263) [Link]

This wasn't really to discuss this, but lets just say that I disagree completely that the GNOME pruning was a bad thing.

The core of my post was that I don't think that KDE or GNOME thinks of their users as an annoyance.

I have a feeling that (Open Source) projects with that attitude mostly are of the "let's make it open source, so we have a commercial argument"-type.

KDE struggles with feature requests

Posted Aug 30, 2009 16:59 UTC (Sun) by anshuljain (guest, #60520) [Link] (4 responses)

I've always been an KDE user, and have been perennially on the bleeding edge with Opensuse Factory KDE snapshots. However, this weekend I had a very very nasty experience with the supposed stable KDE 4.3.0 on Opensuse. I had to take a couple of important printouts. I quickly configured YaST for printing, fired up Okular and started the print jobs. To my dismay it wouldn't print, I was running against time and needed those fast. For some reason I had Adobe Reader installed and tried printing from there. It worked, and so did Firefox 3.5. Then it struck me, all Qt/KDE apps weren't printing...while the GTK ones were.

I'm an exclusive Linux user in a corporate environment and lack of printing support is pretty inexcusable on KDE's part. If it wants to make an impact (and it *definitely* can)...it needs to make these small things work. At the end of all this, I asked myself only one thing- "How useful is something, if it doesn't f&*king work?" I had to go back to using GNOME, albeit reluctantly, where everything works through my laptop.

KDE struggles with feature requests

Posted Aug 30, 2009 17:46 UTC (Sun) by kragil (guest, #34373) [Link] (1 responses)

First rule of running a business:

*Don't install unsupported spanking new bleeding edge releases on machines you depend on*
(That is what KDE 4.3 on OpenSUSE is PERIOD)

KDE struggles with feature requests

Posted Aug 30, 2009 19:33 UTC (Sun) by anshuljain (guest, #60520) [Link]

I didn't make it quite clear- I tried printing on my stable Opensuse 11.0 KDE 4.3 install. The Factory version is on another spare partition...completely segregated from my daily use. It doesn't even share the /home directory with the 4.3 install.

KDE struggles with feature requests

Posted Aug 31, 2009 8:01 UTC (Mon) by halla (subscriber, #14185) [Link] (1 responses)

I think this is a suse-specific bug, though: I cannot print either since
some time with my opensuse 4.3.0 installation, but it works fine from
kubuntu's 4.3.0 (which is on another laptop).

KDE struggles with feature requests

Posted Aug 31, 2009 13:56 UTC (Mon) by kragil (guest, #34373) [Link]

There is no such thing as an offical supported OpenSUSE release with 4.3. Everything there is is unsupported and therefore potentionally more buggy than the normal release. If you want KDE to work on OpenSUSE use the one it had on release day. That is 4.2.

KDE struggles with feature requests

Posted Aug 14, 2009 15:06 UTC (Fri) by jospoortvliet (guest, #33164) [Link]

I'd say you don't get it. There are users who are good citizens to the KDE
community, using it, providing feedback, even helping out a bit. And there
are those who just troll away all day. The latter are who this article is
about, the former are those we DO listen to and try to work with.

KDE struggles with feature requests

Posted Aug 17, 2009 13:55 UTC (Mon) by bfeeney (guest, #6855) [Link] (6 responses)

You're exactly the kind of person that annoys developers.

This is another good example of the current KDE team's thinking; users are an annoyance. They're something to be exploited for free bug-testing by mislabeling releases, not the focus of the project.

KDE is a huge code-base, bigger even than the Linux kernel. Imagine if they refused to release until they had feature parity with KDE 3, they still wouldn't have released 4.0 yet, and they'd be another year away. That would be four years with no major publicly accessible releases.

They do hope users will test software for them. It's free, and open-source. Volunteering help is part of the issue. Have you ever had a bug with KDE? Point me to the bug-ticket you filed, or the comment you added.

The dev's were deliberately disingenuous with the wording of the 4.0 release, it was definitely of alpha quality, but so too was Mac OS X.0. They decided to make a big leap. Distributors who, unlike users, should have known better, made KDE 4 the default instead of an option to be installed alongside 3.0, and thus deserve some blame for the backlash. But certainly, since 4.2, it's been a solid, useful desktop. Some features are still outstanding, but people only have so much spare time, and it will take time for those feature to be added once more.

The whole point of KDE 4, with Solid, Phonon, Plasma, Nepomuk and more, is to build a platform for next-gen applications. They're trying to make it easier to create great applications for users. They haven't created those apps yet, but in the next few years, I'd expect to see interesting things happen.

Gnome, by contrast, has focused on applications at the expense of the platform, which is why you hear a lot of chatter about Gnome 3.0 at the moment. I'd agree that KDE devs focus a bit too much on ideal APIs, rather than applications, but it's important to realise that they're only doing that as they want to make it easy to create the applications users want. For example I think the new version of Amarok is hideous, but I think Phonon will make it easier for someone to come along and write a KDE version of Banshee instead.

KDE struggles with feature requests

Posted Aug 17, 2009 23:00 UTC (Mon) by malor (guest, #2973) [Link] (5 responses)

Wow, go straight for the personal attack, eh?

I didn't have problems with KDE 3.X, so I didn't file any bugs on it. It worked fine for what I needed, so I just quietly used it, donated to the various entities I downloaded it from, and occasionally evangelized a little. I mostly work on servers; desktops are often just a way to juggle multiple command lines.

The sum total of my complaining about KDE 4.X has been that A) I won't use it, and B) my posts here on LWN, pointing out that their user practices are abusive. I'm not on their forums, and don't take their time or bandwidth.

My expectation has always been that if you ship something as a stable release, that as far as you know, it's stable. Everyone knows that .0 releases have problems, because we're all human, but that .0 carries an implied promise that the developers THINK it's ready for primetime. If it's not, then you call it -rc1 or beta or whatever. I would have been perfectly fine with a KDE 4.0 with fewer features than 3.X, as long as what was there actually worked.

Further, I would point out that even distributions trusted them, and got burned. If your caveats are in the fine print, and even the experts are missing those caveats, then at the very least you screwed up. And when the KDE devs have admitted they called it 4.0 to get more testers, then it crosses the line into deliberate deception. They knew that more people would test it than if they called it what it really was, a beta.

For proof, all you have to do is look at the 4.0 announcement page. It's full of breathless promises about all the wonderful new cool stuff for users. Curiously, they entirely neglected to mention in their announcement that it wasn't ready yet. Funny how that works.

In other words, the actual users can go take a fucking hike. Their pain today is irrelevant and unimportant. All that matters is the great applications that might get written someday -- but which, notably, don't even exist now, more than a year and a half after 4.0 was released. And even you don't think they're going to show up for years more. And, meanwhile, 3.X stagnates.

Further, might I suggest that perhaps why the new applications aren't showing up is because the old ones were so lightly abandoned? That team is obviously willing to drop everything and go chase after the shiny thing on the horizon. They might just do it all over again with 5.X. It wouldn't shock me at all if that's why these great applications aren't showing up, because the devs are either waiting for the situation to actually stabilize, or else implementing their ideas on GNOME instead.

The whole point of a desktop is to make users' lives better. And I would suggest that when 'the project' becomes more important than 'the users OF the project', that your focus should be on server software instead.

This LWN article is just another data point that to the KDE team, user pain is less important than dev team pain. That probably works for a lot of projects, but for one that's trying to be the primary user interface, it's completely off-base and wrongheaded.

Gnome, by contrast, has focused on applications at the expense of the platform,

To the end user, the application IS the platform.

KDE struggles with feature requests

Posted Aug 18, 2009 11:29 UTC (Tue) by pointwood (guest, #2814) [Link] (2 responses)

I'm amazed that some people continue to be mad about the mess @ 4.0 release.

Seriously, it's been 1½ year - get a life ;)

"Further, I would point out that even distributions trusted them, and got burned."

Those distributions were pretty damn stupid and ignorant then. If you had just done minimally testing or followed Planet KDE, you'd know that 4.0 wouldn't be ready for most users. That some distributions choose to ship it anyway, can only be the distributions problem.

"In other words, the actual users can go take a fucking hike. Their pain today is irrelevant and unimportant."

Yeah, that's clearly what all the KDE developers are thinking and the primary reason behind creating KDE4.

"All that matters is the great applications that might get written someday -- but which, notably, don't even exist now, more than a year and a half after 4.0 was released. And even you don't think they're going to show up for years more. And, meanwhile, 3.X stagnates."

Yeah, because all the great KDE3 applications suddenly stopped working when KDE4 was released and several KDE3 applications got updated after KDE4 was released. Several of the big KDE applications have been released in KDE4 versions or is close to being released. Yes, it's a pain that it's taking so long but sometime you need to make big breaks and start over or do major surgery.

"This LWN article is just another data point that to the KDE team, user pain is less important than dev team pain. That probably works for a lot of projects, but for one that's trying to be the primary user interface, it's completely off-base and wrongheaded."

You really haven't followed what has happened with KDE4 since the .0 release have you? They have implemented loads of features.

Ps. No, I'm not a developer or in any way affiliated with the KDE project.

KDE struggles with feature requests

Posted Aug 18, 2009 20:57 UTC (Tue) by malor (guest, #2973) [Link] (1 responses)

Yeah, that's clearly what all the KDE developers are thinking and the primary reason behind creating KDE4.

No, they were thinking about their project. User pain was irrelevant. Their project's "health" is of (much) higher importance to them than the users OF the project. It's not that they deliberately set out to cause user pain, they just didn't particularly care about it one way or the other.

There's a lot of software you can do that with. The kernel is one area that demonstrates that thinking in spades, but fortunately, the distros exist to patch that mess into something reasonably stable and well-supported over actual use cycles of customers.

But KDE is a desktop. If you're writing a desktop, and avoiding user pain isn't very close to the top of your priority list, then you're doing it wrong. There are zillions of projects better-suited to that mindset.

As I argued in my original post, GNOME seems to have adopted that thinking much more thoroughly than KDE. GNOME is also the default on all major Linux distros at this point; KDE is a second-class citizen essentially everywhere. Not so long ago, they were the dominant Linux desktop.

I would posit that this is not just a correlation.

KDE struggles with feature requests

Posted Aug 19, 2009 6:42 UTC (Wed) by pointwood (guest, #2814) [Link]

First, I do certainly agree that they shouldn't have called it 4.0, or at least, they should have called it "developers release" or something like that, but that's all history and continuing to discuss and complain about that 1½ year later is stupid and not exactly productive IMHO.

The KDE developers choose to do a "big bang" because there was many too big problems with the current release. I'm no expert but sometimes I do believe that is the best option if you really want to move forward and get something that's considerably better (eventually). Apple's OS X is a good example of that. Granted, they've handled it better than KDE, but that's not really THAT surprising.

In regards to Gnome, the question is whether they at some point will need to do the same, but I could imagine they would have to do some major surgery as well at some point. Hopefully they'll have learnt from KDE's mistakes.

KDE struggles with feature requests

Posted Sep 18, 2009 19:39 UTC (Fri) by sheakauffman (guest, #60890) [Link] (1 responses)

" The whole point of KDE 4, with Solid, Phonon, Plasma, Nepomuk and more, is to build a platform for next-gen applications. They're trying to make it easier to create great applications for users. They haven't created those apps yet, but in the next few years, I'd expect to see interesting things happen.

In other words, the actual users can go take a fucking hike. Their pain today is irrelevant and unimportant. All that matters is the great applications that might get written someday -- but which, notably, don't even exist now, more than a year and a half after 4.0 was released. And even you don't think they're going to show up for years more. And, meanwhile, 3.X stagnates. "

I'm not even a KDE developer, but, as a programmer, this sort of comment really pisses me off. There are 2 kinds of applications in this world, applications that perform a user function (i.e. kate, gimp, grep), and applications that are there to run / utilize other applications (i.e. KDE, firefox, | )

The application is not at all the platform. Platforms hold applications.

Desktop environments are entirely about the API's, the applications are secondary. If developers spend all their time working on KDE applications, they will spend exponentially more time getting "all your features" than if they develop a strong foundation. Since KDE is about supporting applications and how users interface with those applications, the PRIMARY goal is to create stable hooks.

The sum total of my complaining about KDE 4.X has been that A) I won't use it ...

Really? Then perhaps you should shut up since you already said you won't use it. What is the point of saying any of this at all? Apparently no matter what developers do you aren't going to use it, you're just going to complain about what other people do!

And you know what... User pain is definitely less important than developer pain. You want to know why? Because the developers are the ones writing the software! If they don't feel good about the project, there is no more project. End of story. This is true with GNOME, or any other OS project. You want to see grumpy developers? Why don't you go try asking the GIMP team to change the user interface?

It seems like the real problem you have is that you liked KDE 3.5.
If thats the case then go buy www.savekde35.com and go here grab the source and fork! Good luck trying to navigate around that source code though... (I hear it's a little outdated)

You have the ability to start your own community. Take some *** responsibility for your own situation, and quit blaming other people because things aren't the way you like them.

KDE struggles with feature requests

Posted Sep 21, 2009 12:12 UTC (Mon) by nye (guest, #51576) [Link]

>And you know what... User pain is definitely less important than developer pain. You want to know why? Because the developers are the ones writing the software! If they don't feel good about the project, there is no more project. End of story. This is true with GNOME, or any other OS project. You want to see grumpy developers? Why don't you go try asking the GIMP team to change the user interface?

After using Free Software almost exclusively for years, I've been grappling recently with the painful realisation that it's a dead end. There will never be a decent user-oriented Free Software desktop system; the desktop Linux experience has actually been getting *worse* for a few years, and this is why.

Who in their right mind would sit around for a couple of years in the hope that KDE4 actually becomes usable some day, when it's clear the developers *don't want that*, would prefer not to have any actual users in the way, and will undoubtedly rush off to create KDE5 as soon as it looks like KDE4 is approaching stability?

KDE struggles with feature requests

Posted Aug 25, 2009 4:11 UTC (Tue) by Arker (guest, #14205) [Link]

It's no mistake that Slackware is still shipping KDE v 3.5 (and doesnt even include GNOME at all, that mess was removed long ago.)

KDE struggles with feature requests

Posted Aug 14, 2009 14:17 UTC (Fri) by Gorwood (guest, #6597) [Link] (1 responses)

Things would be quieter if the distros had not abandoned KDE3 before KDE4 was ready. If KDE3 was still an option in new installs, then those who feel that KDE4 was not yet ready enough would simply stick with KDE3 and be happy campers.

KDE struggles with feature requests

Posted Aug 14, 2009 14:30 UTC (Fri) by fb (guest, #53265) [Link]

You seem to imply that it was the distributions who are responsible for the KDE4 mess/backslash. I think most distributions dropped KDE3 too soon, because essentially the developers had abandoned it.

From my perspective the best way to look at it is: it would have been quieter if the devs did not abandon KDE3 before KDE4 was ready.

KDE struggles with feature requests

Posted Aug 14, 2009 17:46 UTC (Fri) by giraffedata (guest, #1954) [Link] (1 responses)

I've always wanted to be able to buy free software. I hate begging. I also hate having to persuade developers and project owners to see things the way I do. In a money-based system, there wouldn't have to be any argument about whether something is really desired or what the priorities are.

Alas, I saw two attempts to do something like that during the dot-com bubble, and they fell flat. These allowed pools of users to pay someone to develop features for arbitrary open source programs, though didn't deal with the issue of project owner philosophy.

So I guess the sociology of free software just doesn't support a money economy.

Not only free software

Posted Aug 16, 2009 16:42 UTC (Sun) by man_ls (guest, #15091) [Link]

Just try buying proprietary software which doesn't suck, or just that does what you want it to do. Now imagine sponsoring new features for proprietary software (say, in Word or Photoshop). Maybe the idea just isn't that easy to do.

KDE struggles with feature requests

Posted Aug 21, 2009 11:46 UTC (Fri) by sigra (guest, #57156) [Link]

I created a bug report to track the regressions that are serious enough to
prevent users from migrating from KDE3 to KDE4:
https://bugs.kde.org/show_bug.cgi?id=186184

I was going add the bugs that keep me with KDE3, and welcomed others to do
the same. But unlike dowdle (subscriber, #659) and others here, the KDE
developer(s) did not want that list to exist.

I did dot do any unconstructive complaining, nor did I demand that the
issues should be fixed within any particular time. All I asked for was to
let the list exist.

Some bugs that I would add:
implement in the printing system the feature "print only odd/even pages":
[https://bugs.kde.org/show_bug.cgi?id=190646] (I have only a simplex
printer)
calculator runner of krunner outputs wrong results:
[https://bugs.kde.org/show_bug.cgi?id=167986] (I do a lot of quick
calculations for decesions involving money)

Read LinuxToday's GreyGeek's reply to this kind of trolling for hits

Posted Aug 26, 2009 2:39 UTC (Wed) by zeke123 (guest, #60445) [Link] (2 responses)

Excuse my french but this whole post is total BS, blown out of proportion for the sake of a few hits.
Those writers are a dime a dozen.

On the other might I suggest you read the writings of LinuxToday.com forum contributor GreyGeek's take on this.
GreyGeek along with Brandioch Conner is one of the most respected commentators at LT and he once again calls it right on:

http://www.linuxtoday.com/news_story.php3?ltsn=2009-08-25...

GreyGeek -
Subject: This game is getting old .... ( Aug 26, 2009, 01:19:53 )

What game?

The game of increasing page hits by ranting on KDE4 and its developers with the usual "complaints', with pile-on comments by the usual suspects. Jake Edge picks it up a bit by accusing Seigo of "ranting" when he replies to a poorly worded introduction to a request on the KDE-dev elist:

People still complain about KDE3 features they miss in KDE4 (for instance: http://www.reddit.com/r/linux/comments/97454/a_fir st_look...
).

...
Now, I may be a very simple user because I hardly miss anything(*), but I guess other people feel the same. It's really difficult to add that missing feature if you don't know it's missing in the first place.

OpenSuse has this page:
http://en.opensuse.org/What_features_is_KDE4_missi ng_when...

Can we start something like that in UserBase, for people to tell us what they miss in KDE4 from KDE3? Or have a special category in Bugzilla ?

.,..
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

First off, Quiles is NOT a "simple user". By his own admission he is a "telecommunications & computer science engineer. inventor. always thirsty of knowledge", and he supports FIVE open source projects. As such, he should know better than to begin a request using a complaint and assume a false role of a "simple user". He may be a sensitive guy, but when a bunch of drive-by shooters start attacking his work and him, personally, you can bet he won't be so friendly after a couple years of that.

Edge calls Seigo's response a "rant". Seigo was just stating facts. Several anti-KDE ranters have hit LT and other forums I visit. I followed the trail of rants of one drive-by shooter back through almost 2 years of posts on a wide variety of forums, as he sometimes added his rants to a thread over a year old! The theme was always the same. KDE4 stinks, KDE3 is better. When responders would point out the errors in his "examples", as was done to ranters piling on to Jake Edge's article, the ranter would change his example target and pick up his rant on another site. Always learning from his mistakes his rants kept changing from feature to feature.

Seigo's completed his reply with:

"...
now, i'm all for a proper feature request system. bugzilla is not that, a wiki is not that, random emails are not that, a blog is not that. FATE, as used by opensuse, gets pretty *** close though (and it even has a kde client). one day i'll probably just say "screw bugs.kde.org for feature requests" and have
someone set up a FATE install for plasma. and then we can get on to the business of proper feature request work flow.

i know that's probably a lot more, and not the sort of, feedback your were probably looking for when you wrote your well-meaning email. i just think we need to know where we're going ourselves first and foremost and deal with feature choice and growth issues wisely."

"well-meaning email"? "deal with feature choice and growth issues wisely"? That doesn't sound like a rant to me. It sounds like a reasoned answer by someone in charge of a project who knows what the goals of the project are and how to get there.

Quiles wasn't ranting. Seigo didn't respond with a rant. But, IMO, Jake's article is trying to increase page hits by hammering on KDE4 and the dev crew again. Fortunately, KDE4.2 and higher are getting excellent reviews from the users, and KDE 4.3 is a hit. Drive-by shooters or shooting at other FOSS targets.
---
GreyGeek

He also adds this later on:
http://www.linuxtoday.com/news_story.php3?ltsn=2009-08-25...

GreyGeek - Subject: Re: This game is getting old ....
( Aug 26, 2009, 01:49:49 )

I forgot to add one thing: Jake Edge claims that the KDE dev crew "struggled" with the feature requests. Let's see if that charge is true.

http://dot.kde.org/2009/08/04/kde-430-released-cai zen
KDE 4.3.0 is out, and it is a great release. It is unlikely that any one specific thing will strike the user as the most noticeable improvement; rather, the overall user experience of KDE has improved greatly in KDE 4.3.0. The release's codename, Caizen, is a Japanese philosophy that focuses on continuous improvement throughout all aspects of life. That has been the goal of the KDE team for 4.3.0: polish, polish, polish. The statistics from the bug tracker speak for themselves: 10,000 bugs have been fixed. In addition, close to 63,000 changes were checked in by a little under 700 contributors. That is not to say that the KDE team did not add a large number of new features: 2000 feature requests were implemented in the past 6 months, meaning that any user's pet feature might well be among the improvements KDE 4.3.0 brings.

Struggle? Hardly.

As another KDE developer aptly wrote:
http://osdir.com/ml/kde-devel/2009-08/msg00047.htm l

Face it, if people want a feature implemented in "my application" (speaking as a KDE developer) there is exactly 1 channel to make sure I see that request and am able to remember it in 6 months when it reaches the top of my todo list: bugs.kde.org
---
GreyGeek

Popularity and Majority votes no help in picking feature requests

Posted Aug 31, 2009 7:25 UTC (Mon) by corigo (guest, #59903) [Link] (1 responses)

The biggest problem I have with feature requests and requesting systems, is that popularity and majority rule quite frequently outweigh far more important issues that actually are a real impediment to a workable system. My personal for example on this would be a method for typing in foreign languages. The vast majority of users for KDE work entirely in English or their localized language platform. For these people, life is great. There is, though, a minority of KDE users that need to work in one localized environment, but switch between different languages for typing.

Previously this was supposed to be achieved through SKIM with SCIM in the background. I never was able to get this to work at all in any of the 4+ KDE distros. Which means that my Linux machine is frequently used as a virtual machine host, just so I can type in a different language than my desktop is in. KIMPanel is supposed to the be latest and greatest solution which will be the new default... if anyone can get the time to package it.

Mega-popular feature... no. A complete hindrance for thousands of existing users, yes! That is why there has to be a more intelligent way to navigate the request of users rather than popularity or majority rule that looks at the grade, value, and impact of the changes/requests instead of the whingeing and moaning of a/any vocal minority or majority.

Popularity and Majority votes no help in picking feature requests

Posted Aug 31, 2009 13:41 UTC (Mon) by johnflux (guest, #58833) [Link]

And yet none of those "thousands of existing users" are able to organise and get it fixed.

These problems are solvable, it just takes motivation. Find out what exactly is going wrong with the scim bridge, work out how to fix, file very specific bug reports etc with the various groups.

A good first step would be to get KUbuntu to update its scim scripts - a big reason why scim doesn't work is simply because the scripts haven't been updated.