From coding fixes to building communities: My Open Source journey

My name is Niklas Merz and I first got into Open Source to scratch my own itch. It started with tinkering on my own little projects and some small contributions to Open Source projects I used for my personal and professional work. Over the years, I shifted from contributing code to taking on some community work. I no longer use that project in my day job, but I still like to give something back and help it move forward.

Let’s start at the beginning. Like many others I did smaller documentation and code fixes because I used Open Source projects for my work. At some point during my apprenticeship I got the opportunity to work on a mobile app built with web technologies and this led me down a path to joining a project management committee (PMC) of the Apache Software Foundation (ASF) project Cordova. The ASF has the official motto of “Community over Code” and after some years in this space I can relate to this more than ever.

Everybody finds a different entry, but I think the most sustainable way might be to get active in Open Source is from necessity. When I started using Apache Cordova contributing became logical very soon. Projects like Cordova that have an open plugin ecosystem are naturally good for starting out. At some point in my day job we wanted additional features no existing plugin offered, and I started to build my own plugins and made them Open Source because it’s just fair to give something back. We also encountered some issues or limitation in the core of the framework, so I dug deeper into the project and tried to fix them myself. From my experience it was just much faster to get help from the community if you can show that you did some research and offered solutions to tackle the problem. Every Open Source community is different, but usually it’s appreciated if you show as much initiative as you can.

My Open Source journey started out with coding fixes and features but over the years became much more. I’m proud of the features I implemented, the releases I managed, and the contributors I supported. Lately I really enjoy sharing my expertise as Co-Chair of the W3C WebView Community Group to improve the core technology that made Cordova possible. I also became interested in the community side and attended events to meet people and give talks. You can learn a lot from the wonderful people in Open Source and form meaningful connections. My current job came from a connection that formed at an Open Source event. Along the way, I also began to notice just how different Open Source projects can be in how they arre built and maintained.

Types of projects

After some time in Open Source you find out there are very different types of projects and maintainers with different ways of doing Open Source. If you are planning on using or contributing to a project I think it’s important to check if the project is healthy and active, but also understand how it’s run.

An Open Source project can be just a single person working on their project in public and accepting contributions from others. That’s where I started. I built a plugin that was useful for me and published it on GitHub under the MIT license, so everybody can use and improve it. Over the years this plugin got many releases, issues and contributions. Some parts of the plugin were even rewritten entirely from other contributors and I just did code reviews, testing and publishing. The experience you get from managing your own project prepares you with the basic skills of tools like Git, GitHub, CI and security best practices but most importantly communicating with strangers from all over the world. As a maintainer good communication and patience are very important because that helps new people join and stay in your community.

Another common type of Open Source project is the one stewarded by a larger Open Source foundations like the ASF, Eclipse, Linux Foundation etc. These projects usually have a bigger number of maintainers. The foundation’s job usually is to provide oversight and rules for important things like license and security compliance, release process, trademarks, funding and much more. If you are looking into to contributing to these foundation hosted projects you may be required to make some extra steps and follow additional processes. Most projects try to make contributions as easy as possible and provide useful resources and documentation. No matter the structure, projects rely on people with different strengths. Over time, I started to see recurring patterns in the kinds of roles maintainers play.

Maintainer personas

There are different types of people typically needed to run a bigger project successfully and sustainably. For a talk at the ASF event “Community over Code” I tried to define them and give them names:

• Silent Hero
  • Prefers to stay in background
  • Does a lot of coding work
  • Handles many important and sometimes boring tasks like releases
  • Is a driver of progress
• Helping hand
  • Acts as the contact person for the community
  • Answers a lot of user questions
  • Takes care of issue triage and response
• Advocate
  • Often is seen as the voice of the project
  • Gives talks and takes care of promotion
  • Works on website, documentation, podcasts etc.
• Founder/Legend
  • Started the project or is a contributor since “the early days”
  • Has lots of deep knowledge
  • Knows the history behind things
  • Sometimes is hard to reach because they may have moved on to other things

As you can see there are many roles in Open Source you can fill and all are important for a project to succeed. It’s not just about coding as many people assume, but there are lots of more important tasks that make the code usable by consumers. If you’re part of an Open Source community, you can use these maintainer personas to critically reflect on your own and your fellow maintainers’ roles. I’m sure the list is far from complete. Understanding these roles helped me reflect on how to check how the project works and if the project is healthy. That’s something every maintainer should think about from time to time.

Conclusion

Open source has taken me from fixing small bugs to building communities and sharing knowledge. It’s not just about code, it’s about people, collaboration, and making things better together.

Advise for maintainers

Every maintainer faces challenges like burnout, lack of funding or missing new contributors. For me personally motivation to continue working on some projects decreased, because I no longer really use them daily. Nevertheless, I’d like to stick around and try to give back by doing community work like organizing meetups or helping out on releases. My advice to maintainers of projects that are a larger or older is to do health checks from time to time. For Cordova I wanted to check if our perception matches the reality of the project and check on the user base. We ran a survey to find out who is using Cordova, which parts of the framework are most used and which possible pain points exist. Taking a step back to evaluate the size and health of your project and community can help you refocus and rediscover your motivation.

Advise for contributors

Everybody’s experience is different. It’s important to start somewhere and to stick around to grow. You need to find projects that you’re motivated to work on and just get started doing the work that fits your skills and interests. If you do your best and show initiative, maintainers will appreciate your work, and it will make a difference. It’s really rewarding to see that others are benefiting from your contributions. Be patient and open-minded. You’ll never know where this journey will take you and which people you’ll meet along the way.