Wednesday, January 24, 2007

The Three Most Important Letters in Open Source: CYA

Anyone who follows politics knows that one man’s given is another man’s question. In the software VC world, the merits of open source are regarded as givens- a business model innovation that brilliantly aligns customer and vendor interests.

However, outside of the software VC market, open source remains an enigma wrapped in a mystery. How does free pay? Is open source a backdoor towards communism? Is it anti-capitalist? Despite RHT’s market cap and the success of JBoss, I continue to meet many who question the wisdom and financial merits of open source.

Open source is rife with acronyms – GPL, MPL, OSS, etc. In my experience, however, the three letters in open source that matter most are CYA ("cover your ass"), not GPL…in fact, CYA best explains the economic incentives of open source customers. Simply put, customers will not deploy software into production, independent of whether developers think that they need support, that is not supported.

No IT manager worth his salt will put mission critical software infrastructure into production without a throat to choke. Telling the head of equities that trades are failing due to a software crash and that you have an email into a community forum asking for a fix will result in termination faster than you can say “dumb ass.”

In analyzing open source, I have talked to many developers who tell me they do not need support for many open source projects and that forums, list serves, and documentation provide the material they need to solve their problems. However, IT managers are focused more than ever on service levels and subscribing to open source vendor’s support subscriptions allows them to cover their asses if and when infrastructure fails and transactions are at risk.

If CYA is the key to monetization – what does that mean about the categories of software that are likely to succeed via an open source model? Fundamentally, the closer a product is to a transaction the more important CYA becomes. Applications that are not mission critical –content management, for example - run a material risk of developers using the GPL license and sourcing support from the community rather than via subscription arrangements with the vendor in question.

What other variables characterize successful open source companies:

  • Established market- successful open source projects target established software markets where the incumbent vendors are over charging their customers for bloated, proprietary solutions. Famously, once RHT Linux met their enterprise expectations, Morgan Stanley’s purchases of Solaris servers fell off a cliff and the investment bank realized close to 10x cost reductions per CPU. Can you target a large market and deliver a standards-based product that allows IT organizations to grow their IT capacity at a greatly reduced cost basis?
  • Evidence of organic pull most appropriately characterized by downloads, forum usage, etc.
  • IP rights retained by C-corp established to commercialize project. Indemnities become challenging when it is difficult to provide documented attribution of source code ownership. Also, potential buyers will discount a company’s value if IP remains unclear.
  • Active community – an active community of developers led by a project leader who is employed by the company

Next time someone asks you how free leads to fee…remember that IT managers and risk taking are oxymorons and that having a throat to choke while saving large amounts of money feels good!


  1. richard - it stands for cover your ass

  2. Anonymous11:15 AM

    It's no good you know. When "pros" make minor mistakes there is a little devil that pops up and I just have to tern into the atomic school teacher. "IT Manger" and "Risktaker" are not oxymorons but two seperate words. "Risk Taking IT Manager" is just one oxymoron like "sweet sorrow" or "militry inteligence". I feel better now thank you.

  3. Anonymous12:42 PM

    These comments have been invaluable to me as is this whole site. I thank you for your comment.