What if, instead of basing our platforms, software and development paradigms upon chasing what we perceive the competition has today, we based our decisions upon user demand.
So when a group of people actualy need something, someone (probably people invovled that group having the need) make it. If nobody needs feature/library/component/technology X, nobody makes it and the platform isn't weighed down by it. If this sounds a lot like how things work in open source, it is.
Some development projects, mostly commercial ones (closed and open source), tend to try and think really hard of cool new things that nobody has yet, create those things, and then push those things as being critical and central to the software. Unfortunately, most of those same projects conflate "nobody needs" with "nobody has". Apple's new Expose windowing trick is a great example of something that nobody had, but that is actually useful to people. KDE's XMPLRPC daemon, as an opposite example, was neat in that pretty unique and rather cool but it wasn't exactly useful (in that people didn't use it). The same can be said about many of the features people like Microsoft trot out as being the next Have It Or Die feature.
When they trot out the next Have It Or Die thing there are those who believe them and, propelled by an irrational fear of being left behind, blindly try to clone it as quickly as possible. But then when the Have It Or Die thing flops (as happens more often than not), the cloners have just wasted their time and looked like twice the fool for having imitated the original fool.
Now, I'm not saying that it's wrong to clone concepts and borrow ideas that arise elsewhere: that's called collaberation and inspiration; but such conceptual scavenging should be driven by actual user demand. This does not mean people need to be loudly asking for something before we decide to deliver it, but people should have an actual need for that thing we're going to deliver. The userbase may not actively realize they have that need, or may not be able to articulate it properly; those who create the technology for them have the job of doing that for them.
The Free / Open Source Software community has been creating based on demand for a long, long time. It works really, really well and has brought with it a nice ballance of innovation and conservatism that doesn't suffer from too many wasted dead ends. Those who are trying to focus on chasing tailights as anything more than an interim solution are throwing away one of the lessons we've been taught by experience. Those who would pick up any idea just because it exists elsewhere, as opposed to thoughtfully picking what to borrow and what not to borrow, are openning dangerous avenues that will lead to wasted efforts and less useful technology. Those who think the world of technology is moved by theoretically interesting inventions hasn't been paying attention.
Syndicate Blogs
There a lot of demands which have not been answered
I just want to add to Aaron's point that demand is not only what
users want know but also how they would want to use their computer.
I've just read an article about a court case in France. A woman was
using her office computer to run during her work hours a flower delivery business. Her employer finds it, he reads her files as a proof of her misbehaviour and fires her. She sues him and wins because there is a very strong privacy law in France and your employer is not allowed to spy your personal life even your private information circulates on your
employer property (his phone, his computer, his network).
This legal problem will certainly create a big desire by employer to lock office PC in legal ways. It is a new or emerging demand. If KDE can offer a framework to do that, it will be certainly a good selling point.
Here you go:
Lock your KDE system down to your likings: http://www.kde.org/areas/sysadmin/
Locking
Yes when reading this article about this rogue woman, I was thinking
about how with Linux and Kiosk in KDE, employers could regain control on their employees computers.
Now, we need to make it simple (point-and-click) to restrict the
use of a KDE desktop and promote it like hell...
a little simplistic
Isn't it a little simplistic to say: we should base our decisions upon user demand, or we should base our decisions upon technological paradigms, or we should base our decisions upon our philosophy of Freedom, etc.?
I agree with your main point though; KDE should look to move in the direction that users want, in a way that will help include as many people as possible without making it less useable for existing users, embracing the ideology of Free Software and developing new technologies that facilitate this process.
I think Qt + Designer, Python, PyQt, KDE, PyKDE and KDevelop offer a nice example of how new technologies can be developed almost by accident that open doors to a lot of people, and that, correctly managed, can provide the KDE project with something that other platforms (with the exception of GNOME) simply cannot offer.
no i think its spot on
I think its important that we accomidate users, and make it easy for them to add features themselves if we cannot do it for them. MS has made quite a bit of money on telling people what they want. Some people are happy with that... but MOST companies are not. If they where there I would be begging for change, instead of consulting.
IMHO we are going the right direction. We develop ideas we think are good, and the ones that work go on to do great things, while the ones that are not so hot, fall away... maby to rise someday when they are wanted again...
We dont have a bottom line to worry about, so we shouldnt waste our time trying to worry about it
Did you get my point?
I don't disagree that providing what users ask for is a good idea, but I think that saying KDE will be driven by only one factor, one goal, is simplistic. Not only does it fail to reflect the reality of KDE at present, it fails to emphasise other considerations which are important to the past and future success of KDE.
There is one thing we ought to keep in mind when we talk of "what users want": how do we know? I doubt that even half of the users of KDE even know how to make their needs and desires apparent to KDE developers, let alone actually go on to do it. So in the absence of a reliable picture of what all users want, KDE has to appreciate various other goals such as accessibility, usability, power, flexibility, Free-ness, and probably more. In keeping these in mind whilst developing new and exciting technology, KDE can ensure to some extent that it will be fulfilling users' wishes. And as you say, trial and error will, for the most part, weed out the bad ideas.
"how do we know?"
I doubt that even half of the users of KDE even know how to make their needs and desires apparent to KDE developers, let alone actually go on to do it.
The best way (you knew it, didn't you?) is voting on bugs.kde.org. It's obviously already quite actively used by an increasing number of users, and the more there are the more representative these lists will be, giving developers at least a good hint what they could do next. This should be promoted further.
true
Yes, KDE would do well to keep promoting bugzilla and to put a lot of effort into getting as many users to use it as possible.
But that still won't get a high proportion of users, or at least certainly not enough to know what all users want. In that case, KDE must always fall back on certain goals, which I outlined previously, and which maybe somebody would like to add to?
Well...
The only "certain goal" KDE has is KDE itself (as a system, as a community, as an example for well designed frameworks and software, take whatever you want as long as you don't interfer with others' goals). As soon as you start talking about "KDE's goals" you have to keep in mind that KDE never stood for a specific goal (except offering a complete desktop which is vague at best, and this is good), it is only the developers, contributers and, to a lesser degree, non-contributing users who push KDE each on their own. Giving KDE a goal will most likely only alienating those who don't agree with that particular goal while not changing anything in the end. I suggest you reading Development Model and the other pages in that section, they are the best descriptions about what made KDE what it is today. Any kind of suggested improvement should keep those in mind to be applicable in KDE as a project.
Regarding the fact that bugzilla won't ever reach all or the majority of users, I'm actually doubting that this will matter that much at all. On the one hand one can argue that people who don't complain are likely either to be satisfied enough or to be not as cooperative as needed. On the other hand there are many kinds of researches and polls which only pick on a fraction of the whole but still result in conclusions which are still helpful for (understanding) the whole. I'm currently writing an own blog entry regarding how KDE (is/could be/should be) dealing with this whole topic, stay tuned. =)
Cheers.
Fuzzy goals!
So you are saying, or implying, that by deliberately avoiding setting specific development goals, KDE will organically develop in the best direction(s)? That is certainly a strong theme in most hacker projects, and one that is perhaps facilitated by the nature of Free Software. But I find projects like KDE and GNOME particularly interesting because they, more than most other projects, do set specific goals, either central to the project or as branches.
Accessibility is a good example, whereby KDE takes two approaches. First, it has a development architecture and a set of development guidelines that ensure a certain level of accessibility in all KDE "user level" components (as opposed to backend components). Second, it has specific applications that seek to improve upon accessibility where a framework is insufficient, e.g. kmag.
I am trying to understand how KDE manages these methods that could be contradictory, and in particular how the hacker ethic works in practice in a large project that by its nature has gone beyond simply satisfying the needs of its developers, and yet is still very much driven by that ethic. So to take this thread as an example, how can KDE continue to pursue specific goals without its direction being dictated by specific goals? I think the fact that this occurs is evident both from the goals I have outlined, and from the resistance from KDE developers to the notion that it has any specific goals. To me, as someone interested in and researching the hacker ethic, that's an interesting problem to resolve, because it cannot be a contradiction (two things that are the case cannot be a contradiction).
Tied in with this is of course how KDE can reach out to those who wouldn't traditionally participate in the project, particularly those who have been alienated from any sense of power by the proprietary development process (be it power over what goes in, power over the discussions of what goes in, or power over the frameworks by which these discussions and decisions are made).