• About Us
    • New York
  • Work
  • Capabilities
  • Careers
  • Technology
  • Blog
  • Contact Us
  • About Us
    • New York
  • Work
  • Capabilities
  • Careers
  • Technology
  • Blog
  • Contact Us
May 16, 2018

Two Easy Ways to Start Contributing to Open Source

Posted by Christopher Davis

contributing to open source software

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.

open sourcesoftwaresoftware development
Previous
Next

Latest White Papers

  • Shifting Plans for 2020 & Beyond
  • Game On: How Brands Can Log Into A Diverse Multi-Billion Dollar Industry
  • What CCPA Means For Brands
  • How Google is Improving Consumer Data Privacy
  • Ways to Prepare for the Cookieless Future
  • See all White Papers

Featured Posts

  • Ad Age Names PMG #1 Best Place to Work in 2021
  • MediaPost Names PMG Independent Agency of the Year
  • PMG Client Portfolio Trends During Amazon Prime Day 2020
  • A Closer Look at the Congressional Big Tech Market Power Report
  • What to Know About Reddit

Categories

  • Consumer Insights
  • Content
  • Creative Design
  • Data Analytics
  • Development
  • Digital TV & Video
  • Ecommerce
  • Industry News
  • Local
  • Mobile
  • Paid Search
  • PMG Culture
  • Programmatic & Display
  • SEO
  • Social Media
  • Structured Data
Fort Worth

2845 West 7th Street
Fort Worth, TX 76107

Dallas

3102 Oak Lawn Avenue
Suite 650
Dallas, TX 75219

Austin

823 Congress Avenue
Suite 800
Austin, TX 78701

London

33 Broadwick Street
London
W1F 0DQ

New York

120 East 23rd Street
New York, NY 10010

Get in touch

(817) 420 9970
info@pmg.com

Subscribe to the PMG Newsletter
© 2021 PMG Worldwide, LLC, All Rights Reserved
  • Contact
  • Privacy Policy
 Tweet
 Share
 Tweet
 Share
 Tweet
 Share
 LinkedIn
We and our partners use cookies to personalize content, analyze traffic, and deliver ads. By using our website, you agree to the use of cookies as described in our Cookie Policy.