a few months out of date on a fast-moving project means you are missing a large number of changes and
bug fixes. Often the bug fixes are also
security fixes, and we all know what
happens when people build products
without proper integration of security fixes. Nothing. That’s right, pretty
much everyone gets a pass because we
all know software breaks, and there is
currently no liability for building insecure products.
Another way to sever the roots between your system and the open source
projects from which you consume code
is to make your own changes in the
master branch of the tree. Mixing your
changes directly into the tree, instead
of on a development branch, is a great
way to make any update to the software
nearly impossible. A great way to ensure
you have not severed your software from
the root of the tree is to have your own
internal CI (continuous integration)
system. Many open source projects
have their own CI systems, which you
can directly integrate into your own development systems, and they can verify
whether you have broken the system or
if the upstream software itself is broken.
Continuing to stretch the metaphor, perhaps close to the point of
breaking, we can think now about the
next stage of tending the open source
garden. If you had a vegetable garden,
but you never tended it, you would get
few, if any, vegetables from the garden and it would wither and die. Open
source projects are no different in this
respect from vegetables: We must tend
the garden if we expect it to remain
productive; otherwise, we are just being destructive.
There are many ways to tend a gar-
den. Perhaps the first thing that comes
to mind is weeding, which we might
think of as debugging and patching.
Contributing patches back to an open
source project is a way to help it im-
prove and grow strong. Most open
source projects have a defined process
whereby code contributions can be
made. Although you mention the over-
head involved in having your develop-
ers contribute to a project, you should
turn this thinking on its head and real-
ize that what they are doing when they
submit patches to the upstream proj-
ect is reducing your company’s tech-
nical debt. If you keep a patch private,
then it must be reintegrated every time
you consume a new version of the open
source code. After a while, these patch-
es can number in the tens of thou-
sands, or more, lines of code, which is a
huge amount of technical debt for you
to maintain.
After some period of having your
developers email patches and submit
pull requests, you will realize that
what you want on some projects are
your own gardeners. Having members
of your team working directly on the
open source projects that are most
important to the company is a great
way to make sure that your company
has a front-row seat in how this soft-
ware is developed.
It is actually a very natural progres-
sion for a company to go from being
a pure consumer of open source to
interacting with the project via patch
submission and then becoming a di-
rect contributor. No one would expect
a company to be a direct contributor
to all the open source projects it con-
sumes, as most companies consume
far more software than they would
ever produce, which is the bounty of
the open source garden. It ought to be
the goal of every company consuming
open source to contribute something
back, however, so that its garden con-
tinues to bear fruit, instead of rotting
vegetables.
KV
Related articles
on queue.acm.org
Forced Exception-Handling
Kode Vicious
https://queue.acm.org/detail.cfm?id=3064643
Outsourcing Responsibility
Kode Vicious
https://queue.acm.org/detail.cfm?id=2639483
Using Free and Open-Source Tools to
Manage Software Quality
Phelim Dowling and Kevin McGrath
https://queue.acm.org/detail.cfm?id=2767182
Reference
1. Neville-Neil, G. Lazarus code. Commun. ACM 58,
6 (June 2015), 32–33; https://dl.acm.org/citation.
cfm?id=2753172
George V. Neville-Neil ( kv@acm.org) is the proprietor of
Neville-Neil Consulting and co-chair of the ACM Queue
editorial board. He works on net working and operating
systems code for fun and profit, teaches courses on
various programming-related subjects, and encourages
your comments, quips, and code snips pertaining to his
Communications column.
Copyright held by author.
speakers.acm.org
Students and faculty
can take advantage of
ACM’s Distinguished
Speakers Program
to invite renowned
thought leaders in
academia, industry
and government to
deliver compelling and
insightful talks on the
most important topics
in computing and IT
today. ACM covers the
cost of transportation
for the speaker to
travel to your event.
A great speaker
can make the
difference between
a good event and
a WOW event!
Distinguished
Speakers
Program