Predicting open source success

The qualification(s) for being able to make a prediction is oftentimes frightfully sparse. Usually the only one that matters is that a person is willing to put himself out on a limb. Accordingly, predictions are made (and subsequently proven wrong or valid) everyday. However, it's one thing to make a split second prediction based on a 'gut feeling' and another to make one based on a thorough forecast.

Within the IT spectrum product and services are launched daily to a whole host of predictions and evaluations. Along those same lines, when I am asked to predict or forecast the success of an open source product, I use a set of tools and approaches to make it easier to factor in:

1. Product design
2. Execution model
3. Market demand

All of the above factors help gain a better understanding of what the product/service is and how it fits into a bigger picture. Interestingly, enough the same factors are useful not only to industry analysts but also for potential users who are in the process of evaluating a product.

Product Design
The topic of product design is not as technical as it sounds. It actually has just as much to do with the manner in which a product is packaged and delivered as it does with how many user interface widgets there are across an application's main window panel. Solid product design for open source software is an enabler of, among other things, [comparatively] widespread use, community participation and advocacy amongst a user base. Here are some questions that need to be asked in order to determine the potential for product adoption.

1. Does the product meet the functional needs of its target audience?
2. How easy is it to download, install and run binaries/source distributions?
3. Does it take unusual or special skills to configure and set-up an environment for use?
4. Is the product aligned with larger, related efforts?
5. Does design reflect the product's intended purpose?
6. What hardware dependencies are there?
7. How easy is it to contact a member of the product development/support team before support has been purchased?
8. Are the product's benefits immediately obvious?
9. Can the user intuitively learn to use secondary features?
10. How long has the product been stable?

Execution Model
Whenever open source business models are mentioned, topics like support/subscription, license indemnification, technical architecture, etc. are all touched upon. However, it's very rarely that each of the aforementioned are discussed within their shared context: The Execution Model. Where a business model represents an approach to generating revenue and profit; an execution model is the approach to initiating the set of actions that enable actual sales. An excellent execution model is essential and can be evaluated by examining the following areas of activity:

• Competition: potential market share not only amongst the open source industry but also overall IT.
• Distribution: VAR's, System integrators, independent consultants.
• Financing/funding: Venture funded, government/non-profit backed, self-funded
• Partnerships: ISV's, larger software companies, industry-specific open source groups a la the Open Management Consortium.

Market Demand
High quality, in-depth market research is as valuable a tool as good advertising and PR. However, it isn't the easiest subject to tackle, often requiring significant experience and sufficient background doing so. Data taken from accurately crafted surveys is required to gain a firm estimate of demand for product and services within a market (potential or otherwise). Still there are some straight forward methods of defining and describing a market.

1. Evaluation and analysis of competing and/or comparable products: How well are proprietary alternatives doing? What are the health indicators for other companies who sell similar products. Open source products have experienced the most success (so far) when they can serve as cost-effective, but feature equivalent, alternatives, i.e. JBoss
2. Readiness of the global open source development community: Are there enough developers who have experience with products (proprietary or open source) who could contribute to the growth of the product's code base? This area has plagued open source scientific applications for years. The demand from a user perspective is sufficient (see: the global scientific community), but there are not enough developers who have experience writing those types of high quality applications to churn out good, stable code.
3. Consider the potential group(s) of users and adopters: How many businesses of all sizes, organizations, individuals, etc. can be counted on to consider using the product. Consideration does not make potential users per se, but it does provide a vague idea of the level of widespread adoption a product is capable of. Other factors such as barriers to adoption must be factored in as well.

While a great deal of the above strategies can be/are applied to varied offerings from consumer products to business services, open source software is a unique subject that requires an adjustment of thought and action when it relates to determining success potential. No single approach can be considered 100% full proof as forecasting is just that, forecasting. There never has been nor will there ever be to tell what is going to experience success and what will not. However, there are ways to focus on commonalities amongst successful efforts in order to determine if they exist in others.

Technorati Tags: IT product success |  open source | market forecasting | predictions

Comments

[Anthony Gold]

Alex,
Nice post on predictions and the open source world. From one who works closely with the analyst community, your message resonates well. Perhaps one other point worth mentioning when predicting the success of a new open source product is the value it creates in the user community. One could argue that Market Demand (or Product Design – meeting functional needs) captures this value creation, but in some cases they may not. For instance, a large number of open source projects enable legacy applications to be rebuilt (or services wrapped) to create much greater flexibility (easier to add new features, greater ability to mine silo’ed legacy data for more effective cross-selling, etc.) plus a lower cost of support (licensing/support fees). So, whereas the functional needs being met are certainly a given, Value Creation is another factor to consider when assessing potential success.

Anthony Gold, Unisys Corporation