Once More unto the Breach

Open Source Software Economics in Pictures

Updated [22-Mar-2010]: Added a little text around the Ohloh javascript widget so Google Reader sees a URL to follow.

Recently, I've encountered several technologists that still don't understand open source software economics and got suitably cranky about "people giving away software for free" and "destroying the value of innovation". I thought it time to try to reach for an easier way to demonstrate what's happening in the industry in pictures.

Everyone is familiar with the idea of a normal "bell curve" distribution representing R&D investment over time. As a technology is better understood and a product succeeds in the marketplace, R&D investment increases, and over time as new technologies advance, the R&D investment in the original technology and product wanes. The integral represents the total R&D investment over time. The function can also represent the "knowledge" gained or the increase in the intellectual asset base.

Good companies develop and invest in new successive waves of sustaining technologies. So, looking at Microsoft's success with PC operating systems, DOS was replaced by a greater investment in a more innovative Windows, was replaced by a larger investment in a more innovative NT.

This also fits nicely with Christensen's original observations about incumbent companies being good at sustained innovations and well run companies knowing how to jump from technology to technology along a sustaining innovation path. This all makes sense when considering a single company's R&D investment. It applies equally well to Sun Microsystems when considering that the steeper slope of successive sustaining innovations was on the hardware side versus the slower (but not inconsiderable) investment from SunOS (a BSD variation) to Solaris.

The investment curve for projects like Linux and Apache, with lots of individual and corporate contributors, still looks like a bell curve, but the contributions might better be viewed as a stacked bar chart. Individual contributors invest to meet their specific needs. Because there is enormous overlap in their common needs, they all share the overall investment.

Individual contributors get enormous return on their investment. (One gives a few bug fixes to the Apache httpd team, and in return one gets an entire HTTP daemon.) Corporate contributors give for the same ROI. They get enormous return on their investment in technology they use in a product complement space or as a component in their overall solution to the customer. (Before someone takes issue with my Red Hat example above below, understand the "solution" in the customers mind was "UNIX-like servers on inexpensive 'PC' hardware" and not "Linux".)

Christensen was careful in subsequent work to point out that the disruption wasn't about technology but about business model. The disruption often started when someone assembled standard cheaper lower performing parts into a solution that solved a completely different need with a very different cost basis. The new solution begins its own sustaining innovation curve until the new technology can compete with the incumbent compared against the criteria about which the customer/consumer cares.

The disruptive business model isn't about Linux so much as the ability for corporations to do collaborative development at the component/complement level in a "frictionless" well-managed Internet-enabled community. (The original OSF/1 shared-development of a UNIX-like replacement failed: too few players, too much politics.) Linux is a much stronger disruptive business solution as a way to handle a particular sourcing problem.

It would be interesting to consider the difference between projects with enormous inbound code contribution (versus all the other strengths a well run community brings to the table) distributed across a wide group of players like we see in the Linux and Apache projects, versus projects managed more tightly by a company like MySQL was. Another interesting attribute of this collaborative business model to investigate is how contribution mutates over time. Christensen's work demonstrated that an incumbent gets in trouble when they begin to over-deliver on functionality for attributes their customers consider important. The customer can't absorb the sustaining technology innovation any faster and literally won't pay for it. The slope of the sustained innovation of the competing technology is sufficient to cross into the space covered by the incumbent's solution.

In a shared collaborative development environment, however, because the technology isn't being driven by a single corporate entity, the community of corporations collectively contributes to their own needs and the technology may (i) stabilize where it needs to stabilize, and/or (ii) be taken in new and interesting directions. There is less pressure (if any) to over-deliver with new innovation. The consumers are the developers, but it's a very broad community indeed. This is what I believe just happened with the MeeGo announcement and the combining of the Nokia Maemo and Intel Moblin projects. This is a great inflection point for Linux into the new mobile Internet device space.

One only need read the report from the Linux Foundation charting the growth statistics in the Linux kernel to understand the enormous value generation happening release-on-release, four times a year. Using the Ohloh rules-of-thumb of US$55,000 per person year one gets US$142M of value creation in the 2.6 Linux kernel. The fact that some business models have been destroyed (Sun), or threatened (Microsoft) doesn't mean there's not enormous ongoing value creation in the technology.

Ohloh value chart for Linux 2.6 kernel.

Neither is intellectual property being "destroyed". Again, this is a disruptive business model discussion. Intellectual property is a business choice made on how a company will protect certain intellectual assets as legal property. Which assets to protect, and how, and which property to defend is a business choice based on the cost model a business uses with respect to turning assets into value propositions customers will buy. When a group of companies chooses to collaboratively develop a technology complement/component, they're making a business model choice on how they will selfishly share certain intellectual assets. Nothing was destroyed along the way.

My New Android Phone and AT&T Wireless

I was lucky enough to get one of the new unlocked Android developer phones from a friend at Google to keep me occupied. There are pictures here:

www.flickr.com

I'm an AT&T Wireless customer. I wandered into the store to ask if there were problems, and was told they didn't know. (I added the unlimited data plan for US$15/month while I was there, being ever so hopeful.) A quick Google about and I came across a post that pointed out the following settings (for AT&T and many more mobile operators):

Name: AT&T
APN: wap.cingular
Proxy: leave blank
Port: leave blank
Username:WAP@CINGULARGPRS.COM
Password:CINGULAR1
Server: leave blank
MMSC: http://mmsc.cingular.com
MMS Proxy: wireless.cingular.com
MMS Port: 80
MCC:310
MNC:410 (note. this could also be 310, 41 or 15)
APN Type: leave blank


Create the access point name (APN) from the Settings App->Wireless Controls->Mobile Networks->Access Point Names (hit the Menu button to bring up "New APN"). I selected the newly created AT&T APN and I was up and running.

Everything seems to work so far. Calls, SMS, MMS in/out all work. Need to spend a bit more time with the apps. The stock apps for Gmail and browsing and messaging seem fine. I'm learning to hit the Menu button when stymied about what to do next and it's not obvious. That typically brings up the options for which you were looking. I've loaded Twidroid from the Android App Store along with a few other tools (because everyone needs a command-line window and a telnet client on their phone).

The only thing proving really onerous is Google assumes I have my contacts on GMail and won't read anything from the SIM apparently. The synchronization between my old mobile phone (a Motorola Razr) and my desktop (a Mac PowerBook G4) is horrendously bad. So I'm needing to hand rationalize a lot of phone numbers. Tedious, but an opportunity to clean out the list. I'm going to go fix that problem more broadly soon regardless.

Now to download the Android SDK.

Cloudera Launches Around Hadoop

Copyright Peter DaSilva for the New York Times

Congratulations! Cloudera launched today to bring Hadoop to the enterprise. It's anchored by Mike Olson, Christophe Bisciglia, Amr Awadallah, and Jeff Hammerbacher. Hadoop is the open source project that implements MapReduce, the algorithm that allows companies like Google and Yahoo (and even Microsoft) to search cheaply and easily enormous quantities of data and assemble the results. As most enterprises don't have the sort of operations staff that a Google might have, Cloudera will provide enterprise qualified software, training and consulting.

I've known Mike for a long time now since his days as CEO at SleepyCat before they were acquired by Oracle. I had the pleasure of working with Christophe as a speaker at the inaugural Open Source Forum at the Beijing Software Innovation Summit in China a couple of years ago while he was still at Google. It was Christophe that put together the original training program around Hadoop for university students. Congratulations and best wishes!

P.S. Christophe seems to have gone all corporate with his hair.

The launch video on YouTube

The Microsoft versus TomTom Patent Debate is about the Mobile Internet not Linux

The Linux community is up in arms over Microsoft's filing a patent infringement suit against TomTom, the Dutch navigational unit manufacturer, determined to convey this as an opening move in the debate about what patents Linux does or doesn't infringe. This suit is very likely NOT about Linux. Let's look at the patents. From the complaint, Microsoft patents in the case (collectively, “the Microsoft patents-in-suit”):

• 6,175,789 (16 January, 2001) Vehicle computer system with open platform architecture
• 7,054,745 (30 May, 2006) Method and system for generating driving directions
• 6,704,032 (9 March, 2004) Methods and arrangements for interacting with controllable objects within a graphical user interface environment using various input mechanisms
• 7,117,286 (3 October, 2006) Portable computing device-integrated appliance
• 6,202,008 (13 March, 2001) Vehicle computer system with wireless internet connectivity
• 5,579,517 (26 November, 1996) Common name space for long and short filenames
• 5,758,352 (26 May, 1998) Common name space for long and short filenames
• 6,256,642 (3 July, 2001) Method and system for file system management using a flash-erasable, programmable, read-only memory

Also from the complaint, we have this statement (line 15):

6. Upon information and belief, Defendants are in the business of developing, manufacturing, and selling portable navigation computing devices and software for use on those devices, personal computers, PDAs, and smartphones (hereinafter known collectively as “Portable Navigation Devices and Software”).

This feels much more like positioning for location-based services and the coming mobile Internet war. Microsoft has been the "PC company" for a long time. It got there on the backs of a standardized PC "device". (In a Christensen economic world of a network of complements, Microsoft captured the innovation premium in the OS on commodity hardware.) That world is changing rapidly since Apple demonstrated what the mobile Internet can look like with the release of the iPhone. There has been a rush of delivering iPhone competitors to market since then. Nokia bought Navteq, then Symbian (the predominant mobile OS), to be released royalty free and as open source sometime in the future. Google released Google Maps with instructions to drive places, and then developed and released Android. There are considerably more handset devices on the planet than PCs [see note below]. This feels like a much bigger fight than the first shots in a Linux patent fight. This could have much bigger ramifications for Nokia (and the other handset manufacturers), Google, and Apple than Red Hat et al. These are the players that need to be naming themselves to this patent litigation suit.

Related commentary:

• Microsoft v. TomTom: Patent war, or no?, () Matt Asay's fine blog commentary
• Microsoft sues TomTom for alleged patent infringement, (25 February, 2009) by Ina Fried
• Has Microsoft's Patent War Against Linux Begun?, (25 February, 2009) Glyn Moody's commentary
• Beating the TomTom: Drums of War? (Not), (26 February, 2008) Andy Updegrove's excellent commentary
• Microsoft lawyer 'won't speculate' on Linux suits, (25 February, 2008) Ina Fried's CNET interview with Microsoft's Horatio Gutierrez, senior IP lawyer
• The Microsoft Press Release, (25 February, 2009)

Note: Communities Dominate Brands pointed out that there were 3.3 Billion mobile subscriptions in 2007 versus 900 Million PCs. Or to put this in better context:

Now as the phone handset makers like Nokia, Samsung, Motorola, SonyEricsson and LG ship over a billion phones annually (IDC, Jan 2007), we have a colossus of an industry of high tech pushing ever more powerful gadgets into our pockets. And yes, Nokia alone ships one million phones every day of the year, Saturdays, Sundays and Holidays included. For contrast note that the PC industry shipped 250 million new PCs in 2007, of which about 100 million are laptops (Computer Industry Almanac Jul 2007).

OSBR Article on Open Source and the Mobile Internet

The Open Source Business Resource is an academically sponsored body of work published each month out of Carleton University in Ottawa, Canada. I've an article in this month's issue. Regular readers will recognize a lot of themes they've read here or heard me discuss and present. The focus is on the coming mobile Internet and open source software. I would encourage people that want to comment to hold the discussion on the article's website.

The Arrival of the Mobile Internet Thanks to the Economics of Open Source Software
Walli, S. 2009 Jan 5. The Arrival of the Mobile Internet Thanks to the Economics of Open Source Software. Open Source Business Resource [Online] 0:0. Available: http://www.osbr.ca/ojs/index.php/osbr/article/view/818/790

Developing a Standards Office for Google

I've been thinking about this since I published the Standards Primer a month ago. In the next two to five years, Google will be challenged by a technology standards effort that it will need to encourage or manage in its mission to organize the world’s information and make it universally accessible and useful. Such efforts cannot be erected quickly (as demonstrated most recently by Microsoft), and preparations for that day should begin in the near future. Google is also in a unique position to turn the standards development process on its head.

Here are a number of ideas for how Google can plan for the future in the most flexible and cost effective manner, and contribute a unique and valuable re-think of the standards development process. Well organized, a standards function can be an order of magnitude more effective at growing or defending a company’s business.

A Standards Office for Google

There are a set of strategic questions to be answered by a standards function at Google: What standards should be developed or encouraged to reduce the friction of organizing the world’s information and making it universally accessible and useful, or to open up new areas for growth? Is Android a reference implementation? An open source community? Does it require a standard? Are there micro-format standards that would make indexing web sites, libraries, or health records easier? What standards could others be planning that need to be managed because they threaten Google customer engagements or limit growth? Is a search results standard good or bad for business?

Google has a perceived public culture around serving customers, aggressively innovating, doing no evil, and having fun. These attributes should be celebrated equally loudly in their standards function which for most companies is portrayed as staid, conservative and dull.

As with all business functions, success in the standards function is a matter of organization, preparation and execution. To succeed, you need to:

• Have a strategic planning function that knows how best to recommend using the company assets to develop and respond to standards and standards-like programs and communities.
• Be able to find, organize, and educate potential participants and practitioners within Google quickly as the need arises.
• Be in a position to influence external participants and organizations through successive layers of trust, i.e. you need to be participating and be visible.

The following is the start of some considerations for a standards office at Google:

• Organize the standards office to be a small number of standards strategy staff. This group would have the responsibility for education, evaluation, organization and co-ordination, and forward strategy planning.
• Individual technical staff are generally the first group of people an organization discovers in their own ranks participating in standards. They are the first line of trust and influence. They are in the worst position when it comes to IP risk or reward. Standards practitioners often develop out of the initial group of standards participants. These practitioners are people that have an interest in the success of the standards efforts at a more organizational level and begin to see cross-standards influences.
• Educating participants and practitioners is key to ensure they know how to best get things done, protect the company’s investments, and how to keep others within the company informed of status. The standards office should be responsible for developing and delivering the educational materials.
• Organizing and co-ordinating the efforts of participants and practitioners is important if a company is to get the best return on the investment of having them involved. The initial participants are already building trust in their respective organizations. They are the front line and need to be supported in their roles.
• Google has offices in 27 countries. This is an opportunity to build trust with 27 national member bodies in ISO. Some countries have rules about participation (you need to attend so many of the past meetings to be eligible to vote for example). Some countries are more relevant than others, because they hold particular influence as well. But Google is in a great position to begin here.
• The standards team should be responsible for co-ordination with legal and corporate affairs and the business teams (product marketing and development) for standards-related efforts.
• The standards office should also be responsible for monitoring ongoing activities in the standards development world to watch for particular efforts that should be joined or managed.
• The standards office should develop forward thinking strategy in the standards space. Based on current products and future opportunities, what standards efforts might be undertaken at Google at what cost to best enable customers and users?

The investment need not be great. Google is in a great position to begin. But there are even more interesting ideas in the standards arena and Google is in a unique position to fulfill them.

Turning Standards on their Head

Taking a typical Google viewpoint of what could be done with infinite cycles, storage, and bandwidth when thinking about standards opens up new opportunities in the standards engagement space that come back to Google’s mission to organize the world’s information and make it universally accessible.

Developing interoperability standards is a labour intensive process. A working group meets to debate and discuss the nuts and bolts of the specification, but that act and its attendant work have lots of friction in the system:

• Meetings need to organize and track input documents, minutes, and output documents that pertain to the development of the specification that will become a standard.
• Specification development is often as complex as developing complex software, where a collection of document sources (text, markup+metadata, diagrams, tables), need to come together into a single known identifiable “printable” document that is easily available, indexed and searchable.
• Draft specifications need to be managed and balloted and the votes and comments from the balloting process need to be tallied, tracked and managed against document drafts.
• Interpretations (bug reports) need to be managed against published standards.
• Amendments need to be managed against the history and evolution of the standard specification.
• Many organizations develop software reference implementations for the specification, and the source code needs to be managed as a software project as well as against the specification (and its drafts).
• Some organizations develop test suites for conformance verification and validation against a standard, and again both the software itself needs to be managed, as well as the link to the specifications.

While different standards organizations exist to fulfill different missions, and so have different structures, policies, and practices, this lack of underlying consistency leads to a diverging base of information rather than a converging one. Regardless of the differing policies and practices of the standards development organizations, the friction in the system is common and causes lots of problems.

• Every working group and organization tackles these problems in their own ways, cobbling together the tools and processes that meet the standards development organization’s (SDO) policies and procedures. It is labour intensive, repetitive, and best practices seldom surface across diverse tools and organizations.
• History and knowledge are lost, both in process and content.
• Participation in the process is limited.
• Promulgation of the work can likewise be limited.
• The resulting specifications that become standards are generally not accessible and searchable in a consistent way.
• The quality of the specifications can suffer due to a lack of infrastructure and support.

In the end, regardless of policy and procedure tied to specific SDO, they all need the same basic toolset to support the process. Google has the building blocks in http://code.google.com and “Google Apps for your Domain” to develop http://standards.google.com providing the tool infrastructure and best practices to solve many of the friction problems faced by standards developers.

Regardless of an SDO’s policies and procedures, individual working groups can more easily deliver standards that meet the needs of the SDO and its constituencies in ways that would make the standards more discoverable, accessible, and useable. Using this as the opening olive branch, while developing a strategic standards office would put Google in an excellent position quickly.

Google is in an excellent position to begin their standards strategy function. The effort should be undertaken soon to provide the best most effective platform for success in this strategic area going forward.