The business of software

After the usual foreword, Michael Cusumano opens his book, The Business of Software, by outlining the main chracteristics of that business:

In how many businesses does making one copy or one million copies of your product cost about the same? How many businesses have up to 99 percent gross profit margins for their product sales? In how many businesses do many products companies eventually become services or hybrid companies (that is, providing some customization of product features and technical services such as system integration and maintenance), whether they like it or not? In how many businesses is there frequently a ten- or twentyfold difference in productivity between your best employee and your worst one? How many businesses tolerate some 75 to 80 percent of their product-development projects routinely being late and over budget, with "best practice" considered to be 20 percent on time? How about a company where people who build products often consider themselves artists rather than scientists or engineers and have the mercurial temperament to go with it? In how many businesses are customers "locked in" to a particular vendor because of product decisions someone made a decade or two ago that can't easily be reversed?

…[G]et the strategy and the management side right, and the software business can be like having a license to print money…But get the business model wrong, and—to borrow a metapor from Frederick Brooks's The Mythical Man-Month—software companies can resemble dinosaurs futilely trying to escape the death grip of an ancient tar pit. The more you struggle—that is, the more time, money, and people you pour into product development, sales, and marketing in the hope of a turnaround—the deeper you sink and the quicker you die. In the software business, this is not only because the more people you add to a late software project, the later the project can become—a rule of thumb now described as "Brook's law" (and not always true). But the broader downward spiral can accelerate for a whole company and become self-fulfilling as present and potential customers flee from software producers unlikely to survive long enough to deliver, support, and upgrade their products.

Cusumano's summary strikes all the important chords when it comes to describing the characteristics of commercially produced software. It misses some important characteristics of open-source software communities and economic networks dependent on them.

In an open-source, community project, which (company or private) participant is the producer? Who is paying the production cost? Who is reaping the benefits?

However, when it comes to a business built on bundling of open-source software or on applying such software to solve specific problems through various kinds of software extensions and customizations, we return to the general laws described by Cusumano.

Then, there are a whole set of companies that may appear to some as software companies, say Google, but they are in fact not software companies at all even if they may produce a great deal of software.

This class of companies are indeed more like modern-day AT&Ts or Sprints. Modern day equivalents are web service (e.g. Google Search) or content (e.g. YouTube, Orkut, etc.) or Internet communications (e.g. Skype) concerns. Cusumano's description does not really apply to these companies either. These companies are not in the business of selling software but rather in the business of selling service for a fee (subscription or advertisement). They do software to the extent it helps them to render their services useful and appealing.