Kyle Dickerson

3/21/06

“You Just Don't Understand”

or

Why Open Source Baffles the Traditional Software Industry

Open Source Software (OSS) is complex in almost every aspect of its existence: the process of its creation, the motivations of the creators, how to create a business around it, even the technical success of the code that is written. This inherent complexity is why OSS works to begin with, but it is also why traditional software companies don't understand why OSS is so successful. The many aspects of OSS are not only complex, but fundamentally different than the software created by companies that use a closed source development model. This paper will analyze some of the most important aspects of OSS, how it differs from traditional models, and attempt to determine what these differences mean for the future of the software industry.

Any organization is only as good as the people that it is comprised of. A traditional software company can easily distinguish the many programmers, testers, teams, and managers, as well as their motivation for working. It's really quite a simple relationship. An individual is looking for a job, and applies for an opening at the company, he or she then is conducted through a hiring process and the company decides to either hire them, or not. If hired, then the individual is expected to do some work for some monetary compensation. If the work is not accomplished as agreed, the individual is generally fired, and the company begins looking for another employee. Each entity in the relationship (the company and the individual) knows their role. The employee is to do the work, and the company is to pay for that work. The motivation, therefore, of the employee is to make money. It is also likely that the motivation of the company as a whole is to make money as well. As any individual does, the employee would like to maximize their compensation per unit effort. In an environment where the compensation is monetary, this would mean the employee will try to get the most money for the least effort. In some work environments this translates to doing just enough work to not be fired.

If we were to apply Paul Hedengren's theory of values to the situation we would see that for employees in this situation, writing software is a derivative value in their personal valuation system. That is the software is written as a means to an end, the employee writes the software in order to obtain monetary compensation. This monetary compensation is, in turn, also a derivative value, for it is usually used to buy things that the individual needs or wants. These things being purchased could also be derivative values, or they could be fundamental values. A fundamental value is something which is valued for no explicable reason, merely because it is what it is. For example, joy is a fundamental value, it is not possible to explain why we want to have joy, we want it simply for what it is.

Individuals that create OSS, however, are generally not being compensated monetarily. Their motivations lie elsewhere, somewhere that is usually many steps closer to their fundamental values. Many create software out of the sheer joy of creation. Others may do it because they want to help others, or perhaps they simply believe that people should be able to do what they want with their software and so should have access to the source code. It could also be more complicated than any of these suggestions and may even involve some antipathy towards an established company.

The relationship is no longer as simple as employer / employee. It is now a relationship between an individual and a community. The individual submits code or software to a community, which either accepts or rejects the contribution. The process of accepting or rejecting the code is a matter of the organization of the community to which it is contributed to. Unlike traditional commercial companies which are organized hierarchically with the power at the top, OSS projects don't have a standard organization, but they tend to have a similar type of organization. There is usually a governing body, which is supported by an “Inner Circle” that acts as the mediators between the community at large and the governing body. While this may seem like any other hierarchical structure, the difference is that the true power is held at the edges by the community at large. The community allows the governing body to make decisions in order to maintain focus for the project; but if the persons in charge upset the community, they can be removed, and others will be found to take their place. There is also the unique occurrence of 'forking' that plays a role is the structure of the community. If there is a irreconcilable division of thought in the community, then a fork (or split) might occur. The community will splinter and become two separate entities, and a new governing body will be created for the new entity. This process might be compared to mitosis in a biological cell.

The hierarchy of a traditional company, however, places the power at the top. The two structures might be thought of as a set of concentric circles as opposed to a pyramid. If the employees at the bottom of the pyramid become upset with the governing body, then there is not much that can happen. They might decide to find a new job, but they really can't change the organization. This structure does have many benefits. It allows for a clear chain of command which can filter information from one end of the pyramid to the other. It also allows strict control over what happens in the company. Assignments can be given out, and responsibility assigned when something needs to be accounted for. A drawbacks might be that ideas aren't given a chance because the levels of management assume they know more, or know better than the people they manage over.

This organization is necessary in order to run a successful company. While thus far I have only referred to OSS communities in the abstract, it is important to note that there are a number of businesses that successfully operate around the OSS model. For these businesses the clear hierarchical organization is necessary to function. But their fundamental way of doing business is generally much different than traditional companies.

Traditional software companies operate around their code. The finished piece of software is their product. Therefore the source code is their most secret and important possession. They license the software to their customers for a price, and prevent anyone without a license from using the software. Their business style dictates this style of operation. Because their development process is closed, they must anticipate the needs of their customers. So the creation of the software is a large risk for the corporation. They therefore need to protect their ability to get returns on that investment of time, money, and manpower.

OSS companies necessarily do not rely on the software in and of itself to provide revenue. The driving principle behind OSS is that the code is free. That is the code has a freedom of existing and being modified, but it may not necessarily cost nothing. In the OSS community the usage of the word free is usually clarified by saying free as in speech, or free as in beer. So a OSS company may charge for their software, but they then provide the source code along with the binary version. The customer is now free to modify the code in a manner they deem necessary, as long as it complies with the licensing agreement. There are many types of licenses that currently exist in the OSS community, but their discussion is beyond the scope of this paper. So how does the OSS company make money if they aren't selling the software per se? The companies provide support to their customers. This support may be in form of customization of the software to the particular needs of the individual customers. Something that a traditional company cannot offer, because once the software is written, the code behind remains untouched (in the eyes of the customer) until the next official release. The OSS company can work intimately with customers to provide a customized, and optimized solution that a traditional company cannot compete with.

Just as the end result of the code is different so is the structure and creation of the code itself. The open source communities tend to operate under the principle that anyone can have a good idea, not just the people in charge. As such, anyone is free to try out their idea, and then submit the result to the official code base. The idea is then reviewed, and either accepted or rejected. If rejected, then the individual may decide to take and use their idea anyways, and they have every right and privilege to do so. Another guiding principle to OSS development is the idea of make it work first, then optimize it. Meaning, provide a working piece of code as soon as possible. It might not be elegant, fast, or easy to use; but the important thing is that it exists. Then the author, or the community at large can take it and begin making it better together. This speeds up the overall production time, and allows the collective mind of the community to guide the development process. The end result being a piece of software that may not fulfill its original intent, but instead fulfills the needs of the people that will use it. This collaboration falls hand-in-hand with a third major principle: “With enough eyeballs all bugs are shallow”. This quote is attributed to Linus Torvalds, the creator of Linux. What it means is that if you have enough people using the software and looking at the source code, all bugs (or problems) become clear and even obvious. This helps the community fix bugs quickly and prevents them from becoming major problems.

This is all in sharp contrast the the traditional software development cycle. Generally a team will get to together with a potential customer and outline a set of requirements for the piece of software to be created. This is then filtered down through the levels of management to the engineers and programmers that will be designing and creating the code. Once the product is completed, the customer may realize that the requirements don't actually fit the reality. Both entities have wasted their time, and the company has lost a lot of time and resources. This is a difficult process because the design team needs to try and get everything right the first time, or mostly right, and then adjusted after a brief beta-testing period.

The differences between the OSS model and the traditional model of software creation are at such a fundamental level that the communities just can't understand how the other even functions. The problem is not one way, people heavily involved with OSS usually have just as hard a time understanding the traditional model as vice versa. The focal point of the problem falls on the traditional companies though, and why is this? It seems most likely that this occurs because OSS has grown from a handful of hobbyists into a international, world-wide phenomenon that has been increasing at an almost exponential rate over the last decade. All indications within the software market seem to be pointing to OSS as the future. Traditional companies will soon need to begin making this realization and start embracing the OSS model, or risk being pushed aside as a blurb in the history of the industry. Some companies have already fallen, and some have successfully converted to a more open model. Either way, open source software is not going away, and so far traditional companies have been unable to slow its growth. Since they can't fight it, they should be preparing themselves to join it.