What was your first open source pull request or contribution?

Think back. Tell us about your experience in the comments.
229 readers like this.
Person standing in front of a giant computer screen with numbers, data


Contributing to an open source project can be... Nervewracking! Magical. Boring?

Regardless of how you felt that first time you contributed, the realization that the project is open and you really can contribute is quite awesome.

For new contributors

Having a safe and welcoming testing ground is what new contributors need. They need to know what the barriers to entry are and what resources are available to them. One tip is to find a project to contribute to that satisfies a need or interest for you. This can create a beautiful, reciprocal relationship. Find out how to contribute to a project in this post for cats, er, newcomers.

About project maintainers

It's good for new contributors to understand that the maintainers of these projects, the ones who review your pull request, often have a totally different fulltime day job and are generally very busy. It can be overwhelming. Sometimes this results in short, blunt responses to new contributions. 

Learn more about contributing for the first time and maintainer burnout in Episode 3 of the Command Line Heroes podcast.

Tell us about your first contribution

Think back. What project did you choose? How long ago was it?

Are you still involved with the project in some way, or are you surprised looking back that you chose that project? What feelings came up for you? Scared, elated, angry, happy... or, maybe all of the emotions?

User profile image.
Jen leads a team of community managers for the Digital Communities team at Red Hat. She lives in Raleigh with her husband and daughters, June and Jewel.


The first time I submitted a patch back to a maintainer was around 1995 on GNU Emacs. I had started work at a small company, and our workstations were Apollo DomainOS/AEGIS. I didn't like the Apollo editor pad, so I downloaded the source code to GNU Emacs and tried to compile it. The build process broke somewhere, but I managed to work around it with one or two lines of code.

I submitted my changes back to GNU Emacs, and they made it in. I felt really proud knowing I'd helped in some small way.

Funny story. My first contribution to a prominent open source project was towards the end of the 1.1.x development series of the GIMP in 2000. I did not know how to submit a patch down official channels, and joining a mailing list to send in a patch was a very intimidating first step. The patch was a one-line fix to a GIMP plug-in to correct a small issue with tile management in the plug-in. I don't recall how I found it - I think there may have been a bug created for it on the old bugs.gimp.org website (pre-Bugzilla). In any case, I hit the bug, and fancied myself to fix it.

After coming up with this one-line patch, I looked in the project ChangeLog to find a name and email address to send the patch for review - I happened to see Daniel Egger (still an open source kernel developer) as a frequent contributor at the time, and he was very kind and encouraging with this first contact. Daniel committed the patch on my behalf to the GIMP CVS: https://gitlab.gnome.org/GNOME/gimp/commit/fcc29b05dcbf8b14916bba195d77…

Here's where the story gets funny. My very first contribution was wrong! My second patch to the GIMP, sent approximately an hour later, fixed the first patch. https://gitlab.gnome.org/GNOME/gimp/commit/d8dfc2128aa1f768152d86f12005…

So, I learned early that it's OK to make mistakes as long as you fix them :-)

My first upstream contribution was during my first job post degree in 2001. Our company, Bibliotech, had an community website for schools which was translated into many languages. It was written in Perl as it was starting to get usable UTF-8 support, but we hit a few bugs during testing. One function would report string length in bytes instead of characters, and in the regex engine '.' would match bytes instead of characters. I sent a patch for the first problem which was merged a day later, and a reproducer and partial patch for the second which was then properly fixed by the maintainers a few hours later.


I learnt that the Perl maintainers were very responsive and that the Perl regex engine internals were very scary.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.