Once More unto the Breach

Why the Economics of Open Source Software is so Important

[Updated (18-May-2007, 11:13): Added a new paragraph (in italics) in the business model section towards the end.]

There are two ratios we've been unable to escape since we began programming [1]:

• The number of lines of code written by an "average" developer per day (~20).
• The average number of defects per thousand lines of code in a good development process (~1/1000 LoC).

All the advances in programming whether languages (assembler to "high level" languages to script-based languages and managed code), reuse strategies (modules, libraries, objects, components, distributed objects, etc.), or engineering practice and discipline (requirements, inspection, version/configuration management, build practices, test practices, extreme, agile) have been directed at beating those two ratios by writing more and better software with fewer lines of code.  Writing good software is hard. 

Indeed, it is difficult enough that we have shared software for as long as we have written software.  This certainly predates Richard's desire for software freedom and the GNU Manifesto.  By the time I was attending DECUS conferences in the late 1980s, the tape library was a well oiled machine.  You laid down your "cost of media" and received a magtape full of software.  Some was binary only.  Some in source code form.  All covered by copyright, but some placed in the public domain.  Some developers accepted changes. Some allowed derivatives.  Bandwidth and latency in the "network" were certainly different, but share we did.  (As I understand it, the developers in the IBM world did similar things at a conference called "SHARE" oddly enough.) 

This is also why the economics of "packaged" software were so good, and customers laid down a lot of money through the 1980s and 1990s.  Customers were used to writing all their own software.  Each customer ate the entire cost of development, maintenance, and support.  Domain expert software vendors came along, aggregated requirements, and amortized those costs across the customer base.  Customers got more and better software faster and cheaper than they ever could have developed for themselves.  The economics worked in the customer's favour.  Computing hardware costs fell to the point of the creation of the PC, and packaged software exploded to address the needs of users that didn't even know what programming was.  And a lot of software companies made a lot of money. 

Then the web happened.  Bandwidth exploded.  Latency vanished.   We needn't trickle software across 300 baud acoustic couplers anymore.  Conferences (events artificially bound to a calendar, clock, and geographic location) were no longer the necessary sharing point.  We could form online communities at will, freed from those constraints of linear time and space, and follow our interests and passions. 

Our understanding of sharing under copyright also matured.

Now good software has always been written by good software developers without regard for how they share it.  There is a discipline to developing good software involving inspection, source code management, build automation, test automation, and facilities to encourage discussion and decision making.  We all know what we should do to develop good software, but good software developers know of no other way. 

Good software developers also like working with other good software developers.  Web-enabled communities complemented by copyright licenses that ensured everyone understood the "contract" of the community allowed well run projects to thrive.  Good project managers know how to get the best out of a team of developers. 

So we now have the ability to amortize the costs of developing, maintaining, and supporting the development of good software in web-based communities.  The engineering efficiency is compelling.  Well run open source software projects represent dynamic stable building blocks for solving a growing and  complex set of problems.  They preserve (and indeed expand) the value in the asset created.   (Intellectual property is a set of legal tools used to protect an asset.  Let's not confuse the value of the asset's protection to a business with the value of the asset itself to its users.) 

This does NOT mean that these development communities can't be closed.  Or that they can't reside inside of a company.  But there are two dynamics at work then.  First, by closing a community you may be closing out the very developers that can best help grow the asset's value over time.  Second, understand that a company with a customer must serve certain other economic dynamics, beyond a project with participants and users. 

A company builds solutions for customers.  Customers pay money for the solution and have certain expectations around value-for-money based on the promises made by the company.  A solution or product is much more than "just the software."  (See the Core, Complement, and Context post.)  Businesses selling solutions have an operational side around marketing to get the word out, and sales and delivery channels, and these have costs associated with them.  Yes -- the web is certainly changing the way that happens in everything from eBay and Amazon, to Fedex and UPS, to Microsoft, Adobe, Red Hat, JBoss, and all kinds of other vendors.  But customers pay for value around a solution for which they perceive a need.   That doesn't change whether they're buying Microsoft Windows Server 2003 or Red Hat Advanced Server.   

And here we come up against the other economic dynamic that happens to "software" companies over time.  Companies need to keep selling.  So they need to keep finding new customers, and to keep adding features and providing sustained innovation on the base they're already selling to current customers.  When they begin to over deliver on the customer needs, they need to shift their value proposition to something for which the customer is willing to pay -- enterprise agreements as a repackaging of license and support for example.  And the customer's needs aren't static either, so they're investigating shifting perceived needs at the same time.  The money-for-value equation keeps changing for customers.

The new breed of companies using open source software as a feature are innovating here as well.  Historically, if you were a packaged software vendor, you could only sell a customer again by adding features.  You kept adding features (innovative or not) until you over-delivered.  (Anyone remember when each new release of Hummingbird's PC X11 server had all manner of IETF clients jammed into it -- including email?)  The "subscription" model later invented by such companies looked a lot like a feature update service with support and maintenance.  The new web-enabled subscription services developed by the likes of Red Hat, JBoss, and MySQL provide regular value beyond new features. 

Good engineers work to the constraints of the scarcest resource.  In many cases this is time, and in some cases money.  With open source software, engineers on both the customer AND vendor side have broader freedom in some vertical problems spaces (e.g. content management, office suites, system admin and operations) to make choices based on their own unique needs, which they typically understand better than their suppliers/vendors.  So for a "UNIX" OS replacement they might (depending upon their unique needs) choose:

• Red Hat Advanced Server
• Microsoft Novell SuSE
• Open source Solaris (with or without support)
• Microsoft Windows Server 2003
• roll their own Linux distro (similar to Bank of America or Google)

Open source software is all about solution choice and value preservation in the software asset through shared development and community.  We can collectively amortize the development, support, and maintenance of software.  The rest is just software business. 

[1] I don't need education on the inaccuracies of counting lines of code, nor on how a programmer writing less, or indeed removing code may be the better and more productive programmer -- honest.  I've never measured anyone's productivity based on the number of lines of code they wrote.  The best simple description of all the debate I've read may be this bit from the introduction of this paper from Bell Labs in 2001:

No single system of metrics for measuring software quality is
universally accepted [4,5]. Intuitively, software quality is related
to the ratio of the perceived usefulness of a product and its
perceived buggyness. The usefulness of a product is related to its
functionality, which is in turn related to code size. More
functionality often implies more code. As a metric for buggyness
one often uses the elusive standard of ‘residual defect density.’
The residual defect density is meant to measure the number of
defects that remain in a software artifact after delivery to the end-
user (the customer), weighted by code size. A typical target in
software development is to achieve a residual defect density of
less than one defect per one thousand lines of non-comment
source code [4,10].

[Return to top]

The Microsoft Open Source Patent Gambit

[Updated (16-May-2007, 16:00):  Andy Updegrove weighs in brilliantly with his analysis.  Also an interesting CNet article from Stephen Shankland.]

[Updated (15-May-2007, 15:21):  Adding a few links beyond the set in the first paragraph.  PJ at Groklaw, Linus's comments, and Tim O'Reilly weighs in.  The Open Invention Network responded with a press release. And then there's Tim Bray's pithy four words along with Jonathan's commentary.  So public opinion is pretty unanimous.  In the historical words of Bill Gates, "that’s the dumbest fucking idea I’ve heard since I’ve been at Microsoft.”]

I thought I'd said everything I had to say on the topic of Microsoft and patents and open source weeks ago, and would leave it to better writers than I to comment on the latest news.  But I can't.  (Here is the excellent commentary from O'Grady, Asay, and Augustin, and the original Fortune article and Parloff's additional blog commentary.) 

First, to reiterate, as a customer I am completely uninterested in buying something from a vendor, and then paying every other vendor in the space a license to their possible additional but unproved patents.  I'm not even interested in licensing their PROVED patents.  Patents are vendor to vendor discussions.  To make sure the license wonks in Microsoft Legal and Corporate Affairs understand what I mean: As a customer, when I buy my Xerox copier, I do not intend to additionally license patents from HP, Canon, Epson, or ANY other copier manufacturer.  I buy solutions from my vendors, and I expect value for money. I am uninterested in your protection shakedown.  Move on.  The bullying of customers stops now.

Second, why wait for Gutierrez (Microsoft Licensing Director) to identify the patents? 
There are 6723 patents in the USPTO searchable database with an assignee name of "Microsoft".  Of that, 656 use the word "kernel" in the patent somewhere. 

Ohloh.net claims there are 2402 contributors to the Linux 2.6 kernel, another 1433 Gnome contributors, and 422 OpenOffice.org contributors.  That's a starting number of 4257 developers that have a selfish vested interest in understanding this situation and that with a little guidance may have the few hours to spare to tackle a particular individual patent claim that falls into their area of expertise.  That doesn't include all the other developers working on kernels and UI and office suites that may or may not be open source.  If a site like Groklaw posted a searchable "Microsoft Patent Wiki" such that developers could start to register individual interest in particular claims on particular patents and start to aggregate and co-ordinate the information to tear down bad claims, we could help the USPTO (and Microsoft) clean up the bloat and mess. 

You see, intellectual property law is based on an analogy to real property, i.e. LAND.  But unlike real property divided into "claims", each with clear real boundaries, intellectual property claims may not be real.  That's the problem with analogies.  But claim by claim, on patent by patent, collectively the information base could be built to begin to file requests for declaratory judgments.  And it would be important to ensure each is filed separately on each claim -- not collectively on each patent.  Death by a thousand cuts.   

We don't need to gather together in a geographical location to protest such abuses of the system anymore.  This isn't the era of the equal rights or civil rights movements.  Nor do we need to wait for the Department of Justice to fret about whether they have a concrete case against an economic bully.  We have the web.  We could crowd source the biggest patent case in history.    

At the very least, the companies of the world feeling threatened could simply suggest to Microsoft's Friendly Patent Licensing Team that they're going to wait to see what remains of the claims before entering "contract" discussions. 

Microsoft needs to get back in the business of building exceptional solutions to customer problems, instead of chasing a 1990s dream of IBM's secondary revenues from hardware patent licensing, or worse yet threatening those same customers. 

[Disclaimer: Microsoft is a client.  But I swear I'm reconsidering that decision.  It's unclear to me that the mortgage payment is worth this much aggravation.]

The Death of the Term "Open Source Software"

I don't understand.  Matt Asay has a good post on all the good competition in a growing market for various solutions based on open source software.  In it, however, he includes CentricCRM, the company that claims to be an open source company but isn't.  I went back to the CentricCRM site.  Here's their license link.  (It hasn't changed since I last posted on it.) 

We're not talking about business model problems here.  I have no problem with them selling a software product that is closed or proprietary.  Customers will pay for value.  And I have no problem with them showing up at every conference/convention around the open source world as they run on Linux systems. 

But I do have a problem with them claiming to be open source when the license clearly is as far from the definition as can be.  Their marketing team is either:

• Willfully misrepresenting its offerings i.e. lying to customers, or
• Ignorant in ways that could be cured by a couple of minutes on the web. [Google "open source software".  Link #1 is something called "The Open Source Initiative."  A prominent link on their home page is called "The Open Source Definition".]

Speaking of which, why isn't the OSI weighing in here?  If this were Microsoft, we would see the press and blog world gnashing its collective teeth, there'd be "open letters" from the OSI decrying the abuse of language, and no end of snarling about Microsoft's mis-use of a well defined term.  Even Microsoft made up their own terminology around Shared Source (neither willfully misrepresenting its offerings and certainly not in ignorance.) 

What am I not understanding?  Did I miss a blog discussion somewhere?  Is everyone okay with this?  I will happily change my opinion if given better data.  By all means educate me in the comments -- please!

Core, Complement, and Context: Channeling Geoffrey Moore on Open Source

Geoffrey Moore wrote Crossing the Chasm in 1991.  He might joke in his presentations that he's been milking the idea for 15 years, but it remains a classic.   (I've lost a company in that chasm.  It's real and real ugly.)  In the book, he builds out a simple idea that a business can drive it's success by delivering a "whole product solution" to the customer, i.e. the core and all its complements. 

When we say "core" here, we're talking about the "core value proposition".  It is by definition customer facing.  And there are a wealth of things one can do to provide all those complements. Based on experience at Microsoft, I would observe that one can:

• Use traditional buy-versus-build strategies through the vendor’s own brand, regardless of whether the complement products are offered as add-ons or bundled directly with the core revenue stream for “free”
• Develop a rich ecosystem of add-ons by encouraging developer and partner networks to provide a bigger whole solution 
• Publish proprietary specifications enabling more partners to develop stable businesses in the complement spaces.
• Provide developer tools that help add complements to the ecosystem.
• Create certification programs around the core technology creating service professionals to help customers complete and support their solution
• Develop a consulting services arm for part of the solution
• Develop training programs and train-the-trainer certifications

You can see Red Hat and MySQL AB doing these things as well, as they grow their respective businesses. Free and open source software provides interesting new ways and opportunities to develop out the complement space. For example:

• To buy-vs-build you add “borrow” and “share”
• Companies that participate in communities
  • Can rapidly develop complements to core offerings in their solution network (without necessarily building complete products)
  • Can amortize dev/support/maint costs of complement components across customers/partners/competitors (e.g. IBM and Apache and Websphere)
  • Get to interact directly with like-minded customer prospects in community, influencing customer/partner developers
• Companies that participate deeply in communities better influence those communities (e.g. participate, hire, or acquire)
• Companies can use open source projects to reduce the cost of sales by allowing users to try easily and pre-qualify themselves as customers
• Open source projects are an interesting publication strategy against competitors from an IP strategy perspective
• New companies with lower margin business models (compared to the incumbent) can use open source components to rapidly develop products that either serve new markets or serve the bottom end of an over-served market and then evolve over to or up into an incumbent’s market space

Over the years, Moore has delivered other excellent books, shifting from helping a company survive the chasm, to surviving its success in how to think about operational success and what they need to think about and do differently.  (Indeed, this is what I love about both his work and Christensen in both the Dilemma and the Solution.  They look at a company in the context of history over long periods of time in dynamic markets.)

Moore's latest is "Dealing with Darwin".  Here he begins to contrast "core" with "context", and pleads the case that over time a company's core becomes context as they evolve. He drives towards a view of open source in his related presentations that encourages companies to make open source in areas of context.  This is still great advice, BUT I would offer several caveats along the way:

• Here he's talking about "core competency/asset" not "core value proposition".   The first is what enables the second.
• A core competency or asset is inward facing -- not customer facing like a core value proposition. 
• Making open source as a vendor means different things to making open source as a consumer. 
• Companies need to understand the difference between these two "core" ideas and do the right things in each space. 

Examples obviously help here (and my apologies to each company for somewhat oversimplifying their worlds.)

Microsoft: 
Core value proposition: The ubiquitous desktop (now laptop) computing device for a  "document" computing metaphor.  (The historic message was wonderfully crisp in this regard:  A PC on every desktop and in every home.  Customers knew what they were buying and employees knew what they were building.)
Core competency/asset: Delivering a software "appliance" that runs on thousands of PC with thousands of devices attached, and successfully runs thousands of useful applications.  The testing matrix cross product of the hardware compatibility list with the applications compatibility list requires extraordinary discipline, process, and capital.  This also extends to the development side of the house.  It's easy to get instant on/off to work on a Mac when there are about 20 Mac designs on the planet and you control the end-to-end UI through OS to hardware.  Now think about it from the Windows dev team perspective and the 1000s of machines to be supported.  (To be clear: I still own a Mac.  I may be sympathetic to the engineering problem, but I don't have to live with it as a consumer.) 

Google:
Core value proposition: The ultimate advertising machine in the web world.  Remember the company's customers are paying for advertising.  It's the TV network business model for the web.   
Core competency:  The ultimate search engine on the web.   The asset/competency is the algorithms and people tuning/evolving it and the server farm on which it runs.  (Again, just like Microsoft's capital investment in the delivery infrastructure, so to does Google have a reasonable barrier to entry here.) 

It's really important to understand the difference here.  You can't publish/share (and by extension "open source") your core competency.  Google can't share the algorithms at the heart of their search engine today.  Once they've "indexed all the world's information" and the data [über-annotated-indexes] becomes the core asset, then they might be in a position to consider it. 

But this is also why I maintain that Microsoft could now publish most of their software using open source licenses to advantage -- including Windows and Office (were it legally possible).  Their core competency today is actually tied up in the capital (human knowledge and physical) and processes that enable the Windows and Office distros and support to be delivered through the global channel, and no longer in the source code base itself.  Microsoft could use open source communities to re-invigorate the franchises.

Microsoft Discusses Open Standards (versus Open Source Software)

Matt Asay discusses today's Wall Street Journal article on Microsoft's battles with State governments over ODF.  [Here's the link to the article source from Market Watch lest the WSJ archive go into pay mode.] 

I find this all sort of funny.  Five years ago as governments explored open source software preference legislation, Microsoft's rhetoric machine went into overdrive to lobby people to prefer technology based on open standards regardless of implementation methodology and licensing.  And this IS the right solution for governments.  But based on current rhetoric I thought it would be funny to see what Microsoft had to say for itself.  Unfortunately the Wayback Machine wasn't as helpful this time, and Google search results are jammed with the "Men in Black" story about Microsoft's hired bullies lobbyists. 

I was, however, able to find a document from that period on Microsoft.com.  [Microsoft.com is a sufficiently large site to have a life of its own.  While pages change, downloads often remain.]  A search on Microsoft.com for "standards open source" returned a huge number of links, but a download called "Key Messages" on the first page looked promising.   

So here are some "Key Messages" from Microsoft's standards team circa 2003 (doing battle with the Australian parliament no doubt) [Emphasis added]:

• An open standard is a publicly available specification which details certain technical functionality that may be implemented in different products and services.  It is adopted in an open, consensus-based process and must satisfy other criteria for transparency, ease of access, and broad implementation as described below.
• Open standards exist to facilitate interoperability and data exchange across various products and services in a marketplace of multiple, competing implementations, while ensuring that certain minimum requirements are met.
• Other types of standards (e.g., “proprietary standards”) and market-based mechanisms exist and are currently used to facilitate interoperability.  However, open standards ensure the highest level of interoperability across the widest range of competing products and services.

You can read the rest but you get the idea.  Sooooo ... ODF versus Microsoft Open XML.  I guess we should judge each based on the number of implementations of each.