0 to 60 in 1.6 Gigaseconds

Last week, a client asked me to review their policy on open source software (OSS). It was over 20 pages long (which seems too long to me for any corporate policy), it was well-written, and lucid.  But as I read it, I got the impression that the policy assumed an “apple-to-apple” comparison between commercial, proprietary software and OSS was a logical thing to do since proprietary software and open source software are both, after all, software. That is obviously true, but whereas proprietary software is clearly a product, the traits you typically associate with a product are anything but clear with OSS.

My main point I tried to make back to my client is that OSS is a new paradigm – a new way of doing things. Therefore, it is hard and somewhat dangerous to compare it to the old paradigm to try to understand it as I think their document did. Breaking old paradigms is extremely hard and in this case, I think the best approach is to stop thinking of OSS as a product. So if OSS is not a product, what is it? In my opinion, OSS is first and foremost a community.

With open source, you don’t “buy” the product, you join the community.

This may be a stretch for many, so let me give a couple examples from the policy to highlight the differences:

1. The policy referred to software upgrades in a way that attempted to compare OSS and proprietary software. This is a tough comparison. Proprietary vendors have to create upgrades to generate more revenue; OSS creates upgrades because the community values the upgrade. So proprietary vendors have to convince their users of the need or lock their users in so change is more expense to their clients than the upgrade. The model for upgrades of OSS and proprietary software are very different.
2. One point in the policy stated: “… the OSS marketplace is immature …”. I actually don’t think the acronym OSS and the word marketplace go together. This is an example of carrying forward the old paradigm of proprietary software and assuming a mechanism inherent in the old applies to the new. There isn’t a marketplace of OSS, rather there is an ecosystem and that is very different. Instead of selling bits as products, vendors find ways of selling value-added services around the bits. Also, I don’t know if I’d refer to the OSS ecosystem as “immature” given that Linux/Apache/MySQL dominates the server platforms today. The policy made the point that most people don’t understand OSS licenses. That is true and reflects a measure of immaturity of people, but I think that point and can be generalized up to most people don’t understand how and why OSS even works.
3. I got a giggle out of the policy’s attempt to compare “support or maintenance” between proprietary software and OSS. The reason I chuckled is because the policy seemed rather fond of the support from software vendors which doesn’t match my experience. Most proprietary software vendors use maintenance fees to fund the development of the next version of their product. Sure, they will occasionally perform an “emergency fix” for what they consider to be really bad defects. And they will give you a Help Desk phone number that drives you nuts trying to get a hold of someone who can actually help you. The policy seemed to me to “assert” than vendor support today is the standard to be measured by. If it is, it takes little to nothing to meet that standard in my opinion and OSS has nothing to worry about. In comparison, the community nature of OSS is more open to admission of problems and more enthusiastic towards resolving them. That is another one of the paradigm shifts.
4. I was similarly bemused by the policy’s implication that proprietary licensors “will generally provide warranties and indemnities…”. Yeah, right – kind of like the warranty I get when I buy a can of oil: I can replace it with another can of oil if I get home and find there is water in the can instead of oil, but if I put it in my car and blow up my engine they ain’t buying me a new car. All the license agreements I’ve read do everything they can to remove any and all risk to the vendor as the result of a licensee using their software. So again, I think the policy overstated the value to the way the proprietary model works regarding warranties which was a tough comparison to OSS since it is hard to find a “throat-to-choke” in the OSS model.
5. The policy expressed concern over the quality of OSS compared to proprietary products. OSS advocates express that (despite the fear-mongering of proprietary vendors) OSS is inherently more reliable and secure. Why? In part because the volume of testing is not dependent on a corporate budget to accomplish and ideas are not limited to the “chosen few”. Clay Shirky makes this point best in his Here Comes Everybody book. The corporate culture is to play to the big-hitters, the power-brokers – those with political muscle. The OSS culture is to give equal attention to the one contribution from someone nobody ever heard of before. OSS advocates would say this leads to better product.

Thinking of OSS as a community rather than a product helps in making the paradigm shift. Thought of as a community, you can better understand the motivations and processes that lead to something useful. Thought of as a “free product”, you will always be confused as how to make comparisons.

So do you need an OSS Policy? Probably, but work to understand the paradigm shift before your write it. To me, there are two big risks with OSS worth coverage in a policy:

1. You might commit some software you write into the OSS space without knowing it. In general, OSS works because it is community based, not seller-buyer based. As a member of the community, you are expected to contribute. If you contribute by developing something, it becomes part of the OSS. That is the over-simplified concept which is made much more complicated by the license agreements of the various OSS components. So if you actually want to protect some software component from becoming OSS for whatever reason, you need a good lawyer and you need a good architect.  BTW – get your legal advice from an experienced, outside expert.
2. You might back a loser. An OSS community is a difficult thing to predict or understand. It is not motivated by profit like the free-enterprise system we all understand (well, not all of us but I won’t go there). So where does the interest, the time, the funding for OSS come from? The policy correctly suggested market share should be considered as part of the OSS evaluation criteria. Market share will tell you a lot. But a little research into the community might shed more insight. For example, a specific OSS with a 50% market share sounds good, but what if you discovered 99% of the developer time came from IBM? While this problem can be mitigated by always making selections that can be backed out of (go with openness), the other thing to look for is a community that is diverse, active, vibrant, and passionate – they will likely need the thing as much or more than you do long after you tire of it!

There is no such thing as a free lunch, and OSS is no exception. There are countless articles written to tell you that the acquisition price is just one small part of the total cost of ownership of software. Less obvious (and more important in my opinion) is the cost of joining the community. I council clients thinking about OSS to get active in the community. You should strongly consider that your OSS policy require active participation in that community. Encourage it by allowing employees to use a portion of their paid time to develop code or participate in any of the many other ways to get involved: as designers, as project managers, as testers to name a few. This is another paradigm difference and ensures that you will be able to gauge the health of the community, which is your best way of being successful with OSS.