Open Source Considerations

As I’ve mentioned in an earlier post, I believe open source absolutely has a place in the enterprise; and that enterprises have some responsibility to contribute back (resources, code) to the open source community. Of course, on both ends, you need to be smart. Understand the implications of licensing, IP (yours and theirs), support (yours and theirs), code quality, security and stability, project adoption and longevity, and total cost – because nothing is really free.

In that same post, I also promised ‘more another time’. That time is now. Last week, I wrote an Open Source Considerations report for PSGroup. In the report description (and introduction), I state the following:

Since every enterprise is different, we believe it would be irresponsible to make blanket statements as to where you should, or shouldn’t, be using open source. Instead, in accordance with our standard research practices, in this report we provide insights on open source considerations for you to make informed decisions for your business.

With that, in this post, I’m excerpting those considerations. For the complete report (free), go here. Keep in mind there are some “no-brainer” uses of open source, in which case these considerations might be overkill. Again, you have to make the right call for your business. Examples of those are:

• Using open source purely for R&D to get familiar with a new technology.
• Open source projects which are de facto industry standards, such as Apache Web Server
• Open source embedded in commercial products, such as Apache Axis.
• Low-cost infrastructure (Web server, application server, and database) for development and initial test environments from well-established providers such as ObjectWeb, JBoss, and Apache.
• Developer and administrator tooling (Eclipse, Perl, PHP) that stays within the enterprise.
• Non-modified implementations of commercially-backed operating system distributions (Linux, Solaris 10).

The Excerpt: CONSIDERING OPEN SOURCE

What specifically should you be looking at, as you consider open source beyond the no-brainer uses? You need to look at three things: your project, the open source project, and your enterprise IT environment.

First, Your Project.  Does Open Source Make Sense?
 
The Risk Factors.  As with any IT project, you need to ask yourself the big questions. What is the purpose of this project? Does it provide strategic advantage? Does it provide core (critical path) processing? What are the service level requirements? What are the security requirements? What are the compliance requirements?

If your answers point to a high-risk project, then open source isn’t the right choice, especially for an initial foray. However, you still may find that components of the project fit in the no-brainer category. Remember, in a modular, service-oriented world, you don’t have to make all-or-nothing decisions.

License Restrictions.  If your answers don’t scream risk, and the idea of an open source jumpstart (code base and low financial entry) is appealing, then you need to think about the license obligations you can live with. (The assumption here is that your project will modify, extend, or create a larger work from the open source code.) The questions: Will you be mixing proprietary and open source code in your solution? Will you implement any components outside of your walls? Is there a competitive risk to your business if your code is released to the community? If you answered “yes” to any of these questions, open source may still be an option, but GPL licensed code might not be.

Evaluation Framework.  At this point, you’ve screened your project to determine if open source is a viable consideration. Now, you need to perform normal project activities to identify requirements, create an evaluation framework, and prepare a short list of candidates. For commercial products, PSGroup recommends (and produces) evaluation frameworks with the following six aspects:

• Features and Functions
• Design, Development, and Deployment
• Management and Monitoring
• Architecture
• Product Viability
• Company Viability 

For open source solutions, replace the last two aspects (product and company viability) with an open source project viability assessment, as described next.

Second, The Open Source Project. Is it Viable?

As mentioned earlier, most open source projects are not undertaken with the goal of enterprise consumption in mind. So, in your evaluation of the open source project, you need to think about how to resolve the gap between project and production-ready product. Typical items to be resolved are: documentation, installation scripts, product roadmap/evolution, patch and release management, systems management hooks, and problem/emergency support. These items might be resolved by the project community, by a commercially-oriented ecosystem, by your staff, or most likely, by a combination of all three.

Specifically, as you evaluate an open source project for viability, you need to get answers to the following:

• Project Origin and Objective. Did this project evolve from a group of programmers solving a problem for themselves? Is this project an industry sponsored technology reference (or proof of concept) implementation? Is this project a welcome donation (Eclipse) of commercial software that will form a common foundation? Is this project a dump of commercial software, which has reached end of life?

• Maturity. When was the project established? What is the current project release? What is the adoption rate? Is adoption building, level, or declining?

• Backing. Is there money behind the project? How much, and from who? Who is the community host? Is the host credible?

• Project Leadership. Who are the project leaders? What is their industry track record (open source, commercial, and/or enterprise)? Is the project well managed?

• Community Engagement. Is there an active community of developers, testers, and end users? Are there forums, email lists, and FAQs? How often is the source code updated? Are bugs reported? Fixed?

• Project to Product Gap. What is the gap? Does the project just consist of source code? Are there binaries and installation scripts? Is there documentation? Does the documentation cover the architecture, code, and/or end use? How often are patches released? Can patches be applied incrementally? How often are releases available? Is there a project roadmap? Are there administration scripts? Are there hooks for systems management? Is there a security model? Are there programming APIs?

• Commercial Ecosystem.* Is there a commercial ecosystem––consulting, training, code validation, distribution management, support––for this project? Is it cost effective? Are the firms viable? Is the ecosystem expanding, level, declining?

• Code Base. What language(s) are used? Are open standards used? How is the code quality? Is there a modular, extensible design? Is the architecture apparent? Are there APIs?

• Testing Practices. How does the project test? Is it a formal process? Are testing assets distributed with the code base?

•  License. What license(s) is the project under? What are your rights and obligations? Are there dual license options (open source and commercial)?

• Commercial Conflicts. Are there any commercial conflicts (the project, and/or your business)? Does the code base have a questionable history? Is there any pending litigation?

•  Competitors. Who competes with this project? Are the competitors open source? Commercial?

• Chatter. What are people saying about the project? Check email lists, blogs, community boards, and trade press for participant (developer, end-user) and observer (press, analyst, competitor, partner) chatter.

Third, Your Enterprise. Is There a Fit? Is It the Best Fit?

In this last step, you need to determine if the viable open source project(s) are a good fit with your enterprise. While you are concerned with the normal factors of architectural, operational, organizational and budgetary fit, the lens is slightly different. Essentially, you are mixing buy and build models. There is the code base jumpstart of a commercial purchase, and the ongoing care and feeding of a build.

Could You Survive Alone? With this in mind, the first big question is, “If the community dried up, what would you do?” Can you support this software? Is that the best use of your resources? Would your business be at risk?

Can You Span the Gaps?  Next, you need to address any gaps discovered between open source project and production-ready product. Does the investment (time, skills, people, and dollars) to close that gap fit your enterprise plan? Are there opportunity costs? Are you willing to make a contribution (people, dollars, code) to the open source community to bridge this gap?

 Do You Fit in the Open Source Community? Finally, you need to consider if your enterprise fits into the open source community. After all, they are doing the initial work! Are you willing to participate in the community, contribute to the project’s evolution? Donate back some of the less cool, but very important, production readiness deliverables?

 Best Fit? After determining the fit of the open source solution, you then need to weigh your options. Does an open source solution provide a better/worse fit and value against competing commercial and in-house build solutions?

As mentioned at the onset, there won’t be a single right answer. However, there will be a best answer for each business.

* Some big-name vendors––IBM, SAP, Novell, BEA—are participating in the commercial ecosystems for open source. There are also open source-specific providers such as RedHat, JBoss, SugarCRM, SpikeSource, and SourceLabs. As projects become popular, ecosystems are evolving to feed enterprise appetites. This burgeoning commercial market is particularly interesting to watch, given the roots of open source - individuals solving problems for their own benefit (use, challenge, education, community experience).  [well, at least I find it particularly interesting...] 

Comments

[Jean-Francois Cloutier]

More often than not, adopting OS software means using a configuration of OS libraries, where each library is its own project. Trying to keep up-to-date with new releases while ensuring that OS libraires are mutually compatible can be quite a headache. The GUMP project at Apache (gump.apache.org) is an interesting attempt at automating the process of discovering incompatibilities between OS libraries.

[brenda]

Jean Francois, thanks for the tip. Good to see you Friday. I look forward to learning more about your Information Sharing Needs Analysis work. Send that paper! -Brenda

[Jean-Francois Cloutier]

It was nice seeing you at the MESDA conference. I very much enjoyed the camaraderie between you and your co-presenters Amy and Christianne from LL Bean. It did stir quite a few emotions and memories to hear of battles fought to, in essence, build a better ship while at sea, which is how I see the mission of an enterprise architecture group.

The white paper is on its way...

[James McGovern]

Finally nice to see an industry analyst report that is not about vendors. Would be great if your next report focused in one what enterprises needed to think about in order to contribute not just evaluate open source offerings. Contribution aids in having sustainable EA roadmaps as open source is a vital component.