How did you get involved with Open Source?
My journey into open source started back in 2013. I was heavily into Minecraft at the time, and with a group of friends, we started hosting our server. That quickly grew into building custom plugins, which meant I had to teach myself Java. Over time, what started as a fun project turned into something serious.
As I built more, I started looking at existing open source Minecraft plugins on GitHub—using them, learning from them, and eventually contributing back with bug fixes, feature improvements, and optimizations. That was my first real exposure to contributing to an open source ecosystem. It taught me not only how to write code but how to collaborate with other developers, navigate pull requests, and maintain community-driven software. Those experiences laid the groundwork for everything I do in open source today.
What’s Open Source to you?
Open source is about empowerment, collaboration, and shared learning. It’s a space where anyone can get involved and make a difference, regardless of background or credentials. It’s also where I’ve learned the most—both technically and through working with people from all over the world.
What projects are you involved in?
These days, I’m primarily involved in the Jenkins project. I contribute to Jenkins Core, maintain several plugins, and help with weekly and Long Term Support (LTS) releases. I also serve on the Jenkins governance board, where I work on community processes, release coordination, and broader project direction.
Beyond development, I focus on documentation, infrastructure improvements, and helping new contributors get involved. Jenkins is a large and diverse ecosystem, so there’s always something meaningful to work on.
How do you grow your community?
The most important part of growing a community is making it welcoming. I try to support contributors by reviewing pull requests, answering questions, and mentoring wherever I can. It’s significant that people feel like their time and effort are valued.
We also put great effort into making our processes transparent—clear contributing guidelines, labels for good-first-issues, and open communication channels all help. When contributors see that their work has real impact, they’re more likely to stay and grow into leadership roles themselves.
What are the main challenges you face as a maintainer?
Time management is probably the biggest challenge. Between reviewing code, fixing bugs, releasing updates, and supporting users, there’s always more to do than hours in the day. Many maintainers—including myself—contribute in their free time, which adds to the balancing act.
There’s also the challenge of scaling knowledge and processes as the project grows. Making sure contributors understand best practices, architecture, and long-term goals takes ongoing effort.
How can contributors better support maintainers?
Small contributions really do go a long way. Clear, well-documented pull requests make a huge difference. Testing changes before submitting them, writing or updating documentation, helping triage issues—these are all incredibly valuable.
It also helps when contributors stay engaged. Taking ownership of a plugin or feature, following through on feedback, or helping others in the community can lift a lot of weight off maintainers’ shoulders. Open source is a team effort, and shared responsibility makes it sustainable.
What are some of the key security practices you’ve implemented in your project?
Security is a core part of maintaining software responsibly. In my work, I focus on minimizing dependencies, using secure defaults, reviewing code carefully, and staying up to date with patches.
Jenkins also has a dedicated Security Team that handles vulnerability reports and coordinates responsible disclosures. Their work is essential, but every maintainer has a role to play in keeping things secure—especially when touching sensitive parts of the codebase or publishing new releases.
What do you think are the biggest security challenges facing Open Source today?
The scale of modern open source use is both a strength and a challenge. A small project maintained by just a few volunteers might be used in thousands of production environments. That creates pressure to maintain a high level of security with limited resources.
Dependency management is another major issue. A vulnerability in one upstream library can have a ripple effect across hundreds or thousands of downstream projects. We need better tooling, processes, and collaboration across ecosystems to manage that complexity.
What advice would you give to current and new maintainers?
Start small, stay curious, and ask questions. You don’t have to know everything to be a good maintainer—what matters is consistency, communication, and care for the project and its people.
Focus on building relationships, not just writing code. Good documentation, mentoring others, and being open to feedback all help build a strong, resilient community. Open source is a long-term effort, and it thrives when we support each other.
Read stories shared by other maintainers.
This story was published under CC BY-SA by the author.