Open Source Software: Some Assembly Required
Something that sounds too good to be true probably is, at least in its pure form. The rest might be successfully exploited if we know the limitations as well as the strengths.
Open source software gets a lot of favorable press, not least because it’s free and, presumably, pure as distinct from crass commercial software. And as everyone knows, it’s hard to compete with free. Open source has deep roots in the academic community, where it probably would have remained sterile and ignored if the PC revolution of the 1970s hadn’t occurred. It’s one thing to safely shake fists at a protected data center with raised floors and man traps deep in the bowels of a typically very large building, but quite another when access to a computer is unconstrained. After all, information wants to be free, and who better to foster that freedom than nascent Magister Ludis.
The history of open source software is one of many very small beginnings, often of an individual having some programming skills who does something interesting, at least to them. As a result, the sheer amount of open source software that is available is quite amazing. Most of them have colorful and unusual, if not very descriptive, names. Consequently, finding one for a specific or particular task usually takes a while, as one and then another is examined in various ways. This time can be shortened considerably by asking a friend or colleague for their opinion or recommendation, but there’s always a risk involved. These are free, meaning there’s no support, no marketing material, no success stories published in major trade literature, in short no infrastructure that is a requirement of any business that sells commercial software.
Writing computer programs is much like writing a book: there is no one right way, but there are a lot of wrong ways. Anyone can write a thesis or dissertation on this or that, but not many can write a computer program that works well, is reliable, and meets a very specific and real need. After all, if it were that easy to write a good computer program, then the high tech industry would be very different from what it is in fact.
It takes discipline, organization, teamwork and focus to develop good computer programs, traits that are not particularly abundant in academic circles. They are required of any business that want to stay in business, which is another way of saying that they know who their customers are and know how to provide value to those customers. Certainly most, and arguably all, open source advocates aren’t too interested in the needs and desires of externalities such as customers, and don’t demonstrate value recognition when what they have has no value: it’s free, after all.
As most people know, there are no free lunches, another way of saying that the Laws of Thermodynamics haven’t been repealed for those with academic inclinations. The source code may be free, but making it useful certainly is not. Some of open source costs are hidden and can be a big surprise.
Any tool, be it a shovel or the program code for, say, google’s search engine, has a life, a beginning, usually a long middle, and an end, with costs for each period accruing over time. The sum of all these costs is called the TCO, or Total Cost of Ownership. In the case of open source, the acquisition cost is essentially zero – downloading a file containing all the various pieces of the open source program.
Unlike most physical tools, computer programs evolve over time, because the requirements that there were initially built for evolve as markets and business practices change.
Whatever the open source program is, it does not work out of the box: It needs some changes to become useful. These changes incorporate and embody the requirements and practices that differentiate the user, either an individual or a business, from all other individuals and businesses. These changes are seldom superficial, but deep in the program code itself, to such an extent that they are fundamental. This makes the changed program unique, which a number of interesting, and sometimes exciting, consequences.
The first noticeable consequence arises when a new program change is needed to meet a new business requirement. Previous changes are seldom documented, and sooner or later the person who made them moves on to bigger and better things. Whomever is implementing the next change does not know the assumptions, requirements, architecture, etc., that informed the previous changes, and sooner or later the new changes do something that counters the previous ones, often in subtle ways. At some point, the existing program code has little resemblance to the original program code, and whatever support base there may have been for the original is no longer applicable. The net effect of this is that the pool of individuals who have expertise of the original open source program shrinks, often dramatically, which in turn leads to increased maintenance costs, diminished reliability, and not least increased resistance to further changes.
Another consequence has roots in the open source movement’s misty past. And though it is ancient history, it can project itself into the present with amazing force. This timeshifter is the license by which the open source can be distributed and used. And that use includes and encompasses changes that are considered part of the open source itself, which according to the license should be disclosed in their entirety. So any and all can get a copy for free, in return for fully disclosing changes, including maintenance, for free to any and all. This is probably not a problem for individuals who may be more interested in bragging rights, than demonstrating a positive, and high, return on investment.
Tags: computer programming, open source