There’s a line in “You’ve Got Mail” with Tom Hanks and Meg Ryan where an observation is made about the ridiculous number of choices are involved in buying coffee at the little coffee shop. I don’t know about that, since I don’t drink coffee, but choices are barriers. If you’re a web developer like me, you know that the more clicks a visitor has to make to get them where you want them on your site, the less likely they are to get there. If there are too many options, it is easier not to use it at all.

Options are limited all around you. Businesses like to standardize on computer hardware, vendors, and even jets which saves them money. Options cost money and time.

Unfortunately, in the Linux world, we love options. It’s time to stop that.

I know- heretical. How dare a developer limit options? The fact is that the more options/tools there are, the harder it is to use an app. For example, some apps like Photoshop are now at the point where usability is so hindered by the many menus and panels that only a trained specialist can make use of it. They have to market stripped down versions of Photoshop to customers that don’t want or need the super-charged, confusing edition. Why are Apple’s apps so clean and beautiful? Part of it is that actively reduce choice. There are low-level ways that a power user can modify configurations but for the most part the options a user has access to are limited to a handful of the things they would most likely use. For everything else, Apple makes a judgement call for the user. So limit options.

But I’m not just talking about app preferences. I’m talking the very basics of Linux distributions. In this post from an Adobe employee he talks about the mess that is audio in Linux. I myself have lost some hair because of the jumble of audio stacks.

Now I am not saying we should no longer have any options at all. But standardize on APIs. I would propose that the Linux Foundation or some other organization go out to the five biggest Linux distributions and ask them to sign on with making agreements about standard interfaces for subsystems. So instead of installing every audio stack and figuring out how to configure them together, identify the pieces or modules that make up an operating system at a very low level. Establish APIs for each module so others can always connect and interact with a module that is doing task X. Then go to the projects within the distributions and ask them to define which module(s) their project fills and have them add the standard ways of interacting with that module.

So maybe openSUSE uses module A for audio hardware interaction, module B for audio mixing and plugins, and module C for volume control. If they all followed pre-arranged APIs for talking to one another, if one user wanted to use something other than module B for mixing, they just have to pick a different mixing module with the standard API and they’re done because they can still interoperate.

Why should the people behind those projects listen? For the most part, this is a labor of love, right? But they have their pride, and a) getting this mess straightened out will just lead to more success for Linux and their little piece of it and b) without this kind of structure and specification, they’re on their own to try and make things work and figure out what their project should or shouldn’t do. With it, they have a checklist with which they can know their project will interoperate well with others. Then they can just focus on making their project the absolute best of class for that module their building towards.

A recent post on WorksWithU has it right- app developers should target specific environments, and distributions should work with contributors to make environments that will attract more developers. Every other day we hear about Apple and what they’re doing, how we can compete, and how we’re almost there. No we’re not. Not at all. Mac OS X is not about choice. It is a software stack with little (no?) overlap. If you don’t like the audio subsystem, it’s your problem. You take what you get. Linux users, vendors, and developers say they want to compete. No they don’t. They want to make Linux and have it be successful. But they refuse to compete- competing would mean at least some standardization and limiting of options in order to deliver a more polished product.

Apple is making a Matchbox® car, the kind that is a chunk of metal with wheels on it. Linux is making a model car kit. Although some kits come with the car already assembled, for some reason Linux also includes a dozen interchangeable pieces in the box for every piece built into the car.

Stop with the model car kit. It’s fine to provide some options, but options in Linux have created a mess. You want people to use Linux, to use your app? Fine- but remember that they don’t want Linux. They want something that will help them get things done. If it’s Linux that’s great. If you want it to be, make judgements for what defaults should be and limit options. Have low-level components truly be interchangeable. For the people that want the Matchbox® car, give that to them.