Whitepaper

The Hidden Costs of Open Source

Software Development Tools

Harry Koehnemann
harry@rocketgang.com
Director of Technology
Rocket Gang, an IBM Premier Business Partner
Abstract
There is an old saying, the best things in life are free plus tax, which implies even free things
have associated costs. Many organizations are looking to free, open source software products to reduce
expenses, sometimes without a full understanding of their total cost of ownership. This whitepaper
analyzes software products used in the software development lifecycle configuration/version
management, issue/change management, agile planning, etc. It contrasts the costs of open source
products with those of an integrated commercial development product, IBMs Rational Team Concert.
The purpose of this paper is to discuss their value proposition and ensure organizations make informed
decisions, leaving the reader to decide which solution is right for their organization.

Introduction

Historically, commercial software development closed its development artifacts and processes. Source
code was private, there was limited integration support (poor or non-existent APIs), release plans and
schedules were private, and product support was only offered through call center technicians far
removed from development. Further, many commercial products were monolithic in nature, requiring
organizations to spend a modest effort for installation and support, making them difficult to consume for
smaller organizations. Traditional products for software development did not scale down well to small
and medium teams.
The emergence of open source tools for software development solved many of these challenges, and in
many instances provided better value than commercial products, particularly for small teams. As
smaller organizations have adopted agile practices, the ability to customize and integrate open source
products to support development best practices also provided significant value.
Through its participation with open source projects such as Linux, Eclipse, and Apache, IBM has seen
the value of open development, project visibility, and the formation of communities. Based on that
experience, IBM opened its software development with its new Jazz-based products. These Jazzbased products provide open access to the products source code and the teams incremental builds, issue
tracking, project plans, wikis, blogs, forums, etc. Jazz products are built
on integration standards (Eclipse plug-ins and REST-full interfaces) so
they are naturally extensible through common technologies.
Rational Team Concert (RTC) was IBM-Rationals first offering on the
Jazz platform. RTC provides an integrated solution for software
development with change/issue management, configuration/version
management, agile planning, build management, reporting, collaboration
(chat, event notification), dashboards, search, and agile process. This
paper compares Team Concert with the equivalent open source stack of
tools. It is a value comparison, not a feature comparison. Frankly, this
author believes Team Concerts issue tracking, agile planning, and

Rocket Gang Copyright 2010

Page 1 of 9

configuration management capabilities would soundly beat its open source competitors in a feature
comparison. However, our focus here is on the value of an integrated suite that enables fast and reliable
delivery of business value on a stable, scalable, and cost-effective platform.
The next section discusses open source tools and their value proposition. Section 3 discusses the
sometimes-overlooked costs (hidden costs) associated with open source tools. Section 4 discusses
how Jazz and Team Concert have integrated open source practices and significantly altered commercial
software development. Section 5 provides concluding remarks and considerations on open source and
commercial software selection.

Open Source Software Tools

Software history has many examples demonstrating the value of open source. In the 1970s ARPA
sponsored the projects that would ultimately lead to TCP/IP, ftp, telnet, and eventually the Internet we
know today. While the phrase open source did not yet exist, those efforts shared software to help their
dissemination. In the 1980s, the GNU project was a significant global, collaborative effort and
demonstrated that large, free software products work and that industry can leverage the results. The
1990s saw a proliferation of open source projects such as Linux, Apache, Jakarta, and Eclipse, which
have all seen significant adoption in the commercial world. Open source projects need development
tools to manage their development lifecycle and the
community created a series of software development
tools for version control (CVS, Subversion, Git,
Mercurial), issue tracking (Buzilla, Trac), continuous
build (Ant, Maven, CruiseControl, Hudson), etc. The
figure shows several popular open source tools
grouped by discipline.
It is important to note that many development
organizations using open source software
development tools also see value from commercial
products. Development organizations may use Rally
or VersionOne for agile planning, Jira for issue
tracking, and Perforce for version control as a few
examples of commercial development tools used in
open source development organizations.
Commercial products are shown in green italics in the
figure.
Types of Open Source Software
There are many types of open source software products, from stock tickers to application servers. Not
all categories of open source software have shared the same success. While some domains (IT
operations) have provided huge success and value, other areas have had less impact and stability. Open
source tools for IT operations, including Linux, Apache, and Tomcat, are poster children for open
source. They maintain a significant and stable market that encourages continued support by their
development communities. Open source tools for software development have seen a slightly different
history. The community supports a wide variety of lifecycle development tools for configuration
management (e.g., CVS, Subversion, Git, Mercurial), defect tracking (e.g., Buzilla, Trac), continuous
build (e.g., Ant, Maven, CruiseControl, Hudson), and the like. While open source development
software has also been successful, the products have been less dominant and stable than other open
source initiatives.

Rocket Gang Copyright 2010

Page 2 of 9

For example, in 2000 most open source projects (and many commercial projects) used CVS for version
control. At that time, the community created the Subversion project to address several CVS deficiencies
and by the mid 2000s many open source projects began moving from CVS to Subversion. Around that
same time, the open source community became interested in distributed version control and today Git
and Mercural are emerging as the version control of choice for many open source projects. As the
community migrates, developer support and contributions to the legacy products drop. While the open
source community benefits from this continuous improvement, moving to the next big thing can
challenge commercial organization without a stronger business case.
Further, the open source community builds software products to support their needs, not necessarily the
needs of a commercial software business. For example, the version control direction towards distributed
version control (e.g., Git) makes sense for open source. Open source projects prosper as more
developers explore ideas and easily distribute changes to one another. Commercial software will want
to better track and measure progress towards feature completion and manage their configuration. A
commercial software release is part of a much larger offering that includes marketing, support,
documentation, enablement, and training. Businesses need to know which features will or will not make
a release and reliably track progress. While distributed version control is the obvious direction for open
source projects, its relative value for commercial software is still an open issue.
The Open Source Value Proposition
Freedom to choose. Open source development solutions attract developers for a variety of reasons.
First, projects can begin with no initial investment other than the sweat equity to download, install, and
integrate some open source software products. Little up-front investment provides the freedom to use
the most appropriate product without vendor lock-in. Further, most small projects can begin with
version management and perhaps issue tracking. The development environment can then evolve as
project success brings more developers and there is a need for better planning, continuous builds, and
more complex configuration management.
Flexibility to change. Flexibility is another value as projects are free to choose the best solution
available to them and, as before, the only cost in making a selection is the sweat equity required to
integrate them. Projects are free to select, for example, CVS, then later move to Subversion, and then to
Git. However, the sweat equity and effort to move to new development tools is no small task. While
there is no vendor lock-in, changing infrastructure tools such as version control systems have costs in
terms of effort and lost productivity that are not adding value to the project.
Belonging to a community. Open source projects also have extremely close development
communities. Becoming part of a community that creates something of value and the associated respect
and accolades provides significant personal value for many open source contributors. An open source
projects success depends on the attention and focus of their community and successful projects
encourage and foster their communities. Contributors may be promoted to the class of committers
(given repository commit rights) by showing their value to the project. Value is not just technical
ability, but also an understanding of the projects vision, using good judgment executing that vision, and
generally playing well with others. Good developers, both technically and socially, meet and
collaborate on open source projects and it helps market themselves in the development community.
As an example, a colleague was answering questions about an open source project during a job
interview. The interviewer asked a question about a problem he was having with the product. This
colleague responded, I submitted a fix for that problem and proceeded to show the interviewer his
change in the version control logs. The interview literally ended there and an offer soon followed. This
example demonstrates how contributing helps a developers reputation among his peers in the
community.

Rocket Gang Copyright 2010

Page 3 of 9

Making the job more interesting. Another value for open source is it can make a job more enjoyable.
Contributing to open source projects provide an outlet from the day-to-day project development. As an
example, the CEO of a software services company encourages developer participation in open source
communities. He sees value from the mutual trust with his employees to make good decisions for the
company and sees value in the freedom to make their jobs interesting. In fairness, his business provides
services around open source products and gains some value for his technical staffs involvement.
However, his observation of a content, productive workforce provides a value for using and contributing
to open source.
Many have discussed modern approaches to managing knowledge workers, and freedom, flexibility,
and job enjoyment fit well with those approaches. The challenge we will discuss next is, that, time is
money. Time spent installing, configuring, writing scripts for integrating, repairing, tracking, and
contributing to open source projects is time not spent delivering business value to the projects paying
the bills. The value propositions discussed in this section low initial costs, flexibility, community
involvement, gaining recognition in the community, and making a job more interesting need to
outweigh the associated costs.

Costs of Open Source

Free does not always mean free. This section discusses some costs using
open source development products so we can contrast those costs with IBMs
Jazz and Team Concert in the following section.
Start-up costs. When a new project begins, there is overhead installing,
configuring, and integrating tools to support the development team.
Sometimes an existing configuration can be re-used but often projects opt to
create their own configuration on their own servers to manage them
independently. The start-up time required depends on the skills of the
developer(s) and the tools selected. The time given by an experienced, open
source developer for typical, full-featured, open source development environment (Crusible, SVN, Jira,
Confluence, Hudson) was three to five days for installation and then a day or two to configure the
workflow. More time is required if one wants to automate some practices with scripts.
Integration costs. Open source projects typically have a narrow focus for a single discipline and teams
must integrate them on their own. Some integrations exist between products (e.g., Subversion/Trac) but
effort is still required to fetch the correct versions of products and the right integrations, and then
configure them. Further, these integrations are point-to-point and teams will write and support many
integration scripts for their tools.
Administration costs. The team is responsible for the integration and maintenance of the development
environment. Someone must administer the tools and be accountable when problems arise. Many
individual tools mean many multiple servers, log files, and opportunities for problems. In addition, each
developer requires accounts on all the products. There is no concept of centralized management for this
collection of tools. As developers come and go, someone must be responsible for managing accounts.
Multiple integrated products also require a more complex backup and restore procedure that will span
multiple servers. Administration costs become more significant as a project scales requiring developers
to create more scripts to help automate administration.
Change costs. Agile teams are surprisingly disciplined and have policies and procedures that help
ensure the team functions well together. Developers use scripts and customizations to automate the best
practices established by their team. Retrospectives help discover better ways of working together which
commonly cause changes to tools and/or their integrations. For example, closing an enhancement in an

Rocket Gang Copyright 2010

Page 4 of 9

issue tracking tool should automatically update the progress shown in an agile planning tool. Teams
automate and enforce their practices through custom integrations or manually collect the data (e.g., burn
down charts) which requires time away from delivering business value.
Decreased agility. There are many ways in which open source tools restrict agility. First, agile teams
strive to deliver the most business value during an iteration. Modifying open source code and
integration scripts that help automate an agile development process is not business value. In addition,
time spent away from the customers needs slows the teams progress toward delivering value.
Sometimes being agile is an excuse to skip best practices. While some arguments may have strong
roots in agile and/or lean principles, many (I believe) are an excuse to avoid well-known software best
practice. For example, some developers say branching isnt agile. Branching is a version control
solution that allows independent changes that can later merge. While branching is more effort and
requires reasonable discipline to use properly, there are many business needs that necessitate
independent versions (multiple releases, product line variants, customer-specific modifications, demos).
While most open source projects do not have these needs, they occur frequently in business scenarios.
Some of the ability to be agile problems are in fact tool-related and developers sometime blame the
practice instead of the tool. Continuing the branching discussion, no developer starts a change intending
to branch/merge/label files. Branching is an old model for managing change focused on versioning files
and makes developers responsible for knowing which branches on which files make up a specific
change. A wrong decision on merging or labeling introduces an error, breaks a build, and slows
development. This challenge of branched-based open source tools has led, to some degree, to the
branching isnt agile propaganda. Stream-based change management allows developers to group a set
of related changes together, associate them with work (a defect or an enhancement), and treat the change
as a unit. Developers then share complete changes with one another or between system variants (e.g.,
merging a defect into all product versions) with significant less probability of error (see [1] for a
comparison of streams and branching). Unfortunately most open source version tools are branch-based
helping drive the propaganda.
Deliver fast is a core agile principle. Delivering fast enables business to be more flexible as they can
defer decisions until the last possible moment, yet ensure the team can deliver those decisions. Teams
deliver faster when using a tightly integrated development environment that automates redundant tasks
and eliminates waste associated with human mistakes. The overhead often introduced by multiple,
loosely integrated tools slows development. Other development best practices are sometimes dismissed
as not being agile because of limited tool integration. Examples include relating source changes in
version control with work items in an issue tracking system, associating which work items are being
placed into a specific build, understanding how much work is left to complete a feature (a.k.a. Epic) that
spans iterations. A good, agile development environment automates these activities and a tightly
integrated development environment enables faster delivery.
Less freedom than we think. While organizations should avoid vendor lock-in, committing to any
toolset locks the organization to some extent. Previously we discussed the open source communitys
movement from CVS to Subversion to Git. Changing infrastructure tools requires a significant change,
physically and organizationally. Once we select a tool, integrate it, write scripts that support it, create
practices around using it, and educate our team on how to use it, any move will be painful.
Lock-in comes from tools that are not open and/or not based on standards. Open tools provide source
code so developers can make modifications. Open tools also provide easy integration through
published, documented APIs based on standard technologies that are easily accessible by other tools and
can participate in automation.
Finally, open source projects cannot always ensure free open source availability. Products are
occasionally acquired (or their chief committers acquired).

Rocket Gang Copyright 2010

Page 5 of 9

Does the environment scale? Very few successful projects remain small. Success commonly requires
growth and the ability to handle more capacity and respond to more customers. Many small projects are
challenged by and unprepared for growth. Initial development products, integrations, and practices need
to change as success grows the project. The ability to scale, sometime rapidly, can determine business
success or failure.

Why is Rational Team Concert Different

In the past, commercial products had limited ability to support small, agile teams. They were designed
for larger organizations, had large upfront costs, had closed development environments, and were not
attractive to small- and mid-sized development communities. Only large organizations had the
infrastructure necessary to consume these products. This section discusses how IBMs Jazz technology
and specifically the Team Concert product are different.
In the early 2000s, IBM launched an internal effort to extend Eclipse technology to support a
collaborative development environment for highly cohesive teams. That effort produced a technology
called Jazz, and Rational Team Concert (RTC) was the first of many products built on Jazz technology.
There are many ways to view Jazz and Team Concert. First, Team Concert is an integrated product for
managing development lifecycle activities for large and small, distributed and non-distributed teams.
Tight integration allows Team Concert to automate redundant tasks and ensure tasks are consistently
executed. Second, Jazz is an open platform built on Eclipse technology that, like Eclipse, is easily
extensible by a broad community. Finally, Jazz represents a new approach to commercial software
development that blends open source best practices into the commercial software development process.
Jazz provides a client-server architecure based on standards. All artifacts are stored in a relational
database (Oracle, SQL Server, DB2, or Derby) and the server components run in a JEE container
(Tomcat or WebSphere). All client-server communication are REST-full (XML over HTTP) services.
Jazz-based products like RTC provide several client interfaces including Eclipse, Web, and Visual
Studio. Like other web-based products, a full-featured web client means non-developers (e.g., Product
Owners, Scrum Masters, customers etc.) can perform their tasks from their browser without any
installation.
Rational Team Concert combines change/issue management, configuration/version management, agile
planning, and build management into a single, integrated product. RTC also provides subscriptionbased event notification so users can subscribe to changes that interest them. The RTC process engine
provides the ability to change permissions (who can perform which task based on the users role) and
enable process actions. These process actions provide best practices for team collaboration out of the
box. Agile teams are
surprisingly disciplined and
continually discover better
practices through activities like
retrospectives. RTCs process
actions help teams enforce these
decisions. For example, an
action may require a developer
to associate a work item from
issue tracking with their change
before delivering, or require an
approved code review before
delivering a change to the
repository.

Rocket Gang Copyright 2010

Page 6 of 9

The Team Concert Value Proposition

Community. Jazz projects execute in a radically different model than traditional commercial software
development. From the jazz.net site, users can download the source code, grab incremental builds, view
the RTC teams iteration plans, and add new work items, or provide additional information to existing
ones. The Team Concert development team uses RTC for their development and all work, plans, source
code changes, builds, etc. are accessible to users.
Jazz.net also hosts the teams wikis and blogs, offers over 100 articles on using the Jazz products, and
provides an active discussion forum for users and developers to collaborate. Jazz projects run like
typical, active open source projects in the sense they are open and any one in the community can
contribute. The primary differences are the license and the fact that the committers are IBM employees.
The collaborative nature and openness rival even the largest open source projects.
Immediate productivity. Team Concert works out of the box and requires no setup. Users simply
unzip the server, start the Tomcat application server, configure the servers email (SMTP) and users
(optional LDAP), and start working 10 minutes to delivering business value. If we have an existing
server already running, creating a new project is as simple as New > Project, add team members, and
start working 1 minute to delivering business value. Team Concert reduces administration overhead
to almost zero. As team members join and leave a project, administration occurs in one place, not in
multiple tools.
Reduced integration costs. For standard development activities including version control, issues
tracking, build management, agile planning, and event notification there are no integration costs. They
work together out of the box. However, RTC understands development environments will be
heterogeneous and provides a connector architecture with two usage models (migration and
synchronization) that integrates existing products. There are integrations for Git, Subversion, CVS,
ClearCase for version control, Bugzilla, ClearQuest, Jira, for change management, and Hudson,
CruiseControl, Ant, and Maven for build management available today. See [2] for more information on
RTC integrations.
Some development organizations require integrations with other products. All RTC client applications
(Eclipse, web browser, Visual Studio) communicate with the server over the same REST interfaces.
REST is the de facto standard for systems integration, as it is technology agnostic and all modern
development technologies support XML and HTTP. A full-featured, open, REST-based API means
development teams can integrate with RTC at least as effectively as any open source product.
Flexibility. While RTC appears to be a monolithic development environment, it is deployed as a series
of Eclipse plug-ins. Adding behavior to the client or server is as simple as writing Eclipse plug-ins that
invoke Java APIs. RTC provides an Eclipse self-hosted development environment similar to the Eclipse
PDE to debug both server and client additions. Those organizations that want to customize RTC have
that flexibility and one of the jazz.net forums is devoted to extending RTC. The use of standards
(REST, Eclipse) make RTC perhaps the best platform for integrating development tools.
Increased agility. Agile teams continually improve their processes through activities like
retrospectives, which lead to best practices for the team. As discussed earlier, Team Concert builds in
best practices through permissions and process actions. Teams can change their process by simply
enabling, disabling, or reconfiguring RTC permissions and/or actions. Process changes take minutes,
work out of the box, and do not require changes to code or scripts. Process changes can be made on a
per-team basis so one team may choose to follow a different process than another team (often a large
challenge for script-based practice enforcement). Process can also change per-iteration, for example to
tighten development closer to a release (e.g., requiring code reviews before deliver or only permitting
tech leads to deliver code).

Rocket Gang Copyright 2010

Page 7 of 9

It scales with growing projects. Team Concert scales with a growing organization and mitigates risks
associated with growth. A small project can begin with the free version, and then seamlessly move to a
licensed product based on success. Team Concert scales as far as any development organization grows.
The RTC team performs their scalability tests with 1500 simultaneous users. And internally, IBM hosts
hundreds of projects (including all those on jazz.net) and thousands of developers on a single RTC
instance (two app servers connected to a single database).
Its free! Team Concert is open source and it is even free, in some circumstances. The Express-C
version of Team Concert is free and supports up to 10 users. Team Concert is also free for open source
and academic use regardless of developer size. Organizations can freely use RTC on their projects of up
to 10 and deploy multiple Express-C servers to support multiple projects if necessary.
Issues Adopting Rational Team Concert
While we discussed several advantages Team Concert has over open source products, there are some
challenges in adopting RTC. RTCs largest advantage is perhaps its Achilles Heal. Its tightly
integrated development environment provides significant value, but that size also limits the
communitys understanding of where RTC fits in the development environment. For example,
Subversion is a version management product, CruiseControl is a build management product, and Team
Concert is a version-change-defect-build-process-collaboration-notification-etc. product. Consequently,
when developers see RTC for the first time, it looks large and overwhelming. The solution is to
understand RTC a feature at a time. For example, begin with issue tracking, then add version control,
then agile planning, then build management. The jazz.net site has tutorials that cover the entire product
as well as deep dives into each feature area.
Another challenge for RTC, due its size, is determining an adoption strategy. RTC integrates the most
common development activities versioning, issue tracking, builds, planning. Organizations will
already have products in place to support most of these areas, along with scripts and processes around
using them. While moving from Subversion to Git disrupts a development team, simultaneously
changing version control, issues tracking, builds, agile planning, etc. would be a huge disruption.
Incremental adoption allows the team to consume RTC features over time. And, RTCs connector
architecture can help smooth adoptions by importing artifacts from other tools or providing a real-time
synchronization to allow adoption over time.

Summary

This paper contrasted the value of open source and commercial software development products. While
there was no feature comparison, this author believes RTC would overwhelm other products in a feature
comparison. There are many reasons why organizations select open source products, reduced up front
costs, the flexibility to select the best product, being part of a community, and eliminate vendor lock-in.
However, organizations eliminating capital costs on licenses lose track of the added labor costs
associated with open-source products, particularly if they do not track their labor costs.
Team Concert provides similar value no cost for projects up to 10 developers (and very competitive
pricing for larger projects), a connector architecture for synchronizing with many popular tools (Git,
Subversion, Jira, CruiseControl, etc.), and the jazz.net community which rivals any open source
community. Team Concerts REST APIs coupled with the ability to write custom plug-ins also rival
any open source product for extensibility. And Team Concert scales with a growing project. A small
project can begin with a free version, and then purchase a license as the project grows based on success.
Open Source and IBM: From the Cathedral to the Bazaar
Some may find it ironic to hear IBM mentioned in the same sentence with open source and agile. The
reality is IBM was an early participant with open source projects, migrating very early to Linux from its

Rocket Gang Copyright 2010

Page 8 of 9

own proprietary AIX operating system. IBM is also a significant contributor in Eclipse, Apache, and
Jakarta communities. With this experience, IBM has seen the value of open development, project
visibility, and the formation of communities. Jazz and Team Concert represent a next step in IBMs
commercial product development, integrating best practices from open source communities. The
significance of IBMs decision to open Jazz commercial development to this extent cannot be
understated, shifting from the Cathedral towards the Bazaar [3].
Open Source or Commercial?
This paper made a business case for considering IBM-Rationals Team Concert. Some organizations
will choose open source for the values discussed earlier such as freedom and flexibility. However, this
author believes RTCs features, productivity increases, openness, community, and integration stories
present a compelling value proposition.
The open source versus commercial product value discussion perhaps comes down to organizational
culture. Showing one side, a Software Engineering Director moved to Team Concert in order to
dramatically reduce costs for customizing and integrating development products. He felt development
best practices had stabilized to the point he should get them out of the box why do we think our
development is so different than everyone else what makes us so special? He wanted his
development organization focused on delivering business value, not on their development environment.
On the other side, some organizations see value enabling developers with freedom and flexibility.
Those organizations provide their developers time to review products, customize their environment, and
even contribute back to open source communities the freedom to make the job interesting, to quote
the CEO of a software services organization. Organizational culture business-centered vs. developercentered can be the driving force behind the decision.
While there are business reasons to adopt open source, some may advocate its use without having a
solid business case. As an example, a colleague had a term he called Resume-Oriented Programming
where a developer may recommend a technology not because it represents the best business decision,
but because he could add the technology to his resume. In addition, every community has its vocal
contingency and the open source community is no different with its anything but commercial zealots.
We should make business decisions based on value and return on investment, not on personal agendas
or the choice from the most vocal team member.
Where Do You Go From Here?
The best place to start is jazz.net where you can download Team Concert, ask questions in the forums,
read the articles, wikis, and blogs, and track the development team through their iteration plans, reports,
and dashboards. Jazz.net also contains a significant amount of learning material with articles,
presentations, and techtips.
I am always interested in information and feedback on development products, both open source and
commercial. Please contact me at harry@rocketgang.com. We can also arrange a Team Concert
demonstration with your development team and discuss how Team Concert may or may not fit in your
organization. We have helped many organizations using open source products such as SVN,
Bugzilla, Perforce, VersionOne, Rally, Jira, and home-grown solutions make informed decisions on
software development products.

References

[1] http://daveonscm.blogspot.com/2007/09/agile-branches-vs-streams.html
[2] http://jazz.net/projects/rational-team-concert/integrations/
[3] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

Rocket Gang Copyright 2010

Page 9 of 9