I received my A level in 2005, my technical certificate diploma in 2007, and my engineering diploma in 2011 while working part time at Alcatel-Lucent. I was working in the CI team that had just been created shortly before I joined. The leader of the team asked me to look at Jenkins, then Hudson, to determine if it would fit the needs of the company. My first plugin for Hudson was created in 2009 and I have been working in Jenkins ever since then. After I received my diploma, I moved to Zenika where I was in a consultant role, helping with training and specialized in CI/CD. My consultant work came down to answering the questions “What is the need for that specific customer?” and “What is the cost of getting there?”. In 2014, I joined CloudBees as a support engineer for three years before moving on to engineering. It’s surreal to be in the field and using Jenkins for so long without being bored. CI has changed from what it was then to what it is now. Before, CI was “Is it compiling?” compared to now where pull requests are being created and merged regularly.

I have been using Jenkins since 2009.

I didn’t choose Jenkins as much as it was a mutual decision between myself & Jenkins. Previously, the company I was at was consuming open source as opposed to contributing to it. I had been looking at Jenkins since it was open source, young, and had a responsive community. My first time posting in the mailing list, concerning a bug with my plugin, resulted in Kohsuke (Kawaguchi) informing me of the bug and sharing that a release of Jenkins core was pushed later that day with a fix. If there is a problem, the community around the project is very responsive. It’s also possible to create plugins to match a need. My experience started when it was just one big project and has evolved along with Jenkins to now, where the plugin ecosystem has exploded with many new ones being introduced. The kindness and attentiveness of the community was also a big part of my introduction.

I saw Jenkins as a way to move what other teams were doing more quickly into the customers hands. At Alcatel-Lucent, this meant constantly moving and making sure the team velocity was not reduced by compilation, merging, and organizing everyone’s work. The idea is that something is tedious but not working well enough on its own. However, other teams were working with CI and it was helping streamline the work. Reassurance came from seeing what they were doing was still working with how others were operating outside of that team. Jenkins is a problem-solver for CI issues and keeping things updated, aligned, and working. Throughout my work with Jenkins, core has always been intimidating, so I have focused more on maintaining and enhancing plugins. Most of my support engineer experience with CloudBees had to do with bugs in plugins. Core was rarely the issue brought to our attention, so my work was primarily ensuring that plugins and their code were functioning as expected. Plugins are fascinating because the ecosystem has expanded greatly and they are so malleable. You can propose new solutions to a plugin maintainer or suggest new functions and fixes, and if there isn’t an exact solution that already exists, you can always create your own plugin to fulfil the need.

I like to make things easier for others to use, like what the UX team has been doing over the last couple years with modernization and updating the whole experience. It’s not just colors and rounded corners, it’s the entire user experience of using Jenkins that feels refreshed and easier to use. I have deep admiration for what the UX team has provided to the project. Especially where the number of plugins has expanded, it can be a bit intimidating to find what you need, and the community members working on Jenkins' UX have made great strides to help users navigate the Jenkins plugin ecosystem. Most of the UX work has also reached other areas of the project, beyond just core and plugins.

For my own contributions, I’ve worked on the Java upgrades (8 → 11 → 17 → 21) and recently, the Spring Security 6 migration. These upgrades are necessary to ensure that Jenkins is up to date and safeguarded in multiple ways. The reasoning is that these upgrades are hugely important in making sure that Jenkins continues working in the future and does not get stuck in the past. While not necessarily visible like the UX improvements, our goal with these migrations is to not have any sort of interruption when it comes to users. A successful migration means our work happens without users even noticing. They might need to upgrade their Java version, but that should be the extent of what they run into.

Don’t be afraid to reach out. Don’t be afraid to get started. There’s no such thing as a small contribution. We all started from 0 so there’s no shame or embarrassment to be had, as most people are still learning and not perfect by any means. The community is very respectful of everyone and all opinions. If you have questions, concerns, or an opinion on how something should work, make sure you can back up your thoughts. Plugins are a good way to get into the community.