Why do projects based on open source products often ultimately fail?

Jeff,

Upon what basis are we determining that projects based on open source products "often fail"?

The general statistic is that *most* projects (over 50%) fail. And only some of that failure is due to technical issues. It has not been my experience that projects with (or based on) an open source component fail with any more or less frequency than other types of projects.

Ultimately the success of any technical project is dependent on the following:

-- Communication
(about the benefits, the changes, who will be doing what, when and why)

-- Planning
(understanding possible technical or political issues, and making allowances for them)

-- Preparation
(getting people and things in place beforehand, rather than at the last second)

-- Senior Management Support
(projects that are driven from the bottom vs the top, in terms of support by senior management, will usually fail -- actively or passively)

-- Clear benefits
(for the people who must ultimately use the product or service being deployed)

-- Built on good processes
(technology must be driven by processes and not the other way around)

-- Skill and training
(well skilled technical people for the deployment, and well trained business/technical people for the ongoing use and operation)

As you can see, most of the above list is not even limited to technology-based projects. All sorts of business projects live or die by the same principles.

For open source projects, these same rules apply, independent of the cost of the software involved -- especially since the cost of the software or product itself is but a tiny part of the overall cost of deployment and ongoing usage.

-ASB: http://xeesm.com/AndrewBaker

Just wanted to thank Andrew for a great comment. We need to do all of these things to produce successful projects in IT and he provides a great concise list of reasons why all sorts of projects fail. Part of my post is that we often rely on the budgeting and procurement process to provide the triggers that these processes are needed and that open source projects can bypass the trigger point and may begin with an additional handicap.

Hi Maarten,

Of course, everyone implementing a standard (like IETF RFC ####) _should be_ consistent to it. But that's not what I was talking about. In fact, I don't believe I mentioned a standard. The only place I used the word "standard" was in "non-standard APIs". Perhaps a better way to say this would have been "APIs that are inconsistent with other APIs in the same package."

An API, or Application Programming Interface, is often not standard. Vendors of proprietary software try to keep all the APIs in their products consistent (they write to their "standard" for APIs) I've heard that in some FOS products, everyone who writes a new feature adds the API he wants to write, and there is no consistency between APIs in that FOS product. Having a consistend (or standard) API allows users of the software to minimize their learning curve and makes it faster and easier to use the software.

You misquoted me when you said "open source service companies keep the non-standardization alive." What I said was "What incentive do these [FOS support] companies have to make Linux easier to port, easier to use, easier to enhance, and easier to maintain?"

You also said in a previous email:
"However, in the open source community, you can have literally millions of developers releasing product updates and patches, faster than any commercial product, that relies on lengthy quality control prior to release..."

Let's look at two fallacies in your statement:

First, you imply having millions of developers is good. Think of a boat with a dozen rowers. Unless they are coordinated, you'll never get anywhere. Some rowers will even be working at cross-purposes to other rowers. Millions of developers working without coordination do not always yield a great product.

Second, how many of these updates and patches are actually needed? Would they be needed if the original program had gone through a proper QC cycle? Are many of the defect resolutions necessary to fix a problem caused by a previous update or patch? Perhaps the need for so many updates and patches is caused by this lack of quality control to begin with.

I really like this kind of honest and very knowledgeable discussion, love intelligent people. However, i think we should define our problem first, in a kind of philosophy manner, that is from a global perspective (please pardon me for my English writing, I am a Spanish speaker). I would love to start by defining failure first, then move into the discussion of the subject which is open source project failure. I am not a philosopher or a linguistic or anything important (not even a good programmer), just a social been that is trying to make sense of our existence and think monopolies and capitalism is stooping human social evolution. So, here it is: Failure= does not work or does not do what it is suppose to do. However, we could define failure as not being popular, not making money, or perhaps everything that goes with a non open source project, including corporate capital accumulation and moving resources from millions of hand into a few (like MS). I personally think that the technical part is not an issue here, but other things such as marketing, and economic results to motivate project participants, who are part of an economic system that has been designed for us and we have to survive in it (pay bills and taxes to support people who don't work). Again pardon my broad perspective, but everything is connected and we should think on all the factors. So, let's think about failure first for a moment and then move on to look at the factors.

Sometimes open source products is also open to vulnerabilities to viruses and other system weaknesses. Open source products do not take into account the changing types of attacks and how to defend from them.

Andrew,

Couldn't agree with you more. Indeed, we also need to distinguish what "open source" really is; do we mean "free" as in "speech" or as in "beer".
Dave here, for example, is COO of a company providing a fantastic "free speech" offer what is concerned "open source". But is does not come "free as in beer".
How can it? Nothing comes for free...

AndI'd like to think that commercial open source provides better quality for all of these reasons and more:
* Customers can read your source, and can assess the quality better
* Commercial open source is still somewhat frowned upon, so quality needs to be "better" if it wants to make name for itself
* If you have the source code with the product, integrating into your business needs can only be simpler...

Then, if we go to community supported open source, following Brian's comment, I can only partially agree. It is true there is absolutely NO guarantee whatsoever if you use community based software (whether open source or not). However, in the open source community, you can have literally millions of developers releasing product updates and patches, faster than any commercial product, that relies on lengthy quality control prior to release...

So, as a conclusion I could state that any hybrid solution offers the best choice for your project, and given the integration comment I made, you could even say it would offer a better chance of success. However, that would then rely on your human capital and its ability to deliver... But here's where the specialist service companies come in ;-)

My 5 cents...

One easy reason that some open source projects fail is that the author deprecates the package in favor of one of the many other packages that do the same thing. But proprietary software companies have gone out of business, so that's not unique to open source. Its just more prevalent because there's often no way to get an answer about how long the author (or team members) will continue to support open-source for free.

First, there are all different levels of quality in free open source code. The more used the code is, the more one can hope that its high quality. So the experience you have with Linux may be far different than you have with a specialized, esoteric package like an open source SNA protocol stack (if such a thing exists at all). The following issues are found more with the specialized, nich open source software packages more than the general widely used packages.

Some of the issues my customers complain about with open source are the lack of documentation, and the non-standard APIs.

Lack of documentation is self-explanatory, not many engineers want to "waste time on documentation”.

Customers have complained that the APIs of open-source each have to be learned individually, there is no commonality. Each author does what they think is best (or easiest). While this may fit the author’s needs, it’s not a general implementation, and the next engineer to use the code often finds that they need to expand the API, and each expands it in the way they think is best.

This lack of commonality continues into the code, open-source is often “spaghetti code” where each contributor adds exactly what they need in the style that they like. While a prettyprinter can enforce tabs, bracketing conventions and the like, a bigger issue is with style—case statements vs. if-then-else statements (or C’s conditional operator) vs. jumptables vs. mathematical operations (more often used in DSP type code). And the biggest issue with the code, IMO, is the naming conventions used for functions and variables. Great names can lead to a better understanding of the code, making enhancements and debugging easier.

So the lack of documentation, variety within APIs and lack of coding conventions all hamper the use of free open source. But while these are all implementation considerations; there is also a strategic issue which is easily grasped if you follow the money.

Let’s use Linux as an example, even though its a very widely used, heavily maintaned open source project. Linux code is free, but there are many companies making money on supporting Linux. What incentive do these companies have to make Linux easier to port, easier to use, easier to enhance, and easier to maintain?

A company that licenses proprietary code often offers support of that code. They have a great incentive to make the code require little or no support. As a result, their customers get used to having a great experience with that product—portation is quick, maintenance is easy, and enhancements are not hard at all.

It’s not hard to imagine a higher level manager thinking that portation of proprietary software is just a portation, and portation of open source code is just a portation, and then equating the two. And once the use of open source starts, the final project is only one more bug away from completion. And it stays “just one more bug” away for months.

Hank, please allow me to comment on yours.
I can only see this being potentially true, in a free open source environment. Not in commercial open source. There I can only see your comment on the "proprietary code" and here come the benefits I previously mentioned, in addition into play.
However, I absolutely disagree with the statement that open source service companies keep the non-standardization alive. Any good open source service company would seek to implement standards. If only to interface with other software. You must be mixing with the wrong crowd :-)

My previous comments on "commercial open source being frowned upon" is exactly illustrated by your comments.
Please distinguish "free beer" and "free speech" :-)