KDE on the Fray of User-Developer Interaction

Following the recent complaints regarding the lack of proper market research in the F/OSS world, KDE users suggested paying money through Bugzilla to see their features/bugfixes done, a proposal that was denied by the core KDE developers. The lengthy discussion comes down to SuSE's Waldo Bastian reply which illustrates once more the developer-centric nature of F/OSS (in contrast to the more user-centric nature of commercial products): "KDE will be able to sustain itself just fine without users, while it will not last a single day without developers. So when it comes to choosing between scaring away developers and scaring away users, the choice is rather easy actually." (2nd reply)

Special Note: My article the other day that seemed to have created a huge controversy, was not about implementing every damn thing people wanted, but only implement things that are really needed by the majority and only when these things are not coming in contrast with the general direction of the project. For example, if someone was asking Gnome to implement a "KDE-alike control panel", that should be rejected because that design is not Gnome's way. But when someone says "make Shift+Delete to delete a file on Nautilus automatically", that's a legitimate feature request to be taken under consideration, and many users would expect it to be there already (that's not my feature request btw).

It's about market research, it's about putting together things that really need to get done (that's feedback filtered by a special team, not by the developers who are already under a lot of pressure). That's what market research is about. It's not about listen to every single idiot out there and his little or big feature request. So, don't take my article out of context and don't make it about myself or specific feature requests, because it is not so. It is about evolving a project to become better by taking in some well-structured user feedback in it. That's all.

Gaming on Linux

Linux has so far failed to establish itself as a gamer's operating system of choice. Attempts to create multi-OS compatible games and current attempts to build a bridge between Windows-based games and Linux have yet to bear much fruit. How might things change in future?

Reliability and availability: What’s the difference?

How do you design a computing system to provide continuous service and to ensure that any failures interrupting service do not result in customer safety issues or loss of customers due to dissatisfaction? Historically, system architects have taken two approaches to answer this question: building highly reliable, fail-safe systems with low probability of failure, or building mostly reliable systems with quick automated recovery.