Getting started as a GitLab contributor

GitLab's open culture makes it very welcoming to contributors. Here's what I learned when I decided to become one.

Dan BarkerGitlab's open culture is one of its strongest assets and the main reason I use GitLab in DevOps transformations. The community edition's code is open source and the paid version makes its source code available for contributions. These are valuable factors rooted in the company culture its CEO has diligently maintained over the years. It doesn't hurt that its tools are great, too.

I believe GitLab's sales and marketing team is the best of any company out there. They have included me as a user, customer, and friend over the last few years, and they are genuine and caring people. This was underscored last year when I wanted to contribute a feature, and GitLab's team went to extraordinary lengths to help me succeed. Here's the story of making my first contribution to GitLab.

How it started

During a review of our application code, the National Association of Insurance Commissioners (NAIC) found that many applications either didn't include our license or the license was no longer current. We needed to make it easy for everyone in the company to access our proprietary code license and provide an auditing function to ensure they all stayed current.

So, I went spelunking through GitLab issues in search of something related. I found a related issue that was a couple of years old and didn't look like it would be worked on anytime soon. I mentioned to Joe Drumtra, our GitLab account manager, that I'd like to contribute the feature, and he got very excited.

Joe immediately scheduled time with me to speak to the product owner, James Ramsay, and the lead engineer, Douwe Maan, on that team. He also added me to a channel in their Slack for better collaboration. We had the first meeting a week after I mentioned we'd like to contribute.

Our first meeting

Aaron Blythe from the NAIC joined me on the first call with James and Douwe from GitLab. They recorded our first conversation on Zoom and shared it publicly afterward. They also posted a follow-up in the Slack channel detailing what we discussed.

During that first call, James walked us through how licenses worked in the version we'd be modifying, then we discussed the vision for the feature we'd be implementing. This was to ensure we were all on the same page and everyone understood what was happening. This was really helpful for Aaron and me so we could look back as we went through coding the new feature.

They also brought in a designer, Sarah Vesselov, to ensure the UX would be right. They were migrating to a new look where we'd be working, so our timing would be an issue. Sarah also made some great mockups for the result and posted them on the GitLab issue.

During the call, Douwe navigated Aaron and me through the Ruby on Rails code and made some of the initial changes. He served as an experienced guide to make us more familiar with the code, show us the parts we would likely need to change, and help us avoid some pitfalls. Thanks to his thorough explanation, we were able to complete a lot in just an hour.

After looking through the code, I felt a little nervous. Just a few years ago, I was writing Ruby all day every day, and these weren't simple scripts. I was contributing to complex systems with race conditions and functionality, like creating a directed acyclic graph of tasks and executing them. However, none of that was in Ruby on Rails, and Ruby on Rails looked barely like the Ruby I remember.

Programming (really) in the open

Aaron and I decided to live stream our endeavor on our DevOps KC YouTube channel. We did two live streams, two hours each, with the two of us pair programming. We did a little bit of prep before the first live stream, mostly just looking around and trying to understand the code.

We began the first live stream with a brief refresher of the issue. I struggled a bit to figure out how to use Google Hangouts. (In fact, the whole live stream might be proof that I need to remove Ruby from the languages I say I know, and I might not even understand technology all that well.) Mostly we stumbled around testing out different solutions and hoping one would work. Most people just call this "programming."

During this session, Aaron taught me a lot I didn't know about Ruby on Rails and reminded me of some things I'd forgotten about Ruby language idioms. I believe Aaron also learned some things from me. During the first live stream, we created several pieces of the feature and knew where we needed to find a solution.

We learned even more in the second live stream. For example, we discovered that managing environments and dependencies is hard, but there are tools that can help. Also, it can be hard to manage projects when you have a directory structure that includes separate projects within projects. Context matters a lot! We also found out that dropdowns are really hard to work with.

The finishing touches

The feature wasn't done after the live streams, but we were close. I decided to finish it up on my own because Aaron needed to focus on some other work. I also struggled to find time to complete it, so I was thankful when someone from GitLab reached out and asked if I needed help. I finished what I could and submitted a merge request. (If you want to learn a lot very quickly, it's worth reading through the merge request discussions.)

Douwe and Nick Thomas from GitLab quickly hopped on and gave me a lot of guidance to finish some of it. We figured out there was a pretty obscure problem with the dropdown code that was causing most of our problems with it. Without Nick's help, I don't think I ever would have found the problem or the code that needed to be updated.

Nick put in a lot of changes to get it ready to merge, and I helped out where I could to finish it up over the next couple of weeks.

The feature was finally completed and merged back into the Master branch for GitLab's 11.3 release. However, this wasn't the only feature related to our work that was completed. Nick also implemented other file types like .gitlab-ci.yml, .gitignore, and Dockerfile as instance-level templates.

Why did I do it?

So, why did the chief architect of a nonprofit organization decide to contribute to GitLab? There are three main reasons:

First, it gave me a chance to show that I don't know everything and I'm fallible. We are building a culture of blamelessness and servant leadership at NAIC, and this was the fastest way I could think of to walk the walk.

Second, we wanted to make it part of our culture to contribute back to open source projects. It's hard for someone to say, "you aren't allowed to contribute," when the chief architect does it live on YouTube and tells everyone else they can. Also, we are funded by consumers, so one of my goals is for NAIC to operate as lean as possible and contribute back to the community as much as we can.

Finally, I wanted to contribute this specific feature because it's something our legal department needed. Making it easier to stay in compliance helps our legal team, which helps us build a strong relationship of trust and mutual benefit that's important as we move into new areas with legal ambiguity. Also, I knew no one would work on this issue in the near future, a lot of customers wanted it, and the other file types could be implemented quickly once we established the framework.

Getting started as a contributor

Deciding whether to contribute to GitLab and open source or source-available code might involve your legal team and company policies, so consult with them first. Even contributing to source-available code (like we did) is valuable. We changed code not only in the commercial version but also in the open source version.

If you want a feature that GitLab isn't prioritizing, I recommend contributing it back by contacting someone through the issue or connecting with your account manager. They're likely willing to talk with you to make sure you're going in the right direction, and they may even agree to collaborate as they did with us.

Before you start on the fun part of working on a contribution, check out GitLab's contributing guide. If you want to contribute, but don't have a specific feature in mind, an easy way to get started is to search GitLab issues and sort by weight. The lower-weight values are expected to be the easiest. GitLab also tries to make contributing easier with some automated magic around changelog updates and other routine administrative work, but it can be more confusing if you're not aware those things exist.

I hope you'll contribute soon. I'm hoping for my second contribution to happen in 2019.

About the author

Dan Barker - Dan spent 12 years in the military as a fighter jet mechanic before transitioning to a career in technology as a software engineer and then a manager. He was the Chief Architect at the National Association of Insurance Commissioners leading their technical and cultural transformation. He's now leading RSA Archer as their Chief Architect in their cloud migration and conversion to SaaS. Dan is also an organizer of DevOps KC and the DevOpsDays KC conference.