This is some commentary by me about two articles that Eric Raymond wrote recently. Both focus on difficulty in setting up a printing package under Linux. Part one lays out the general problem, and part two goes into some detail about how to solve some of the issues. I agree with many of the points brought up in those articles, but not the prescription given for finding a better situation. Computer systems can become orders of magnitude more usable if effort is put into improving the configuration and setup systems, but I think it will take some effort separating the technical guts from the setup phase before we see this on a large scale.

Why? Because these are open source projects we’re dealing with. The technical geeks hack on them because they want cool technical systems to play with. I’m certainly not prepared to tell these people who make the software that I use every day that they need to make it more usable. This is the root of open source - if I see a problem I have to be prepared to make the effort to fix it myself. If it’s not worth my time, why should it be worth anyone else’s? There are cases where the techies would probably be best served by learning how to make the user interface of their system more approachable, but there are a lot of “if”s in there. At the most general level, all of us open source wonks benefit if the software is more approachable. The more users we have for the projects, the more resources get dedicated to improving them, and the better the systems become as a whole. Right? Hopefully, but there’s a lot of abstraction in that explanation. Open source has already been very successful. Why have the interface gurus not popped up to solve these issues yet? Why should we redirect the geeks to get them to solve the newbie problems? I don’t think we should.

First off, imagine what would happen if every one of the packages in a standard Linux distribution had it’s own configurator. Imagine if every one of them tried to be as novel as possible, providing just the interface that they thought the user would need and providing the mechanisms for discoverability that ESR speaks about. It’s possible that this would work out perfectly, but I think it’s more likely that we would just have a large number of different interface styles. Somewhere along the line I think the limit would be hit and we would find that one person’s discoverability is another person’s obfuscation. Plus I still believe very strongly in the “do one task and do it well” philosophy of Unix in general. Requiring that a package that does printing also include rules for probing a network to determine what resources are available just doesn’t strike me right. I can certainly see where there would be benefit to proving info like this to the user, but I also think this is where the distribution providers should come into play.

I personally think that tools like configurators and setup wizards are the kinds of tools that distribution providers should be feeding back into the community, because they are currently the ones who stand to benefit the most from it. The value proposition for me, as a single person without any ties to desktop Linux except being an avid user, in writing a better configurator for CUPS is almost zero. Once I know enough about CUPS to write that thing, why would I bother? I really don’t have a direct interest in seeing other people not have to learn about the system. However, the distribution providers do care if people can use CUPS without spending a lot of time doing config. Sure, the CUPS people might be a great group, they might be interested in seeing more people use CUPS and they might care about their existing users. That would be great. But it doesn’t have to be the case. And I think it will probably be the exception rather than the norm.

The distribution providers are in a great place to deal with this issue. The people working on individual projects normally don’t have too much visibility of the user system as a whole. People working on a single project aren’t always sure what other projects are going to coexist with their own. Distribution providers do get the cross-project view of the system. They are in a position to provide standardization for some services that haven’t caught on well because of their overarching nature. Such as service discovery. Sure, we could probe the network for resources using custom assembled packets. But we could also try to implement more deterministic methods of finding resources, such as picking one of the many Java related protocols for discovery or really starting to aggressively pursue Rendezvous. I agree with ESR that the type of discovery doesn’t matter that much, but the distro providers are the ones who should be looking to solve these problems, not the individual package producer. This might mean working closely with the project developers to provide additional support for discovery and configuration, but the distribution providers should be providing the manpower to do it. I think the long term success of trying to transform OSS into a more usable form will mean factoring out a lot of the user interface from backend projects, and adding in the proper hooks so that a distribution provider can move away from the simple role of adding nice colors and consistent graphical elements. Currently distribution providers add a relatively thin veneer (for the most part), and in order to move to a place where Aunt Tillie can use the system they’re probably going to have to add something more like a thick upper layer of the applications stack. A system like this would provide for greater hackability to a degree as well.

Currently there is a lot of effort that would need to be made to change the look and feel of a Linux system. The user exposed bits come from lots of different packages with lots of different ideas about how things should work. If the user exposed bits were something that could be switched around relatively easily at the level of the whole distribution rather than on a project by project basis, this would give distro providers and talented users a larger degree of freedom in terms of experiment with new UI styles. Instead of having to change hundreds of packages they might be able to get away with a much smaller set of updates. This wouldn’t be a panacea of course, figuring out the base API for a “distribution interface” is a daunting task and would probably itself see a lot of missteps and outright flaws. But as a whole I think the more componentized open source software becomes the better off we are.

I know not everyone agrees, but I think that autoconf and automake have done great good in terms of making source code versions of software available to many more developers. This is effectively an API for the development and compilation phase of a project. I would like to see a more developed system for the deployment and runtime phases of a project. Am I sure it could be done? No, not absolutely. But I think that the efforts of Apple, both in terms of setting up a very usable user interface as a layer over a BSD kernel and in getting Rendezvous setup for the networking part of configuration, show that the user interface portions can be factored out of a traditional Unix system to make it look like something completely different. I do agree with ESR about making systems more discoverable, he’s right on the mark there in my opinion. I think we might just differ in regard to who the torch of discoverability should be carried to.