I used Jenkins at my first job out of university. It was a tool that we used for our builds, so it’s something that I learned as soon as I started working. Then, I got more involved with development and started learning about Linux servers and managing them. This turned out to be valuable information because we were eventually running these things in our team.

I’ve been using Jenkins for roughly 10 to 11 years.

Back then it was pretty much the only free option. Our team was entirely focused on open source, so being free and open source were the ideal criteria. Our work was Java based and everything we ran or used was open source. It was just easy to get up and going, without having to worry about licensing or funding. As far as I knew, Jenkins was the best tool for that sort of thing at the time.

Repeatable builds that show they’ve built beyond someone’s local machine. Being able to maintain repeatable deployments, content, and builds helps with scalability. This also helps when hundreds of people are using it and creating thousands of builds daily. Compared to other options it’s fairly cheap, easy to run, and you don’t have to rely on a provider or other party. We just do it ourselves really easily and it’s fairly stable, I just can’t find another service like Jenkins.

I like to work on the UI side of it. I feel like there’s a lot to improve there and there’s a lot that can be done to make it even nicer. Most of my contributions are around performance or stability issues and then general improvements that I’m working on.

I appreciate the modernization work that’s going on. Some of the features that Jan Faracik has implemented UI modernization for are fantastic. This modernization is helping us drop all those old technologies and frameworks. The Prototype removal may not be hugely visible, but its impact is immense. This modernization also means there’s hacks that can be dropped and modern libraries that were previously affected can now be used.

Getting started as a contributor is really hard, especially when you’re trying to figure out how the project works, but the guides, documentation, and best practices really help when contributing. At first, I would say start with small changes and fixes so you can learn about the project as you go. Don’t try to bite off something too big, just learn how it works and get familiar with stuff. Keep in mind there’s a lot of history to the project and there’s a lot of things there to understand. There’s always opportunities to improve and there are several areas with open issues to be worked on.