10.7 Interacting with the Open Source Community 239
Chapter 10
From this, we can tell if the application is a candidate for migration and
start developing a project definition.
Issues we may find include data quality of the current system, its histori-
cal availability and cost of service, and security. Older systems often have
issues with system availability, scheduled or unscheduled—for instance,
they are not so likely to support Web or global 24/7 needs. There also may
be difficulty in use, such as high training costs or data entry error rates.
A common strength of existing systems is that the system is paid for and
the current staff is trained in its use. However, over time costs of security
and maintenance may have crept up, and most systems have periodic main-
tenance and upgrades. Some companies outsource because these types of
costs have gone out of control.
Development productivity is commonly an issue with older systems,
making it difficult to respond to changes in the business or to access data in
new ways. Development activities in old complex systems often have
remarkably little connection with current customer priorities.
10.7 Interacting with the Open Source Community
We will interact with the open source community in several ways. We will
have open source developers on staff, and need to consider how to hire and
retain them. We will interface with open source products by using them, and
may have opportunities to contribute to them with code, work, or finance.
10.7.1 Hiring from the Community
A few people in open source are famous in a general sense, but, much more
importantly, at the level of code contribution to particular projects, many
people have built reputations within a particular community. Open source
is open and public, so you can see code, written postings, and so on that
you would never see in a candidate from a closed code company. It may be
a good idea to use those resources.
In some cases, you might want to hire the maintainer of a code project if
it’s important to you. Martin Fink of Hewlett-Packard cites a “two-hop
rule. If a project is important to his organization, he likes to know that he is
two people away from a maintainer or key contributor to the project. Either
someone on the project, or someone who is known and trusted by those on
the project, should be known to him.
240 10.7 Interacting with the Open Source Community
In any case, a maintainer from a successful open source project has a
project management background. Maintainers have managed code contri-
butions; motivated and given credit; attracted/retained developers and
other resources, mostly without using money; and developed or adopted
processes for code management and release. That is a good set of skills, even
if the project they work on is directly relevant to you.
10.7.2 Employee Agreements
There are several issues where organizations generally do not have policies
today, but may need to develop one. This may involve a review of relevant
employment contracts. The following are some examples, but this is not an
exhaustive list; there may be other issues.
Some employees will want to be allowed to work on open source
projects while on organization projects—for instance, by sharing utility
code or returning enhancements made to open source software. This is rea-
sonable, but may conflict with current employment agreements. Others
may wish to contribute to open source software on their own time. This is
also reasonable, but many organizations have blanket policies prohibiting
it. There is also the question of copyright ownership. Most open software
projects, including Samba and Apache, do not allow retention of copyright
by the contributing company. This again may conflict with current policies.
Some employees may only be willing to work on open source, and your
company will probably not be doing open source exclusively. This may
require a special arrangement—for instance, they may have to work as con-
tractors rather than employees.
10.7.3 Repaying the Community
Organizations that benefit from open source software often develop meth-
ods for repaying the community. The simplest can be allowing employees to
work and contribute to the community, as well as serving as a reference and
otherwise being a good citizen. There may be opportunities for sponsoring
enhancements that are relevant to your organizations use. By directing
investment toward enhancements your organization needs, you may gain
leverage in the direction of the product.
In negotiating with open source developers, it may be helpful to bear in
mind the motivation discussed in the previous chapter. Money is an ele-
ment, but so is a measure of fame and an opportunity to work on some-
thing worthwhile. If your organization is able to offer a proposition that

Get Open Source Software: Implementation and Management now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.