What it takes to run a successful open source project

Armin and Daniel from Dynatrace share their experience with leading OpenTelemetry

In one of our latest PurePerformance podcast episodes, I had the pleasure to interview a governance committee and a technical committee member of the open source project OpenTelemetry: Armin Ruech and Daniel Dyla.

What I found particularly fascinating about this conversation was to learn more about the behind the scenes of running an open source project. Both Armin and Daniel have been part of OpenTelemetry since its inception, a.k.a. when OpenCensus and OpenTracing were brought together to become one, and have naturally experienced a lot on the way to becoming one of the most popular projects in the CNFC (Cloud Native Computing Foundation) landscape.

With this write-up, I’d like to share a few points that struck me during our conversation that reveal what open source is like for project leads, which is often very different from what you’d expect when just occasionally contributing or using open source projects!

But first, what is OpenTelemetry?

In a nutshell, OpenTelemetry (OTel) is a collection of tools to collect and export telemetry data from software and thus enabling effective observability. It’s part of the CNCF landscape and has a quite large community of contributors and users.

The project’s vision is that to make it standard that the majority of software developed in the future will come instrumented with OTel out of the box. This gives teams responsible for operating an easy option for automated observability.

The OpenTelemetry collector does minimal processing, but the analysis is done by vendors, so it serves as a data source for them. As the data comes in a standardized format, however, switching between backends is possible, thus preventing lock-in with a particular vendor.

Who are Armin and Daniel?

Armin is a team lead and software engineer at Dynatrace, who is part of the technical committee of OpenTelemetry (TC). The TC is responsible for all technical development within the project, including setting release dates, setting quality standards, repository management, etc.

Daniel Dyla is an open source architect at Dynatrace, focusing mainly on OTel, but also having contributed to Distributed Tracing Working Group (W3C Trace Context and W3C Baggage). He is part of the governance committee, which defines guidelines, codes of conduct, project governance processes, etc.

Open Source: Behind the scenes

Now that we know the setting, let’s have a look at some of the main points that reveal a bit more about what it’s like to be a committee member in open source.

Most contributors work for companies

When you mention open source, many assume that it’s run by volunteers who code in their free time. This may be true for some projects, but the majority of bigger projects are supported by companies, who have a vested interest in the success of the project.

Organizations can support projects either by donating money or by donating resources, and the latter are often more valuable. There’s always a lack of engineering or project management resources, and, being aware of this, some companies hire employees for them to specifically contribute to open source.

Having said that, there still are many contributors that work on the project because they are passionate about open source. It’s also a great way to gather a bit of work experience before entering the job market, supported by many mentorships programs (like LFX or GSoC). As well as getting your name known in the community, putting you on the radar for organizations that offer open source positions.

Open source for maintainers is 80% management

Daniel recalls that when he started in OpenTelemetry, he was doing 80% coding and 20% community management. Now it’s the other way around. A lot of his contributions are actually PR reviews, issue triages, governance, etc…

Furthermore, as the number of contributors increase, the amount of admin work also increases along with it, and it’s sometimes hard to keep up the momentum and enthusiasm when a large part of the contributors are volunteers.

Getting started is often the hardest step

In many big open source projects, there’s usually a core group of regular contributors and maintainers. Some may contribute more sporadically, but if somebody is new to the space they are unfortunately sometimes left alone because they are unknown by this core group. Part of the job of the governance committee is to find ways to bridge this gap and make sure that every contributor, new or old, is welcome and valued in the community.

It can be discouraging for a first contributor to open a first PR and see that nobody responds for a long time. The goal is to ensure that we don’t lose enthusiastic new contributors that may become maintainers over time.

People who want to contribute should start by getting familiar with the project. Try out a tutorial and give feedback or raise issues if you find bugs. Another good entry point is documentation, which helps you learn more about the project before you contribute code. There’s always some “good first issues” or “help wanted” items in the backlog that can get you started.

The Open Source Tax is real

One interesting thing that you learn about once you’re a committee member is the so-called Open Source Tax: what happens when you have the “problem” of too many smart people in a team.

When you have multiple good ideas for a solution, it’s hard to decide on which one to take, and this can cause delays in a project. If there is one good and one bad solution, it’s easy to choose one. When you have two good solutions with different tradeoffs, you can fall in the trap of debating forever on which option to take.

In the end, it’s a great thing to have a smart community that cares a lot about the project. So, all in all, the open source tax is a small burden to bear.

What’s upcoming in OpenTelemetry?

OpenTelemetry is a thriving project and is excited to release its metrics specification soon, which expands upon the current specifications for traces and logs.

If you’d like to learn more about what’s happening in the project, listen to the full podcast episode here: OpenTelemetry from a Contributors perspective with Daniel Dyla and Armin Ruech

Or get in touch with Armin or Daniel directly on the OTel Slack.

What it takes to run a successful open source project was originally published in Dynatrace Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.