Skip to content

What do users want?

Sunday, 16 November 2003  |  tjansen

The main problem is to find out what users want. Did you know whether users will like Expose or they will use KXmlRpc before they have been implemented? I don't think so. Did users ask for Expose? Unlikely. Can we know whether WinFS's way of searching files with meta-data queries will replace today's file systems? No. All I know is that it sounds useful, and that if it is a success KDE will look pretty outdated with its file dialogs.

Unless you limit yourself to cloning proven concepts, you will never know. Every feature comes with a risk, the risk that users won't accept it. There's nothing you can do about it, unless you refuse to innovate. And that comes with another risk, the risk that the other product is superior. In the end users don't care whether the competition has 9 ideas that failed miserably as long as there is one really useful feature. Did they use more resources while finding out which idea was the good one? Sure. But which is the better product? The one that contains 9 things that nobody uses and one brilliant feature, or the product that lacks all 10?

Basing the software on demand is what the market is doing anyway, for free software as well as proprietary software. You write software, you release it and and hope that people like it. If people buy/use software it will continue to live. If not it will just go away, sooner or later. The question is how large is the risk that you are willing to take. Implementing a feature that no one has done before has a high risk, it's easy to fail and lose all the time/money that you have spent. But the gain is high, you could have written a brilliant feature that stands out against the competition. Cloning a feature that the competition already has and all your users want is low risk. You will make your users happier than they would be without it, but it doesn't make your product better than the competition.

So far free software had mostly success in cloning features from proprietary systems and making them better, more reliable, maybe faster. But if you look at the most successful projects, their competition stood still. Linux was able to succeed with its strategy because the lack of Unix progress in the last 10 years. Since Apache destroyed the competition neither Apache nor any other web server added any noticable improvement. SQL databases also had no significant progress (if you ignore high-end stuff like clustering), so it was easy for MySQL and others to grab a relatively large share. Browsers stood almost still since the IE 4.x days, which made it was quite easy for Konqueror to compete. All these products went a low risk way. Their technical archievement may be high, but it was clear from the beginning that the end result would be useful.

This is also a reason for the fast, perceived progress of free software. We can laugh about Microsoft's Bob project, or the paper clip. But only because they have tested for us whether it works, and we have learned from their mistakes. That's the comfort that you have when you are picking up the ideas that others have tested.

But the next challenge is competing with those systems that are making progress. Most people will not stop using proprietary systems as long as the free alternatives are not noticably better. Even when both are comparable in functionality inertia will win over price and freedom in most cases. And to get better, free software needs many new ideas. And there will certainly be many flops among them, and many people will lose their time by writing them. But these failure are needed for progress, to find the good ideas.