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...]
