Getting Started in Open Source
“The fundamental act of friendship among programmers is the sharing of programs”
– Richard Stallman
Recently, I’ve been working to contribute more to Open Source software. The following post
is based on that experience and research for a presentation I did with Jordan Papaleo for TahoeJS.
Contributing to Open Source can be a great way to learn more about software development,
work on your programming skills, and contribute to the community but it can also be intimidating:
- Any code that you submit is open to the review and criticism of the project maintainers and the public.
- You might be afraid that people in the project won’t be nice
- Linus Torvalds, the original creator of Linux, is known for commenting on one pull request to the Linux kernel, “Christ people. This is just sh*t.”
- There are barriers to entry in learning what and how to contribute
Tools to Get Started
The tools for open source are primarily the tools used by most modern developers. However, each community will be different. Many projects will require tests to be submitted with any pull request.
- git & github
- testing framework
Finding a Project
First, it’s probably best to contribute to a project that you already use on a regular basis. If you don’t use it regularly, you may be capable of making documentation updates and simple bug fixes, but you won’t have the context needed for making larger bug fixes, refactors and new features. I say this because open source projects are a community, and, as such, large changes are commonly discussed before they’re implemented. If you’re not part of those discussions, then you may not have the context or the roadmap for the larger changes and features.
I think there are benefits and drawbacks to choosing a small project vs. a large one.
- Small projects
- Small projects are often maintained by a few people at most. This may mean that the maintainers are happy to accept help but it may also mean that they’re too busy to provide help.
- Since they’re small, it’s easier to wrap your head around the whole project. However, this may mean that the maintainers already have a specific vision for the project.
- Large projects
- Large projects may be maintained by a large team of people. This may mean that they have time to flag beginner issues and provide feedback, but it may also mean that they’re overwhelmed by pull requests
- It would be harder to understand the entirety of a large project but it may be easier to find a small piece that you can work.
- Large projects mean large amounts of documentation, and that always needs work
Making a First Commit
The following steps are an example of a typical workflow for contributing to an Open Source web project:
- fork the repo
- this will make a copy of the repo under your Github profile
- make a new branch, if you want to keep your changes out of the master version of your fork
- make your changes
- create any necessary tests for new code and make sure existing tests pass
- commit your code to your branch
- if you only make one commit to your branch, it should give a brief summary of the changes that you made
- if you make multiple commits to your branch, the project may ask you to use
git rebaseto collapse those commits into one commit that explains your contribution
- from Github, create a pull request
- it depends on the project, but usually your PR will be against the master branch of the parent repo
- the project will probably ask that your PR contain a summary of your changes, tests, screenshots of any UI changes, etc
- the project may ask you to sign a Contributor License Agreement (CLA)
What to Expect
Once you submit your pull request, it is up to the maintainers. They may run automated tests against your code. They will almost certainly do a code review of it, possibly multiple, if it is a big change. If it’s a larger change, your PR may be submitted to the larger community for comments.
Growing as a Contributor
One common path to growth seems to be:
- documentation fixes or improvements
- minor bug fixes
- larger bug fixes or features
- ability to review pull requests and merge
- project maintainer
- job developing open source
Like any volunteer position, burnout is a possibility. I think one of the keys to avoiding burnout is keeping a sane schedule for yourself.
- First Timers Only
- Initiative by Scott Hanselman and Kent C. Dodds
- Built to encourage project owners to make it easy for first time contributors
- How to Contribute to Open Source
- very detailed guide about why and how
- Up For Grabs
- aggregates Github tags such as
up for grabs,
beginner friendlyto try to surface projects that are actively looking for help
- aggregates Github tags such as
- First Pull Request
- see the first PR that you ever made
- Contributing to the Mozilla code base
- Contributing to a more traditional, desktop application