Computer programmers love Star Wars. So it should be no surprise that practically every single member of the free source community has, at one time or another, rolled out the phrase, “Use the Source, Luke.” It does a perfect job of capturing the mythical faith that the free source world places in the ability to access the source code to a program. As everyone points out, in the original version of Star Wars, the rebel troops used the plans, the Source, to the Death Star carried in R2D2 to look for weaknesses.
The free source realm has been pushing the parallels for some time now. When AT&T unveiled their round logo with an offset dimple, most free source people began to snicker. The company that began the free software revolution by pushing its intellectual property rights and annoying Richard Stallman had chosen a logo that looked just like the Death Star. Everyone said, “Imperialist minds think alike.” Some even wondered and hoped that George Lucas would sue AT&T for some sort of look-and-feel, trademark infringement. Those who use the legal intimidation light saber should die by the legal intimidation light saber.
Of course, the free source folks knew that only their loose coalition of rebels spread out around the galaxy would be a strong match for the Empire. The Source was information, and information was power. The Source was also about freedom, one of the best and most consistent reservoirs of revolutionary inspiration around. The rebels might not have teams of lawyers in imperial star cruisers, but they hoped to use the Source to knit together a strong, effective, and more powerful resistance.
The myth of open access to free source code is a powerful one that has made true believers out of many in the community. The source code is a list of instructions for the computer written out in a programming lan guage that is understandable by humans. Once the compilers converted the source code into the string of bits known as the binary or object code, only computers (and some very talented humans) could understand the instructions. I've known several people who could read 8080 binary code by eye, but they're a bit different from the general population.
When companies tried to keep their hard work and research secret by locking up the source code, they built a barrier between the users and their developers. The programmers would work behind secret walls to write the source code. After compilers turned the Source into something that computers could read, the Source would be locked up again. The purchasers would only get the binary code because that's all the companies thought the consumers needed. The source code needed to be kept secret because someone might steal the ideas inside and create their own version.
Stallman saw this secrecy as a great crime. Computer users should be able to share the source code so they can share ways to make it better. This trade should lead to more information-trading in a great feedback loop. Some folks even used the word “bloom” to describe the explosion of interest and cross-feedback. They're using the word the way biologists use it to describe the way algae can just burst into existence, overwhelming a region of the ocean. Clever insights, brilliant bug fixes, and wonderful new features just appear out of nowhere as human curiosity is amplified by human generosity in a grand explosion of intellectual synergy. The only thing missing from the picture is a bunch of furry Ewoks dancing around a campfire.
Eric Raymond, a man who is sort of the armchair philosopher of the open source world, did a great job of summarizing the phenomenon and creating this myth in his essay “The Cathedral and the Bazaar.” Raymond is an earnest programmer who spent some time working on projects like Stallman's GNU Emacs. He saw the advantages of open source development early, perhaps because he's a hard-core libertarian. Government solutions are cumbersome. Empowering individuals by not restraining them is great. Raymond comes off as a bit more extreme than other libertarians, in part because he doesn't hesitate to defend the second amendment of the U.S. Constitution as much as the first. Raymond is not ashamed to support widespread gun ownership as a way to further empower the individual. He dislikes the National Rifle Association because they're too willing to compromise away rights that he feels are absolute.
Some people like to call him the Margaret Mead of the free source world because he spent some time studying and characterizing the culture in much the same way that Mead did when she wrote Coming of Age in Samoa. This can be a subtle jab because Margaret Mead is not really the same intellectual angel she was long ago. Derek Freeman and other anthropologists raise serious questions about Mead's ability to see without bias. Mead was a big fan of free love, and many contend it was no accident that she found wonderful tales of unchecked sexuality in Samoa. Freeman revisited Samoa and found it was not the guilt-free land of libertine pleasures that Mead described in her book. He documented many examples of sexual restraint and shame that Mead apparently missed in her search for a paradise.
Raymond looked at open source development and found what he wanted to find: the wonderful efficiency of unregulated markets. Sure, some folks loved to label Richard Stallman a communist, a description that has always annoyed Stallman. Raymond looked a bit deeper and saw that the basis of the free software movement's success was the freedom that gave each user the complete power to change and improve their software. Just as Sigmund Freud found sex at the root of everything and Carl Jung uncovered a battle of animus and anima, the libertarian found freedom.
Raymond's essay was one of the first to try to explain why free source efforts can succeed and even prosper without the financial incentives of a standard money-based software company. One of the biggest reasons he cited was that a programmer could “scratch an itch” that bothered him. That is, a programmer might grow annoyed by a piece of software that limited his choices or had an annoying glitch. Instead of cursing the darkness in the brain cavity of the corporate programmer who created the problem, the free source hacker was able to use the Source to try to find the bug.
Itch-scratching can be instrumental in solving many problems. Some bugs in software are quite hard to identify and duplicate. They only occur in strange situations, like when the printer is out of paper and the modem is overloaded by a long file that is coming over the Internet. Then, and only then, the two buffers may fill to the brim, bump into each other, and crash the computer. The rest of the time, the program floats along happily, encountering no problems.
These types of bugs are notoriously hard for corporate testing environments to discover and characterize. The companies try to be diligent by hiring several young programmers and placing them in a room with a computer. The team beats on the software all day long and develops a healthy animosity toward the programming team that has to fix the problems they discover. They can nab many simple bugs, but what happens if they don't have a printer hooked up to their machine? What happens if they aren't constantly printing out things the way some office users are? The weird bug goes unnoticed and probably unfixed.
The corporate development model tries to solve this limitation by shipping hundreds, thousands, and often hundreds of thousands of copies to ambitious users they called “beta testers.” Others called them “suckers” or “free volunteers” because once they finish helping develop the software, they get to pay for it. Microsoft even charges some users for the pleasure of being beta testers. Many of the users are pragmatic. They often have no choice but to participate in the scheme because they often base their businesses on some of the software shipped by these companies. If it didn't work, they would be out of a job.
While this broad distribution of beta copies is much more likely to find someone who is printing and overloading a modem at the same time, it doesn't give the user the tools to help find the problem. Their only choice is to write an e-mail message to the company saying “I was printing yesterday and your software crashed.” That isn't very helpful for the engineer, and it's no surprise that many of these reports are either ignored or unsolved.
Raymond pointed out that the free source world can do a great job with these nasty bugs. He characterized this with the phrase, “Given enough eyeballs, all bugs are shallow,” which he characterized as “Linus's Law.” That is, eventually some programmer would start printing and using the Internet at the same time. After the system crashed a few times, some programmer would care enough about the problem to dig into the free source, poke around, and spot the problem. Eventually somebody would come along with the time and the energy and the commitment to diagnose the problem. Raymond named this “Linus's Law” after Linus Torvalds. Raymond is a great admirer of Torvalds and thinks that Torvalds's true genius was organizing an army to work on Linux. The coding itself was a distant second.
Of course, waiting for a user to find the bugs depended on there being someone with enough time and commitment. Most users aren't talented programmers, and most have day jobs. Raymond and the rest of the free source community acknowledge this limitation, but point out that the right person often comes along if the bug occurs often enough to be a real problem. If the bug is serious enough, a non-programmer may even hire a programmer to poke into the source code.
Waiting for the bug and the programmer to find each other is like waiting for Arthur to find the sword in the stone. But Raymond and the rest of the free source community have even turned this limitation on its head and touted it as an advantage. Relying on users to scratch itches means that problems only get addressed if they have real constituencies with a big enough population to generate the one true believer with enough time on his hands. It's sort of a free market in people's time for fixing bugs. If the demand is there, the solution will be created. It's Say's Law recast for software development: “the supply of bugs creates the talent for fixes.”
Corporate development, on the other hand, has long been obsessed with adding more and more features to programs to give people enough reason to buy the upgrade. Managers have long known that it's better to put more time into adding more doohickeys and widgets to a program than into fixing its bugs. That's why Microsoft Word can do so many different things with the headers and footers of documents but can't stop a Word Macro virus from reproducing. The folks at Microsoft know that when the corporate managers sit down to decide whether to spend the thousands of dollars to upgrade their machines, they'll need a set of new compelling features. People don't like to pay for bug fixes.
Of course, corporations also have some advantages. Money makes sure that someone is actively trying to solve the bugs in the program. The same free market vision guarantees that the companies that consistently disappoint their customers will go out of business. This developer has the advantage of studying the same source code day in and day out. Eventually he'll learn enough about the guts of the Source to be much more effective than the guy with the jammed printer and modem. He should be able to nab the bug 10 times more quickly then the free source hobbyist just because he's an expert in the system.
Raymond acknowledges this problem but proposes that the free source model can still be more effective despite the inexperience of the people who are forced to scratch an itch. Again he taps the world of libertarian philosophy and suggests that the free software world is like a bazaar filled with many different merchants offering their wares. Corporate development, on the other hand, is structured like the religious syndicates that built the medieval cathedrals. The bazaars offered plenty of competition but no order. The cathedrals were run by central teams of priests who tapped the wealth of the town to build the vision of one architect.
The differences between the two were pretty simple. The cathedral team could produce a great work of art if the architect was talented, the funding team was successful, and the management was able to keep everyone focused on doing their jobs. If not, it never got that far. The bazaar, on the other hand, consisted of many small merchants trying to outstrip each other. The best cooks ended up with the most customers. The others soon went out of business.
The comparison to software was simple. Corporations gathered the tithes, employed a central architect with a grand vision, managed the team of programmers, and shipped a product every once and a bit. The Linux world, however, let everyone touch the Source. People would try to fix things or add new features. The best solutions would be adopted by oth ers and the mediocre would fall by the wayside. Many different Linux versions would proliferate, but over time the marketplace of software would coalesce around the best standard version.
“In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you've winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect,” Raymond said.
“In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena--or, at least, that they turn shallow pretty quick when exposed to a thousand eager code-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door.”
This bazaar can be a powerful influence on solving problems. Sure, it isn't guided by a talented architect and teams of priests, but it is a great free-for-all. It is quite unlikely, for instance, that the guy with the overloaded printer and modem line will also be a talented programmer with a grand vision to solve the problem. Someone named Arthur only stumbles across the right stone with the right sword every once and a bit. But if the frustrated user can do a good job characterizing it and reporting it, then someone else can solve it.
Dave Hitz was one of the programmers who helped Keith Bostic rewrite UNIX so it could be free of AT&T's copyright. Today, he runs Network Appliance, a company that builds stripped-down file servers that run BSD at their core. He's been writing file systems ever since college, and the free software came in quite handy when he was starting his company. When they started building the big machines, the engineers just reached into the pool of free source code for operating systems and pulled out much of the code that would power his servers. They modified the code heavily, but the body of free software that he helped create was a great starting point.
In his experience, many people would find a bug and patch it with a solution that was good enough for them. Some were just kids in college. Others were programmers who didn't have the time or the energy to read the Source and understand the best way to fix the problem. Some fixed the problem for themselves, but inadvertently created another problem elsewhere. Sorting through all of these problems was hard to do.
But Hitz says, “Even if they fixed it entirely the wrong way, if they found the place where the problem went away, then they put a giant arrow on the problem.” Eventually, enough arrows would provide someone with enough information to solve the problem correctly. Many of the new versions written by people may be lost to time, but that doesn't mean that they didn't have an important effect on the evolution of the Source.
“I think it's rarely the case that you get people who make a broad base of source code their life,” he said. “There are just a whole bunch of people who are dilettantes. The message is, 'Don't underestimate the dilettantes.'”
When Raymond wrote the essay, he was just trying to suss out the differences between several of the camps in the free source world. He noticed that people running free source projects had different ways of sharing. He wanted to explain which free source development method worked better than others. It was only later that the essay began to take on a more serious target when everyone began to realize that Microsoft was perhaps the biggest cathedral-like development team around.
Raymond said, “I think that like everyone else in the culture I wandered back and forth between the two modes as it seemed appropriate because I didn't have a theory or any consciousness.”
He saw Richard Stallman and the early years of the GNU projects as an example of cathedral-style development. These teams would often labor for months if not years before sharing their tools with the world. Raymond himself said he behaved the same way with some of the early tools that he wrote and contributed to the GNU project.
Linus Torvalds changed his mind by increasing the speed of sharing, which Raymond characterized as the rule of “release early and often, delegate everything you can, be open to the point of promiscuity.” Torvalds ran Linux as openly as possible, and this eventually attracted some good contributors. In the past, the FSF was much more careful about what it embraced and brought into the GNU project. Torvalds took many things into his distributions and they mutated as often as daily. Occasionally, new versions came out twice a day.
Of course, Stallman and Raymond have had tussles in the past. Raymond is careful to praise the man and say he values his friendship, but also tempers it by saying that Stallman is difficult to work with.
In Raymond's case, he says that he once wanted to rewrite much of the Lisp code that was built into GNU Emacs. Stallman's Emacs allowed any user to hook up their own software into Emacs by writing it in a special version of Lisp. Some had written mail readers. Others had added automatic comment-generating code. All of this was written in Lisp.
Raymond says that in 1992, “The Lisp libraries were in bad shape in a number of ways. They were poorly documented. There was a lot of work that had gone on outside the FSF and I wanted to tackle that project.”
According to Raymond, Stallman didn't want him to do the work and refused to build it into the distribution. Stallman could do this because he controlled the Free Software Foundation and the distribution of the software. Raymond could have created his own version, but refused because it was too complicated and ultimately bad for everyone if two versions emerged.
For his part, Stallman explains that he was glad to accept parts of Raymond's work, but he didn't want to be forced into accepting them all. Stallman says, "Actually, I accepted a substantial amount of work that Eric had done. He had a number of ideas I liked, but he also had some ideas I thought were mistaken. I was happy to accept his help, as long as I could judge his ideas one by one, accepting some and declining some.
“But subsequently he asked me to make a blanket arrangement in which he would take over the development of a large part of Emacs, operating independently. I felt I should continue to judge his ideas individually, so I said no.”
Raymond mixed this experience with his time watching Torvalds's team push the Linux kernel and used them as the basis for his essay on distributing the Source. “Mostly I was trying to pull some factors that I had observed as unconscious folklore so people could take them out and reason about them,” he said.
Raymond says, “Somebody pointed out that there's a parallel of politics. Rigid political and social institutions tend to change violently if they change at all, while ones with more play in them tend to change peacefully.”
There is a good empirical reason for the faith in the strength of free source. After all, a group of folks who rarely saw each other had assembled a great pile of source code that was kicking Microsoft's butt in some corners of the computer world. Linux servers were common on the Internet and growing more common every day. The desktop was waiting to be conquered. They had done this without stock options, without corporate jets, without secret contracts, and without potentially illegal alliances with computer manufacturers. The success of the software from the GNU and Linux world was really quite impressive.
Of course, myths can be taken too far. Programming computers is hard work and often frustrating. Sharing the source code doesn't make bugs or problems go away--it just makes it a bit easier for someone else to dig into a program to see what's going wrong. The source code may just be a list of instructions written in a programming language that is designed to be readable by humans, but that doesn't mean that it is easy to understand. In fact, most humans won't figure out most source code because programming languages are designed to be understood by other programmers, not the general population.
To make matters worse, programmers themselves have a hard time understanding source code. Computer programs are often quite complicated and it can take days, weeks, and even months to understand what a strange piece of source code is telling a computer to do. Learning what is happening in a program can be a complicated job for even the best programmers, and it is not something that is taken lightly.
While many programmers and members of the open source world are quick to praise the movement, they will also be able to cite problems with the myth of the Source. It isn't that the Source doesn't work, they'll say, it's just that it rarely works anywhere near as well as the hype implies. The blooms are rarely as vigorous and the free markets in improvements are rarely as liquid.
Larry McVoy, an avid programmer, proto-academic, and developer of the BitKeeper toolkit, likes to find fault with the model. It isn't that he doesn't like sharing source code, it's just that he isn't wealthy enough to take on free software projects. “We need to find a way for people to develop free software and pay their mortgages and raise a family,” he says.
“If you look closely,” he says, “there really isn't a bazaar. At the top it's always a one-person cathedral. It's either Linus, Stallman, or someone else.” That is, the myth of a bazaar as a wide-open, free-for-all of competition isn't exactly true. Sure, everyone can download the source code, diddle with it, and make suggestions, but at the end of the day it matters what Torvalds, Stallman, or someone else says. There is always a great architect of Chartres lording it over his domain.
Part of this problem is the success of Raymond's metaphor. He said he just wanted to give the community some tools to understand the success of Linux and reason about it. But his two visions of a cathedral and a bazaar had such a clarity that people concentrated more on dividing the world into cathedrals and bazaars. In reality, there's a great deal of blending in between. The most efficient bazaars today are the suburban malls that have one management company building the site, leasing the stores, and creating a unified experience. Downtown shopping areas often failed because there was always one shop owner who could ruin an entire block by putting in a store that sold pornography. On the other side, religion has always been something of a bazaar. Martin Luther effectively split apart Christianity by introducing competition. Even within denominations, different parishes fight for the hearts and souls of people.
The same blurring holds true for the world of open source software. The Linux kernel, for instance, contains many thousands of lines of source code. Some put the number at 500,000. A few talented folks like Alan Cox or Linus Torvalds know all of it, but most are only familiar with the corners of it that they need to know. These folks, who may number in the thousands, are far outnumbered by the millions who use the Linux OS daily.
It's interesting to wonder if the ratio of technically anointed to blithe users in the free source world is comparable to the ratio in Microsoft's dominion. After all, Microsoft will share its source code with close partners after they sign some non-disclosure forms.
Answering this question is impossible for two different reasons. First, no one knows what Microsoft reveals to its partners because it keeps all of this information secret, by reflex. Contracts are usually negotiated under non-disclosure, and the company has not been shy about exploiting the power that comes from the lack of information.
Second, no one really knows who reads the Linux source code for the opposite reason. The GNU/Linux source is widely available and frequently downloaded, but that doesn't mean it's read or studied. The Red Hat CDs come with one CD full of pre-compiled binaries and the second full of source code. Who knows whoever pops the second CDROM in their computer? Everyone is free to do so in the privacy of their own cubicle, so no records are kept.
If I were to bet, I would guess that the ratios of cognoscenti to uninformed users in the Linux and Microsoft worlds are pretty close. Reading the Source just takes too much time and too much effort for many in the Linux world to take advantage of the huge river of information available to them.
If this is true or at least close to true, then why has the free source world been able to move so much more quickly than the Microsoft world? The answer isn't that everyone in the free source world is using the Source, it's that everyone is free to use it. When one person needs to ask a question or scratch an itch, the Source is available with no questions asked and no lawyers consulted. Even at 3:00 A.M., a person can read the Source. At Microsoft and other corporations, they often need to wait for the person running that division or section to give them permission to access the source code.
There are other advantages. The free source world spends a large amount of time keeping the source code clean and accessible. A programmer who tries to get away with sloppy workmanship and bad documentation will pay for it later as others come along and ask thousands of questions.
Corporate developers, on the other hand, have layers of secrecy and bureaucracy to isolate them from questions and comments. It is often hard to find the right programmer in the rabbit warren of cubicles who has the source code in the first place. One Microsoft programmer was quoted as saying, “A developer at Microsoft working on the OS can't scratch an itch he's got with Excel, neither can the Excel developer scratch his itch with the OS--it would take him months to figure out how to build and debug and install, and he probably couldn't get proper source access anyway.”
This problem is endemic to corporations. The customers are buying the binary version, not the source code, so there is no reason to dress up the backstage wings of the theater. After some time, though, people change cubicles, move to other corporations, and information disappears. While companies try to keep source code databases to synchronize development, the efforts often fall apart. After Apple canceled development of their Newton handheld, many Newton users were livid. They had based big projects on the platform and they didn't want to restart their work. Many asked whether Apple could simply give away the OS's source code instead of leaving it to rot on some hard disk. Apple dodged these requests, and this made some people even more cynical. One outside developer speculated, “It probably would not be possible to re-create the OS. The developers are all gone. All of them went to Palm, and they probably couldn't just put it back together again if they wanted to.”
Of course, corporations try to fight this rot by getting their programmers to do a good job at the beginning and write plenty of documentation. In practice, this slips a bit because it is not rewarded by the culture of secrecy. I know one programmer who worked for a project at MIT. The boss thought he was being clever by requiring comments on each procedure and actually enforcing it with an automated text-scanning robot that would look over the source code and count the comments. My friend turned around and hooked up one version of the popular artificial intelligence chatterbots like Eliza and funneled the responses into the comment field. Then everyone was happy. The chatterbot filled the comment field, the automated comment police found something vaguely intelligent, and the programmer got to spend his free time doing other things. The boss never discovered the problem.
Programmers are the same the world over, and joining the free source world doesn't make them better people or destroy their impudence. But it does penalize them if others come along and try to use their code. If it's inscrutable, sloppy, or hard to understand, then others will either ignore it or pummel them with questions. That is a strong incentive to do it right.
The limitations to the power of open source might be summarized in the answer to the question “How many open source developers does it take to change a lightbulb?” The answer is: 17. Seventeen to argue about the license; 17 to argue about the brain-deadedness of the lightbulb architecture; 17 to argue about a new model that encompasses all models of illumination and makes it simple to replace candles, campfires, pilot lights, and skylights with the same easy-to-extend mechanism; 17 to speculate about the secretive industrial conspiracy that ensures that lightbulbs will burn out frequently; 1 to finally change the bulb; and 16 who decide that this solution is good enough for the time being.
The open source development model is a great way for very creative people to produce fascinating software that breaks paradigms and establishes new standards for excellence. It may not be the best way, however, to finish boring jobs like fine-tuning a graphical interface, or making sure that the scheduling software used by executives is as bulletproof as possible.
While the open development model has successfully tackled the problem of creating some great tools, of building a strong OS, and of building very flexible appliance applications like web browsers, it is a long way from winning the battle for the desktop. Some free source people say the desktop applications for average users are just around the corner and the next stop on the Free Software Express. Others aren't so sure.
David Henkel-Wallace is one of the founders of the free software company Cygnus. This company built its success around supporting the development tools created by Stallman's Free Software Foundation. They would sign contracts with companies to answer any questions they had about using the free software tools. At first companies would balk at paying for support until they realized that it was cheaper than hiring in-house technical staff to do the work. John Gilmore, one of the cofounders, liked to say, “We make free software affordable.”
The company grew by helping chip manufacturers tune the FSF compiler, GCC, for their chip. This was often a difficult and arduous task, but it was very valuable to the chip manufacturer because potential customers knew they could get a good compiler to produce software for the chip. While Intel continued to dominate the desktop, the market for embedded chips to go into products like stoves, microwave ovens, VCRs, or other smart boxes boomed as manufacturers rolled out new chips to make it cheaper and easier to add smart features to formerly dumb boxes. The engineers at the companies were often thrilled to discover that they could continue to use GCC to write software for a new chip, and this made it easier to sell the chip.
Cygnus always distributed to the Source their modifications to GCC as the GNU General Public License demanded. This wasn't a big deal because the chip manufacturers wanted the software to be free and easy for everyone to use. This made Cygnus one of the clearing-houses for much of the information on how GCC worked and how to make it faster.
Henkel-Wallace is quick to praise the power of publicly available source code for Cygnus's customers. They were all programmers, after all. If they saw something they didn't like with GCC, they knew how to poke around on the insides and fix it. That was their job.
“[GCC] is a compiler tool and it was used by developers so they were smart enough. When something bothered someone, we fixed it. There was a very tight coupling,” he said.
He openly wonders, though, whether the average word processor or basic tool user will be able to do anything. He says, “The downside is that it's hard to transfer that knowledge with a user who isn't a developer. Let's say Quicken has a special feature for lawyers. You need to have a more formal model because the lawyers aren't developers. (We're fortunate in that regard.)”
That is, lawyers aren't schooled enough in the guts of computer development to complain in the right way. A programmer could say, “GCC is optimizing away too much dead code that isn't really dead.” Other folks in the GCC community would know what is going on and be able to fix it. A lawyer might just say, “Quicken screwed up my billing and had me billing twenty-six hours in a day.” This wouldn't pinpoint the problem enough for people to solve it. The lawyer doesn't understand the inside of the software like the programmer.
In situations like this, Henkel-Wallace believes that a corporate-style team may be the only one that can study the problems thoroughly enough to find solutions. Intuit, the manufacturer of Quicken, is well known for videotaping many standard users who use their product for the first time. This allows them to pinpoint rough spots in the program and identify places where it could be improved. This relentless smoothing and polishing has made the product one of the best-known and widely used tools on desktops. It isn't clear that non-programmers could have accomplished the same quality by working together with the Source at their disposal.
There are deeper, more philosophical currents to the open source world. The personal computer industry is only a few decades old. While it has advanced rapidly and solved many problems, there is still very little understanding of the field and what it takes to make a computer easy to use. This has been the great struggle, and the free source world may be an essential part of this trip.
Tim O'Reilly, the publisher of many books and a vocal proponent of the open source world, says, “We've gone through this period of thinking of programs as artifacts. A binary object is a thing. Open source is part of thinking of computers as a process.” In other words, we've done a good job of creating computers you can buy off the shelf and software that can be bought in shrink-wrapped boxes, but we haven't done a good job of making it possible for people to talk to the machines.
To a large extent, the process has been a search for a good language to use to communicate with the computer. Most of the recent development followed the work at Xerox PARC that created some of the first graphical user interfaces. Apple followed their lead and Microsoft followed Apple. Each bought into the notion that creating a neat picture representing the files on a screen would make a neat metaphor that could make it easier for people to interact with the computers. Dragging a file to the trash was somehow easier for people to do than typing a cryptic command like “rm.”
In the 1980s, that sort of graphical thinking was considered brilliant. Pictures were prettier than words, so it was easy to look at the clean, pretty Macintosh screen and think it was easier to use just because it was easier to look at.
But the pretty features merely hid a massive amount of complexity, and it was still hard to work with the machines. Don Norman, a human/computer interface engineer at Apple, once wrote a fascinating discussion of the company's design of their computer's on-off switch. He pointed out that the switch couldn't be a simple power switch that could cut the power on and off because the computer needed to orchestrate the start-up and shutdown procedure. It needed to close up files, store data safely, and make sure everything was ready to start up again.
The design of the power switch was made even more complicated by the fact that it was supposed to work even when the computer crashed. That is, if bad programming jumbles the memory and screws up the central processor, the power switch is still supposed to shut down the machine. Of course, the computer couldn't even add two numbers together after it crashed, so it couldn't even begin to move through all the clerical work necessary to shut down the machine. The Macintosh on which I wrote this book can crash so badly that the power switch doesn't work, and I can only reset it by sticking a paper clip into a hidden hole.
Norman's work shows how hard it can be to come up with a simple language that allows humans and computers to communicate about a task that used to be solved with a two-position light switch. This problem can be seen throughout the industry. One computer tutor told me, “I am so tired of telling people to shut down their computers by pushing the 'Start' button.” Microsoft Windows places all of the features on a menu tree that grows out of one button labeled “Start.” This may have been a great way to capture the potential to do new things that they felt they were selling, but it continues to be confusing to all new users of the machines. Why should they push start to stop it?
The quest for this Source-level control can take many strange turns. By the middle of the 1980s, programmers at Apple realized that they had gone a bit too far when they simplified the Mac's interface. The visual language of pointing and clicking at icons may have been great for new users, but it was beginning to thwart sophisticated users who wanted to automate what they did. Many graphics designers would find themselves repeatedly doing the same steps to image files, and it was boring. They wondered, why couldn't the computer just repeat all their instructions and save them all that pointing and clicking?
In a sense, the sophisticated Mac users were looking for the Source. They wanted to be able to write and modify simple programs that controlled their software. The problem was that the graphical display on the Mac wasn't really suited to the task. How do you describe moving the mouse and clicking on a button? How do you come up with a language that means “cut out this sample and paste it over here”? The actions were so visual that there weren't any words or language to describe them.
This problem confounded Apple for the next 10 years, and the company is slowly finishing its solution, known as AppleScript. The task has not been simple, but it has been rewarding for many who use their Macintoshes as important chains in data production lines. Apple included instructions for moving icons to locations, uploading files, changing the color of icons, and starting up programs with others.
The nicest extension was a trick that made the AppleScript “recordable.” That is, you could turn on a recorder before stepping through the different jobs. The Mac would keep track of your actions and generate a program that would allow you to repeat what you were doing. Still, the results were far from simple to understand or use. Here's a simple snippet of AppleScript code that will select all files in one directory with the word “Speckle” in their title and open them up with another application:
tell application "Finder"
set theFiles to every file in folder (rootPlus) whose
name contains "Speckle"
with timeout of 600 seconds
repeat with aFile in theFiles
open (aFile) using (file "Macintosh HD: Make
GIF (16 colors, Web)")
end repeat
end timeout
end tell
This Source can then be run again and again to finish a task. Making this tool available to users has been a challenge for Apple because it forces them to make programming easier. Many people learn AppleScript by turning on the recording feature and watching what happens when they do what they would normally do. Then they learn how to insert a few more commands to accomplish the task successfully. In the end, they become programmers manipulating the Source without realizing it.
O'Reilly and others believe that the open source effort is just an extension of this need. As computers become more and more complex, the developers need to make the internal workings more and more open to users. This is the only way users can solve their problems and use the computers effectively.
“The cutting edge of the computer industry is in infoware. There's not all that much juice in the kind of apps we wrote in the eighties and nineties. As we get speech recognition, we'll go even more in the direction of open source,” he says.
“There are more and more recipes that are written down. These are going to migrate into lower and lower layers of software and the computer is going to get a bigger and bigger vocabulary.”
That is, more and more of the Source is going to need to become transparent to the users. It's not just a political battle of Microsoft versus the world. It's not just a programmer's struggle to poke a nose into every corner of a device. It's about usability. More and more people need to write programs to teach computers to do what they need to do. Access to the Source is the only way to accomplish it.
In other words, computers are becoming a bigger and bigger part of our lives. Their language is becoming more readily understandable by humans, and humans are doing a better job of speaking the language of computers. We're converging. The more we do so, the more important the Source will be. There's nothing that Microsoft or corporate America can do about this. They're going to have to go along. They're going to have to give us access to the Source.
License: Free For All is Licensed under a Creative Commons License. This License permits non-commercial use of this work, so long as attribution is given. For more information about the license, visit https://creativecommons.org/licenses/by-nc/1.0/
≅ SiSU Spine ፨ (object numbering & object search)
(web 1993, object numbering 1997, object search 2002 ...) 2024