· 5 Min read

My DevRel Journey: First Steps in Open Source

How I got into Open Source, and my thoughts on the value of DevRel.

Post

Year after year, more organizations decide to make their critical infrastructure open source in order to increase the quality of their codebase. GitHub researchers have said that more than 90% of the Fortune 100 use its service to host open source code, and GitHub now has more than 94 million developers on its platform.

It's a simple fact that more eyes on the code help reduce the number of bugs and develop new features. On top of that, almost every single company relies on open source in one way or another. As an organization's involvement with the open source community grows, an overlooked role in tech suddenly takes the spotlight: Developer Relations.

What exactly is DevRel?

According to developerrelations.com, Developer Relations is "a process for nurturing mutually beneficial relationships between organisations and software developers". The main focus of DevRel is to increase adoption of a product, enable developers to use the product effectively and achieve a better understanding of developers' needs.

Furthermore, they describe four pillars of developer relations:

Four Pillars of DevRel

  • Developer Marketing: understanding who the target developers for a product are, then making sure they have the information and tools to make a decision.
  • Developer Enablement: providing everything that developers need to be successful with the product.
  • Developer Advocacy: acting as a champion for and conduit between developers and the organisation.
  • Developer Community: creating and maintaining an ongoing process in which developers can pursue a common goal in relation to your product or organisation.

Even if we aren't directly selling a product, DevRel plays a pivotal role in making sure open-source projects are healthy, active, and useful for the developers that rely on them daily. Furthermore, maintainers want to make sure that their tools reach the developers that need them the most.

That's not all: the picture above shows that DevRel is a cycle. Each of these pillars feeds into the next, and the cycle continues until you have a flourishing open-source project, where the right tools are in the hands of the right developers, and real long-term value is created for the organizations involved.

My DevRel Journey

I'd like to talk a bit about my journey as a DevRel Fellow for G-Research Open Source Software. It involved a healthy mix of software engineering, marketing, and developer enablement.

Journey

I got this opportunity thanks to MLH (Major League Hacking), which sponsors a Fellowship Program for students to work on open source projects. I was one of the very lucky few out of 10,000+ applicants to be able to join the program.

They provided me not only with this truly invaluable opportunity, but also with mentorship to ensure I could succeed in my role. I am truly grateful that I had the chance to participate in the Fellowship, and would love to continue.

At first, I didn't understand very much about my role as a DevRel. Tabatha, a DevRel Engineer and member of G-Research Open Source Software who I worked closely with for the past 3 months, told me that it's all about reducing friction for potential adopters and contributors.

In other words, we use our technical and people skills to promote projects, engage developers and make sure documentation is available and useful. Our ultimate goal is to attract new users, and convert existing users into contributors.

She really helped me understand how DevRel fits into the greater scheme of things, and the value that it brings to the table for organizations and the open source community as a whole.

My Impact

The bulk of my contributions have been to ParquetSharp. When I began, the repository was already in really good shape, so I was worried about being able to find areas for improvement! After doing a thorough inspection of the README and available documentation, I found that most of it was not SEO-friendly, and the repository itself was lacking tags for GitHub searches. So, my first contributions were mostly related to SEO and marketing.

First PR

Fun fact: My first PR consisted of a few small changes to the README, to let users know more about Parquet and ParquetSharp's advantages versus other open-source alternatives. Sprinkle in some SEO-friendly keywords, and voilà! The README was now more likely to show up in GitHub and Google search results.

After that, I focused on reducing friction for new adopters of ParquetSharp. My goal was to make the user guides as useful, comprehensive, and friendly as possible. I added a guide on How to use ParquetSharp from Powershell, as well as a README section on how to troubleshoot potential build issues.

Finally, I decided it was time to contribute something big! I noticed a feature request in the Issue section. A user wanted to Read and Write Parquet files using Custom Types with the Row-Oriented API. Quite the mouthful! Without much of a clue, I jumped into it, hoping to figure out the details along the way.

A G-Research Engineer, Marcin, helped me understand the requirements of the feature. Once I created the PR, one of ParquetSharp's core maintainers, Adam, helped me improve my code to the high standards of both G-Research and the open-source community. I managed to get the feature merged in, and it was available in ParquetSharp 14.0.2!

First Feature

I'm really proud of the work I've done, and I'm excited to continue contributing to ParquetSharp and other open-source projects. Most importantly, I am deeply grateful to all the people who helped me get started in this journey, and I hope to be able to help others in the same way.

Getting Started with DevRel and Open Source

To wrap this up, I'd like to share some tips for students and junior developers trying to get into Open Source:

Making your first contributions to open source through DevRel is a great idea! As a junior engineer, you have a unique perspective on whether or not documentation is intuitive for people who don't necessarily have profound technical expertise. By making existing guides more user-friendly, or creating troubleshooting guides, you will help projects grow more quickly and ensure high levels of developer satisfaction.

Get started today by checking out G-Research's open source repositories!