Organizations and Money: Businesses, Non-Profits, and Governments
This chapter examines how to use money and organizational
capacity constructively in a free software environment. It also
discusses some of the adjustments an organization may need to
make as it gets involved in free software projects.
When an
organization makes an investment in open source, people at all levels
have to understand not just how best to structure that investment, but
the effects that long-term open source engagement will have on the
organization itself. Open source can be
transformative — at least when done right. Thus,
while the material here should be useful for developers who are paid
to work on open source projects, it's really meant for managers
and for executives making strategic decisions.
This chapter is not primarily about how to
find funding sources for your open source project, though I hope it
will usefully inform that topic. There are many different ways open
source projects are fundedSee https://en.wikipedia.org/wiki/Business_models_for_open-source_software
for an incomplete list., just as there are many ways
all human endeavors are funded. While open source is incompatible
with one particular business
model — monopoly-controlled royalty streams based on
per-copy sales — it is compatible with all the others,
and indeed is better suited to some of them than proprietary software
is.
The Economics of Open Source
People are still sometimes surprised to learn that most free
software is written by paid developers, not by volunteers. But the
economics that drive open source are actually quite straightforward: a
company needs a particular piece of software to be maintained
and developed, and does not need monopoly control of that software.
Indeed, it would often be disadvantageous to have a monopoly, because
then the entire burden of maintenance would fall on that one company,
instead of being shared with others who have the same needs. For
example, most companies have web sites and therefore need a web
server, but almost no companies need exclusive control over the
development of their web server, or intend to sell copies of it on a
proprietary basis. The same is true of office software suites,
operating system kernels, network connectivity tools, educational
programs, etc — just as historically it has also been true
of electric grids, roads, sewer systems, and other goods that everyone
needs but no one needs to own. Just as we expect road workers to be
paid, we should expect software developers to be paid as well.
Even in the early days of free software, when the proportion of
truly unpaid volunteers was probably higherThis is an
educated guess — I'm not aware of any rigorous
research into the question. I do know from personal experience
and anecdotal evidence that at least some paid open source work was
happening early on. than it is now, there were
already developers who were paid for their work. There was also a lot
of informal subsidy, as there continues to be today. When a system
administrator writes a network analysis tool to help her do her job,
then posts it online and gets bug fixes and feature contributions from
other system administrators, what's happened is that an unofficial
consortium has been formed. The consortium's funding comes from the
sysadmins' salaries; its office space and network bandwidth are
donated, albeit unknowingly, by the organizations those people work
for. Those organizations also benefit from the investment, of course,
though they may or may not be institutionally aware of it.
Today such efforts are often more
formalized. Corporations have become conscious of the benefits of
open source software, and now involve themselves intentionally in its
development. Developers too have come to expect that really important
projects will attract funding in one way or another. The key question
is how the hierarchical command structures of corporations and the
polyarchical, non-coercive communities of free software projects
can work productively with each other — and how they can
agree on what "productively" means.
Financial backing is generally welcomed by open source
development communities. Having paid developers means that bug reports
are more likely to be listened to, that needed work is more likely to
get done, and that the project will be less vulnerable to the Forces
of Chaos (e.g., a key developer suddenly losing interest) that lurk
at the edges of every collaborative endeavor. One important dynamic
is that credibility is contagious, to a point. When a large company
visibly backs an open source project, people assume the project will
receive adequate support in its early stages and have the chance to
succeed or fail on its long-term merits; other participants' resultant
willingness to invest in the project can then make this a
self-fulfilling prophecy.
However, money can also bring a perception of control. If not
handled carefully, this can divide a project into in-group and
out-group developers. If developers who aren't officially paid to
work on the project get the impression that design decisions or feature
additions are simply available to the highest bidder, they'll leave for
a project that seems more like a meritocracy and less like unpaid
labor for someone else's benefit. They may never complain overtly on
the mailing lists. Instead, there will simply be less and less noise
from sources outside the main funded group, as the "out" developers gradually stop trying
to be taken seriously. The buzz of small-scale contribution may
continue, in the form of bug reports and occasional small fixes. But
there will be fewer and fewer large code contributions from unexpected
sources, fewer unexpected opinions offered in design discussions,
fewer bug reports that reveal unexpected new uses of the software, and
so on. People sense what's expected of them, and live up (or down) to
those expectations.
So money needs to be used carefully, and without communicating
an intent to control. But it can still buy influence. The trick is that it
doesn't buy influence directly. Instead, it buys
development credibility, which is convertible to influence through the
project's decision-making processes.The report
Open Source Archetypes: A Framework For Purposeful Open
Source (https://opentechstrategies.com/archetypes), as mentioned earlier in
, may be worth a look if you're trying to
understand the ways in which a project should be subject to
influence and by whom.
In a straightforward commercial transaction, you trade money for
what you want, because your counterparty has enough control to
guarantee the delivery of the goods. If you need a feature added, you
sign a contract, pay for it, and (if all goes well) the work gets done
and the feature eventually lands in the product.
In an open source project, the process is more complex. You may
sign a contract with some developers, but they'd be fooling
themselves — and you — if they
guaranteed that the work you paid for would be accepted by the
development community simply because you paid for it. The work can
only be accepted based on its own merits and on how it fits into the
community's vision for the software (see
and ). You may have some say in that vision,
but you won't be the only voice.
But although money can't purchase influence directly in an open
source project, it can purchase things
that lead to influence. The most obvious example
is programmers. If you hire good programmers, and they stick around
long enough to get experience with the software and credibility in the
community, then they can influence the project by the same means as
any other member. They will have a vote, or if there are many of
them, they will have a voting block.Even though actual
votes may be rare, as noted in ,
the possibility of a vote has great implicit
power, so membership in the electorate is still important even if no
vote is ever held. If they are respected in the
project, they will have influence beyond just their votes. There is
no need for paid developers to disguise their motives, either. After
all, everyone who wants a change made to the software wants it for a
reason. Your company's reasons are no less legitimate than anyone
else's. It's just that the weight given to your company's goals will
be determined by its representatives' status in the project, rather than by
your company's size, budget, or business plan.When
companies need to guarantee that certain features and bug fixes land
in a specified amount of time, they accomplish this by keeping their
own copy of the project (ideally also public and under open source
license), and merging it from time to time with the separate upstream
project that has its own independent governance. Google's Android
operating system is a classic example: Google maintains its own copy
(or copies) of Android, which it governs as it pleases, and from time
to time merges changes to or from the main Android Open Source Project
(https://en.wikipedia.org/wiki/Android_%28operating_system%29#Open-source_community).
Essentially, Google is on a very long copy-modify-merge loop with
respect to main the open source project, and vice versa. It is in
neither side's interests to permanently diverge from the
other.
Goals of Corporate Involvement
There are many different reasons open source projects get
corporate support. The list below is just a high-level survey, and
the items in it aren't mutually exclusive — often a
project's financial backing will result from several, or even all, of
these motivations:
Share the burden
Separate organizations with related needs often
find themselves duplicating effort, either by redundantly writing
similar code in-house or by purchasing similar products from
proprietary vendors. As the inefficiency becomes apparent to the
different parties, they may pool their
resources — often gradually, without at first
realizing the overall trajectory of the
process — and create or join an open source
project tailored to their needs. The advantages of doing so are obvious: the
costs of development are divided, but the benefits accrue to all.
Although this scenario might seem most intuitive for nonprofits,
in practice it happens often among for-profit competitors
too.
Ensure maintenance of product infrastructure
When a company sells services which depend on, or are made
more attractive by, particular open source programs, it is
naturally in that company's interests to ensure those programs
are actively maintained.
Establish a standard
Often a corporation has strategic reasons to establish a
technical standard. Releasing an open source
implementation of that standard, and shepherding the software
into widespread use, is usually the most effective way to get
buy-in from others for the standard.
Create an ecosystem
For investors who like to think big, the right open source
effort can create a new ecosystem — one in which
those investors are more likely to flourish.
Support hardware sales
The value of computers and computer components is directly
related to the amount of software available for them. Hardware
vendors — not just whole-machine vendors, but also makers
of peripheral devices and microchips — have found that
having high-quality free software to run on their hardware is
important to customers.
Undermine a competitor
Sometimes companies support a particular open source
project as a means of undermining a competitor's product, which
may or may not be open source itself. Eating away at a
competitor's market share is usually not the sole reason for
getting involved with an open source project, but it can be a
factor.
Marketing
Having your company associated with a popular open source
application can be good brand management, not just in the eyes of
customers but in the eyes of potential employees.
Proprietary relicensing
Proprietary relicensing is the practice of
offering software under a proprietary license for
customers who want to resell it as part of a proprietary
application of their own, and simultaneously under a free license
for those willing to use it under open source terms. If the open source developer
community is active, the software gets the benefits of wide-area
debugging and development, yet the company still gets a royalty
stream to support some full-time programmers.
Proprietary relicensing is controversial because it is not a
open source" model, but rather yokes
funding for open source development to a monopoly-based revenue
stream. Whether this is a problem for you depends on where you
fall on the "open source is just a way of software development"
to "open source is a way of life" spectrum. The presence of
revenue from a proprietary version does not necessarily
mean that the free software version is worse off, and some very well-known
and widely-used free software has had corresponding proprietary
versions (MySQLhttps://en.wikipedia.org/wiki/MySQL
is probably the most famous example). However,
some developers dislike the thought that their contributions may
end up in the proprietary version. Also, the mere presence of
the proprietary version suggests the possibility that some of the
best salaried developers' attention is going to the proprietary
code, not the open source code. This tends to undermine other
developers' faith in the open source project, which in turn makes
it difficult to develop a truly flourishing ecosystem around the
open source version.
None of is meant to persuade you not to do proprietary relicensing.
You should just be aware that this strategy is unlike the other
business approaches I've listed here, that it requires more care
and sophistication to manage successfully, and that it is usually
incompatible with the presence of a committed and involved
ecosystem of developers from outside your organization,
particularly developers who might have their own commercial
motivations.
See for
more.
A funder's business model is not the only factor in how that
funder relates to an open source community. The historical relationship
between the two also matters: did the company start the project, or did
it join an existing development effort? In both cases, the funder
will have to earn credibility, but, not surprisingly, there's a bit
more earning to be done in the latter case. The organization needs to
have clear goals with respect to the project. Is it trying
to keep a position of leadership, or simply trying to be one voice in
the community, to guide but not necessarily govern the project's
direction? Or maybe it just wants to have a couple of committers
around, able to fix customers' bugs and get the changes into the
public distribution without any fuss?
Keep the question of goals in mind as you read the guidelines that
follow. They are meant to apply to any sort of organizational
involvement in a free software project, but every project is a human
environment, and therefore no two are exactly alike. To some degree,
you will always have to play by ear, but following the principles in
this chapter will increase the likelihood of things turning out the
way you want.
Governments and Open Source
Since the first edition of this book came out in 2005, I've worked with
various U.S. government agencies (federal, state, and municipal)
to help them develop and participate in open source software. I've also been
lucky enough to observe, and in a few cases work with, some government
agencies outside the U.S. These experiences have convinced me of one
thing: government is different. If you work at a government agency
and the material in this book so far has made you shake your head and
think "Sure, but it'll never work here", you have my sympathy
— I know what you mean. Governments differ
from individuals and from private-sector organizations in some
fundamental ways:
Governments often aren't trying to retain technical
expertise in-house. That's what contractors are for, after all.
Governments have labyrinthine and in certain ways
inflexible procurement and employment policies. These policies can
make it difficult for a government agency to be nimbly responsive in
an open source development community.
Government agencies tend to be unusually risk-averse.
Somewhere at the top there's an elected official who, reasonably,
sees an open source project as just another exposed surface for
opponents to attack. After all, when development happens in public,
the inevitable false starts and wrong turns are also public; if
development were internal, no one else would know about it when
those things happen.
Government officials hunger for well-timed and
well-controlled publicity events, and this need can sometimes be in
tension with overall project health. The need for good publicity
is, in a way, the complement of being risk-averse. Elected
officials and those who work for them understand that most people
aren't paying much attention most of the time. Therefore,
government workers want to make sure that in the few moments when
people are paying attention they see something
good. This is understandable, but it can cause certain actions to
be delayed — or, in some cases, done too
soon — based on external publicity implications
rather than on what's best for the project technically and
socially.
There are good reasons for all of these things; they've been
true for decades or even centuries, and they're not going to change.
So if you're a government agency and you want to start a successful
open source project, certain adjustments will be necessary to
compensate for the structural idiosyncrasies mentioned above. Much of
that advice is also applicable to non-governmental organizations, and
is already present elsewhere in this chapter, so below I'll
simply list the sections that I think are most
important for a government agency:
In addition to the above sections in this book, there are many
excellent online resources about open source in government. I
won't even try to include a complete list, as there is too much and it
changes too quickly. Here are a few sites that are likely to remain
good starting points for some time to come, especially for government
agencies in the United States and in countries with procurement and
civil service systems similar to those of the U.S.
https://18f.gsa.gov/ is a digital services agency within the United
States federal government, created in 2014 to bring modern software
development practices to government work. 18F serves as a
technology consultancy to other agencies, and builds its
deliverables out in the open as open source software. Along the
way, 18F has generated useful guidelines and observations that anyone
trying to run an open source software project within government can
benefit from.
http://www.dwheeler.com/, the home site of Dr. David A. Wheeler, is a
fantastic trove that includes, among many other open-source-related
things, tons of information about how to use U.S. government
procurement regulations to support open source development.
http://ben.balter.com/2015/11/23/why-open-source/ is a terrific
post to mine for arguments, if you are advocating for open source
development within a government agency. Many of Ben Balter's other
writings are worth looking at too.
Finally, there is one issue in particular that I have
encountered over and over again in government-initiated open source
projects. It is so common, and so potentially damaging to a project,
that I have given it its own subsection below.
Being Open Source From Day One is Especially Important for
Government Projects
In , I
explained why it's best for an open source project to be run in the
open from the very beginning. That advice, particularly , is especially applicable to
government code.
Government projects have greater potential to be harmed by a
needless exposure event than private-sector projects have. Elected
officials and those who work for them are understandably sensitive to
negative public comments. Thus even for the most conscientious team,
a worrying cloud of uncertainty will hover over everything by the time
they're ready to open up hitherto closed code. How can they ever know
they've got it all cleaned up? One can never be
totally sure some hawk-eyed hacker out there won't spot something
embarrassing after the publication. This worry is an
energy drain: it causes the team to spend time chasing down ghosts, and at
the same time can cause them to unconsciously avoid steps that might
risk revealing real problems.
This concern doesn't only apply to government software, of
course. But in the private sector, businesses sometimes have
competitive reasons to stay behind the curtain until their first
release, even if they intend for the project to be open source in the
long run. Government projects should not have that motivation for
starting out closed, at least in theory, and they have even more to
lose.
Hire for the Long Term
If you're managing programmers on an open source project, keep
them there long enough that they acquire both technical and political
expertise — a couple of years, at a minimum. Of course, no
project, whether open or closed-source, benefits from swapping
programmers in and out too often. The need for a newcomer to learn
the ropes each time would be a deterrent in any environment. But the
penalty is even stronger in open source projects: outgoing
developers take with them not only their knowledge of the code, but
also their status in the community and the human relationships they
have made there.
The credibility a developer has accumulated cannot be
transferred. To pick the most obvious example, an incoming developer
can't inherit commit access from an outgoing one (see
later in this chapter), so if the
new developer doesn't already have commit access, he will have to
submit patches until he does. But commit access is only the most
easily quantifiable manifestation of lost influence. A long-time developer
also knows all the old arguments that have been hashed and rehashed on
the discussion lists. A new developer, having no memory of those
conversations, may try to raise the topics again, leading to a loss of
credibility for your organization; the others might wonder "Can't
they remember anything?" A new developer will also have no political
feel for the project's personalities, and will not be able to
influence development directions as quickly or as smoothly as one
who's been around a long time.
Train newcomers through a program of supervised engagement. The
new developer should be in direct contact with the public development
community from the very first day, starting off with bug fixes and
cleanup tasks, so he can learn the codebase and acquire a reputation
in the community, yet not spark any long and involved design
discussions. All the while, one or more experienced developers should
be available for questioning, and should be reading every post the
newcomer makes to the project forums, even if the posts are in threads
that the experienced developers normally wouldn't pay attention to.
This will help the group spot potential rocks before the newcomer runs
aground. Private, behind-the-scenes encouragement and pointers can
also help a lot, especially if the newcomer is not accustomed to
intense peer review of his code.
Case study
At CollabNet, when we hired a new developer to work on
Subversion, we would sit down together and pick some open bugs for the
new person to cut his teeth on. We'd discuss the technical outlines
of the solutions, and then assign at least one experienced developer
to (publicly) review the patches that the new developer would (also
publicly) post. We typically didn't even look at the patch before the
main development list saw it, although we could if there were some
reason to. The important thing is that the new developer goes through
the process of public review, learning the codebase while
simultaneously becoming accustomed to receiving critiques from
complete strangers. But we also tried to coordinate the timing so
that our own review came immediately after the posting of the patch.
That way the first review the list sees is ours, which can help set
the tone for the others' reviews. It also contributes to the idea
that this new person is to be taken seriously: if others see that
we're putting in the time to give detailed reviews, with thorough
explanations and references into the archives where appropriate,
they'll appreciate that a form of training is going on, and that it
probably signifies a long-term investment. This can make them more
positively disposed toward the new developer, to the degree of spending a
little extra time answering questions and reviewing patches
themselves.
Appear as Many, Not as One
Your developers should strive to appear in the project's public
forums as individual participants, rather than as a monolithic
corporate presence. This is not because there is some negative
connotation inherent in monolithic corporate presences (well, perhaps
there is, but that's not what this book is about). Rather, it's
because individuals are the only sort of entity that open source projects
are structurally equipped to deal with. An individual contributor can
have discussions, submit patches, acquire credibility, vote, and so
forth. A company cannot.
Furthermore, by behaving in a decentralized manner, you avoid
stimulating centralization of opposition. Let your developers
disagree with each other on the mailing lists. Encourage them to
review each other's code as often, and as publicly, as they would
anyone else's. Discourage them from always voting as a bloc, because
if they do, others may start to feel that, just on general principles,
there should be an organized effort to keep them in check.
There's a difference between actually being decentralized and
simply striving to appear that way. Under certain circumstances,
having your developers behave in concert can be quite useful, and they
should be prepared to coordinate behind the scenes when necessary.
For example, when making a proposal, having several people chime in
with agreement early on can help it along, by giving the impression of
a growing consensus. Others will feel that the proposal has momentum,
and that if they were to object, they'd be stopping that momentum.
Thus, people will object only if they have a good reason to do so.
There's nothing wrong with orchestrating agreement like this, as long
as objections are still taken seriously. The public manifestations of
a private agreement are no less sincere for having been coordinated
beforehand, and are not harmful as long as they are not used to
prejudicially snuff out opposing arguments. Their purpose is merely
to inhibit the sort of people who like to object just to stay in
shape; see for more about
them.
Be Open About Your Motivations
Be as open about your organization's goals as you can without
compromising business secrets. If you want the project to acquire a
certain feature because, say, your customers have been clamoring for
it, just say so outright on the mailing lists. If the customers wish
to remain anonymous, as is sometimes the case, then at least ask them
if they can be used as unnamed examples. The more the public
development community knows about why you want
what you want, the more comfortable they'll be with whatever you're
proposing.
This runs counter to the instinct — so easy to acquire, so
hard to shake off — that knowledge is power, and that the more
others know about your goals, the more control they have over you.
But that instinct would be wrong here. By publicly advocating the
feature (or bugfix, or whatever it is), you have
already laid your cards on the table. The only
question now is whether you will succeed in guiding the community to
share your goal. If you merely state that you want it, but can't
provide concrete examples of why, your argument is weak, and people
will start to suspect a hidden agenda. But if you give just a few
real-world scenarios showing why the proposed feature is useful,
that can have a dramatic effect on the debate.
To see why this is so, consider the alternative. Too
frequently, debates about new features or new directions are long and
tiresome. The arguments people advance often reduce to "I personally
want X," or the ever-popular "In my years of experience as a software
designer, X is extremely important to users" or "...is a useless frill
that will please no one." The absence of real-world usage
data neither shortens nor tempers such debates, but instead allows
them to drift farther and farther from any mooring in actual user
experience. Without some countervailing force, the end result is
likely to be determined by whoever was the most articulate, or
the most persistent, or the most senior.
As an organization with plentiful customer data available, you
have the opportunity to provide just such a countervailing force. You
can be a conduit for information that might otherwise have no means of
reaching the development community. The fact that the information
supports your desires is nothing to be embarrassed about. Most
developers don't individually have very broad experience with how the
software they write is used. Each developer uses the software in
her own idiosyncratic way; as far as other usage patterns go, she's
relying on intuition and guesswork, and deep down, she knows
this. By providing credible data about a significant number of users,
you are automatically improving the quality of debate in the public
development community. As long as you present it right they will welcome it
enthusiastically, and it will propel things in the direction you want
to go.
The key, of course, is presenting it right. It will never do to
insist that simply because you deal with a large number of users, and
because they need (or think they need) a given feature, therefore
your solution ought to be implemented. Instead, you should focus your
initial posts on the problem, rather than on one particular solution.
Describe in great detail the experiences your customers are
encountering, offer as much analysis as you have available, and as
many reasonable solutions as you can think of. When people start
speculating about the effectiveness of various solutions, you can
continue to draw on your data to support or refute what they say. You
may have one particular solution in mind all along, but don't single
it out for special consideration at first. This is not deception, it
is simply standard "honest broker" behavior. After all, your true
goal is to solve the problem; a solution is merely a means to that
end. If the solution you prefer really is superior, other developers
will recognize that on their own eventually — and then they will
get behind it of their own free will, which is much better than you
browbeating them into implementing it. There is also the possibility
that they will think of a better solution.
This is not to say that you can't ever come out in favor of a
specific solution. But you must have the patience to see the analysis
you've already done internally repeated on the public development
lists. Don't post saying "Yes, we've been over all that here, but it
doesn't work for reasons A, B, and C. When you get right down to it,
the only way to solve this is Q." The problem is not so much that it
sounds arrogant as that it gives the impression that you have
already devoted some unknown (but, people will
presume, large) amount of analytical resources to the problem, behind
closed doors. It makes it seem as though efforts have been going on,
and perhaps decisions made, that the public is not privy to — and
that is a recipe for resentment.
Naturally, you know how much effort you've
devoted to the problem internally, and that knowledge is, in a way, a
disadvantage. It puts your developers in a slightly different mental
space than everyone else on the mailing lists, reducing their ability
to see things from the point of view of those who haven't yet thought
about the problem as much. The earlier you can get everyone else
thinking about things in the same terms as you do, the smaller this
distancing effect will be. This logic applies not only to particular
technical discussions, but to the broader mandate of making your goals
as clear as you can. The unknown is always more destabilizing than
the known. If people understand why you want what you want, they'll
feel comfortable talking to you even when they disagree. If they
can't figure out what makes you tick, they'll assume the worst, at
least some of the time.
You won't be able to publicize everything, of course, and people
won't expect you to. All organizations have secrets; perhaps
for-profits have more of them, but nonprofits have them too. If you
must advocate a certain course, but can't reveal everything about why,
then simply offer the best arguments you can under that handicap, and
accept the fact that you may not have as much influence as you want in
the discussion. This is one of the compromises you make in order to
have a development community not on your payroll.
Money Can't Buy You Love
If you're a paid developer on a project, then set guidelines
early on about what the money can and cannot buy. This does not mean
you need to post twice a day to the mailing lists reiterating your
noble and incorruptible nature. It merely means that you should be on
the lookout for opportunities to defuse the tensions that
could be created by money. You don't need to
start out assuming that the tensions are there; you do need to
demonstrate an awareness that they have the potential to arise.
A perfect example of this came up early in the Subversion project.
Subversion was started in 2000 by CollabNet (http://www.collab.net/), which was the
project's primary funder and paid the salaries of
several developers (disclosure: including myself). Soon after the
project began, we hired another developer, Mike Pilato, to join the
effort. By then, coding had already started. Although Subversion was
still very much in its early stages, it already had a development
community with a set of basic ground rules.
Mike's arrival raised an interesting question. Subversion
already had a policy about how a new developer gets commit access.
First, she submits some patches to the development mailing list. After
enough patches have gone by for the other committers to see that the
new contributor knows what she's doing, someone proposes that she just
commit directly (that proposal is private, as described in ). Assuming the
committers agree, one of them mails the new developer and offers her
direct commit access to the project's repository.
CollabNet had hired Mike specifically to work on Subversion.
Among those who already knew him, there was no doubt about his coding
skills or his readiness to work on the project. Furthermore, the
non-CollabNet developers had a very good relationship with the CollabNet
employees, and most likely would not have objected if we'd just given
Mike commit access the day he was hired. But we knew we'd be setting
a precedent. If we granted Mike commit access by fiat, we'd be saying
that CollabNet had the right to ignore project guidelines, simply
because it was the primary funder. While the damage from this would
not necessarily be immediately apparent, it would gradually result in
the non-salaried developers feeling disenfranchised. Other people
have to earn their commit access — CollabNet just buys
it.
So Mike agreed to start out his employment at CollabNet like any
other new developer, without commit access. He sent patches to
the public mailing list, where they could be, and were, reviewed by
everyone. We also said on the list that we were doing things this way
deliberately, so there could be no missing the point. After a couple
of weeks of solid activity by Mike, someone (I can't remember if it
was a CollabNet developer or not) proposed him for commit access, and
he was accepted, as we knew he would be.
That kind of consistency gets you a credibility that money could
never buy. And credibility is a valuable currency to have in
technical discussions: it's immunization against having one's motives
questioned. In the heat of argument, people will sometimes look
for non-technical ways to win the battle. The project's primary
funder, because of its deep involvement and obvious concern over the
directions the project takes, presents a wider target than most. By
being scrupulous to observe all project guidelines right from the
start, the funder makes itself the same size as everyone
else.See also Danese Cooper's blog post, preserved in
the Internet Archive's Wayback Machine at https://web.archive.org/web/20050227033105/http://blogs.sun.com/roller/page/DaneseCooper/20040916,
for a similar story about commit access. Cooper was then Sun
Microsystem's "Open Source Diva" — I believe that was
her official title — and in the blog entry, she
describes how the Tomcat development community got Sun to hold its own
developers to the same commit-access standards as the non-Sun
developers.
The need for the funders to play by the same rules as everyone
else means that the Benevolent Dictatorship governance model (see
) is slightly
harder to pull
off in the presence of funding, particularly if the benevolent dictator works for
the primary funder. Since a dictatorship has few rules, it is hard
for the funder to prove that it's abiding by community standards, even
when it is. It's certainly not impossible; it just requires a project
leader who is able to see things from the point of view of the outside
developers as well as that of the funder, and act accordingly. Even
then, it's probably a good idea to have a proposal for non-dictatorial
governance sitting in your back pocket, ready to be brought out if
there start to be indications of widespread dissatisfaction in the
community.
Contracting
Contracted work needs to be handled carefully in free software
projects. Ideally, if you hire a contractor you want her work to be
accepted by the community and folded into the public distribution. In
theory, it wouldn't matter who the contractor is, as long as her work
is good and meets the project's guidelines. Theory and practice can
sometimes match, too: a complete stranger who shows up with a good
patch will generally be able to get it into the
software. The trouble is, it's very hard to produce an acceptable
patch for a non-trivial enhancement or new feature as a
complete stranger. One must first discuss the changes with the rest
of the project, and even for those who are very familiar with the
project the duration of that discussion cannot be precisely
predicted — for those new to the project, the margin
of error will only be higher. If the contractor is paid by the hour,
you may end up paying more than you expected; if she is paid a flat
sum, she may end up doing more work than she can afford.
There are various ways to cope with this. You can try to make an
educated guess about the length of the discussion process, based on
whatever past experience you have with that community, add in some
padding for error, and base the contract on that. It also helps to
divide the problem into as many small, independent chunks as possible,
to increase the predictability of each chunk.
Another standard technique is to contract for delivery of a
patch that meets the formal upstream guidelines and for a tightly
budgeted "best effort" at getting the patch integrated into the
upstream project treat. The contract itself can never
require that the patch be accepted by the
upstream project, because that would involve selling something that's
not for sale. (What if the rest of the project unexpectedly decides
not to support the feature?) However, the contract can require a
bona fide effort to get the change
accepted by the community, and that it be committed to the repository
if the community agrees with it. For example, if the project has
written standards (e.g., about coding conventions, documentation,
writing regression tests, submitting patches, etc), the contract can
reference those standards and specify that the contracted work must
meet them. In practice, this usually works out the way everyone
hopes.
Contracting and Transparency
Both techniques described above raise a couple of questions:
Should contracts ever be secret? And when they're not secret, should
you worry about creating tensions in the community by the fact that
you've contracted with some developers and not others?
In general, it's best to be open about contracts when you can.
Otherwise, the contractor's behavior may seem strange to others in the
community — perhaps she's suddenly giving inexplicably high
priority to features she's never shown interest in the past. When
people ask her why she wants them now, how can she answer convincingly
if she can't talk about the fact that she's been contracted to write
them?
At the same time, neither you nor the contractor should act as
though others should treat your arrangement as a big deal. Sometimes
I've seen contractors waltz onto a development list with the attitude
that their posts should be taken more seriously simply because they're
being paid. That kind of attitude signals to the rest of the project
that the contractor regards the fact of the contract — as opposed
to the code resulting from the contract — to
be the important thing. But from the other developers' point of view,
only the code matters. At all times, the focus of attention should be
kept on technical issues, not on the details of who is paying whom.
For example, one of the developers in the Subversion community handles
contracting in a particularly graceful way. While discussing his code
changes in chat, he'll mention as an aside (often in a private remark,
or privmsg, to one of the other committers)
that he's being paid for his work on this particular bug or feature.
But he also consistently gives the impression that he'd want to be
working on that change anyway, and that he's happy the money is making
it possible for him to do that. He may or may not reveal his
customer's identity, but in any case he doesn't dwell on the contract.
His remarks about it are just an ornament to an otherwise technical
discussion about how to get something done.
That example shows another reason why it's good to be open about
contracts. There may be multiple organizations sponsoring contracts
on a given open source project, and if each knows what the others are
trying to do, they may be able to pool their resources. In the above
case, the project's largest funder (CollabNet) was not involved with
these piecework contracts, but knowing that someone else was
sponsoring certain bug fixes allowed CollabNet to redirect its
resources to other bugs, resulting in greater efficiency for the
project as a whole.
Will other developers resent that some are paid for working on
the project? In general, no, particularly when those who are paid are
established, well-respected members of the community anyway. No one
expects contract work to be distributed equally among all the
committers. People understand the importance of long-term
relationships: the uncertainties involved in contracting are such that
once you find someone you can work reliably with, you would be
reluctant to switch to a different person just for the sake of
evenhandedness. Think of it this way: the first time you hire, there
will be no complaints, because clearly you had to pick
someone — it's not your fault you can't hire
everyone. Later, when you hire the same person a second time, that's
just common sense: you already know her, the last time was
successful, so why take unnecessary risks? Thus, it's perfectly
natural to have a few go-to people in the community, instead of
spreading the work around evenly.
Update Your RFI, RFP and Contract Language
If you're hiring outside contractors to create software for you,
the language you put in your Requests For Information (RFIs), Requests
For Proposals (RFPs), and contracts becomes crucially
important.
There is one key thing you must understand at the outset: the
decision makers at most large-scale software development vendors don't really want their
work to be open source. (The programming staff may feel differently,
of course, but the path to the executive suite is usually smoother
for those with an instinct for monopoly.) Instead, the vendors would
prefer that a customer hire them to produce bespoke software
that, under the hood, shares many components with the
other bespoke software they're producing for
other customers.By the way, those common components
are quite often open source libraries themselves. These days, it's
typical for a proprietary software product to contain a lot of open
source code, with a layer of proprietary custom code wrapped around
the outside. That way the vendor can sell mostly the
same product at full price many times. This is especially
true of vendors to government agencies, because the needs of
government agencies are so similar, and because jurisdictional
boundaries create an artificial multiplicity of customers who all have
pretty much the same needs. Only minor customizations may be needed
for each instance, but the different customers will pay full price
each time.
As a customer, then, your starting point for a successful
large-scale open source project is to set clear, explicit requirements
about open source development from the beginning. From the RFI or RFP
stage, all the way through the contract and into delivery and
maintenance, you must require behaviors and deliverables that will
result in a truly open source product — meaning, among
other things, a product that has the potential to be supported and
customized by vendors other than the one who originally developed it.
The most important of those requirements are:
Design and development must be done in the open from the
very start of the project (see
The code shall be explicitly licensed for open source distribution,
from the start of development through delivery and
deployment.
If the same vendor is both writing the software and
deploying the production instances, require that deployed
code must match the open source code. Don't let
proprietary tweaks — and thus vendor
lock-in — slip in via the back door
through deployment customizations.
The product should have no dependencies on proprietary
software modules; written permission from you must be
obtained before any such dependencies are
introduced.
Documentation must be sufficient to allow third parties to
understand, configure, and deploy the software. (Some
customers even test this by hiring an independent third
party to perform a deployment and submit any needed
improvements to the installation
documentation — via the open source
project's usual contribution channels, of course.)
documentation must be in formats typically used by open
source projects, e.g., plaintext, Markdown, Asciidoc, DocBook,
etc.Microsoft Word format is almost never
seen in open source projects, among other reasons because
it is not amenable to auditable spot-changes by
contributors. You will need to make sure your vendor
knows this, or else you are likely to end up with a lot of
.docx files in the repository.
The vendor's engagement with third parties who become
involved in the project should be anticipated and budgeted
for. If it is a successful open source project, there
will eventually be community management overhead, so
plan for it: e.g., specify that the vendor must
establish a participation workflow, review and prioritize
contributions, etc.
Set clear expectations about the extent to which the
vendor will participate in publicity about the
project, both among technical developer communities and
among potential users.
You, the customer, should be the copyright owner of the
code written by the vendor.
For any patents controlled by the vendor and affecting the
project, there must be an unambiguous, non-restrictive
patent grant not just to you but to everyone who receives
the code under its open source license.
If the vendor has little or no experience running or
at least participating open source projects, bring in a
separate Open Source Quality Assurance (OSQA) vendor to
provide assistance and oversight (see ).
Although this is not a complete list — every
project is different — it should give you some idea of
how to set expectations with your partners. The ability to recognize
whether these expectations are being met, in spirit not just in
letter, is also important of course, and is the subject of the next
section.
Open Source Quality Assurance (OSQA)
When a vendor whose normal mode is proprietary development is
hired to do open source, the result is usually a product that is not
truly open source and that no third party can actually
deploy.While some selection bias no doubt informs my
experience — after all, the consultant tends to get
brought in when things are going wrong, not when they're going
right — my assertion that proprietary vendors don't
get open source right if left to their own habits is based not just on
my own experiences but also on talking to many other people, who
report the same finding with remarkable
consistency. This section is about how to avoid
that problem. While in some instances the vendor — or
at least factions within the vendor — may be actively
resistant to open source, more often the problem is that they simply
don't know what they don't know. The fastest solution is to
bring in that knowledge from the outside: have a separate contract
with a different company, one entirely independent of the primary
vendor, to play the role of third-party open source
participant.
There is a long tradition of such outside review in technical
contracting, where it's known as IV&V, for
"Independent Verification and
Validation".For a more general discussion of
IV&V, see https://en.wikipedia.org/wiki/Verification_and_validation and https://en.wikipedia.org/wiki/Software_verification_and_validation.
Note that neither of those discusses open source specifically,
however. It ensures that the deliverables meet the
necessary standards by having an independent party verify this. The
independent reviewer reports to the customer, not to the primary
development contractor.
My colleague James Vasile came up with the name Open
Source Quality Assurance (OSQA)
for the corresponding role in open source software development
efforts. I like that name much better than "Open Source IV&V"
because it emphasizes the interactive and collaborative nature of the
independent vendor's role. In an open source project, the
deliverables include not just the code, but the development process
itself and the resultant potential for third-party participation.
Assistance from a separate OSQA vendor can make the difference between
a project that is open source in name only and a project that is truly
open source, in the sense that it is possible for parties other than
its original developers to deploy, maintain, and improve it.
During development, an OSQA reviewer participates the
way any third party would, posting in the project's public discussion
forums, using the installation documentation to try to get the
software up and running, reporting bugs via the public tracker,
submitting pull requests, and so on. As the project reaches the alpha
or beta stage, the reviewer confirms that the software can be deployed
as documented, without reliance on proprietary dependencies or
vendor-specific environmental conditions; that necessary
per-deployment configurations can be made; that sample data can be
loaded; that there exist documented paths by which third parties can
participate in the project; and so on — in other
words, that all the expectations one would have of an open source
project are truly met.
But the reviewer's job is not just to review. The reviewer is
there to help the primary vendor meet these
expectations throughout development, and to report back to the
customer as to whether the vendor is doing so. In far too many cases,
I have seen a nominally open source project be contracted for and
developed, only for the customer to discover at the
end — too late to do anything about
it — that no party besides than the original
vendor can actually deploy, maintain, or extend the software, because
the vendor never came close to meeting normal open source standards.
Had parallel, independent review been built into the process from the
start, the problems would have been detected early and the
unsatisfactory outcome prevented. (Relatedly, see .)
Note that the primary vendor may often be quite unconscious that
anything is wrong. In their mind, they developed and delivered
software the way they usually do, so what's the problem? The fact
that no one other than them can deploy or modify the end result
doesn't register as a failure, because in all their other projects
third-party deployability was not a goal in the first place. The fact that the
contract requires it is meaningless unless the customer has some way
to test and enforce that requirement. Since most customers do not
have the in-house technical capability to do so, the open source
clauses in the contract are effectively void unless there is some kind
of external review process.
Independent review is not merely a sort of open source
insurance, however, although it would be worthwhile even if it were only that.
It is also an investment in the success of future partnerships with
the primary vendor. The vendor becomes more inherently capable of
performing quality open source work in the future, because the
OSQA process provides a practical education in open source
development. Thus, done right, third-party review results in both a
healthier open source project and a healthier long-term relationship
with the primary vendor.
It also helps foster concentrations of expertise outside that
primary contractor right from the start, as discussed in . Ideally, at the end of
development for a new open source product, you should have at least
two independent commercial entities able to deploy and support the
software: the primary development vendor and the OSQA vendor. That's
already twice as much supplier diversity as most projects have coming
out of the gate, and it's much easier to add a third vendor than a
second.
The key to successful OSQA is that the reviewer is
responsible to the customer, not to the primary
development vendor. That part is crucial: even if the two vendors are
contracting through the same prime vehicle, or one is a subcontractor
to the other, it must be clear in the contracts that the reviewer
reports directly to the client, interacting with the primary
development vendor only to perform the OSQA function.
The cost of OSQA review is much smaller than the cost of
the main contract — generally, expect on the order of
5% to 10% — and the benefit is large: the difference
between an end product that is not usably open source and one that is
truly open source, able to be deployed and supported by anyone.
The "New Developer" Test
One of the most useful forms of OSQA is what I call the
new developer test: have a competent developer
who is entirely unfamiliar with the project approach it through its
front door, by trying to get an instance up and running, and perhaps
even contributing a minor bugfix or documentation patch.
The key is that the new developer doesn't get any special
access. At the beginning of the process, she is simply told the
project's home page, and perhaps pointed to a suitable bug report if
one is available. Her mission is to become a participant in the
project by following the project's own documented
procedures for doing so. If the deployment instructions
are insufficient, she files a ticket in the issue tracker and tries
to get a constructive response — there are no
behind-the-scenes telephone calls or special requests made by those
who hired her for this role, because those would reduce the value of
the exercise.
The output of a successful New Developer Test consists of two
things. One: a flurry of forum posts, new tickets, and
documentation patches that show the project the difference between
where they thought they were in terms of welcoming new participants
and where they actually are. Two: a heightened appreciation on the
part of the project's developers of the effort required to make open
source software that is truly approachable by strangers, and of what
it will take to maintain that approachability over the lifetime of
the project.
Don't Surprise Your Lawyers
Corporate lawyers (and to a lesser degree lawyers in the
non-profit world and in government) sometimes have an uneasy
relationship with free software. They have often spent their careers
diligently seeking to maximize the control and exclusivity their
clients have over everything the clients
produce — including software. A good lawyer will
understand why their client is choosing to deliberately give up that
control for some larger purpose, when it is explained, but even then
may still be unfamiliar with the factors that go into choosing an open
source license for the project, the interaction of the license with
trademarks and patents, the legal technicalities of how to accept
contributed code such that it can be redistributed, etc. (See for a deeper discussion of legal issues.)
The ideal course is to make sure your lawyers first understand
why you are running an open source project, and
give them a chance to familiarize themselves with open source in
general, before you bring the particulars of the project to them. If
the lawyers are good, they will know when they should seek help from
outside advisors and will not hesitate to do so. By the time the
project is under way, the lawyers should have enough familiarity with
open source legal issues to make basic decisions with confidence, and
to know when and where they need help.
Do not assume that open source is part of a standard legal
education. It is not, at least as of this writing in 2022. If you
wait until development is already under way and code is starting to be
published before consulting your legal team, they may be forced to
scramble and make under-researched decisions hastily. This will not
be good for either the project or the organization, in the long
run.
Funding Non-Programming Activities
Programming is only part of the work that goes on in an open
source project. From the point of view of the project's participants,
it's the most visible and glamorous part. This unfortunately means
that other activities, such as documentation, formal testing, etc, can
sometimes be neglected, at least compared to the amount of attention
they often receive in proprietary software. Organizations are
sometimes in the best position to make up this gap, by devoting
some of their own staff time to open source projects.
The key to doing this successfully is to translate between the
company's internal processes and those of the public development
community. Such translation is not effortless: often the two are not
a close match, and the differences can only be bridged via human
intervention. For example, the company may use a different bug
tracker than the public project. Even if they use the same tracking
software, the data stored in it will be very different, because the
bug-tracking needs of a company are very different from those of a
free software community. A piece of information that starts in one
tracker may need to be reflected in the other, with confidential
portions removed or, in the other direction, added.
The sections that follow are about how to build and maintain
such bridges. The end result should be that the open source project
runs more smoothly, the community recognizes the company's investment
of resources, and yet does not feel that the company is
inappropriately steering things toward its own goals.
Technical Quality Assurance (i.e., Professional Testing)
In proprietary software development, it is normal to have teams
of people dedicated solely to quality assurance: bug hunting,
performance and scalability testing, interface and documentation
checking, etc. As a rule, these activities are not pursued as
vigorously by the development community on a free software project.
This is partly because it's hard to get highly-motivated labor for
unglamorous work like testing (committers have their names inscribed
for all time in the history of the project, but there are fewer
mechanisms for remembering the tester who found the bug a committer
fixed), partly because developers tend to assume that having a large user
community gives the project good testing coverage, and, in the case of
performance and scalability testing, partly because not all developers
have access to the requisite hardware resources anyway.
The assumption that having many users is equivalent to having
many testers is not entirely baseless. Certainly there's little point
assigning testers for basic functionality in common environments: bugs
there will quickly be found by users in the natural course of things.
But because users are just trying to get work done, they do not
consciously set out to explore uncharted edge cases in the program's
functionality, and are likely to leave certain classes of bugs
unfound. Furthermore, when they discover a bug with an easy
workaround, they often silently implement the workaround without
bothering to report the bug. Most insidiously, the usage patterns of
your customers (the people who drive your
interest in the software) may differ in statistically significant ways
from the usage patterns of the Average User In The Street.
A professional testing team can uncover these sorts of bugs, and
can do so as easily with free software as with proprietary software.
The challenge is to convey the testing team's results back to the
public in a useful form. In-house testing departments usually have
their own way of reporting test results to their own developers,
involving company-specific
jargon, or specialized knowledge about particular customers and their
data sets. Such reports would be inappropriate for the public bug
tracker, both because of their form and because of confidentiality
concerns. Even if your company's internal bug tracking software
were the same as that used by the public project, management might
need to make company-specific comments and metadata changes to the
tickets (for example, to raise a ticket's internal priority, or to
schedule its resolution for a particular customer). Usually such
notes are confidential — sometimes they're not even shown to the
customer. And even when they're not confidential, they're not very
helpful to the public project.
Yet the core bug report itself is important
to the public. In fact, a bug report from your testing department is
in some ways more valuable than one received from users at large,
since the testing department probes for things that other users won't.
Given that you're unlikely to get that particular bug report from any
other source, you definitely want to preserve it and make it
available to the public project.
To do this, either the QA department can file tickets directly in
the public ticket tracker, if they're comfortable with that, or an
intermediary (usually one of the developers) can "translate" the
testing department's internal reports into new tickets in the public
tracker. Translation simply means describing the bug in a way that
makes no reference to customer-specific information (the reproduction
recipe may use customer data, assuming the customer approves it, of
course).
It is definitely preferable to have the QA department filing
tickets in the public tracker directly. That gives the public a more
direct appreciation of your company's involvement with the project:
useful bug reports add to your organization's credibility just as any
technical contribution would. It also gives developers a direct line
of communication to the testing team. For example, if the internal QA
team is monitoring the public ticket tracker, a developer can commit a
fix for a scalability bug (which the developer may not have the
resources to test herself), and then add a note to the ticket asking
the QA team to see if the fix had the desired effect.
Either way, once a public ticket exists, the original internal
ticket should simply reference the public ticket for technical content.
Management and paid developers may continue to annotate the internal
ticket with company-specific comments as necessary, but use the public
ticket for information that should be available to everyone.
You should go into this process expecting extra overhead.
Maintaining two tickets for one bug is, naturally, more work than
maintaining one ticket. The benefit is that many more coders will see
the report and be able to contribute to a solution.
Legal Advice and Protection
Corporations, for-profit or nonprofit, are almost the only
entities that ever pay attention to complex legal issues in free
software. Individual developers know basic differences between
various open source licenses, but they generally do not have the time
or resources to competently handle legal issues themselves. If your
company has a legal department, it can help a project by assisting
with trademark issues, copyright license ownership and compatibility
questions, defense against patent trolls, etc. If the project decides
to organize formally, or to join an existing umbrella organization (as
described in ), your legal
department can help with issues of corporate law, asset transfer,
reviewing agreements, and other due diligence matters.
Some more concrete ideas of what sorts of legal help might be
useful are discussed in . The main thing is to
make sure that communications between the legal department and the
development community, if they happen at all, happen with a mutual
appreciation of the very different universes the parties are coming
from. On occasion, these two groups talk past each other, each side
assuming domain-specific knowledge that the other does not have. A
good strategy is to have a liaison (usually a developer, or else a
lawyer with technical expertise) stand in the middle and translate for
as long as needed.
Documentation and Usability
Documentation and usability are both famous weak spots in open
source projects, although I think, at least in the case of
documentation, that the difference between free and proprietary
software is frequently exaggerated. Nevertheless, it is empirically
true that much open source software lacks first-class documentation
and usability research.
If your organization wants to help fill these gaps for a
project, probably the best thing it can do is hire people who
are not regular developers on the project, but
who will be able to interact productively with the developers.
Not hiring regular developers is good for two reasons: one, that way
you don't take development time away from the project; two, those
closest to the software are usually the wrong people to write
documentation or investigate usability anyway, because they have
trouble seeing the software from an outsider's point of view.
However, it will still be necessary for whoever works on these
problems to communicate with the developers. Find people who are
technical enough to talk to the coding team, but not so expert in the
software that they can't empathize with regular users anymore.
A medium-level user is probably the right person to write good
documentation. In fact, after the first edition of this book was
published, I received the following email from an open source
developer named Dirk Reiners:
One comment on Money::Documentation and Usability: when we had some
money to spend and decided that a beginner's tutorial was the most
critical piece that we needed we hired a medium-level user to write it.
He had gone through the induction to the system recently enough to
remember the problems, but he had gotten past them so he knew how to
describe them. That allowed him to write something that needed only
minor fixes by the core developers for the things that he hadn't gotten
right, but still covering the 'obvious' stuff devs would have missed.
Funding User Experience (UX) Work
The field of user experience (UX) design
has lately (starting somewhere between 2010 and 2020) begun to acquire a new
seriousness of purpose and consistency of professional standards.
Naturally, one thing many companies think of when they want to help
improve an open source project is to fund UX work, since that's just
the sort of thing that projects often overlook or, in some cases,
don't even know they need.
As with many other types of engagement, do not assume that a UX
expert can be parachuted into the project. User experience design is
not a checkbox. It is an attitude taken by a team throughout
development, and one of the primary qualifications to look for in UX
contractors is their ability to gain long-term credibility with the
developers, and to help developers pay attention to user experience
goals. For example, in addition to their innate domain knowledge, UX
designers often know how to set up and incorporate feedback from user
trials — but those trials will only be effective if
the results are presented to the development team in a way that makes
it easy for the developers to take the results seriously. This can
only happen through a sustained, two-way interaction, in which UX
experts are subscribed to the appropriate project forums and take the
attitude that they are a kind of specialized developer on the project,
rather than an outside expert providing advice. Use UX experts who
have worked with open source projects before, if possible.
Providing Build Farms and Development Servers
Many projects have infrastructure needs beyond just hosting of
code, bug tracker, etc. For example, projects often use
continuous integration (CI) testing,
a.k.a. build farms, to automatically ensure
that the changes developers are committing integrate cleanly into
the main branch and pass all automated tests. See
for more about this
practice.
Depending on the size and complexity of the codebase, the
number of developers checking in changes, and other factors, running a
responsive build farm can cost more money than any individual
developer has at their disposal. A good way to help, and gain some
goodwill in the process, is to donate the server space and bandwidth
and the technical expertise to set up the
continuous integration and automated testing. If you don't have the
technical expertise available on staff, you could hire someone from
the project to do it, or at the very least give some of the project's
developers administrative access to the CI servers so they can set
things up themselves.
Running Security Audits
If your company has a good internal security department, or can
afford to hire specialists, providing in-depth security review on an
open source project's code base can do the project a tremendous amount
of good. Any feedback from a security audit should be provided back
to the project using the precautions described in . However, it is fine to be public
about the fact that you are conducting the audit; there your
organization should get credit for a substantial contribution like
that.
Sponsoring Conferences, Hackathons, and other Developer Meetings
A very effective use of funds is to sponsor in-person contact
between developers who might not otherwise meet. The usefulness of
in-person meetings — e.g., conferences, hackathons,
smaller informal meetups, etc — is mainly discussed in
. Here I will simply mention
that encouraging such encounters is a very good use of money in an
open source project. From a corporate sponsorship point of view,
nothing creates good will like a plane ticket and a hotel room. From
a personnel management point of view, it is healthy for your own
developers to have in-person contact with their peers in the open
source projects they work on, and when those peers work at at other
companies, project-centric meetups are the perfect neutral ground for
such meetings.
Sending your developers to conferences is also a good way to
signal commitment to a project. When others meet your developers at a
conference the first time, it is a signal that your company has a real
investment in the project. But when your developers show up again at
the same conference the next year, still working on the same project,
that's a very powerful signal that your organizational commitment to
the project is long-term and strategic. This gives your developers an
advantage in influencing the direction of the project, because they
are seen as people who will be around for the long term, and it of
course gives your company a recruiting advantage when you are looking
for new developers to work on the same project.
Even when you don't have people traveling to a meetup, you can
still sponsor some of the meetup's expenses. Everyone remembers
fondly the company that sponsors the pizza, or lunch, or drinks or
dinner for one night of the meetup.
Marketing
Although most open source developers would probably hate to
admit it, marketing works. Good marketing can
create buzz around an open source product, even to the point where
hardheaded coders find themselves having vaguely positive thoughts
about the software for reasons they can't quite put their finger on.
It is not my purpose here to dissect the arms-race dynamics of
marketing in general. Any corporation involved in free software will
eventually find itself considering how to market themselves, the
software, or their relationship to the software.
Much of the advice in this section is simply about how to avoid
common pitfalls in marketing open source products (see also and ),
although we will start by examining a major marketing advantage that
open source products enjoy over proprietary products, and that open
source businesses should promote as often as possible: the lack of
vendor lock-in.
Open Source and Freedom from Vendor Lock-In
Vendor lock-in is what happens when a
vendor sells a service or product to a customer, perhaps at a cheap
up-front price, but the customer has to make certain further
investments in order to use the
product — e.g., infrastructure changes, workflow and
other process changes, data reformatting, retraining, etc. The cost
to the customer of switching away from that vendor's product is now
the degree to which the vendor has the customer locked in. Note that
these switching costs are different from
sunk costs. There may also be sunk costs
involved, but that is independent of the switching costs, and it is
the latter that are the real issue here. Even if the customer is
eventually unhappy with the vendor, by that point the total cost of
moving to someone else may be quite high, and that cost is separate
from whatever licensing or service fees the vendor charges.
The great commercial strength of open source is that product and
vendor are not the same. In open source, you can switch to another
vendor, or to a combination of vendors, or even a combination of
vendor and in-house support, all while continuing to use the same
product in more or less the same way.
So if you sell open source, make sure your potential customers
are clear on this point, and give them as many concrete examples as
you can. It may, in some circumstances, even be useful to point out
the existence of some of your competitors, because their presence
paradoxically reassures the customer that choosing you is a safe
decision — if things don't work out, there are other
options. If you just make sure things work out, then the customer
will never need to seek out those other options.
Proprietary vendors often compete against open source by talking
about the "total cost of ownership", that is,
they sell against open source's up-front cost of
zero — no per-copy royalties, no per-seat license
fees — by pointing out, reasonably enough, that
although there may be no licensing fees, in practice software
integration involves organizational and technical costs that can be
quite significant. This is quite true, as far as it goes, but that
argument works the other way too: to the extent that there
are such costs — and there really
are — the danger to the customer of vendor lock-in is
directly proportional to them. Another way of saying it is that the
costs of proprietary software tend to outstrip the costs of open
source over a long enough period of time. One pays a premium for
decreasingly competitive vendor selection, both in money and in loss
of flexibility and options.
To draw a contrast with "total cost of ownership", I would love
to see open source sales representatives talk more
about the "cost of total ownership", that is, how
much does it cost a company to be totally owned by its software
vendors? With open source, customers are not
owned — they are the owners, to exactly the degree
that they want to be, and they can outsource as much of that
responsibility to outside vendors as they want. Their relationships
with those vendors are thus more likely to be based on mutual
satisfaction and mutual benefit, not on an asymmetrical pseudo-monopoly that
gives existing vendors undue inertia in customers' procurement
decisions.
Remember That You Are Being Watched
For the sake of keeping the developer community on
your side, it is very important not to say
anything that isn't demonstrably true. Audit all claims carefully
before making them, and give the public the means to check your claims
on their own. Independent fact checking is a major part of open
source, and it applies to more than just the code.
Naturally no one would advise companies to make unverifiable
claims anyway. But with open source activities, there is an unusually
high quantity of people with the expertise to verify
claims — people who are also likely to have high-bandwidth
Internet access and the right social contacts to publicize their
findings in a damaging way, should they choose to. When Global
Megacorp Industries pollutes a stream, that's verifiable, but
only by trained scientists, who can then be refuted by Global
Megacorp's scientists, leaving the public scratching their heads and
wondering what to think. On the other hand, your behavior in the open
source world is not only visible and recorded, it is also easy for
many people to check it independently, come to their own conclusions,
and spread those conclusions by word of mouth. These communications
networks are already in place: they are the essence of how open source
operates, and they can be used to transmit any sort of information.
Refutation is difficult when what people are saying is true.
For example, it's okay to refer to your organization as having
"founded project X" if you really did. But don't refer to yourself as
the "makers of X" if most of the code was written by outsiders.
Conversely, don't claim to have a deeply involved, broad-based developer
community if anyone can look at your repository and see that there are
few or no code changes coming from outside your organization.
Case Study: You Can't Fake It, So Don't Try
Years ago I saw an announcement by a very well-known computer
company, stating that they were releasing an important software
package under an open source license. When the initial announcement
came out, I took a look at their now-public version control repository
and saw that it contained only three revisions. In other words, they
had done an initial import of the source code, but hardly anything had
happened since then. That in itself was not worrying — they'd
just made the announcement, after all. There was no reason to expect
a lot of development activity right away.
Some time later, they made another announcement. Here is what
it said, with the name and release number replaced by pseudonyms:
We are pleased to announce that following
rigorous testing by the Singer Community, Singer 5 for Linux
and Windows are now ready for production use.
Curious to know what the community had uncovered in "rigorous
testing," I went back to the repository to look at its recent change
history. The project was still on revision 3. Apparently, they
hadn't found a single bug worth fixing before the
release! Thinking that the results of the community testing must have
been recorded elsewhere, I next examined the bug tracker. There were
exactly six open tickets, four of which had been open for several months
already.
This beggars belief, of course. When testers pound on a large
and complex piece of software for any length of time, they will find
bugs. Even if the fixes for those bugs don't make it into the
upcoming release, one would still expect some version control activity
as a result of the testing process, or at least some new tickets. Yet
to all appearances, nothing had happened between the announcement of
the open source license and the first open source release.
The point is not that the company was lying about the "rigorous
testing" by the community (though I suspect they were). The point is
that they were oblivious to how much it looked like
they were lying. Since neither the version control repository nor the
ticket tracker gave any indication that the alleged rigorous testing
had occurred, the company should either not have made the claim in the
first place, or should have provided a clear link to some tangible
result of that testing ("We found 278 bugs; click here for details").
The latter would have allowed anyone to get a handle on the level of
community activity very quickly. As it was, it only took me a few
minutes to determine that whatever this community testing was, it had
not left traces in any of the usual places. That's not a lot of
effort, and I'm sure I'm not the only one who took the trouble. (It's
now been over a decade since that announcement; I can confirm that the
software project did not flourish.)
Transparency and verifiability are also an important part of
accurate crediting, of course. See
for more on this.
Don't Bash Competing Vendors' Efforts
Another situation companies find themselves in, when selling
services based on open source software, is that they have competitors
in the marketplace who may be selling services based on the
same software.
If you're going to sell your company's services, you inevitably
will need to compare your company against others selling the same or
similar things. This is expected, and in many ways healthy. However,
be careful to avoid straying into public criticism of the other
development teams or of their development priorities.
Your own developers have to work directly with those
competitors' developers in the open source project. They often have
friendly relations, show up at the same conferences, etc. Even if
that's not the case today, it may be tomorrow (as discussed in ). Furthermore, you may find
yourself hiring developers from your competitors;
if you burn up available goodwill in advance, you may not get the best
candidates.
Without mentioning names, in part because the situation
eventually got better and I don't want to rekindle the flames now, I
will say that I saw exactly this happen between two companies (one of
whom was my employer at the time) who were competing to sell services
based on the same open source software. The ill will stirred up among
the project's developers by the marketing statements of one company
(not my employer) had real consequences, and that company lost out on
retaining the services of some excellent developers because it failed
to think about the fact that their marketing in the commercial realm
was also visible and had effects in the development community.
"Commercial" vs "Proprietary"
One common pattern among companies involved in open source
software is to market a fully open source version of their product
alongside, and in direct comparison to, an enhanced proprietary
version. Since the open source version is free software, anyone
could in theory add those enhancements themself,
or collaborate with others to do so, but in practice, the effort
required to do that (and to maintain a divergent fork of the
project) is, for each collaborator, much greater than the cost of just
paying for the proprietary version, so it rarely happens.
This sales model is often referred to as "open core", that is, a
core set of functionality that is available as open source software,
with a more featureful application wrapped around it as proprietary
software. This model usually depends on the open source core having a
non-copyleft license, of course, and is discussed in more detail in
.
Open core is somewhat controversial among open source
developers, but it has been successful strictly from a business point
of view: companies that do it make money in the way that they expect
to make money. However, there is bit of marketing slippage that many
of these companies fall into, and I would like to point it out here in
order to convince you not to be part of the problem.
If you sell a free software version and an enhanced proprietary
version of your product, please use the words "open source" and
"proprietary" to refer to them, respectively. Do
not call the open source version the "Community
Edition" and the proprietary version the "Commercial Edition" (or
"Enterprise Edition").
Aside from the fact that everyone knows there is very little
"community" around these so-called "Community Editions", there is a
deeper problem here. Calling the proprietary version the "Commercial
Edition" implies that open source software is not commercial, while
calling it the "Enterprise Edition" implies that open source software
is not suitable for enterprise-level use. The former is untrue
because open source software is commercial by definition: the license
guarantees the freedom to use the software for any commercial purpose.
(Open source is anti-monopoly, of course, but
that doesn't affect its commerciality.) The latter is also generally
untrue: open source software is widely used at enterprise
scale, with and without third-party support, and chances are an
enterprise could use your open source edition too.
This kind of misleading marketing particularly hurts efforts
by open source companies to get their software accepted by governments
and by other buyers who have sophisticated procurement requirements.
These procurement regulations often include stipulations that
purchased software must be "commercial", "commercial off-the-shelf",
or "commercially available" — definitions that all
open source software meets — so portraying open
source as non-commercial gives purchasing officers a misimpression.
When those decision-makers think of open source as inherently
non-commercial, that hurts open source software as a whole.
Open Source and the Organization
Through the consulting work I've done in the years since the
first edition of this book was published, it's become clear to me that
there are special concerns that apply to organizations launching or
participating in open source projects. Organizations contain formal
management structures and informal social structures: both are
affected by engagement with open source projects, and both may
need adjustment to better support open source activity by the
individuals within the organization. In particular, government
agencies have special pitfalls to watch out for when working with open
source projects.
This section therefore examines organizational issues generally,
and some issues specific to government agencies, and offers
advice about how to make organizational engagement with open source
more likely to succeed. Many of these recommendations will be brief
and somewhat generalized, not because there isn't more depth to go
into, but because the specifics can vary so much from organization to
organization that exploring all the possibilities here would require
too much space. Please treat these bits of advice as starting points,
not as complete recipes in themselves.
Dispel Myths Within Your Organization
In organizations that have been producing or using proprietary
software for a long time, certain myths about open source software
sometimes circulate. One traditional source of such myths is, of
course, sales representatives from vendors of proprietary systems.
But one can't attribute it all to them. It's just as often the case
that someone had some bad experiences in an open source project, or
used open source in the past without ensuring proper support channels,
and since that was their first experience in an unfamiliar territory,
the entire territory is now tainted.
Below are some of the myths I've encountered most frequently.
First, the negative myths:
If it's open, that means anyone can
change our code.
Believe it or not, you need to be prepared to respond to
this. Sometimes people — particularly senior
decision-makers who have limited technical
experience — don't understand the difference
between an upstream codebase allowing anyone to copy the code and
modify the resultant copies, and someone modifying the
particular instance that you deploy. The
former is just the definition of open
source, of course. The latter would be a security vulnerability,
if it happened, but it has nothing to do with the license on the
code. I mention this myth merely to prepare you for encountering
it, because otherwise you might not expect that anyone could hold
this particular misunderstanding. Trust me, they
can, and you need to be ready to answer
it.
Open source software is insecure,
because anyone can see the code / change the code.
These are so easy to answer that I won't give a detailed
refutation here; again, I merely note it so you can be prepared
for it. If you find yourself having to explain why open source
software is at least as secure as any other kind of software, if
not more secure, you may wish to use the excellent resources
provided by Dr. David A. Wheeler at http://www.dwheeler.com/#oss.
Open source comes with no
support.
There are plenty of companies that sell support for open
source software, and they're not hard to find. There are also
wonderfully helpful unofficial support communities on the
Internet for different open source packages, of course, but often
what organizations are looking for is vendor that offers
a guaranteed response time. Such offerings
are available, it's just that the source from which you
procure the software may be unrelated to the source from which
you procure the support. One way to respond to this myth is
to ask specifically what packages support is desired for, and
then show some sources of support available for
them.
If we open source this project, we'll
have to spend a lot of time interacting with outside
developers.
You open source your code, not your time and attention.
You are never under any obligation to respond at all to outside
parties, let alone engage substantively with them. You should
only do so when engaging will benefit
you — which it often will;
after all, one of the key strengths of open source is that it
enlarges the collective brain of your development team in direct
proportion to how much they interact with other developers who
become interested in the code. But that engagement is always
under your control and at your discretion. If you don't want
your team's attention going to bug reports or development
questions from outside your organization, that's fine. Just be up front about
that in project announcements and in the documentation, so that
others can take that into account before they put a lot of energy
into trying to communicate with your developers, and so they can
decide whether forking to create a more open community would make
sense for them (indeed, sometimes it might even be to your
advantage for them to do that).
If we open source this project, then
we'll have to release all our other stuff as open source
too.
This myth usually results from a misunderstanding of
copyleft licenses and the GNU General Public License (GPL) in
particular. I won't go into detail here; see for a discussion of what the GPL actually
stipulates. After reading that chapter, especially
, you will be able
to explain why this belief is incorrect.
Next, the positive myths:
Open source is cheaper.
Licensing costs are often not the largest cost with
proprietary software; they are often outweighed by training costs,
installation and configuration costs, and other factors that make
up the "total cost of ownership". But all of those other costs
are, on average, the same for open source software. Don't make
the mistake of pitching your organization on open source software
on the grounds that it is cheaper. At least in terms of the most
easily quantified costs, it is not. It is often cheaper in the
long run, because it frees your organization from proprietary
vendor lock-in (see ),
reduces training costs for new employees (because
they arrive already familiar with the software), gives you
greater ability to customize software to your
needs — which is a strategic advantage, not just
a cost advantage — and so on. But
these are long-term benefits, and they may not show up directly
on a balance sheet unless you take steps to make your accounting
reveal them. In the short term, open source generally isn't
cheaper than proprietary software, and shouldn't be pitched that
way.
Developers will devote attention to
this code just because we released it.
People with little experience in open source sometimes
assume that the mere act of releasing code to the public will
result in a flurry of attention from other
developers — questions, patches, high-quality
code review, bug reports, etc. But what actually happens, in
most cases, is silence. Most good developers are busy people,
and they're not going to pay attention to your project until they
have some reason to. If your code is good and solves a real
problem, you can expect word to travel to the right places
eventually, and of course you can help that word along with
tactically smart announcements and posts (see ). But until your code has
had time to naturally accumulate credibility and mindshare, most
people won't pay any attention, so you shouldn't expect that
first release to be a big deal for anyone but you.
There is a situation in which this myth is not a myth. A
large organization with a reputation and a dedicated public
relations team can create buzz around an
initial open source release. If you do this, then make sure not
to squander that buzz: be ready to constructively engage the
developer attention you attract right away.
Other companies / cities / whoever
will pick up this software and start using it right
away.
Adopting any software involves costs. Indeed, merely
evaluating software involves costs. So when
you release a new open source project that you and your team are
excited about, that doesn't necessarily mean other entities are
going to adopt that software right away. Many of them may
notice it, if you've done your announcement process well, but
that just means they'll put it on their list of things to
investigate based on long-term organizational
priorities — in other words, they'll take a
closer look based on their schedule, not
yours. So don't expect a flood of early adopters. You may get a
few, and they should be cultivated because they will
provide the word-of-mouth that gets you more adopters. But in
general you're more likely to see a trickle of early adopters
over the first year or so after your initial release, than to see
a flood of them immediately when the release is
made.
We can casually copy open source code
into our own code.
Open source licenses are still licenses, and they come with
a few conditions. Virtually all of them require attribution at
the source level and inclusion of the license together with the
covered code. Some licenses, especially the copyleft licenses
discussed in , cause the
entire derivative work to be under the same open source license,
thus implying redistribution obligations that you may not want.
Some licenses have patent clauses that can affect your company in complex
ways.I am strongly opposed to software patents of
any kind, for the reasons given in , but if you are a patent holder I
would still like you to at least be aware of the possible patent
consequences of incorporating open code into your
programs.
For all these reasons,
incorporating open source code into software that will be
distributed under a different license — whether
open source or proprietary — cannot be done
casually. Organizations that incorporate open source code into
their products usually need a formal process for doing so, one
that involves review by someone who understands the legal issues
and the possible interactions between licenses.
Foster Pools of Expertise in Multiple Places
Sometimes organizations that are accustomed to procuring
proprietary software treat open source software as if it were
proprietary, in the sense that they assume there is exactly one
authoritative provider of expert support, and that therefore it is
necessary to have a commercial relationship with that provider.
That's not how open source works. One of the great strengths of
open source is the availability of support from multiple, competing
providers. It's perfectly fine, and often advisable, to have a
commercial relationship with just one of those sources, but you must
remember that support in open source is fundamentally a
marketplace, not an add-on feature that just
happens to come with the software license, as is often the case with
proprietary software. Actually, even proprietary software sometimes
has a competitive support marketplace — think for
example of the third-party support providers for Oracle databases and
Microsoft operating systems — but in open source these
marketplaces tend to be more fluid and not as dominated by single,
easily-recognizable giants, because there isn't necessarily one
commercial outfit that automatically assumes a place at the top of
the hierarchy to sell gold-label support (as Oracle or Microsoft
themselves would be, in the example just given).
The goal of fostering independent pools of expertise
should even influence how you structure contracts to develop the software
in the first place. If you hire a firm to develop new open source
software, have a few of your own programmers working alongside them if
possible, so that you accumulate some in-house expertise. This is not
necessarily because you won't want to use the same firm for future
maintenance — they might be a great
choice — but just so that you'll have a better
bargaining position and not be locked in. Essentially, the more people
in different organizations who know the code, the
healthier it is for the project, and the better position you are
in.This is also one of the side benefits of holding
hackathons, as discussed in . The report
Open Data For Resilience Initiative & Geonode: A Case
Study On Institutional Investments In Open
Sourcehttps://opendri.org/wp-content/uploads/2017/03/OpenDRI-and-GeoNode-a-Case-Study-on-Institutional-Investments-in-Open-Source.pdf.
I am a co-author. describes in detail how this
technique was used in the GeoNode project, for example.
If your organization does not have enough in-house technical
ability to participate in the development process directly alongside
your contractor, or at least to perform knowledgeable review, then I
strongly recommend finding a third-party to provide
independent deployability and maintainability
review while the project is under way, as described in
.
Establish Contact Early With Relevant Communities
Another way to foster independent sources of expertise is to
establish contact with potentially interested technical communities
early and often during development. They're almost always out there.
For example, if you're developing software with geospatial
functionality, there is an open source geospatial community that
probably wants to hear about it; if you're developing software to
process financial data, or medical data, there are open source
fintech and medical data communities.
You may even have already announced your project to those people
when you began, as discussed in . But
there's more you can do to create external reservoirs of knowledge.
When your project runs across a design issue that you suspect others
may have encountered before, it's fine to ask them how they handled
it, as long as you do your homework by first finding out what you can
from their code and documentation and then asking any remaining
questions. You can also arrange small-scale contracts with developers
who are active in related projects, to serve two goals at once:
improving your project's quality while also establishing mindshare in
places that may be strategically useful later.
Don't Let Publicity Events Drive Project Schedule
Although open source projects are amenable to software project
management techniques, in general if you have an active developer
community you do lose some control over the exact timing of events in
the life of the project, especially the scheduling of releases. Or
rather, you can still have as much control as you want, but then there
are other things you lose if you exercise that control
in the wrong way. For example, if the release manager (see ) is someone from outside your
organization, and she's doing a good job, then if you try to force the
release to be on a certain precise date, you may cause her and many of
the developers participating in release-specific work to give up and
devote their attention to something else. You'd gain fine-grained
control of the release schedule, but at the cost of lower quality
releases and the possible loss of some of your development
community.
This is just one example illustrating the general principle that
if you have publicity needs related to an open source project, you
generally shouldn't let those needs drive the project's schedule. If you
arrange a press conference for the project reaching 1.0 and being
deployed live, but then the developers decide on an extra two weeks of
testing because of some last-minute bugs, you'll have some improvising
to do. (This example is drawn from real life, by the way.)
There are two ways to achieve this independence, and they are
not mutually exclusive. One way is to just let project events drive
publicity instead of the other way around, such as by preparing
release announcements ahead of time but being ready to publish them
based on when the release is actually done. The other way is to
create publicity events that are not bound to development milestones,
but are rather associated with project-related things that
are able to be scheduled, such as new support
offerings, new partnership announcements, major deployments,
conference appearances, hackathons, etc.
You might be tempted to try a third way: to bring the
development community into the scheduling process, so that through
consensus you are able schedule certain milestones accurately enough
to tie timed publicity to them. While that may sound like a good
idea, in practice it rarely works. An exception to this is if the
whole project is on board with doing time-based releases, as described
in . If the development community
as a whole shares that goal, then they will make the sacrifices
necessary to keep to the time-based cycle — but your
organization must also be willing to abide by that schedule, even if
it doesn't always align with business needs.
An open source development community's first priority is the
software itself, and making sure it meets the needs its developers
are working toward. Of course the community wants releases and other
deadlines to be met with reasonable regularity, and every development
community makes tradeoffs for that. But even with the best of
intentions among all parties, you can never guarantee how that
tradeoff will be decided in a particular case, when things get down to
the wire. The outcome of a community's decision-making process cannot
be anticipated with perfect accuracy, by
definition — if it could, there would be no need for a
decision-making process. So while it's fine to try to influence the
community's priorities in ways that work to your advantage, you should
avoid relying on that for scheduling purposes, because you won't
succeed at it every time.
The Key Role of Middle Management
If you intend to have long-term organizational engagement with
open source software projects, the people in your middle layer of
management will play a key role in determining whether you succeed or
fail.
Supervising programmers who spend part or all of their time on
open source projects is more complex than supervising programmers on
purely internal projects. Many aspects of the developers' work and
schedule will be strongly influenced by external factors not under the
control of management, and in any case the developers' own desires may
not always perfectly line up with the employer's. After all, each
developer now has two unrelated audiences to satisfy: her employer, as
embodied by her direct manager, and her colleagues in the open source
project, many of whom may work for other employers.
If a manager is not sufficiently sensitive to this dynamic, then
developers can start to feel like they're being pulled in conflicting
directions. Sometimes this is just the result of poor planning, but
other times it may be unavoidable. Good management can prevent the
former case from happening in the first place. In the latter case,
good management is essential for recognizing the situation and
addressing it so as to give the developer clarity and a way
to handle the conflict.
Middle managers also have not only the usual upward and lateral
internal reporting responsibilities, but are to some degree
responsible for the image — the open source brand
identity — of the organization itself in the projects where
its developers are active. This essentially means having an entire extra
constituency to satisfy, and managers who have no experience with open
source participation themselves are unlikely to have a solid
understanding of how to position the organization and its developers
within the project.
The middle layer of management is often also in the best
position to serve as a communications conduit and information filter
between the project (that is, the whole project including all its
other participants) and the company. The wealth of information
available from the activity in an open source project is most useful
to the organization if there is a filtered channel by which the most
interesting activities can be communicated to the relevant
stakeholders within the organization — stakeholders
who might include other technical staff, executives, and sales team
members. Both by their position and their temperament, the
programmers themselves are often not best suited to serve as this
conduit. They may have a very deep understanding of the particular
projects they work on, but they often have a less complete view of the
organization's interests — for example, in a
commercial environment, the programmers often do not have a clear idea
of how the project fits into the company's strategy, various lines of
business, or sales processes. Middle managers are better positioned to
maintain the requisite bidirectional sensitivity: aware enough of the
project to ask the programmers for more information when necessary,
and aware enough of the organization to have a sense of what in the
project is most relevant to the organization.
Think carefully about who occupies the middle management
positions that serve as the interface between the organization's
priorities and the open source project's development direction, and
provide them with extra training if necessary. It is best if the
managers themselves have had direct, personal experience as participants in some
open source project. This doesn't have to be the same project as the
one for which they are now managing developers; the situations and
tensions that arise in open source projects tend to be similar, so
experience from one project will generally translate well to other
projects. But a manager who has never dealt with open source projects
first-hand at all will start out with limited ability to understand the
pressures faced by the organization's developers operating in
open source environments, and limited ability to be an effective
communications conduit between the organization and the
project.
InnerSourcing
InnerSource or
innersourcing means using standard open source
development practices only within the boundaries of an organization.
For example, a company might move all of its projects to GitHub
(albeit in private, not public, repositories), and declare that,
inside the company, any engineer can report bugs and contribute pull
requests to any project anywhere else in the company. Innersourcing also
often includes serious efforts at internal cultural change: managers
encouraging developers to speak their mind on both technical and
process issues, developers being given more latitude to choose which
projects and teams they work with, etc.
In early 2016 I conducted interviewsActually, my
friend and business partner James Vasile and I both conducted these
interviews, and we were much aided by O'Reilly Media providing
introductions to open source staff at a few companies where we did not
have personal contacts. with open source specialists
at a number of medium- and large-sized technology companies, many of
whom had observed innersourcing efforts and were willing to talk about
the results. What they reported was pretty consistent from company to
company, and consistent with my own experience as a consultant:
innersourcing really can make a positive
difference, in several ways, but it's also definitely not the same as
true open source.
For companies that already participate in open source projects,
innersourcing can reduce the difference between internal development
practices and external ones. If some of your engineers
participate in upstream open source projects anyway, where they
must use typical open source collaboration tools and adhere to open
source standards for submitting and reviewing code and documentation,
then moving the company's internal engineering infrastructure and
processes in that direction means less context-switching overhead
for existing staff, an easier onboarding process for new hires, and
often improved technical compatibility between internal and
external projects. (For these reasons, innersourcing is also often
used as the first "baby steps" toward genuine corporate participation
in open source projects.)
But the benefits of innersourcing go beyond that. When
accompanied by a real commitment to reduce managerial and
organizational barriers to engineers participating in projects across
the company, innersourcing can improve morale, help spread expertise
around the company and make software development more
efficient.If you're interested in learning more, see
http://innersourcecommons.org/, where Danese Cooper and
others have organized a number of resources about
InnerSource.
Nevertheless, innersource is not the same as open source, nor is
it even "open source lite". The managers we talked to reported that
innersourced projects don't have the provocative, uncontrolled energy of truly
open source projects, because all the actors in innersourcing are,
ultimately,embedded in the same hierarchical authority structure.
Fundamentally, open source dynamics require at least the potential for
totally permissionless modification (i.e., you don't have to worry
what someone else might think of a fork). When software only
circulates within a given management hierarchy, then that potential
for permissionless collaboration vanishes — and with
it, the potential for true open source behavior vanishes too. The
permission structure that governs one's behavior with respect to the
code is not just a matter of the code's license: it's also about
power: whom you report to, what others in the hierarchy might think
about your changes, etc.
In the long run, the dynamics of open source collaboration
require an external supply of freedom. There must always be people
who could, in principle, fork or do whatever they want without
worrying about consequences to the original authors' organization.
When that external freedom is removed, everything changes.
Innersourcing also fails the "portable résumé"
test — an employee can't take the code with her, and
her work will not be publicly visible (see ).
If she leaves the company, she will be alienated from the fruits of
her work, which means that her motivation to personally invest is
reduced.
None of this means that innersourcing isn't worth it. It can be
very beneficial on its own terms, and is also sometimes useful as an
intermediate step for a traditionally closed company that's still
figuring out how to do open source participation. Just don't imagine
that innersourcing is somehow "just like open source, but inside our
company". They're two different things and shouldn't be
conflated.
Hiring Open Source Developers
If you're trying to hire developers who have open source
experience, you have a big advantage compared to hiring other kinds of
developers. Most of the résumé of an open source developer is
public — it's everything they've ever done in every
open source project they've ever worked on, because all of that
activity is publicly archived.Brian Fitzpatrick has
written about the usefulness of having an open source résumé in two
articles, The Virtual Referral (https://web.archive.org/web/20171203195720/http://www.onlamp.com/pub/a/onlamp/2005/07/14/osdevelopers.html) and
The Virtual Internship (https://web.archive.org/web/20180325231558/http://www.onlamp.com/pub/a/onlamp/2005/08/01/opensourcedevelopers.html).
But you shouldn't need to go searching for all of it. When you put
out a job posting, tell prospective candidates directly that the
résumé they send in should include references to their open source
profile. This means their committer accounts on the projects where
they've been active (or their account names at the overall project
hosting sites where they're been active, e.g., their usernames on
sites like GitHub, GitLab, etc), the email addresses or usernames they have used when
posting in discussion forums, documentation they have written, and
anything else that would lead you to places where you can see their
open source project activity.
Look not only at their direct
technical activity, but also at their relations with the other developers
in the project. Examine the candidate's commits, but also examine
the frequency with which they reviewed others'
commits, and examine the candidate's reaction to reviews of their own commits. In
the project's issue tracker, how often did the candidate respond
constructively to incoming bug reports or contribute useful
information to a bug ticket? Visit a threaded view of the project's
discussion forums and see how often the candidate's posts were
responded to, and what the general tone of the responses was. Someone
who consistently causes negative reactions from others in the project
may have social problems as a collaborator, which is important to know
independently of their technical ability.
If the candidate is applying for a position that would involve
working on an open source project, but seems to have little or no open
source experience themselves, this is not necessarily a showstopper,
but it's a sign that you should ask some probing questions, and that
you should expect some ramp-up time if you hire them. If the
candidate is young and inexperienced in general, then lack of
participation in open source is easy to understand. However, if the
candidate has been a programmer for a while, and especially if they
already have experience as a user of some of the open source software
you'd be hiring them to work on, and yet they have never participated
much in that project except to download and use it, then you should
ask them questions about why. There is nothing wrong with being
uninvolved as a participant in software that one uses. However, if
you're hiring someone to be a participant in a
project, and they already had a chance to be and chose not to, that
could imply a lack of intrinsic motivation to participate and may indicate
that this person's temperament is not what you're looking for. Or
there could be other reasons — for example, the
candidate's prior management forbade them from participating.
Whatever the reasons are, you should make sure you find out.
Hiring for Influence
It is very common for companies to hire an open source developer
precisely because of her existing position in an
open source project. She may be the founder or leader of the project,
or may just have commit access,See . but
either way her ability to get things done in the upstream community is
part of her value as a prospective employee; often, it is just as
important as raw technical skill.
As noted in , there is
nothing wrong with purchasing influence in this way, as long as the
employer understands that the new employee will have dual loyalty. It
is inappropriate to ask the employee to take actions that would harm
her standing in the project. The employee's manager needs to be
sensitive to this, and to let the employee know that the door is open
for discussion and pushback if she ever feels she's being put into
such a situation (hence the importance of managers who understand open
source, as described in ). It is
perfectly fine for the employee to promote the company's technical
interests in the project, and to do so openly, as long as the
proposals are compatible with the project's overall goals and the
company provides resources to support those proposals in a way that's
sustainable for the project.
Remember that influence in an upstream project is usually not
transferable to some other employee. Position and influence travel
with the person, not with the employer. There are occasional
exceptions to this, e.g., in corporate-driven projects where the
balance of power among competitors is especially important, or in
standards bodies with formal organizational representation policies. In these cases,
a governance committee seat may be reserved for a certain company, and
the company gets to designate who sits in that seat. But even then,
informal influence still tends to matter a lot, and individuals may not be
truly interchangeable in practice.
This makes the recommendations in all the more important. When an
employee holds a position of influence in an open source project that
is strategically important to your company, that employee has a pretty
good bargaining position.
Since that kind of employee is likely to be with you for the
long term, try to take advantage of it by having her help onboard
others into open source projects. Nithya Ruff,
then Director of Open Source Strategy at Western Digital, told me
that when her company acquired another company that had a history
of working on certain strategically important (to the acquirer) open
source projects, the engineering team that came with the acquisition
became a strong influence inside the newly combined company. The
developers had good reputations in the upstream projects, and the new
management not only made sure they were able to continue working in
those projects, but brought them into a company-wide open source
working group to help other engineers get involved in upstream
maintenance too.
Evaluating Open Source Projects
Although this book is mainly about how to launch and run new
open source projects, that topic is inextricably linked to the problem
of evaluating existing open source projects. You can't know whether
you need to start a new project until you've evaluated what's out there
(as explained in ). Furthermore, even
in a new project, you'll usually still be building on existing open
source components, and will often be in the position of choosing
between different projects that implement the same basic
functionality. That is not just a technical choice; it's also about
social health and general level of project maturity. How large and
diverse are their developer communities? Do they get new contributors
on a regular basis? Do they handle incoming bug reports in a
reasonable way? Do they make stable releases frequently enough for
your needs?
Evaluating open source projects is an art, not a
science. However, there are some shortcuts that experienced people
use. Below is what has worked for me. By "worked", I mean that
when I have applied these evaluation techniques to a project and then
checked in with that project months or years later, I have generally
found its current status to be in line with what the
evaluation predicted.
Look at bug tracker activity first.
The most reliable reflections of project health can usually be
found in the bug tracker. Look at the rate of issue filings and
the number of unique filers (because that's a proxy for the size
and level of engagement of the user base). Look also at how often
project developers respond in bug tickets, and
at how they respond: are they constructive?
Do they interact well with both the reporter and with other
developers? Is it always the same developer responding, or is
responsiveness well-distributed throughout the development team?
Are they inviting technically promising reporters to try becoming
contributors?
More bug reports is better, by the way (as discussed in ). The rate at which
bug reports are closed is not as important
as you might think; in a healthy project with an active user
base, bug reports are often filed faster than the
development team can close them, especially when the user base is
growing. The relevant signal is not the rate of resolution, but
how project developers respond to and organize the influx of
reports.
Measure commit diversity, not commit rate.
Look at the distribution of commits across committers, not
just at the raw frequency of commits. Does the project have a
variety of people working together in a sustained way? Too often,
evaluators look just at the commit rate, but that rate isn't very
informative — knowing the number of commits per
week could just tell you that someone keeps making typos and then
correcting them in new commits. If you have time to look at the
content of individual commits, then look at how often one
developer's commit is a response to (i.e., refers to)
some other developer's previous commit. This tells you that
group code review is going on, and the more of that you see, the
better the project is doing.
Evaluate organizational diversity.
In addition to looking for a variety of individual
identities, see if you can tell how many different
organizations are participating in the
project — in particular, commercial
organizations. If a number of different sources of money are all
investing in a project, that's a sign that that project is going
to be around for the long term. (See also the discussion of "bus
factor" in .)
Discussion forums.
If the project has discussion forums, scan them quickly
looking for signs of a functional community. Specifically,
whenever you see a long thread, spot check responses from core
developers coming late in the thread. Are they summarizing
constructively, or taking steps to bring the thread to a
decision while remaining polite? If you see a lot of flame wars
going on, that can be a sign that energy is going into argument
instead of into development.
News, announcements, and releases.
Any project that is functioning well will usually have made
announcements within the past few months. Check the project's
front page, news feed, Twitter or other microblog accounts, etc.
If things are quiet on stage, they're probably quiet backstage
too.
This is just a brief introduction to the art of evaluating
projects, but even using just the steps above can save you a lot of
trouble. I have found them particularly useful when evaluating the
two sides of a recent fork.That is, a "hard fork";
see Even in
a recent fork, it is often possible to tell, just by looking at some
of the signals described above, which side will flourish over the long
term.
Crowdfunding and Bounties
Perhaps unfairly, I will group crowdfunding campaigns and
bounty-based development incentives together here, not because they
are the same thing, but because to the extent that they are
problematic as ways of funding free software development, their
problems are similar.
Crowdfunding refers to many
funders — often mostly
individuals — coming together to fund a particular
piece of development. Crowdfunding campaigns generally fall into two
categories: "all
or nothing", meaning that each funder pledges money toward a total
threshold and the pledges are collected only if the threshold is met,
or "keep it all", which is essentially traditional donation: funds go
immediately to the recipient whether or not a stated goal amount is
ever met. https://goteo.org/ and
https://kickstarter.com/ are
probably the best-known examples of all-or-nothing crowdfunding
services, though there are many others (I like Goteo because their
platform is itself free software, and because it is meant specifically
for freely-licensed projects, whereas Kickstarter does not take a
position on restrictiveness of licensing). There are also sites like
https://www.indiegogo.com/ that
support both models.https://en.wikipedia.org/wiki/Comparison_of_crowdfunding_services.
Bounties are one-time rewards for
completing specific tasks, such as fixing a particular bug or implementing a new
feature. Bounties are often offered directly by the interested
parties, since there is no need for a pledge-collecting system, but
the site https://www.bountysource.com/ also serves as a clearinghouse for open
source development bounties.
While both crowdfunding and bounties have funded some open
source work, they have not been a major economic force compared to
contracted or salaried development. This does not mean you shouldn't
consider them: depending on the problem you're trying to solve, and on
the shapes of solutions you're willing to accept, crowdfunding or
bounty funding might be a good answer. The problem they share is that
they are structured around development as a one-time
event rather than as an ongoing process. This would be
problematic for any kind of software development, but is especially so
for open source development, which if anything is is optimized more
for low-intensity, long-term investment rather than for high-intensity
burst investment. Both crowdfunding campaigns and bounty prizes are
more compatible with high-intensity, one-time bursts of activity, and
do not provide for ongoing maintenance or investment past the
completion of the campaign goal or prize condition.One
service trying to solve that problem is https://snowdrift.coop/, which aims to
provide sustainable funding for freely-licensed works using a
carefully designed matching pledge model. Whether Snowdrift will
succeed is unknowable as of this writing in mid-2015, since the
service is still in a preliminary stage, but I am watching it with
interest. Snowdrift also did a thorough survey, in the Fall of 2013,
of funding platforms for free software, and posted their results at
https://snowdrift.coop/p/snowdrift/w/en/othercrowdfunding; it's worth
a read if you're interested in this topic.
A crowdfunding campaign can sometimes be a good way to get a
project launched, but generally is not a way to fund development after
the initial launch. Successive crowdfunding campaigns for later
stages of development or for releases will inevitably tire out even a
willing and supportive audience. There is a reason why long-running
charities, for example the public radio network in the United States,
seek to develop sustaining funders (euphemistically called "members"
despite rarely having any governance role) to provide a
long-term, stable revenue stream, and then raise funds for specific
one-time efforts separately from that.
If you do launch a crowdfunding campaign, take a close look at
how other open source projects have run theirs. There are a number of
useful techniques that can be learned from the successful ones. For
example, most campaign sites have a mechanism for offering different
rewards to backers at different monetary levels. You could offer a
mention in a SUPPORTERS file in the project, and
perhaps at higher levels a mention on a thank-you page on the
project's web site. But more creatively — I first
heard this idea from Michael Bernstein, and used
it — you can offer to dedicate a commit to each backer
at or above a certain level, by thanking the backer directly in the
commit's log message. The nice thing about this is that it's
decentralized and easy to administer: any developer on the project can
help fulfill that reward. Individual developers can also offer free
or discounted consulting about the project as a reward. However, if
you are one of those developers, be
careful not to sell too much of your time: the point of the campaign
is to raise funds for development, not to turn the development team
into a consulting team.
One thing that many crowdfunding campaigns do that I think is
not appropriate for free software projects is to sell early access.
That is, one of the rewards will be a "sneak preview" or "beta access"
to in-progress versions, before the public release. The problem with
this is that, for open source projects, the public is supposed to
already have access to in-progress work. Access to an open source
project should be limited by the time and interest of the parties
seeking the information, not by the project. So learn
what you can from other crowdfunding campaigns, but remember that some
of the techniques used by campaigns for non-free-software products may
not be suitable for an
open source project that wants to keep the good will of its users and
development community.
Finally, a word of caution: if your project accepts donations, do
some public planning of how the money will be used
before it comes in. Discussions about how to
allocate money tend to go a lot more smoothly when held before there's
actual money to spend; also, if there are significant
disagreements, it's better to find that out when the money is still
theoretical than when it's real.