I Took a Deep Breath and Contributed to an Open Source Project

Published: 2018-11-27 03:53 |

Category: Collaboration | Tags: code, learning, open source, programming, project, reflection

I've been playing around with building websites and self-teaching myself (is that redundant?) web development languages. I feel like I've crossed some kind of line in the last 18 months where I can identify a problem, conceptualize a web-based solution, and then build it much more easily than I could in the past. I know that skill comes from experience, but it's nice to reflect back on my learning and see growth.

I built mostly for myself at the start. I run a simple [static homepage](https://ohheybrian.com) and a few small pages (see links in the right sidebar) for some small Google Apps Add Ons that haven't seen much love lately (shame on me). I've also kicked off a couple of projects for the district that have seen some daylight.

Most of this has been totally private. I would cruise [GitHub](https://github.com) from time to time for [interesting](https://github.com/bennettscience/tweetmineR) [projects](https://github.com/bennettscience/TimelineJS3) [to play with](https://github.com/bennettscience/gifify), but never really contributed to any of the projects.

Without getting too deep, Git tracks all changes made to files by anyone working on a project. It's terrifyingly complex, especially when you work yourself into an unsolvable tangle, but it does make seeing changes to code really, really handy. GitHub takes all of this information and puts it into one nice place for people from all over the world to see and work on together.

Contributing to a project on GitHub felt like walking into a room with a bunch of geniuses and asking what I could help with.

![I've made a huge mistake](https://proxy.duckduckgo.com/iur/?f=1&image_host=http%3A%2F%2F31.media.tumblr.com%2Fd86b14c7bd853f1db317007cd523605c%2Ftumblr_mjmxf5Uvnb1qduy16o4_500.gif&u=http://78.media.tumblr.com/d86b14c7bd853f1db317007cd523605c/tumblr_mjmxf5Uvnb1qduy16o4_500.gif)

Recently, I came across a really cool project called [Lychee](https://lycheeorg.github.io/) which is a self-hosted photo sharing site. It runs on any web server and gives you a nice, clean tool to upload, organize, and share photos. [I downloaded and got it running](https://photos.ohheybrian.com) after a couple days of [poking around](https://blog.ohheybrian.com/2018/11/forget-the-mac-mini-bring-on-the-raspberry/). While I was using it, I noticed a small error: toggling a setting didn't work because of a wrong function name. I was able to look at the code, find, and fix the error on my own site within about 20 minutes.

Then came the scary part - submitting a fix to the problem.

I had done this only once, and it ended with the owner saying, "Thanks but no," which was a bummer and a little embarrassing. I was about to submit some code that would be used in a real, live app that people downloaded and installed on their machines. My name would be attached to this particular fix (git tracks who changes what). I was worried that my fix would magically not work as soon as I posted it.

All of this fear was built up in the _perception_ of what community-based projects require. Most of the anxiety I felt was because of the image of this world being closed off to people who could speak the language or do things perfectly (sidebar: this is true, especially in the [tech sector](https://www.recode.net/2018/2/5/16972096/emily-chang-brotopia-book-bloomberg-technology-culture-silicon-valley-kara-swisher-decode-podcast), and GitHub isn't immune. More on that later.). But, things break. Problems need to be solved. And I'd just solved one that could help someone else. And anyone can submit fixes to code, so I decided to [give it a try](https://github.com/LycheeOrg/Lychee/pull/112).

Nothing scary happened. The site manager sent me a quick thanks and implemented the code.

I just had a small bugfix pull request merged into a real-life open source project, so that's cool.

—Brian E. Bennett (@bennettscience) November 22, 2018

I started looking through some of the other issues on this particular project and noticed one that I felt like I could help with, even if it was just exploring possibilities. Someone wanted to be able to tag photos with Creative Commons licenses using a menu, not just throwing tags into the `tag` field.

Long story short, this was a much bigger problem. There were easily six to ten non-trivial changes necessary to make this update happen. Over the last four days, I've worked hard to learn about the app's structure, the languages used to make the whole thing tick, and how to implement this feature without breaking the entire site. Today, [that feature was added](https://github.com/LycheeOrg/Lychee-front/pull/18) after some back and forth on code structure with the main author.

I'm a hobbyist. I don't plan on going into development full time because I like teaching too much. But there are definite things I learned through this weekend's project:

- **Submitting requests to update an app is just that: a request**. I'd built up this idea that submitting code - even flawed code - to a project would be a waste of that person's time. But really, providing a starting point can help make progress on complex issues.
- **Take time to look at the culture around the project**. The first one I'd submitted to was a single guy who wrote a script to make something easier. In hindsight, submitting a suggestion for a feature wasn't in his interest, so he had every right to say no. Larger projects have more eyes on requests and dialog is easier to kick off.
- **Pay attention to the project's style guides and code requirements**. I was able to save myself a major headache by going thoroughly through my code to make sure it was at least up to the grammatical standard set by the project owners. That way, we could focus on implementation discussion rather than form.
- **If you can't submit code, submit bug reports or provide insight in other discussions**. The documentation pages are a great way to get involved as well. Bugs need to be reported and instructions don't write themselves. Both are low-barrier entry points and can help get you established as a good-faith contributor to the community.
- **Take a big breath of humility**. I didn't submit my request thinking it was the best solution, only that it was a _potential_ solution. After I submitted, we spent a day going back and forth, tweaking items here and there before adding it to the core files. [And there was _still_ a bug we missed!](https://github.com/LycheeOrg/Lychee/issues/120) Code is written by people, and people make mistakes, so plan on your code having mistakes. Know that you will get feedback on whatever you submit, but look at the goal and avoid taking it personally.
_Featured image is an [Unsplash photo](https://unsplash.com/photos/hokONTrHIAQ) by [Steve J](https://unsplash.com/@steve_j)._

Comments are always open. You can get in touch by sending me an email at brian@ohheybrian.com