When Billions Aren't Enough

Our favorite anti-open source article, "Winning the Linux Wars", suggested that Microsoft partners should be "Playing the R&D card" by emphasizing that "Microsoft invests north of $6 billion a year on R&D. There is nobody in the Linux world that does that."

Well, Merck (MRK) invests about $4 billion a year in R&D. Bristol-Meyers (BMY) $669 million. Eli Lilly & Co. (LLY) $2.7 billion. Pfizer (PFE) $1.8 billion. Sanofi-Aventis (SNY) a whopping $10.2 billion, or nearly half of its $20.5 billion in revenues. Together, that's about $19.5 billion a year in research and development.

Apparently, though, that's not enough. This Friday (January 20, 2006), The Wall Street Journal's "Science Journal" ran article entitled "In Switch, Scientists Share Data to Develop useful Drug Therapies" which pointed out that there is a "crisis in 'translational science,' or turning basic discoveries into therapies," and that only twenty new drugs were approved by the US Food and Drug Administration in 2005.

One billion a drug, approximately.

More importantly, the article points out some interesting trends:

1. The pace of basic biomedical research is outstripping the pace of translational research. In other words, we're learning about genetics and biology faster than we're able to make drugs based on that knowledge.
2. As a result, foundation grants have not produced concrete results of cures for illnesses.
3. In response, the foundations are now shifting funds from basic research into therapies, taking over a role once left to industry.

No doubt much of the problems here is specific to the pharmaceuticals industry and the fact that we are in between sciences: the traditional pharmaceutical companies continue to research chemical cures, while basic research is focused on genetics.

Nevertheless, the fact that non-profit foundations are now moving into product development suggests that the fundamental research and product development model is encountering problems. Usually, a well-financed industry (and few are as well-financed as major pharmaceuticals: MRK, LLY, PFE, and BMY have $43 billion in cash and short-term investments between the four of them) should be ideally positioned for product development, while only basic science needs charitable support.

But there is hope: one key gene for multiple sclerosis could now be turned on and off in mice "a year sooner than they would have been, thanks to a unique collaboration that is slaying some of the most sacred cows in bio-medicine."

What is the unique collaboration? Sharing knowledge. The foundation which sponsored the research is apparently requiring the scientists it funds "share results in real time," rather than keep their discoveries proprietary. As a result, it has made the scientists feel more accountable for their work and therefore become more engaged in curing diseases.

The parallel with open source is clear. There is a real benefit to research and development when knowledge is shared. Other researchers could extend your work in new and novel ways. Furthermore, there is transparency and accountability for your work. That transparency in turn grants prestige and recognition, which are often powerful motivators. Perhaps this combination explains why academia has always been, and continues to be, a very efficient way to do research, even though their budgets are limited compared to industry.

The parallel from open source is also interesting. If open source and collaborative development is a successful model, could it help make research and development in other fields more efficient? The medical industry is sliding from open knowledge and collaborative research into a proprietary world of patents, licensing, and investors.

But if the billions aren't enough, should they be considering a return to open collaboration?

Will Microsoft Win the Linux Wars?

Open source advocates should read Winning the Linux Wars in this month's Redmond Channel Partner magazine. Emblazoned with tanks and missiles, the feature article boldly proclaims that "[Microsoft] partners should relish the opportunity to compete with Linux, and they should win every time."

How? By making total cost of ownership comparisons which highlight the following advantages of Microsoft products:

1. More complete feature set, which could be very costly to develop in their open source equivalents.
2. High cost and difficulties of finding or training people with Linux skills.
3. A clear and coherent future for Microsoft products, thanks to its size, dominant market share, and research budget.

Some of the article's arguments are downright silly, while others point to legitimate weaknesses in the open source model as it exists today.

The Silly

For example, the article claims that "because open source software is readily customized, there's no guarantee that even a specialist fully understands a particular company's exact flavor of Linux."

Come on. This is like saying buying a popular model car is riskier because too many mechanics would know how to fix it.

The Gap

A more legitimate concern is that while open source software comes without licensing costs, it could be more expensive for a single user to complete all of its "missing" features than buying a commercial package. Despite all the advances in open source software, this actually often happens.

This may not actually be a problem. Open source software is developed on an "as needed" basis, with new features implemented as users need them. In contrast, commercial software is developed according to a product vision which could often be bloated with features most users won't ever use. Therefore, an open source solution with fewer features may actually be better for the user.

We would be deluding ourselves, however, if we thought this is always the case. There are many features which users do indeed want but do not find their way into open source software. Some of these are high performance "enterprise-class" features. Others are user-friendly convenience features. Still others are industry-specific features that fit the needs of a smaller market niche. Finally, there are the strategic "killer-app" features that a user does not know she needs today but would rush out to buy whichever software offered it tomorrow.

In these areas, the commercial software model has a fundamental advantage: commercial software vendors can spread development costs across licensing and support revenues from many customers. In contrast, a pure open source model relies on incremental contributions from a large pool of user-developers. To work at all, this model requires a large number of technically capable users, since at any one time, only a small percentage of them can be expected to contribute back to the project.

Such a development model can be highly efficient but would not address some important market needs. For example, it cannot help non-technical consumers who cannot develop the features they want themselves. (Think about 100,000 users with $10 each to spend. That's $1,000,000 of development which would probably never find its way into open source.) It also fails when, based on the laws of probability, there are simply too few users to create a large pool of developers. Finally, it would also not work very well when the users themselves could not envision the features they would actually need.

This is a serious gap which, if unsolved, could leave open source software as niche solutions for technically-savvy users who of commodity horizontal applications. If open source is to branch out and grow in other areas, new models for financing the development of open source software must be found.

We should, however, not fear: open source is the embodiment of the free market, and free markets by their nature innovate.

Our Archilles's Heel

Most importantly, "Winning the Linux Wars" correctly points out that "... the open source environment's Achilles' heel is supportability and maintenance."

There is a myth out there that there is no support for open source software, and that myth creates enormous anxiety. Lack of support means down time, down time means lost revenues and, more importantly perhaps, lost jobs. In reality, this is a myth: there often is actually better support for open source than commercial software (especially if you know how to get it.) Nevertheless, most IT managers do not like the idea of using mailing lists to track down support or expertise, so readily available support and expertise continues to be a key hurdle to open source software in the enterprise.

What It Really Means

Stepping back for a moment, though, it's not hard to see that support is really a codeword for credibility. Most buyers of commercial software don't actually verify that its features are bug free or check out its support lines. Instead, their "due diligence" consists of making sure that there are other users using the software, including, most importantly, their golf buddies.

Who then makes open source software credible? Today, it is usually the IT department of a company. Someone in IT, such as a systems administrator or developer, may try an open source application, get familiar with it and its community, and then start to convince others to use it. This person is then the ambassador or advocate for open source in the organization, and the adoption of open source software has traditionally meant winning over IT departments.

If open source is to gain popularity and move "up the stack", however, open source software will need other advocates in the enterprise. Somebody else besides the IT department must also be able to convince enterprise users that open source software is indeed a credible solution. Whether that advocate ultimately is a consulting firm, a distributor, or an ISV using open source software, we don't really know yet.

What we can be certain of is this: whoever makes open source a credible in the enterprise would ultimately win the "Linux wars."

Can Open Source Fill a Vacuum?

We often hear about open source vs. commercial software, but what about when there is no commercial software?

Believe it or not, this actually happens. Last month I was at an industry tradeshow, and I walked into a conference session about software. In of itself, this was a rarity--usually, trade show attendees are too busy buying and selling to listen to software vendors. The closet you might get at one of these shows is a talk on search engine optimization or email marketing.

Even more amazing, this session was well-attended. After a while, I realized why. This industry had no commercial software vendors serving it, because it is an industry with a lot of small businesses and very complicated business processes. The former means that specialized commercial applications vendors couldn't serve them profitably. The latter means that off-the-shelf desktop accounting programs couldn't really satisfy their needs.

In this industry, people referred to their software as "Tom's program," and programmers like Tom were retiring or leaving the business. As a result, the industry is technologically a decade behind. Out of an audience of fifty, only one company was taking orders online. This is truly a software vacuum.

Can open source fill this vacuum? Possibly. Of the three groups presenting at the software session, one was a consulting firm which was using open source databases and languages to create a fairly sophisticated commercial package for this industry. Two other groups were users who had built their own in-house applications and were looking to start software development co-operatives with their peers.

This shows that there are two ways open source can fill a vacuum. First, by leveraging existing open source projects and tools, a commercial product can be created much more cheaply. Thus, commercial vendors may be able to serve these niche segments that would be un-economical for vendors who don't use open source software.

An alternative strategy is the pure collaborative or community model of software development, modeled after successful open source projects. In a sense, this is going back to the earliest days of business software, before there was commercial business software. Back then, companies would collaborate on software development by sending tapes reels in the mail. Today, collaborative development has progressed much farther with the Internet as its distribution vehicle and open source project management being much more mature. By following best practices from successful open source projects, a collaborative development effort would be much more likely to succeed.

Whether either of these models would ultimately fill the vacuum in this industry remains to be seen, but one thing is for sure: people and businesses do need software, and if there is a vacuum, open source is a logical way to fill it.