We all use open-source software or libraries. Developers usually have an urge to give back and contribute code or bug fixes or whatever — not only is it great to contribute in general but having some public examples of our code and interaction with real software projects is a huge benefit for a job search or resume.
Actually contributing, though? That can be hard. Issue trackers may be massive lists without much direction for beginners. Sometimes new features or major changes need the direction of a project’s committers or core members. In theory, it’s easy to pick an issue or bug and fix it. In practice, that can be a very large rabbit hole to fall into.
Below are two of the easiest ways I’ve found to contribute.
1. Find a Bug and Fix It
This is one of the easiest ways to get involved with an open source project: use a library or piece of software (we all do this), find a bug in said library or software (we’ve all had this happen!), submit an issue, fix it yourself, and send a pull request back to the library.
Bugs are often found during work, and, don’t tell my boss, but I often fix those bugs on company time. This is a benefit for PMG itself (we get to keep using a library) and the open source project.
Just be sure to search the project’s issue tracker for similar issues before opening a new one. Here’s a bug I found in doctrine/dbal and the fix.
2. Triage Old Issues
Find a project that you use or are familiar with. Head to its issue tracker.
Then start with the oldest issue/bug and start seeing if it’s still relevant. Is a more current version of the library/software out? Does that version still have the problem described? Has the feature already been added?
Sometimes this is just a matter of reading the code and posting a comment.
Other times a great way to figure out if a bug is still relevant is to add a test case to try and reproduce the issue. Don’t have enough info to do that? Ask in the issue tracker. Doing this may prompt the original submitter to return and describe whether a version upgrade fixed things or if the bug is still happening.
Adding tests is a really great way to learn how a project does tooling (which test harness, how are tests run, etc.) which is extremely applicable to something like coming into a new project at work where everything is unfamiliar.
Be Okay With Rejection
These two methods share a common theme: they often do not require input from the project owners or core committers. That, in my opinion, is a great feature, but it means that one has to be okay with rejection.
Software project owners and committers make choices about what their software should do and how it should be used. That’s the nature of software in general, but it gets particularly felt when users of open source libraries feel entitled to things like support of the use of a library in a certain way.
That’s not always going to happen.
That bug? A project owner may not consider it a bug, and they may not accept a PR for it. That issue from a year ago that seems irrelevant? A committer may already have a fix almost done, or the solution you found may be way off.
These things happen in open source, and they happen in closed source software too. Remember that a critique of your code is not a critique of you. That said, code reviews should always be and feel respectful. If they don’t feel that way, the open source project may not deserve your help.
It feels great to get code into a project or help solve a bug. But even if those things don’t really pan out when contributing, it’s important to keep trying to contribute and take whatever learnings to the next issue. Every project is different. The more you contribute to a project, the easier subsequent contributions are.
