4. Lists

While Alan Cox was sleeping late and Microsoft was putting Richard Schmalensee on the stand, the rest of the open source software world was tackling their own problems. Some were just getting up, others were in the middle of their day, and still others were just going to sleep. This is not just because the open source hackers like to work at odd times around the clock. Some do. But they also live around the globe in all of the different time zones. The sun never sets on the open source empire.

On January 14, 1999, for instance, Peter Jeremy, an Australian, announced that he had just discovered a potential Y2K problem in the control software in the central database that helped maintain the FreeBSD source code. He announced this by posting a note to a mailing list that forwarded the message to many other FreeBSD users. The problem was that the software simply appended the two characters “19” to the front of the year. When the new millennium came about a year later, the software would start writing the new date as “19100.” Oops. The problem was largely cosmetic because it only occurred in some of the support software used by the system.

FreeBSD is a close cousin to the Linux kernel and one that predates it in some ways. It descends from a long tradition of research and development of operating systems at the University of California at Berkeley. The name BSD stands for “Berkeley Software Distribution,” the name given to one of the first releases of operating system source code that Berkeley made for the world. That small package grew, morphed, and absorbed many other contributions over the years.

Referring to Linux and FreeBSD as cousins is an apt term because they share much of the same source code in the same way that cousins share some of the same genes. Both borrow source code and ideas from each other. If you buy a disk with FreeBSD, which you can do from companies like Walnut Creek, you may get many of the same software packages that you get from a disk from Red Hat Linux. Both include, for instance, some of the GNU compilers that turn source code into something that can be understood by computers.

FreeBSD, in fact, has some of its own fans and devotees. The FreeBSD site lists thousands of companies large and small that use the software. Yahoo, the big Internet directory, game center, and news operation, uses FreeBSD in some of its servers. So does Blue Mountain Arts, the electronic greeting card company that is consistently one of the most popular sites on the web. There are undoubtedly thousands more who aren't listed on the FreeBSD site. The software produced by the FreeBSD project is, after all, free, so people can give it away, share it with their friends, or even pretend they are “stealing” it by making a copy of a disk at work. No one really knows how many copies of FreeBSD are out there because there's no reason to count. Microsoft may need to count heads so they can bill everyone for using Windows, but FreeBSD doesn't have that problem.

That morning, Peter Jeremy's message went out to everyone who subscribed to the FreeBSD mailing list. Some users who cared about the Y2K bug could take Jeremy's patch and use it to fix their software directly. They didn't need to wait for some central bureaucracy to pass judgment on the information. They didn't need to wait for the Y2K guy at FreeBSD to get around to vetting the change. Everyone could just insert the fix because they had all of the source code available to them.

Of course, most people never use all their freedoms. In this case, most people didn't have to bother dealing with Jeremy's patch because they waited for the official version. The FreeBSD infrastructure absorbed the changes into its source code vaults, and the changes appeared in the next fully updated version. This new complete version is where most people first started using the fix. Jeremy is a programmer who created a solution that was easy for other programmers to use. Most people, however, aren't programmers, and they want their software to be easy to use. Most programmers aren't even interested in poking around inside their machines. Everyone wants the solution to either fix itself or come as close to that as possible.

Jeremy's message was just one of the hundreds percolating through the FreeBSD community that day. Some fell on deaf ears, some drew snotty comments, and a few gathered some real attention. The mailing lists were fairly complex ecologies where ideas blossomed and grew before they faded away and died.

Of course, it's not fair to categorize the FreeBSD world as a totally decentralized anarchy. There is one central team led by one man, Jordan Hubbard, who organizes the leadership of a core group of devoted programmers. The group runs the website, maintains an up-to-date version of FreeBSD, and sponsors dozens of lists devoted to different corners or features. One list focuses on hooking up the fast high-performance SCSI hard disks that are popular with people who demand high-performance systems. Another concentrates on building in enough security to keep out attackers who might try to sneak in through the Internet.

That January 14, a man in Great Britain, Roger Hardiman, was helping a man in Switzerland, Reto Trachsel, hook up a Hauppauge video card to his system. They were communicating on the Multimedia mailing list devoted to finding ways to add audio and video functions to FreeBSD systems. Trachsel posted a note to the list asking for information on how to find the driver software that would make sure that the data coming out of the Hauppauge television receiver would be generally available to the rest of the computer. Hardiman pointed out a solution, but cautioned, “If your Hauppauge card has the MSP34xx Stereo Decoder audio chip, you may get no sound when watching TV. I should get this fixed in the next week or two.”

Solutions like these float around the FreeBSD community. Most people don't really care if they can watch television with their computer, but a few do. The easy access to source code and drivers means that the few can go off and do their own thing without asking some major company for permission. The big companies like Microsoft and Apple, for instance, have internal projects that are producing impressive software for creating and displaying multimedia extravaganzas on computers. But they have a strict view of the world: the company is the producer of high-quality tools that make their way to the consumer who uses them and pays for them in one way or another.

The list ecology is more organic and anti-hierarchical. Everyone has access to the source code. Everyone can make changes. Everyone can do what they want. There is no need for the FreeBSD management to meet and decide “Multimedia is good.” There is no need for a project team to prioritize and list action items and best-of-breed deliverables. Someone in Switzerland decides he wants to hook up a television receiver to his computer and, what do you know, someone in Great Britain has already solved the problem. Well, he's solved it if you don't have an MSP34xx stereo decoder chip in your card. But that should be fixed sooner or later, too.

4.1. Free Doesn't Mean Freeloading

There are thousands of other mailing lists linking thousands of other projects. It's hard to actually put a number to them because the projects grow, merge, and fade as people's interests wax and wane. The best flourish, and the others just drift away.

Life on the mailing lists is often a bit more brutal and short than life on earth. The work on the project needs to split up. The volunteers need to organize themselves so that great software can be written.

On that January 14, a new member of the WINE list was learning just how volunteering works. The guy posted a note to the list that described his Diamond RIO portable music device that lets you listen to MP3 files whenever you want. “I think the WINE development team should drop everything and work on getting this program to work as it doesn't seem like Diamond wants to release a Linux utility for the Rio,” he wrote.

WINE stands for “WINE Is Not an Emulator,” which is a joke that only programmers and free software lovers can get. It's first a play on the recursive acronym for the GNU project (“GNU is not UNIX”). It's also a bit of a political statement for programmers. An emulator is a piece of software that makes one computer act like another. A company named Connectix, for instance, sells an emulator that lets a Macintosh behave like a Windows PC so anyone can use their Windows software on the Mac. Emulators, however, are pretty slow because they're constantly translating information on the fly. Anyone who has tried to hold a conversation with someone who speaks a different language knows how frustrating it can be to require a translator.

The WINE project is an ambitious attempt to knock out one of the most important structural elements of the Microsoft monopoly. Software written for Windows only functions when people buy a version of Windows from Microsoft. When you purchase a Connectix emulator for the Mac, you get a version of Windows bundled with it.

The WINE project is a group of people who are trying to clone Windows. Well, not clone all of it. They just want to clone what is known as the Win32 API, a panoply of features that make it easier to write software for a Microsoft machine. A programmer who wants to create a new button for a Windows computer doesn't need to write all of the instructions for drawing a frame with three-dimensional shading. A Microsoft employee has already bundled those instructions into the Win32 API. There are millions of functions in these kits that help programmers. Some play audio files, others draw complex images or movies. These features make it easy for programmers to write software for Windows because some of the most repetitive work is already finished.

The WINE clone of the Win32 is a fascinating example of how open source starts slowly and picks up steam. Bob Amstadt started the project in 1993, but soon turned it over to Alexandre Julliard, who has been the main force behind it. The project, although still far from finished, has produced some dramatic accomplishments, making it possible to run major programs like Microsoft Word or Microsoft Excel on a Linux box without using Windows. In essence, the WINE software is doing a good enough job acting like Windows that it's fooling Excel and Word. If you can trick the cousins, that's not too bad.

The WINE home page (www.winehq.com) estimates that more than 90,000 people use WINE regularly to run programs for Microsoft Windows without buying Windows. About 140 or more people regularly contribute to the project by writing code or fixing bugs. Many are hobbyists who want the thrill of getting their software to run without Windows, but some are corporate programmers. The corporate programmers want to sell their software to the broadest possible marketplace, but they don't want to take the time to rewrite everything. If they can get their software working well with WINE, then people who use Linux or BSD can use the software that was written for Microsoft Windows.

The new user who wanted to get his RIO player working with his Linux computer soon got a rude awakening. Andreas Mohr, a German programmer, wrote back,

Instead of suggesting the WINE team to “drop everything” in order to get a relatively minor thing like PMP300 to work, would you please install WINE, test it, read documentation/bug reports and post a useful bug report here? There are zillions of very useful and impressing Windoze apps out there . . . (After all that's only my personal opinion, maybe that was a bit too harsh ;-)

Most new free software users soon discover that freedom isn't always easy. If you want to get free software, you're going to have to put in some work. Sometimes you get lucky. The man in Switzerland who posted his note on the same day found out that someone in Britain was solving his problems for him. There was no one, however, working on the RIO software and making sure it worked with WINE.

Mohr's suggestion was to file a bug report that ranks the usability of the software so the programmers working on WINE can tweak it. This is just the first step in the free software experience. Someone has to notice the problem and fix it. In this case, someone needs to hook up their Diamond RIO MP3 player to a Linux box and try to move MP3 files with the software written for Windows. Ideally, the software will work perfectly, and now all Linux users will be able to use RIO players. In reality, there might be problems or glitches. Some of the graphics on the screen might be wrong. The software might not download anything at all. The first step is for someone to test the product and write up a detailed report about what works and what doesn't.

At the time of this writing, no one has stepped up to the plate. There are no reports about the Diamond player in the WINE database. Maybe the new user didn't have time. Maybe he wasn't technically sophisticated enough to get WINE running in the first place. It's still not a simple system to use. In any case, his bright idea fell by the wayside.

The mailing lists buzz with idle chatter about neat, way-out ideas that never come to fruition. Some people see this as a limitation of the free software world. A corporation, however, is able to dispatch a team of programmers to create solutions. These companies have money to spend on polishing a product and making sure it works. Connectix, for instance, makes an emulator that lets Mac users play games written for the Sony PlayStation. The company employs a substantial number of people who simply play all the Sony games from beginning to end until all of the bugs are gone. It's a rough job, but someone has to do it.

WINE can't pay anyone, and that means that great ideas sometimes get ignored. The free software community, however, doesn't necessarily see this as a limitation. If the RIO player were truly important, someone else would come along and pick up the project. Someone else would do the work and file a bug report so everyone could use the software. If there's no one else, then maybe the RIO software isn't that important to the Linux community. Work gets done when someone really cares enough to do it.

These mailing lists are the fibers that link the open source community into the network of minds. Before e-mail, they were just a bunch of rebels haunting the moors and rattling around their basements inventing monstrous machines. Now they're smoothly tuned mechanisms coordinated by messages, notes, and missives. They're not madmen who roar at dinner parties about the bad technology from Borg-like corporations. They've got friends now. One person may be a flake, but a group might be on to something.