November 20, 2018
How To Get Involved
With Open Source Software
Open Source Software!
It’s everywhere. But how do you
get involved in open source software?
It’s a question I’ve fielded often and it’s not as obvious as you
think. I got involved with the Apache Hadoop
ecosystem and Apache HBase in particular when I co-founded Explorys in 2009,
eventually becoming an HBase committer in 2011.
My open source experience was personally rewarding and professionally
beneficial. So this is what I tell people
when they ask about getting involved in open source development:
1) Be Greedy
“What’s the ‘best’
open source project? What project should
I get involved in?” are common questions.
The best open source project,
per se, is one that you care about and are willing to spend a lot of time
in. So while there are certainly many
popular open source communities, the best one for you is one that you like and
one you need. The great thing about the
Apache Software Foundation, for example, is that there are a great many
projects to choose from. Pick something
that interests you and that you like – so in that sense “be greedy.” Get involved in
a project that will help address your
problems or interests.
2) Learn The Open Source Ropes
Once you’ve identified a project that you’d like to get
involved with, you need to learn about how Open Source software functions.
Project Organization
The Apache Software Foundation as a great description of
roles here…
Contributing – Community
Open source software is community around code, not just the
code. There are multiple forms of
contribution, and critical aspect is having a lively and supportive dist-list. Next
to the documentation, dist-lists are often the entry-point to the community.
For starters, don’t be a jerk to new users. Questions of the “how do I do X or Y?” can be
tiresome to experienced developers, but never lose the ‘newby’ eye! Projects that turn off new users and developers
don’t thrive.
When evaluating developers to promote to ‘committer’ status,
one of the things considered is how helpful they are to other developers. How do they interact with others on the
dist-list? Are they helpful? Do they review other people’s patches - and
with constructive comments? These small
interactions matter.
Contributing - Code
While smaller projects can get away with an open repository
(i.e., anyone can commit a change), most of the larger projects require a
process called patch submission to submit changes – and committers are the
gatekeepers for those changes.
This is an example of patch submission advice for Apache
HBase…
… each project will have it’s own set of procedures.
3) Learn About The Project
Sign up for the dist-lists, sign up for the project Jira,
check out the source code, build it locally and run it. Reviewing unit tests are a great way to
understand the project. Read the documentation!
The great thing about open source development is you can watch
it evolve in front of you.
4) Be Greedy, Redux
What features should you develop? It depends on what you are interested in and
what you care about. Again, be greedy. Large projects will have code infrastructure
that span multiple sub-projects, and infrastructure layers that include but are
not limited to configuration, logging, monitoring, security, etc. And then there is the business-end of
whatever the project does, with plenty of unit and system tests. Often there will be user-interfaces for variety
of purposes (e.g., operational and otherwise), and of course successful
projects always need copious amounts of documentation. Open source projects are living organisms so
release management is essential too.
Long story short, there is *always* something to be
done. Just pick something that matches
your interests and skillsets. All improvements, no matter how small, are forward progress for an open source project.
For my own story, I started submitting a few documentation
patches for HBase and wound up co-authoring the online HBase Reference Guide
for a couple of years. HBase was nascent
and the available documentation was slim because the community was both growing
and moving very quickly. As a user of
HBase I had my own vested interest in making sure that HBase was as explainable
as possible to my own co-workers (let alone the rest of the community), so I
started submitting documentation patches.
After a couple dozen or so I was voted a committer to keep running with
the Reference Guide. It was a great
match because it took a software engineer to understand the HBase codebase, but
also took somebody who had an interest and skill to write things down. It was a great fit and I enjoyed it.
Your interactions with an open source project might start small
– perhaps just answering other people’s questions on a dist-list. But everything matters! These are all parts of an effective open
source ecosystem.
5) Spread The Word
Talk to your co-workers, do presentations for user groups,
and submit conference presentations. In
short, spread the open source word!
© 2018 – Doug Meil
