- "When your key business processes are executed by opaque blocks of bits that you can’t see inside of (let alone modify), you have lost control of your business."
—Claim of an Open Source Methodology Guru
- "Companies have been using packaged (closed) software, ranging from spreadsheets to ERPs, happily and successfully for decades."
—Counterclaim of an Open Source Doubter
Open source software is one of the most fascinating subjects of our time. People enjoy building software so much that they do it for no pay, and argue that everyone else should (actually, will someday) do the same!
Open source is also a watershed issue. The people who love it, love it with a religious fervor. The people who don’t, sometimes hate it with an equal fervor. Quotes like the two above reverberate through the meeting halls and the literature of the field. A professional journal recently proposed to do a special issue on an open source related topic; the proposal responses of the editorial board members were split directly (and vehemently!) across these watershed lines. Because of that fascination and that vehemence, it is imperative to look more deeply at what open source is all about—I begin with sociology.
Sociology: It’s More Complicated Than You Think
It is common in open source circles to view the participants in the open source movement as willing, independent enthusiasts. But, on deeper analysis, it is evident there is a strange kind of hierarchy in the movement.
First of all, there are the methodology gurus. A very few outspoken participants articulate the movement and its advantages, through their writings and speaking engagements, spreading the gospel of open source.
More significantly, there are also product gurus. Because of the large number of people reading, critiquing, and offering changes to open source products, there is a need for someone to adjudicate among those proposed changes and configure the final agreed-upon version of the product. Linux, for example, has Linus Torvalds, and it would be difficult to imagine the success of the Linux operating system without him. I will discuss a bit further why a product guru is needed in what follows.
Then there are the contributors of open source products. These are the programmers who develop products and release them into the open source product inventory. Some of these contributors, if their products are especially successful, may become product gurus.
The notion of the average user feeling free to change the open source product is a highly mixed blessing, and one unlikely to be frequently exercised.
And finally, there is that great mass of open source code readers. Readers analyze and critique code, find its faults, and propose changes and enhancements. As in many hierarchies, the success of the open source movement is really dependent on these readers at the bottom of the hierarchy. Its claims of reliability and security are—in the end—entirely dependent on the rigor and energy and skill which the readers place in their work.
To understand this hierarchy better, it is necessary to contemplate how it functions when a change or an error fix for a product is proposed. The change moves up the hierarchy to the product guru, who then makes a decision as to whether the change is worthy of inclusion in the product or not. If it is, the change is made and becomes a permanent part of the product.
It is if the change is rejected for inclusion when things can get interesting. Now the reader who identified the change has a dilemma to deal with: either forget about the change, or make that change in a special and different version of the product. This latter is actually considered an option in the open source movement, and there is a verb—to fork—that covers this possibility. The reader who wants his or her change made in a special version is said to have forked the product, and the further development of the product may take place on both of these forks.
But forking is an extremely uncommon thing to do in the open source movement, with good reason. First of all, there is the possibility of loss of commonality. The Unix operating system, for example, is roundly criticized because there are multiple versions of that product, each with its own (often, vendor) advocate, and as a result there is really no such thing as the Unix system any more. That is a serious enough problem to warrant strict attention to whether forking a product is really a good thing.
There is an even stronger reason, however, why forking is uncommon. It has been well known in the software field for over 30 years that making modifications to a standard product is a bad idea. It is a bad idea because, as the product inevitably progresses through many versions each of which includes, usually, desirable changes and modifications, the forked version(s) are left out of that progress. Or, worse yet, the new changes are constantly being added to the forked version (or the forking changes are being added to the new standard version) by the person who created the fork, both of which are highly labor-intensive and error-prone activities.
Now, let’s step back and look at the impact of this forking problem on the field of open source. The claim is frequently made by open source advocates that programmers who find fault with a product are free to make their own fixes to it, and are capable of doing so because they have access to the product’s source code. That’s all well and good if those changes are eventually accepted into the product, but if they are not then the very serious problem of forking arises. Thus the notion of the average user feeling free to change the open source product is a highly mixed blessing, and one unlikely to be frequently exercised.
There is another interesting sociological problem with open source. Again, the claim is frequently made that users can read their code and find and fix its problems. This works just fine if the users are programmers, but if they are not this is simply a technical impossibility. Code reading is a difficult exercise even for the trained programmer, and it is simply not possible, to any meaningful degree, for the non-programmer user. What this means is that only code where programmers are the users is likely to receive the benefits of open source code reading.
And how much code is used by programmers? This is an important question, one for which fortunately there are answers. The largest category of code, according to numerous censuses of programs, is for business applications—payroll, general ledger, and so forth. The next largest category is for scientific/engineering applications. In neither of these cases are the users generally programmers. It is only for the category "systems programs" where, commonly, the users are in fact programmers (operating systems, compilers, programmer support tools). Thus the percentage of software likely to be subject to open source reading is at best quite small.
All of these open source hierarchic sociological conditions are a bit ironic, in the context of some of the claims made for open source. For example, one zealot, in the midst of reciting the benefits of open source and urging people to switch to its use, said "abandon your corporate hierarchies," implying that hierarchies didn’t exist in the open source movement. As we have seen, that claim is specious.
Politics: It’s Getting Ugly Out There
In a sense, the open source movement is analogous to a utopian society. In utopian societies, people tend to believe they are onto something so powerful that it is fundamentally life-transforming, and they are willing to devote themselves wholeheartedly to the utopian movement of their choice. But there’s a problem with nearly all utopian societies. They burn brightly across the horizon for awhile, then flame out. Usually their life spans are measured in decades … certainly not in centuries.
Why do they flame out? The fervor tends to wane. The impractical nature of working for communal accolades alone comes to the fore. And, more often than not, political splintering among the leaders of the movement wreaks havoc among the faithful.
To date, with respect to open source, there is little evidence of the fervor waning, and there is also little indication that the accolade effect is wearing off. There is, to be sure, a bit of political splintering happening. There is one serious fracture in the open source movement, between those who believe in "free" software and those who believe in "open" software (an explanation of the differences is vitally important to those on both sides of the fracture, but of little importance to anyone else studying the movement), but so far, except for public spats in the literature, these differences seem to have had little effect.
The possibility of product forking, as we have already seen, could lead to political splintering as well. But there is no evidence to date that it has done so, and in fact the negative aspects of forking argue that it may not happen. Thus the utopian burnout phenomenon seems a long way from happening to this movement.
However, there are some interesting further political considerations afoot here. Both the open source and proprietary supporters have begun trying to enlist political support to ensure and enhance the future of their approaches.1 For example, one South American country (Peru) has considered a law that would require "free software in public administration," on the grounds that open source is the only way to guarantee local control of the software product (as we have seen here, local control is a dubious promise). And the U.S. Department of Defense is said to have been inundated by requests from proprietary companies like Microsoft to oppose the use of open source code in DoD systems. This kind of thing, ugly at best, may get uglier as time goes on.
So, let’s stand back and look at the sociopolitical aspects of open source. The sociology is well-defined, hierarchic, and an interesting study all by itself. The politics, where perhaps a greater threat to the movement might lie, seems to be pretty much under control, except for some ugly forays into the broader political realm by both advocates and opponents, which may intensify in the future.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment