For: Application Best Practices: Adopt Open Source

Software To Improve Development

Development
& Delivery
Professionals

Effectiveness
by Jeffrey S. Hammond, March 23, 2015

Key Takeaways

Create And Maintain A Developer-Friendly Open Source Policy

Create a short (15 pages or less) open source policy that spells out how developers
should consume and contribute to open source projects. Spell out goals, processes, and
internal contacts. Revisit your policies and update them on a yearly basis.

Shorten Purchasing Cycles To Keep Commercial Software Competitive

Developers often choose open source because it’s easier than working through complex
purchasing cycles. Work to make acquisition of commercial products as easy as possible,
or developers will end up choosing open source options by default.

Use Open Source To Drive Software Innovation

Open source projects drive innovation in key technology areas including mobile,
cloud, big data, and the Internet of Things. Use open source as a key part of a software
innovation strategy, especially in concert with scale-out hardware architecture.

Plan For Project Remediation, Just In Case

Inadvertent use of virally licensed open source happens more than you might think, but
if (or when) it happens, it’s not the end of the world. Make sure teams have a plan in
place to quickly remediate projects when license violations are uncovered.

Forrester Research, Inc., 60 Acorn Park Drive, Cambridge, MA 02140 USA

Tel: +1 617.613.6000 | Fax: +1 617.613.5000 | www.forrester.com
For Application Development & Delivery Professionals March 23, 2015

Best Practices: Adopt Open Source Software To

Improve Development Effectiveness
by Jeffrey S. Hammond
with Christopher Mines and Dominique Whittaker

Why Read This Report

Open source software (OSS) is increasingly ubiquitous as application development professionals look
to trim enterprise software costs while simultaneously creating new, modern applications. OSS seeps
into development shops through a variety of channels, whether managers know it or not. Unchecked
tactical adoption of OSS creates unmanaged risk and unrealized returns, and application development
professionals should not tolerate it when a proactive OSS adoption strategy can increase its benefits. The
first step in moving from a tactical mess to a strategic plan is to specify the conditions under which OSS
is permissible in your development shop. By creating concise OSS consumption and contribution policies,
adopting tactics from open source communities, and adding control points to application life-cycle
management (ALM) processes and tools, application development professionals can shift from tactical
responses to conscious integration based on realistic expectations and articulated economic benefits. This
is an update of a previously published report; Forrester reviews and updates it periodically for continued
relevance and accuracy.

Table Of Contents Notes & Resources

2 Adopting Open Source Software Isn’t A Forrester interviewed 17 systems integrators,
Question Of If, But How vendors, and user companies about their
open source adoption best practices.
5 Best Practice No. 1: Create A Concise Open
Source Software Policy
Related Research Documents
9 Best Practice No. 2: Re-Engineer The
Software Acquisition Process Brief: It’s Not Your Grandfather’s Open
Source BI Market Any Longer
14 Best Practice No. 3: Make Adjustments To February 13, 2015
People, Processes, And Tools
Quick Take: Microsoft Open Sources .NET
17 Beyond The Basics: Next Practices For Open November 12, 2014
Source Adoption
Quick Take: Brocade Launches Networking’s
21 Identifying Your Challenges First Commercial Open Source Software
September 23, 2014
22 Supplemental Material
From Geek To Enterprise Chic: Open Source
Digital Experience Tools Gain Traction
May 22, 2014

© 2015, Forrester Research, Inc. All rights reserved. Unauthorized reproduction is strictly prohibited. Information is based on best available
resources. Opinions reflect judgment at the time and are subject to change. Forrester®, Technographics®, Forrester Wave, RoleView, TechRadar,
and Total Economic Impact are trademarks of Forrester Research, Inc. All other trademarks are the property of their respective companies. To
purchase reprints of this document, please email [email protected]. For additional information, go to www.forrester.com.
For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 2

Adopting Open Source Software Isn’t A Question Of If, But How

During the past decade, OSS has become a force for change that development shops can’t ignore. In
the early days of the free software movement, it was easy to view open source proponents as long-
haired barbarians at the gates of tech management shops, but now it’s increasingly hard to find an
enterprise application platform vendor that hasn’t incorporated OSS into its enterprise software
strategy. IBM makes extensive use of Eclipse and Apache, Oracle provides support for Linux and
MySQL. And even Microsoft, where executives once declared OSS projects like Linux as a “cancer,”
have open sourced core projects like the .NET runtime and the next generation C# compiler.1 Over
the past five years, multiple Forrester surveys have shown that developer adoption of substantial
OSS components is widespread across development and production environments (see Figure 1).

It’s a bit surprising then, that we get client inquiries on a regular basis about the wisdom of
adopting open source software. Why ask about adoption if developers are already using OSS in
their production projects? Our conclusions: 1) A “don’t ask, don’t tell” attitude lingers in some
mainstream development shops, and managers still lack awareness of just how much OSS is in use;
2) Many Microsoft shops are concluding that they can no longer pursue a strategy that exclusively
uses commercially licensed software; 3) Shops that are already consuming open source are now
evaluating broader commitments and contributions back to OSS projects, but are uncertain how to
do so safely. In each case we see a desire on the part of application development executives to move
beyond a tactical process with few rules and unclear goals to a strategic adoption process based on
proven best practices from organizations that have realized significant benefits from their use of
open source software.

The Wrong Way: Tactical Adoption Of OSS, Outside Traditional Corporate Controls
Even when firms have no set policies in place, OSS seeps into development shops in a variety of ways:

■ Open source code is embedded in commercial enterprise software. Tech decision-makers

may not realize that independent software vendors (ISVs) are wrapping their commercial
products around OSS components with amenable Open-Source-Initiative- (OSI-) approved
licenses such as the Apache License and the Eclipse Public License. Examples include IBM
Worklight and Adobe Experience Manager, built on Apache Cordova, and the Google Chrome
browser, based on the open source Chromium project.

■ Systems integrators (SIs) deliver open source as part of consulting projects. The business
services sector consistently shows high rates of OSS adoption. As large and regional SIs like
Accenture, CGI, CapGemini, Engineering Italia, and Wipro adopt support for and delivery of
OSS components as part of their go-to-market strategy, it’s natural that software shops might
find themselves maintaining multiple OSS components once they take delivery of a custom
development project.2

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 3

■ Developers download open source tools and frameworks. It’s hard to overstate the effect
of open source programming languages, frameworks, and tools on application development.
Open source development tools such as Apache Ant, Eclipse, Jenkins, Git, Subversion, and
Oracle NetBeans form the building blocks of many development shops’ application life-cycle
management strategy. And OSS frameworks such as Hibernate, jQuery, Angular, Ruby on Rails,
and Node.js are increasingly popular choices for developers looking for a leaner way to get their
jobs done quickly and with a minimum of fuss. Even Microsoft has joined the party, releasing
multiple .NET projects including ASP.NET 5 under the Apache 2.0 License.3

As a result of these adoption vectors, it’s common for development shops without OSS governance
processes to have multiple components adopted by developers outside the traditional software
acquisition process. When software executives discover the full extent of tactical adoption of OSS
by their developers, it often touches off a predictable set of responses: denial, anger, bargaining,
depression, and finally, acceptance (see Figure 2). But working through each stage of grief can take
some time; in the meantime, development shops get bogged down in a flurry of activity, after-the-
fact code scans and remediation meetings as executives try to get a handle on the situation and the
overall level of risk to the business.

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 4

Figure 1 Four Out Of Five Developers Used Open Source In The Past 12 Months

“Which of the following classes of open source software tools/frameworks

have you used for development or deployment in the past 12 months?”
(Multiple answers accepted)

Relational DBMSes 41%

Operating systems 38%
Web servers 37%
Development IDEs 34%
Application servers 25%
Application frameworks 21%
SCM tools 21%
Build and release management tools 18%
Content management systems 17%
NoSQL DBMSes 15%
Business applications 14%
Release/deployment management tools 13%
Business intelligence tools 12%
Management and monitoring tools 11%
Portals or mashup servers 11%
Other 2%
Have not used open source software 20%
Base: 1,716 BT developer professionals
Source: Forrester’s Business Technographics Global Developer Survey, 2014
46361 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 5

Figure 2 The Five Stages Of Open Source Software Acceptance

Stage Symptoms of progression

Denial that open source is already in use • No recent audits of custom software
• Low awareness of popular OSS components
• No official company policy for OSS usage
Anger over a surprise loss of control • Software in use with no record of adoption
• Management looks to assign accountability.
• Developers practice “don’t ask, don’t tell.”
Bargaining to re-establish existing controls and • Crash program to identify total exposure
processes • Program put in place to remove existing OSS
• Lawyers spend hours meeting with application
development teams.
Depression on realizing the point of no return • Realization that extracting open source would bring
has been reached Tech Management systems to a halt
• Recognition that the expense involved in extracting
OSS would be prohibitive
Acceptance of open source software • Implementation of a formal OSS strategy
• Adjustments to policies and processes
• An attitude shift from tolerance to exploitation

46361 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

The Right Way: Best Practices For Adopting Open Source

To understand how software executives regain control of their development shops, we spoke
with development managers, architects, analysts, CTOs, and developers at companies that are
successfully and strategically exploiting open source. Moving from tactical to strategic adoption of
OSS starts by acknowledging that traditional purchasing processes and communication mechanisms
are no longer capable of controlling the acquisition and use of software components. To regain
control, managers should:

1. Create and maintain a concise open source software policy.

2. Re-engineer the software acquisition process.

3. Make targeted adjustments to people, processes, and tools.

Best Practice No. 1: Create A Concise Open Source Software Policy

Popular OSS options such as the Apache HTTP Server and Linux are well into their second and
third decades of existence and yet we still encounter development shops that don’t have a formal
policy governing the use of open source software. All development shops must put a stake in the

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 6

ground with an official OSS policy, even those that will not allow open source tools or runtimes
at all. Regardless of whether managers view OSS as desirable or inevitable, the first step in moving
from a tactical mess to a strategic plan is to specify the conditions under which development
executives will approve or reject the use of OSS on development projects or inside products.

Once an executive defines the terms of use for OSS, it’s much easier to get the entire development
shop on the same page and more difficult for rebellious projects to claim ignorance as a defense for
unrestrained adoption of the latest OSS framework. As part of this effort, it’s important to create a
policy document that meets the needs of all parties who have a stake in the technical and business
changes that open source introduces. We recommend that development professionals:

■ Specify goals and aspirations for OSS usage. It’s important to declare what development shops
are trying to accomplish by adopting OSS software. If the sole goal is cost avoidance, make that
clear and specify the measures used to evaluate success (e.g., reduction of yearly maintenance, or
lower capex costs). Also specify where open source adoption is permitted: only in development
environments, or to replace server operating systems, or everywhere possible?

“We use open source heavily in development, but we don’t see widespread adoption at the
application platform level in production, because we want to be able to quickly separate
OSS libraries from our applications if our general counsel demands it.” (Senior vice
president of IT, financial services regulator)

As part of due diligence during this goal-setting process, managers should spend time with
developers and architects who have already tactically adopted OSS components to find out
why they have done so. Try to harmonize the development shop’s strategic goals with the
tactical realities of in-flight projects; it will help create allies and hasten acceptance of a
standardized process.

■ Involve general counsel early and often. The applicability of a given OSS component comes
down to answering two questions: Can teams successfully use it and should they use it?
Architects and developers can answer the first question through technical due diligence, but
the second question is best answered by a lawyer, preferably one with experience in software
intellectual property issues. It may be uncomfortable, but development executives should
proactively engage the firm’s legal department at the start of OSS policy development. Expect to
do a fair amount of education about OSS and that it will take some persistence to get past initial
indifference or opposition.

■ Ensure that developers internalize the OSS policy. The more concise a policy is, the more
likely development teams are to read it, and, more importantly, internalize the contents. The
best and brightest developers don’t think twice about delving into a reference manual to solve
a technical challenge, but give them a 50-page OSS policy to read, and they are likely to skim

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 7

it once and then file it next to corporate travel and HR policies. Focus on developers, because
they are most likely to bring in unapproved OSS frameworks. Aim for a document no longer
than 15 pages. Make sure that the policy gives clear, non-legalistic directions to developers and
focuses on the basics, for example, allowed license types, approval processes, and how to report
accidental violations (see Figure 3).

■ Classify software by license type and deployment impact. The Open Source Initiative lists 69
approved open source licenses, but an OSS policy document doesn’t need to address all of them.
Instead, focus on the most widely used licenses and specifically state how the organization will
permit or restrict usage of OSS components that fall under each one (see Figure 4). In addition
to classification by license, it’s also useful to classify by usage, especially with respect to OSS
runtimes. For example, it may be fine to use a General Public License (GPL) licensed testing
tool to debug a new customer self-service application, but linking a GPL-licensed library into
that same application could force a team to expose a proprietary business processes for all to see.

“We create four license classifications as part of our process, which range from permissive
licenses that allow developers to use OSS however they want up through the most viral
licenses, where we tend to discourage active use.” (SVP of IT at a financial services regulator)

■ Gain an understanding of distribution and viral OSS licenses. The most widely used open
source license is the GNU General Public License. The GPL is a “viral” license because it
requires software that is linked to or that incorporates a GPL program to also be made available
in source form under the same license when it is “distributed.”4 The danger of a viral license
is that a developer, not knowing that the software he is building will violate the distribution
clause of the GPL, might inadvertently expose core business processes and software intellectual
property (IP) to all comers. At first blush, it would seem risky to incorporate any OSS
components with viral licenses into a firm’s open source strategy, but simply forbidding use
of GPL licensed components can prevent a firm from using popular OSS components such as
Linux or MySQL.5 The GPL isn’t the only viral license development executives will run into, so
it’s a good rule of thumb to assume that a license is suspect until your firm’s legal department
has cleared it.6

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 8

Figure 3 Sample Contents Of A Concise Open Source Software Policy

Policy component What it should specify

Goals of OSS adoption Justification for using OSS (e.g., cost avoidance, speed,
performance, quality)
Acquisition processes: • How will you acquire OSS components?
• Method of procurement • Where are they downloaded from?
• Distribution policies • How is dependent code made available?
• Support policies • What’s the strategy for providing support?
• RACI matrix • Who is responsible, accountable, consulted, informed?
Rubric for business case • How will you determine the total cost of ownership?
• What performance service-level agreements are needed?
Guidelines for appropriate use including: • What are the specific guidelines for developers?
• License classification • What OSS licenses can be used and where?
• Usage restrictions • When should OSS not be used?
• Reporting requirements • How do projects report their use?
• Derivative use • How are modifications handled?
• Remediation policies • What is done when unreported use is detected?

46361 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

Figure 4 Commonly Used Open Source Licenses

Percent of 2015
components
License using license
GNU General Public License (GPL) 2.0 25%
MIT License 19%
Apache License 2.0 16%
GNU General Public License (GPL) 3.0 10%
BSD License 2.0 7%
Artistic License (Perl) 5%
GNU Lesser General Public License (LGPL) 2.1 5%
GNU Lesser General Public License (LGPL) 3.0 3%

Microsoft Public License 2%

Eclipse Public License (EPL) 2%

Source: Open Source Initiative (http://www.opensource.org) and Black Duck Software

(http://www.blackducksoftware.com/oss)
46361 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 9

Pitfalls To Avoid When Creating A Concise Open Source Software Policy

Development executives should avoid the following pitfalls when creating an OSS consumption policy:

■ Don’t treat policy-making as a once-and-done task. It’s easy to view the creation of an OSS
policy as a one-time activity where one or two development executives spend a week with the
legal department locked in a conference room putting everything into place. In reality, open
source licenses are evolving, the case law is evolving, and open source ISVs’ business models
are evolving. Plan to revisit the policy document at least once per year to properly reflect the
ongoing evolution of the space; make sure to highlight the differences in each new version of
the policy document and, when changes in policy affect existing projects, provide a reasonable
migration period for development teams to adjust applications.

■ Don’t prematurely declare victory. In and of itself, an OSS policy document isn’t worth
much more than the paper it’s written on. Is there a plan in place to share it with the entire
development organization? Plan a set of follow-up activities and well-defined metrics to make
sure that developers are internalizing the policies the document puts in. It’s important to get
down in the trenches with developers to measure their awareness of specific policies. One
firm we spoke with appointed an informal open source steward and provided him with a small
budget to host brown-bag lunches on the topic with fellow architects and developers. Another
firm publicly rewarded successful projects that correctly followed the process.

■ Don’t let lawyers own the policy-setting process. Open source adoption is a balancing act
between the risk of legal liability and the rewards of cost avoidance, software innovation, and
more-efficient development. If development executives let a firm’s lawyers lead the process, they
will always find themselves playing defense at the “minimize risk” end of the risk-reward curve.
It’s up to development decision-makers to build the OSS business case and provide lawyers with
up-to-date information on the rewards. Be prepared to involve the CIO and COO in the event
of intransigence from the general counsel: In the end, unless tech management and legal can
agree on a sensible policy, developers will simply revert to a “don’t ask, don’t tell” mentality, and
uncontrolled tactical adoption will resume.

Best Practice No. 2: Re-Engineer The Software Acquisition Process

When development shops choose to use open source tactically, they are using it outside of (and
often in spite of) a formal software acquisition process. While this out-of-band approach works for
individual projects, it creates organizational risk because an individual developer or project manager
may not appreciate the long-term consequences of a tactical decision. For example, a developer
may decide to link to a GNU GPL licensed component knowing that the internal customer service
application he is working on will never be distributed to customers. Fast-forward five years, and that
very same component could easily become part of a customer self-service mobile app.

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 10

Folding the selection of OSS components into a formal software acquisition process gives
development executives the ability to inject organizational concerns into open source adoption.
The first step is simple: Ensure that when project teams are starting up new projects, they evaluate
OSS and commercial options concurrently during their technical due diligence. From there,
implementation takes a different course: While standard acquisition processes rely on vendor
involvement and require participation from purchasing agents and sign-offs from executives,
implementing OSS frameworks requires neither. Additionally, industry best practices on software
acquisition such as the Capability Maturity Model Integration for Acquisition (CMMI-ACQ) don’t
provide much guidance on how to handle the differences that OSS introduces into the acquisition
life cycle.7

To merge commercial and OSS acquisition processes:

■ Define a consistent rubric to quickly evaluate all types of software. Regardless of the current
level of acquisition process maturity, reviewing CMMI-ACQ is worthwhile, because it provides
good guidance for the types of activities a mature acquisition process should have. It also
provides a good starting rubric for evaluating potential OSS acquisitions: the software “iron
triangle” (see Figure 5). CMMI-ACQ is designed to help software acquisition leaders meet
aggressive performance, cost, and schedule objectives while creating a flexible environment for
acquisition and decreasing acquisition cycle times — which is all the more important as Agile
development teams compress acquisitions to days and weeks instead of months.

■ Make sure evaluations include the entire cost profile of commercial and OSS alternatives.
Obviously, license costs for open source are substantially lower than those for commercial
enterprise software. But initial capital outlays are only part of an overall software total cost of
ownership (TCO) model. It’s best to evaluate TCO over a multiyear period and include license,
support, training, and upgrade costs for all options (see Figure 6). When building a cost profile,
specify whether each cost is optional or mandatory. For example, support licenses that preserve
the right to upgrade to the latest version of a product are essentially a mandatory expense.
Another important consideration is fixed versus variable costs (e.g., a scale-out and cloud
architecture will be sensitive to per-processor/node software license costs but not to optional
software support costs).

“Our acquisition of OSS is driven primarily by the desire to avoid software costs wherever
possible, but we always buy product support because it’s less costly than supporting OSS
projects ourselves.” (CTO at a leading travel provider)

■ Reorder acquisition tasks to front-load evaluation and selection. Many Agile development
teams use OSS options for prototyping and early-stage minimum viable products (MVPs)
because they can get started as quickly as they can download, install, and configure a framework.
This allows developers to assess technical feasibility before committing any project resources

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 11

to software (or purchasing licenses). Bureaucratic purchasing processes and the inadequacy of
time-bombed products and trial licenses put commercial products at a disadvantage. To create
real bake-offs between commercial and open source options, development execs and purchasing
managers need to make sure that the definition of requirements, verification, and validation of
acquired software solutions are concurrent steps that can be executed at the start of a software
selection process, or even prior to projects when strategic suppliers are known (see Figure 7).

“Time-to-market was a critical concern for our business sponsor; we couldn’t afford to wait
for a commercial vendor to give us the integrations we needed. An OSS solution allowed us
to write three modular integration components instead of writing the whole solution from
scratch.” (Florent Mara, project manager, Harmonic)

■ Demand a realistic assessment of the need for “-ilities.” Everyone always wants the best
scalability, accessibility, reliability, maintainability, extensibility, portability, and security — and
a chauffeured ride to work every day sounds good too. When defining product requirements,
separate the “good enough” from the “nice to have” items. Software indemnification is a good
example: Development executives look for blanket coverage, but it comes at price, and even
then, the coverage is often limited. In reality, the exposure for a given application may not be
that serious. If so, indemnification becomes more of a “nice to have,” and an OSS component
may be “good enough” especially in early stages of product definition.

■ Focus initial adoption at lower levels of the application platform stack. The best place for
initial adoption of OSS frameworks is wherever there are well-established projects with strong
ecosystems or companies and a vibrant set of core committers actively participating.8 A vital
OSS ecosystem tends to form when there is broad demand for a given set of features and users’
needs are well known.

“The more horizontal the problem, the more likely you’ll see an open source solution.
Application and network security is a horizontal problem, so we’ve found many good open
source options to use in our solution.” (Richard Newman, managing partner, Reliant)

The net result of this community dynamic is that open source tends to sees its broadest adoption
at the infrastructure level of the application platform stack — in programming languages,
databases, web servers, operating systems, and security tools.

■ Use OSS alternatives to drive better deals with commercial software suppliers. Enterprise
software suppliers understand OSS’s impact on their business models, so use that understanding
for advantage in negotiations. But be warned: Enterprise solution providers also know that a
development shop that is used to dealing exclusively with commercial software companies will
find it difficult to throw out its existing suppliers as part of an immediate, forced conversion to
OSS, and so may call an unprepared bluff. But once development executives have demonstrated

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 12

a capability to adopt OSS, existing suppliers tend to become much more flexible in their
pricing arrangements, especially when an alternative OSS standard is judged “good enough” by
development teams to satisfy individual product performance and time-to-market needs.

Figure 5 The “Iron Triangle” As A Merged Software Acquisition Rubric

The software “iron triangle”

Schedule
• Acquisition period
• Development cycle
• Velocity

Costs Capability
• Capital expenses • Features
• Operational expenses • Quality and
• Labor expenses “-ilities” risks

46361 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

Figure 6 Evaluate Commercial And Open Source Software Options Using A Multiyear Cost Profile

Example of a simple three-year formula for annualized total cost of ownership (TCO)*
TCO = (capital expenses + 3 (operational expenses))/3

Capital expenses = Operational expenses =

hardware acquisition + software license acquisition maintenance + power + labor + indirect costs
CAPEX considerations: OPEX considerations:
• Can commodity hardware or public cloud • Are recurring costs optional or mandatory:
infrastructure suffice, or is specialized hardware How much flexibility is there?
required? • Labor costs include developer and administrator
• Are license costs a lump sum, or do they salaries and training fully-loaded costs.
increase as deployment scales? • Indirect costs include vendor management, software
• Are software licenses perpetual or fixed-term? configuration and administration tools, and the cost
of migrating to new platforms.

*For greater precision, use net present value (NPV) calculations for opex and break out indirect
costs on a separate, annualized basis.
46361 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 13

Figure 7 Front-Load Requirements, Verification, And Validation

Traditional acquisition process

Solicitation
and supplier
agreement
development
Acquisition
requirements
management

Acquisition
verification

Acquisition
validation

Agreement
management
Acquisition technical
management

Front-loaded acquisition process

Acquisition requirements management Front-load and separate

requirements definition from
Define customer Define contractual contractual requirements.
requirements requirements

Develop master agreements

Solicitation and supplier with strategic suppliers that
Acquisition agreement development allow rapid acquisition.
verification

Agreement
Acquisition management
validation

Acquisition
technical
management

46361 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 14

Pitfalls To Avoid When Re-Engineering The Software Acquisition Process

There are two common mistakes development executives make when adding OSS options to their
software acquisition process. To avoid them:

■ Don’t rely on purchase authority as a process control for software acquisition. It’s bad
enough that developers circumvent acquisition processes by buying individual software
licenses or cloud computing cycles on a credit card, but tactical open source acquisitions lack
even a manager’s sign-off on an expense report to signal rogue adoption. The simple truth is
that development managers can no longer rely on purchasing controls to regulate software
acquisition. To appropriately regulate software adoption, executives must shift to build and
deployment time dependency analysis of who’s using what software components and where.

■ Don’t overemphasize direct costs simply because they are easier to calculate. Open source
may be free (as in freedom), but it’s not really free (as in lunch). If a cost analysis survey focuses
on just the capital costs of software licenses and doesn’t consider the operational expense of
commercial support, the net result will be a business case that doesn’t adequately reflect the
true TCO of an OSS investment. When development shops initially adopt open source, most
purchase some level of commercial support. Subsequently, their OSS adoption includes training
costs, installation costs, and maintenance costs. Even when shops self-support, open source
isn’t a free lunch: Planning to support OSS internally means that managers will have to estimate
higher internal labor costs to get an accurate TCO as a component for a rough return-on-
investment (ROI) analysis.

Best Practice No. 3: Make Adjustments To People, Processes, And Tools

Creating a concise open source policy and re-engineering software acquisition are best practices
that help development teams come to grips with OSS adoption. Once executives have stripped out
control points from the software acquisition process, the best place to reinsert them is in application
life-cycle management (ALM) processes — specifically during build and delivery tasks. Re-exerting
a reasonable level of governance doesn’t have to be onerous or expensive; firms that we spoke
with made a few targeted adjustments to improve ALM processes to incorporate OSS governance.
Development executives should:

■ Require project managers to identify OSS dependencies. Project managers represent the best
control point for identifying and cataloging OSS dependencies. Expand their job description to
include the responsibility of identifying the dependencies their project has on OSS components
and frameworks. One simple, effective way to do this is to require projects managers to fill
out a certificate of originality (COO), which details what commercial and OSS components
their software uses (see Figure 8). To ensure that every project has a COO, don’t allow projects
without them into production.

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 15

■ Trust development teams, but verify projects with code-scanning utilities. One of the best
ways to reduce the risk of inadvertent OSS IP infringement or license violation is to back up
a project manager’s articulation of OSS dependencies with automatic detection of OSS code.
Products such as Black Duck Suite, Open Logic Exchange, Palamida Application Security,
Protecode, and WhiteSource systematically scan source code for potential dependencies and
highlight violations. One senior vice president of IT at a financial services regulator explained,
“Before we escrow any software that goes into active use, we run it through Black Duck to
identify any OSS dependencies. We keep the list of the OSS components we find in a database
for reporting purposes.”

■ Use enterprise architects to regulate OSS exploitation and maintenance. Active use of open
source software puts new demands on software development organizations. For example,
installing and configuring OSS libraries may take more time than the same process for well-
packaged commercial alternatives. Alternatively, the shift away from per-processor licensing
enables developers to consider using commodity hardware or public cloud computing instances
in situations where using commercially licensed software would be cost prohibitive.

“When we bring in new architects, they need to learn how to build horizontally scalable
systems. As a result, we see increased training costs, because it’s not a single product they
need to learn, but a mix-mash of OSS components that they need to learn how to integrate.”
(CTO, leading travel provider)

Increased integration demands are typical in shops that adopt OSS on a large scale. Plan for
increased demands on architects’ integration skills as developers bring more and more OSS
components in house. Architects can help define a reference application platform stack, review
and approve the technical capabilities of OSS components, specify open source alternatives that
can be used in lieu of commercial products, and assist with component integration — similar to
what they would do if they were charged with assembling a commercial application architecture.

■ Require a repository of preapproved OSS components. If adoption of OSS grows to more than
a few projects or beyond the bounds of a single business unit, executives should work with a
project management office, or centralized ALM team to establish a repository where developers
can access approved versions of OSS components for their projects. This repository can be as
simple as a shared, read-only network folder, an extension of a shop’s software configuration
management (SCM) repository, or it could be a full-blown asset repository like Sonatype
Nexus Pro or JFrog Artifactory. The idea is to provide an internal resource for developers’ OSS
component needs, so they won’t look to the Internet first and download components from
unauthorized sources.

Significantly streamlining the approval process for using components within the internal
repository is one way for executives to incent rapid adoption by developers. Furthermore,
an internal repository is a single source for truth in code when shop is creating bug fixes or

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 16

extensions to OSS projects. It may take some time to get these changes incorporated into official
project build streams, but in the meantime, actively discourage mixing different versions of
components when possible.

Figure 8 A Sample Certificate Of Originality

CERTIFICATE OF ORIGINALITY (SAMPLE)

1. Basic project information

Project name:
Version/release:
Brief functional description:

2. Details on any portion of the software written by any party other than those listed above:
Name of software Name of portion Author names Author affiliation Ownership details
from above

3. Did you obtain any content from any party or source not listed above?
4. Who owns copyrights in the content?
5. Does anyone charge for the content?
6. Does anyone consider the content to be confidential?
7. What copyright notice is on the content?

Name of submitter:
Date:

Source: National University Of Ireland Maynooth (research.nuim.ie/enterprise/commercialisation_forms/

documents/CertificateofOriginality.doc) and IBM (http://www.vm.ibm.com/download/thirdagr.iagree)
46361 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

Pitfalls To Avoid When Making Targeted Adjustments To People, Processes, And Tools
In our research, we found a few common pitfalls that are easy to run into when adjusting a development
organization’s people, processes, and tools to take advantage of OSS. To avoid these problems:

■ Focus on outcomes, not development processes and artifacts. Development shops know that
they need to put more effort into controlling OSS, but adding a lot of extra process steps or
artifacts to track components can reduce the time-to-market advantages of OSS adoption. If an
executive needs to sign off every time a developer uses an OSS component instead of one that

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 17

includes preapproved components, the velocity of development slows. And if it takes months to
get a new OSS component into a sanctioned repository so that it can be used, don’t be surprised
when developers work around such a process instead of complying with it. In short, make sure
that the process adjustments that you make are lean in spirit: They should reduce time-to-
market and cost as well as cut out waste wherever possible.

■ Don’t expect perfection, and plan for remediation. Inadvertent inclusion of OSS components
happens to even the best development shops. Even if project managers manually spot-check
or use tools to automatically scan code, we recommend that executives have a rapid response
process in case of licensing violations. First, make sure that the problem is not a false positive,
especially when using code-scanning tools. Next, work with the legal department to examine
the copyright of the code in question to determine the level of actual risk. Then expunge risky
code and immediately patch any compromised systems. Finally, forgive and re-educate sporadic
offenders while punishing repeat violators in direct proportion to the resulting risk exposure.

Beyond The Basics: Next Practices For Open Source Adoption

While our research uncovered a number of basic OSS adoption best practices, there are also some
next practices for application development professionals to implement once they’ve mastered the
best practices (see Figure 9):

■ Join and contribute to OSS communities. The vast majority of OSS adopters consume
the fruits of OSS without giving back their own ideas, contributions, and support to the
communities on which they rely. In the early stages of OSS adoption, development teams may
buy a support contract from a sponsor organization, if available, but they usually don’t think
about becoming committers themselves. But as shops gain experience with open source, more
are taking the opportunity to provide their own committers to implement the features that they
need on top of the core contributions of others. Need an integration to connect to an obscure
database or a specialized vertical application? Why not write it and contribute the results back
into the OSS project’s integration stream?

■ Adjust support-sourcing strategies to maximize value delivered. Getting support for

commercial software products is pretty straightforward — teams buy it directly from the vendor,
along with the right to upgrade. With OSS, development executives have the flexibility to buy
commercial support, self-support with internal expertise, or use a third party such as an SI or a
specialist ISV. But taking advantage of this newfound flexibility requires tracking support
expenses versus the value received. As an example, if a product team only makes a few support
calls per year for an application server or mobile app framework, then a six-figure support
contract might not be a good option. Alternatively, if the strategic adoption of open source
frameworks is growing, and developers are pulling their hair out on a daily basis, it may indicate
that it’s time to either develop in-house specialists instead of paying a non-responsive third party.

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 18

■ Model internal reuse strategies on the example of successful open source communities.
When it comes to software reuse, open source projects have achieved in practice what many
enterprise development shops have long desired: high levels of reusable components that enable
rapid assembly of new solutions. There’s substance to the argument that the more transparent
a component’s development, the more likely that other developers will want to use it. And if
new developers can also make changes or extensions to a component, so much the better. We’re
beginning to see large, geographically distributed development shops apply the principles of
foundations like Eclipse and Apache to their own “inner sourcing” efforts, setting the stage for
increased collaboration and component reuse in the process.

■ Innovate through an “OSS-first” mindset. While many development shops started working
with open source in an effort to save money, that’s no longer the case for advanced adopters.
“Good enough” has given way to “market leader” in many new technology areas (see Figure
10). Examples include NoSQL DBMSes like CouchDB, HBase, MongoDB, and Redis; big data
frameworks like Apache Hadoop, and Spark; mobile frameworks like Apache Cordova and
Google’s Angular. As development shops move to embrace cloud computing, big data, and their
customer’s mobile devices, they will find it virtually impossible not to embrace open source as a
key enabler of their efforts.

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 19

Figure 9 Open Source Adoption Best And Next Practices

Best practice “How to” How to avoid pitfalls

Create a concise open source • Specify your goals and aspirations • Don’t treat policy-making as
software (OSS) policy for OSS usage. a once-and-done task.
• Involve general counsel early and • Don’t prematurely declare
often. victory.
• Ensure that developers are able to • Don’t let lawyers lead the
absorb the information in your policy policy-setting process.
document.
• Classify software by license type and
deployment impact.
• Gain an understanding of the potential
dangers of distribution and viral licenses.

Re-engineer the software • Define a consistent rubric to evaluate • Don’t rely on purchase
acquisition process all types of software authority as a process
• Make sure evaluations include the control for software
entire cost profile of commercial and acquisition.
OSS alternatives. • Don’t overemphasize direct
• Reorder acquisition tasks to front-load costs simply because they
evaluation and selection. are easier to calculate.
• Demand a realistic assessment of the
need for “ilities.”
• Start OSS adoption at the lower levels
of the application platform stack.
• Encourage the use of OSS alternatives
to drive better deals with conventional
suppliers.
Make targeted adjustments • Require project leaders to identify • Don’t dwell on
to people, processes, and OSS dependencies. development processes and
tools. • Trust but verify with code-scanning artifacts; focus on outcomes.
utilities. • Don’t expect perfection,
• Use architects to regulate OSS and plan for remediation.
exploitation and maintenance.
• Maintain a repository of preapproved
OSS components.
Next practices • Join and contribute to OSS communities.
• Vary support-sourcing strategies by measuring delivered value
• Model internal reuse strategies on the example of successful open
source communities.
• Innovate through an “OSS-first” mindset.

46361 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 20

Figure 10 OSS Projects Drive Software Innovation In Many Areas

Technology area Example of market-leading OSS projects

Integrated development environment Eclipse, NetBeans, Brackets
SCM Git, Subversion, Mercurial
Test automation (GUI, API, Functional) Selenium, SoapUI
Unit testing JUnit, Nunit, CPPUnit
Test driven development Cucumber, Fit/Fitnesse, SpecFlow
Performance testing Jmeter, Benerator
Test data management Jailer, Jmeter
Build/build management Jenkins, Maven, Hudson, Ant, Ivy
Configuration management Ansible, Salt, Puppet, Chef, CFEngine
Front-end frameworks Cordova, Angular, Ionic, Jquery, Sencha
Server-side frameworks Spring, Node
WCM/portal Drupal, Joomla, Liferay
Containers/container management Docter, Kubernetes
Cluster management Mesos
NoSQL DBMS Mongo, Redis, Couch, HBase
Big data/analysis Hadoop, Spark
Visualization D3
Integration Jboss, Talend, Wso2, Mulesoft
Task execution Grunt
Rules IFTTT

46361 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 21

Identifying Your Challenges

Where should you start? Use this diagnostic tool to assess your current level of OSS adoption
readiness — and as a way to identify OSS adoption goals and potential benefits (see Figure 11).

Figure 11 Open Source Adoption Self-Diagnostic Tool

Part 1: Create a concise open source software (OSS) policy Yes No

Have you clearly articulated the strategic goals you want to achieve through adopting OSS?
Have you fully involved your general counsel, and have they signed off on your OSS policy?
Have senior developers and architects reviewed and signed off on your OSS policy as clear
and actionable?
Does your policy cover use of OSS in development and production environments?
Have you defined appropriate usage guidelines for common OSS licenses?
Have you identified software subject to the distribution requirements of viral OSS licenses?
Do you review and update your OSS policy on an annual basis?
Have you specified how your organization will handle contributions back to OSS projects?

Part 2: Re-engineer the software acquisition process Yes No

Do you have a consistent evaluation methodology for commercial and OSS software
components?
Do you factor software CAPEX and OPEX over a multiyear period into total-cost-of-ownership
(TCO) and return-on-investment (ROI) calculations?
Does your acquisition process allow you to evaluate commercial software options with
the same speed as your evaluations of OSS options?
Do you define requirements for quality, scalability, security, and reliability based on
project type and need?
Do you consider multiple support options including support by independent software
vendors (ISVs), systems integrators, and self-support?
Will your commercial software suppliers provide software for extended evaluations and
prototyping before requiring financial commitments?

Part 3: Make targeted adjustments to people, processes, and tools Yes No

Have you identified which IT roles are responsible and accountable for identifying OSS
dependencies?
Do you spot-check dependency reporting for accuracy?
Have you integrated OSS dependency reporting with regular compliance activities?
Do you maintain a centralized repository of preapproved OSS components that development
teams can reuse?
Do you have a process to quickly validate unreported OSS usage when it is discovered
and to remediate any license violations?
Have you allocated additional resources to architecture groups to support increased
integration, configuration, and standardization?
Do you regularly report metrics that allow comparison of functional and qualitative aspects
of OSS and commercial components?

46361 Source: Forrester Research, Inc. Unauthorized reproduction or distribution prohibited.

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 22

Supplemental Material

Companies Interviewed For This Report

Accenture IBM
Acquia J.P. Morgan
Actuate Landmark
Adobe Reliant Software
Alcatel Lucent Talend
Alfresco The U.S. Department of Energy
Black Duck Software Wipro
Harmonic

Online Resource
The online version of Figure 11 is an interactive self-diagnostic tool that helps clients assess how
their current practices stack up against those of their peers

Endnotes
1
Microsoft announced at its Connect() event that it would contribute parts of the .NET framework to open
source and move towards becoming cross-platform. See the November 12, 2014, “Quick Take: Microsoft
Open Sources .NET” report.
2
For more details, check out the following links. Source: “Accenture Open Source Software Services:
Driving Enterprise Agility and High Performance,” Accenture (http://www.accenture.com/
SiteCollectionDocuments/PDF/Accenture-Open-Source-Brochure.pdf) and Derek du Preez, “CGI opts
to launch new open source centre in Scotland,” Computer World UK, October 10, 2013 (http://www.
computerworlduk.com/news/open-source/3473238/cgi-opts-to-launch-new-open-source-centre-in-
scotland/ and http://www.eng.it/home/home-eng.dot?com.dotmarketing.htmlpage.language=1).
3
For more information about the Microsoft’s efforts to open source key part of the .NET framework check
out the following link. Source: .NET Foundation (http://www.dotnetfoundation.org/).
4
As shown in Figure 4, the GNU GPL accounts for approximately 35% of OSS licensed projects.
5
While buying commercial licenses of dual-license code is an option, it’s wise to closely study the terms
of alternative licenses and the terms of the “copyleft” license to see if in fact the redistribution effects are
triggered by the intended use.

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

For Application Development & Delivery Professionals
Best Practices: Adopt Open Source Software To Improve Development Effectiveness 23

6
Other examples of “copyleft” licenses include the Affero GNU Public License (AGPL), the Open Software
License (OSL), the Academic Free License (AFL), and the Non-Profit OSL. For a framework for evaluating
the viral effects of GPL use, check out the following book. Source: Ron Phillips, Deadly Combinations: A
Framework For Analyzing The GPL’s Viral Effect John Marshall Journal of Computer and Information Law,
Summer 2008.
7
The CMMI-ACQ defines effective and efficient practices for acquisition projects, including acquisition of
software, and is designed to work hand-in-glove with CMMI-Development. For more information, check
out the following link. Source: Dr. Karen Richter, “CMMI for Acquisition (CMMI-ACQ) Primer, Version
1.2,” Software Engineering Institute, May 2008 (http://www.sei.cmu.edu/publications/documents/08.
reports/08tr010.html).
8
We recommend that development executives review prospective projects on OpenHub. OpenHub provides
project data on number of committers, frequency of commits, comtitter turnover, and how often new
versions of a project are released. Source: OpenHub (https://www.openhub.net/).

© 2015, Forrester Research, Inc. Reproduction Prohibited March 23, 2015

 About Forrester
A global research and advisory firm, Forrester inspires leaders,
informs better decisions, and helps the world’s top companies turn
the complexity of change into business advantage. Our research-
based insight and objective advice enable IT professionals to
lead more successfully within IT and extend their impact beyond
the traditional IT organization. Tailored to your individual role, our
resources allow you to focus on important business issues —
margin, speed, growth — first, technology second.

for more information

To find out how Forrester Research can help you be successful every day, please
contact the office nearest you, or visit us at www.forrester.com. For a complete list
of worldwide locations, visit www.forrester.com/about.

Client support
For information on hard-copy or electronic reprints, please contact Client Support
at +1 866.367.7378, +1 617.613.5730, or [email protected]. We offer
quantity discounts and special pricing for academic and nonprofit institutions.

Forrester Focuses On
Application Development & Delivery Professionals
Responsible for leading the development and delivery of applications
that support your company’s business strategies, you also choose
technology and architecture while managing people, skills, practices,
and organization to maximize value. Forrester’s subject-matter expertise
and deep understanding of your role will help you create forward-thinking
strategies; weigh opportunity against risk; justify decisions; and optimize
your individual, team, and corporate performance.

« Andrea Davies, client persona representing Application Development & Delivery Professionals

Forrester Research (Nasdaq: FORR) is a global research and advisory firm serving professionals in 13 key roles across three distinct client
segments. Our clients face progressively complex business and technology decisions every day. To help them understand, strategize, and act
upon opportunities brought by change, Forrester provides proprietary research, consumer and business data, custom consulting, events and
online communities, and peer-to-peer executive programs. We guide leaders in business technology, marketing and strategy, and the technology
industry through independent fact-based insight, ensuring their business success today and tomorrow. 43461