Getting Started in Open Source

By Garrett McCullough | June 1, 2017

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.

  • npm
  • git & github
  • testing framework
  • node

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:

  1. fork the repo
    Forking a repository in Github

    Forking a repository in Github

    1. this will make a copy of the repo under your Github profile
    2. make a new branch, if you want to keep your changes out of the master version of your fork
  2. make your changes

    Code changes as they appear in Github

    Code changes as they appear in Github

  3. create any necessary tests for new code and make sure existing tests pass
  4. commit your code to your branch
    View of a code commit in Github

    View of a code commit in Github

    1. if you only make one commit to your branch, it should give a brief summary of the changes that you made
    2. if you make multiple commits to your branch, the project may ask you to use git rebase to collapse those commits into one commit that explains your contribution
  5. from Github, create a pull request
    Making a pull request in Github

    Making a pull request

    1. it depends on the project, but usually your PR will be against the master branch of the parent repo
    2. the project will probably ask that your PR contain a summary of your changes, tests, screenshots of any UI changes, etc
  6. 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.

A pull request in Github that is waiting to be merged

A pull request that is waiting to be merged

Growing as a Contributor

One common path to growth seems to be:

  1. documentation fixes or improvements
  2. minor bug fixes
  3. larger bug fixes or features
  4. ability to review pull requests and merge
  5. project maintainer
    • job developing open source
    • burnout

Like any volunteer position, burnout is a possibility. I think one of the keys to avoiding burnout is keeping a sane schedule for yourself.

Resources

Posted in JavaScript, Truckee-Tahoe

Leave a Comment