I've posted elsewhere (http://advice.cio.com/esther_schindler/how_do_enterprises_learn_about_open_source_alternatives ) several key, evaluative criteria for determining the wherewithal of an open source software vendor / provider. Here, I'll refine the criteria to assuredly answer Esther's question.

Open source software should be considered along mostly similar, but somewhat distinct, lines as proprietary software. Similar to proprietary software, open source products should be evaluated based on functionality and capability - to ensure the enterprise implements the technically best (or at least sufficient) offering. Then, to determine whether an open source product or vendor is "safe for enterprise adoption" (beyond product capability / functionality), here is a checklist of items that are distinct from proprietary products / vendors:
a. Ensure it is available from a commercial open source company that has the resources and licensing mechanism to ensure your success (including customer support).
b. Check the size and vibrancy of its community (which, even better than annual revenue, helps to determine the likely success possible with its products).
c. Try to learn how many production deployments are in use (by other commercial enterprises), which is a strong indicator of the product's (and the vendor's) ability to really deliver.
d. Then, use all the standard evaluation techniques used with proprietary vendors (quality of the product roadmap, strength of the company's personnel, availability of training and professional consulting services, etc.).

Finally, we're at a place where open source isn't just about better value. We've really hit a place where the best commercial open source solutions are reaching value/support/functionality parity with proprietary solutions. What does this mean for the choice customers will make? The value proposition for many proprietary solutions are just not going to be there any longer. By applying this brief checklist against these vendors, an enterprise can reduce its risks and improve the likelihood of success with open source software. Reaping the rewards of very high quality software at (typically) a fraction of the price of proprietary alternatives makes this exercise well worth the time.

Brian Gentile
JasperSoft

Esther,

Let me take a stab at answering this one.

What are the leading indicators that an open source company is safe for enterprise adoption?

I don't think the fact that a company is "open source" much changes the analysis that an enterprise consumer should do. Or in other words, enterprise adopters already know what questions to ask because they've been doing this for a long time. Don't let the "open source" tag change your evaluation process.

As an enterprise consumer your desires are longevity of the technology, avoiding vendor lock-in, solid support, vendor stability and clean IP. In my view, a healthy and dynamic open source project and community only impacts the first two of those parameters in vendor selection, and even then only moderately.

There was a subtle point implicit in the statements above. Namely, my assertion that the inclusion of open source has a minimal impact on the IP cleanliness of a vendor’s products. Our experience at Eclipse is based on analyzing several hundred open source projects for their copyright provenance, and generally speaking our view is that most open source projects do a pretty good job of tracking contributions, managing their participants and fixing problems immediately if any are found. Software patents are a hold other kettle of fish, but there is nothing in open source that makes a patent infringement more or less likely than proprietary software.

But in the end most "open source companies" are typically going to try to sell you a commercial license for a software product, and you need to evaluate them as such.

How does an open source project's revenue/business model affect an enterprise's willingness to adopt it?

I note that you’ve now moved from talking about an “open source company” to the business model of an “open source project”. I find this conflation of OSS projects and business parameters a distressing trend. OSS projects need to be evaluated in terms of openness, transparency, activity, adoption, diversity and the like. Software companies need to be evaluated in terms of business models, installed base, funding stability, depth of management team, customer service and the like. Mixing the two is almost guaranteed to provide a confusing result. And in the end, any open source project or community which is only supported by a single vendor has to be analyzed by consumers with that fact in mind. Because the ability of such projects to out-live the demise or strategy change of their single backers are limited. Certainly there are some that have, but there are many more that have quietly withered and died.

We have recently seen several spectacular acquisitions that prove there is a robust business model behind the open source movement. After attending the Open Source Think Tank held in February, 2008 at the Silverado resort, I am convinced that a best-practices model is emerging for enterprise open-source software vendors.

In honor of the think tank event, I am dubbing these practices the Silverado Rules for Open Source Success. Open-source vendors should adopt the following best practices to optimize community participation while developing a viable commercial business:

1. Fix the last mile problem. Make sure that your open source product is ready for contact with non-bearded humans of less than super-human programming capabilities.


2. Optimize for community and commercial growth. Increasingly, community success drives commercial adoption and vice versa.


3. Play by the community rules. Pay attention to what constitutes a "win" for community developers and protect their interests as jealously as you protect the interests of commercial customers.


4. Implement role-based pricing. Give away the development tool/razor and charge for the server deployment/blades.


5. Enable on-site and on-demand deployment. Give customers flexibility in how they deploy your solution.


6. Adopt a dual license strategy based on GPL + Commercial License. Enable a true open source community while providing a path to commercial success.

Following these rules may not lead to guaranteed business success, but ignoring them may well lead to failure!

One way a company can ensure a positive business model is by showcasing customer use cases where they have a significant return on investment in the use of the open source solutions they are providing to their customers. In addition, the company can also leverage the customers view points on the ROI against expensive commercial competitor to the low cost open source solution.

For example, FTD, one of the largest floral companies in the world, went looking for such an alternative to power the external reporting for its mission-critical ARGO shipping administration system, built on Oracle. FTD saved 83% in Oracle license costs by moving their reporting from Oracle to EnterpriseDB Advanced Server, the world's leading Oracle-compatible database.

FTD was able to:

Offload reporting from production order-processing Oracle servers for one-sixth the cost of new Oracle servers
Improve performance by 400% to support peak-volume Mother's Day season, without costly hardware upgrades
Run existing Oracle Reports with little or no modification
Automatically replicate data on Oracle servers to EnterpriseDB
This real-world case study explains how EnterpriseDB open source solutions helped make FTD's Mother's Day rush an overwhelming success.