The 80/20 Myth

There are three types of lies--lies, damn lies, and statistics.

- Mark Twain or Benjamin Disraeli

One commonly cited statistics about open source software is that for any given project, 80% of the code is written by ~ 20% of the developers.

Although this statement is factually correct, its interpretations are often not. For example, some have used it to suggest that the development of open source software is not that different from the development of commercial software. Others have used it to justify the excluding community participation in the development process.

These interpretations assume that the value of software is directly proportional to lines of code, which is simply not true. Consider:

1. The amount of time and effort required to get an 80% completed "alpha" release to a production release. How many of us have sat and waited for something that is "almost done"?
2. The amount of time and effort required to gather the requirements and features in the beginning of a project. Look around your own company or at your vendors. How many people actually write code versus write use cases, gather requirements, manage projects, and perform QA?
3. The biggest risk, and therefore one of the biggest costs, of software development is mis-specification. More software projects fail because of incorrect or inflexible specifications than any other reason.

When these factors are considered, it turns out that producing code is sometimes not even a majority of the cost of producing software.

This is where open source development processes can really reduce the costs and risks of software development. Open development processes are fundamentally collaborative. Developers and users work together to discuss what an application should do, how it should work, and how best to implement it. When a developer writes the code, others in the community help test it, report bugs, and even suggest fixes. These activities can be immensely valuable even if they result in relatively few lines of code.

Furthermore, over longer periods, the cost of maintaining software dwarfs the cost of producing the software. In open source communities, ongoing maintenance is spread over a large community of users and developers. Some will try novel uses or find new bugs. Others may think of new features and extend the application. Thus, the costs are not concentrated at any one particular user or developer organization.

The result: a better product with lower costs and less risk.

The Grand Experiment

A few weeks ago, someone asked me what I did. I was at a loss for words (yes, it happens to me too.)

What do I do?

Why am I starting a company called Open Source Strategies??

Later, I realized why I was at a loss: Unlike most of my peers, I'm not betting on a particular technology. Instead, I'm conducting an experiment, which comes down to this:

Can we make software better with open source processes?

More specifically:

Can we develop better software?

• Would collaboration allow us to get better ideas?
  
• Is remote, asynchronous development more efficient?
  
• Can a collaborative environment attract better developers? (In other words, are there smart people working outside your company?)
• Can peer review help us write higher quality software, with more flexibility and fewer defects?

Can we build better software businesses?

Could software vendors:

• Reduce the cost of developing software by using existing open source code?
• Avoid wasteful R&D investments with a tighter vendor-user relationship?
  
• Lower distribution costs achieved through an open source model?
  
• Move to a demand-driven business model? (In other words, what we've been telling those other industries to do.)

Can we meet the needs of users better?

Would users benefit from:

• access to source code?
• greater flexbility in customization?
• taking control of support/maintenance decisions?

Collaboration is at the heart of open source software. It changes the way software is created and brings together users and developers across traditional boundaries. What I'm trying to figure out is:

Can a knowledge intensive field like software benefit from collaboration?

I do not believe we can replace the commercial software business model with an open source one. Rather, I wonder if we can bring together the best of both worlds--the innovation, creativity, and efficiency of the open source model and the resources and organization of the commercial one.

Marketing gurus say everybody needs a mission statement. Here's mine:

Making Software Better

Can Open Source Survive?

Thoughts on another commonly asked question about open source software.

Another common question people ask about open source software is:

Who will be around to support it?

Open source software is not singled out for persecution here. The availability of long term support is a key concern for enterprise users. Smaller commercial software vendors are often asked to disclose their financial information to prospective clients. Their larger cousins are, in turn, peppered with questions about potential mergers, acquisitions, or restructurings.

There is an added concern with open source software, though. Many users are concerned that companies which "give away" their product are repeating the worst follies of the dot-com era. In other words, will you be around to support me?

The answer is usually YES. As an open source project becomes mature, there will emerge many viable options for support. In fact, support prospects can be better for open source products, for one simple reason:

With commercial software, you depend on a single vendor for support. In open source, you can rely on a whole network of other users and suppport organizations.

With commercial software, the original vendor is the one with the source code. There may be various partners, but without access to the source code, what they can do is limited. The vendor will support its products because that's what its customers want, but it may stop doing so if:

1. it goes out of business;
2. it is acquired, and the new owners have other plans;
3. it decides, rightly or wrongly, that it can no longer afford to continue supporting this product;
4. it wants its customers to upgrade to a newer version and strategically decides to withdraw support for an older one.

In addition, remember that the focus of a commercial software vendor is generating new licensing revenue, not supporting existing installations. This is what their investors want, what their sales and marketing teams' mission is, and what their best engineers are reserved for.

In open source communities, by contrast, there is an active support ecology of users, developers, and service providers. Users and developers support each other through mailing lists, while service providers offer their clients commercial-quality support through traditional formats.

Thus, open source support is never dependent on any particular group being around. In fact, as long as there are other users, there is support for an open source project. The loss of a particular group in the support network could even be viewed as a business opportunity for others to jump in and fill a vacuum.

Now let's consider an interesting real life example:

In 1998, Netscape open sourced its browser under the Mozilla Foundation. At the time, Netscape had a multi-billion dollar market value and was one of the most influential companies in the industry. Most people would have bet on Netscape rather than the open source Mozilla Foundation to continue pushing its product forward.

Yet exactly the opposite has happened. In 2004, Time Warner which merged with AOL which bought Netscape announced that Netscape 9.0 would be the last release of this once revolutionary product. In the meantime, though, Mozilla lives in open source and has been reincarnated as the Firefox browseer. With all the security concerns about Internet Explorer, it is now gaining market share at IE's expense, in an unlikely sequel to the browser wars.

So there you have it: The flagship product of a multibillion dollar commercial software vendor has disappeared, while its sibling lives on and thrives in open source.

Now do you think open source can survive?

Is Open Source Secure?

Some thoughts to one of the most commonly asked questions about open source software.

Here is a commonly voiced concern about open source software:

If anyone can contribute to open source software, doesn't it become a free-for-all full of loopholes?

At the simplest level, the answer is just NO. This statement involves a basic misconception. While anyone can propose a contribution to an open source project, any actual change must go through a small core group of maintainers first. Getting a change incorporated into an open source project is thus rather like getting an article published in a scientific journal.

At a deeper level, though, there are some real reasons why open source software can actually be more secure than their commercial counterparts. They have to do with how possible flaws are discovered and the motivations of parties involved.

Discovering Bugs and Security Flaws

Open source software is more heavily tested than their commercial counterparts. A commercial software vendor might employ one, maybe two, testers per programmer. Those testers often follow pre-written test scripts and address a finite range of use cases.

An open source project, however, might have tens or even hundreds of thousands of downloaders around the world. Each one of the downloaders may subject the software to a different use or operating environment. Any one of them can discover a bug or security flaw and submit those reports back to the project.

Once the Flaw is Found

What happens once the flaw is found?

If the code is openly available, a bug or security flaw can be definitively proven. A patch could be suggested and posted on the internet. At this point, there is only incentive to fix the flaw and no real incentive to hold back. Users would obviously want the problem solved as soon as possible. Any service provider would use it as an opportunity to demonstrate its value added by fixing its clients' installations. The project's core maintainers, while potentially embarrassed, have no further reason to cover up the flaw. In fact, if they do not fix the problems quickly enough, other community members can take matters into their own hands and start an open source derivative of the original project which incorporates the needed fixes.

In the commercial world, in contrast, things are not always so clear cut. The code is not available, so bugs or security flaws may be hard to prove. The vendor may have already made promises to its customers or statements to the press about how secure or bug-free its product is. Admitting to the bug or flaw may incur negative publicity or, worse, wrath of the marketing department. So, if the flaw cannot be definitively proven or is not generally known yet, maybe it would be better just to keep it under wraps and fix it in the next release?

But now I'm just being paranoid. This never happens in real life, right?