When you are new to open source, there are two broad categories of projects that you can join. There are mature projects that tend to be large scale, well organized and have their basic development roadmaps already established. Then there are younger, scrappier efforts that can be more chaotic and liable to collapse, but ones where you can make a greater immediate impact.
So, which open source project is better to start out on? I’m an open source developer with over two decades of experience, but I recently engaged with a project of each kind. I thought it might be useful to share my experience with each of them in the hopes of helping open source newcomers decide which way they might like to go.
The first project is Envoy, the well-established, high-performance service proxy. Envoy enjoys support from major corporations like Google and Lyft and has a large and active developer community. It’s a thriving project to which anyone can contribute to, knowing that their work will be useful to many.
I started working on Envoy at the request of some VMware colleagues who had a list of existing upstream issues that they were interested in moving forward and that no one was addressing. They also had some problems that they wanted to be converted into issues but where it wasn’t entirely clear how they should be handled, along with a rough timeline within which they’d like all the work to be done.
The challenge with joining an open source project like Envoy lies both in its size and the web of relationships that have already formed within the community. Both make it harder to know how to push your ideas forward. When there is something you think you can contribute, it isn’t immediately obvious who you need to approach with the idea. And when you find the right people, you have to be ready to accommodate your proposal to fit development decisions that had already been made in other areas of the project.
With Envoy, I began by doing my research. I read up on the project’s history, watched some recent conference presentations, read blog posts and the Git log. I also wanted a general sense of how the community operates, so I read through all the available documentation and looked at existing pull requests and closed issues to try and figure out how the process of making contributions work in practice.
After that, I felt ready to approach the community. I began by asking questions about existing upstream issues and then tried to gather some community feedback on what solving the issues I was tasked with addressing might mean for the other contributors. In a couple of cases, where my questions touched on a potentially sensitive issue like encryption, that involved reaching out to people one on one.
Now I was ready to create new issues of my own, gather feedback from the community on how they could best be addressed and submit my first pull requests. Because Envoy has a very established community with multiple sub-projects responsible for different parts of the code, my code had to go through several layers of review. They also had strict testing requirements and an established testing environment. In one case, I had to go in and upgrade the testing environment before it could properly test the new code I was writing.
Despite the challenges, we were able to resolve all the issues we started out with and the upstream community was happy with the solutions we developed. We did find that it was hard to keep to our timeline. With an open source project like Envoy, where there are multiple parties and interests involved, it can very difficult to accurately predict how fast things will go.
As I was finishing up my work on Envoy, I heard about a much smaller and newer initiative, Network Service Mesh, which was developing a new way to map the concept of a service mesh to lower level (i.e. L2/L3) network payloads. In contrast with Envoy, Network Service Mesh had very few contributors and was wide open in terms of the kinds of contributions it was looking for. It also seemed to have a lot of potential, so I read what little documentation there was and got involved almost immediately.
I then began finding little issues that could be easily fixed and filing small patches for them. That got my name recognized as someone interested in the project. I started attending workgroup calls and joined the project’s communications channels. As I began to figure out who the key contributors were, I approached them with questions that helped establish that I was serious about Network Service Mesh and contributing to it.
Being so young, the project was in a fairly chaotic state when I joined. For example, there was very little documentation and much of what existed was outdated. But that also made it much easier than Envoy to make a quick, positive impact.
One issue we faced was that the project was set to present at an upcoming KubeCon but had no proof of concept available. Although it was a little intimidating, I volunteered to help create a working demo in time for the conference. We had to overcome a challenging lack of clarity about how we wanted the demo to work, but the community was incredibly helpful. Before long, we got where we needed to go—in fact, my efforts were recognized at the conference by being promoted to project maintainer at the event.
Working on a young and immature project like Network Service Mesh can be tremendously satisfying. But you do need to be disciplined about the work you do. It’s on you to figure out what will move the project ahead and how you can bring the most value.
So, which kind of open source project should you join first? I’d say it depends on which you see yourself fitting most comfortably. Successful open source projects are built by healthy communities, so pick the kind that you think would help you perform at your best. Then, dig in and get involved. Be active and passionate. Think about what the community needs, then volunteer to help get it done.
Want to know more about becoming an open source project contributor? Stay tuned to the Open Source Blog and follow us on Twitter (@vmwopensource) for additional resources and insights.
