Back to blog

Impressions from Jenkins Contributor Summit in Brussels

Stefan Spieker
Stefan Spieker
March 2, 2026

Jenkins Contributor Summit 2026: A Personal Reflection

The Jenkins Contributor Summit in Brussels was a milestone for me.

Not just because contributors from across Europe and also from the United States came together in one place. But because it was the first time I had the privilege of moderating the event. Thanks a lot to Stephane Merle for the time keeping and Bruno Verachten for the planning and organization support.

Standing in front of a room full of long-time maintainers, officers, SIG leads, and community members is both humbling and inspiring. Many of us collaborate daily online, yet being physically in the same room changes the dynamic completely.

This summit reminded me that Jenkins is not just an automation server — it’s a living ecosystem shaped by people who care deeply about it.

Setting the Stage

We began by welcoming everyone and outlining the goals for the day.

As moderator, my role wasn’t to dominate discussions but to guide them with keeping conversations focused, making sure different voices were heard, and ensuring we stayed aligned with the broader objectives. Open source thrives on open discussion, but structure helps turn discussion into progress.

From the beginning, the atmosphere was collaborative and forward-looking.

The Present and the Future - Officer Perspectives

One of the core sessions focused on the present state and the year 2025 of Jenkins from the perspective of project officers.

We heard updates covering the year’s accomplishments, ongoing challenges, and strategic priorities from the officers’ point of view:

  • Infrastructure

  • Release processes

  • Documentation challenges and improvements

  • Events and community engagement

  • Security efforts

These perspectives grounded the summit in reality. Jenkins operates at global scale, and maintaining trust — in releases, infrastructure, and security — requires continuous effort behind the scenes.

It was a reminder that governance and operational work are just as critical as writing code.

There will be a separate blog post covering the officer updates in more detail, but I want to highlight the security update here.

Security and Bug Bounty Program

An important aspect worth highlighting is the sponsorship support from the European Commission. The funding, managed by YesWeHack as part of a structured Bug Bounty program, strengthens the security posture of Jenkins in a very concrete way. This kind of institutional support demonstrates that open source infrastructure like Jenkins is recognized as critical digital infrastructure. If you missed the blog post about the Bug Bounty program, you can find it here: Introducing the Jenkins Bug Bounty Program. A big thanks also to the security team for their ongoing efforts in this area and securing nice shirts for all contributors.

SIG Updates and Technical Direction

The Special Interest Groups shared progress and plans, particularly around User Experience and Platform topics.

The UX discussions highlighted how carefully the project must balance modernization with backward compatibility. Jenkins cannot simply reinvent itself overnight — it evolves incrementally, respecting the massive ecosystem built around it.

On the technical side, we discussed Java support, the challenges faced by community plugin maintainers, and the ongoing effort to modernize plugins at scale.

The session on plugin modernization and OpenRewrite stood out. Automating large-scale refactoring is essential for keeping the ecosystem healthy without overwhelming maintainers. Sustainability is not just about infrastructure, it’s also about reducing maintenance burden.

Interaction and Momentum

We made space for interaction — including brainstorming workshop ideas and identifying areas where deeper collaboration is needed.

Once contributors start exchanging ideas in person, momentum builds quickly. Topics ranged from AI fabricated Pull Requests to onboarding improvements and UX refinements.

The energy in the room was constructive. Disagreements were pragmatic rather than ideological. Everyone shared the same goal: ensuring Jenkins remains relevant and reliable.

I took a photo during one of the sessions, and it captures the spirit of the summit:

Jenkins Contributor Summit Session

Advocacy and Community Building

We also talked about advocacy and outreach.

How do we attract new contributors? How do we support existing maintainers? How do we communicate innovations more effectively?

One recurring realization: Jenkins builds valuable improvements, but we don’t always communicate them clearly enough. Strengthening community outreach is essential for long-term growth.

Open Discussion and the “Headstand” Exercise

During the open discussion, we ran a structured “headstand” exercise to generate fresh ideas.

Instead of asking, “How do we achieve our goal?”

we deliberately flipped the challenge upside down and asked, “How could we guarantee the opposite?”

The Headstand

The concrete question we explored was:

How can we help maintainers spend as much time as possible with first-time contributors?

We brainstormed policies, tools, behaviors, and attitudes that would guarantee this outcome.

The answers were intentionally “bad” ideas:

  • Remove or neglect documentation

  • Avoid automation wherever possible

  • Make contribution guidelines unclear

  • Spending as much time as possible on manual feedback

  • Auto merge failing pull requests without feedback

By exaggerating the negative, we uncovered hidden assumptions about onboarding, mentorship, and process inefficiencies.

Flip It Back

We then inverted the ideas:

How could we make maintainers spend as little time as possible with first-time contributors?

Each “bad” idea was turned into its constructive opposite:

  • Improve documentation clarity and structure

  • Automate repetitive feedback and checks

  • Invest in contributor education and self-service resources

  • Make use of bots and tools to handle common issues

The exercise created clarity quickly. Instead of abstract discussions about “better onboarding,” we identified concrete improvement areas grounded in real maintainer experience.

Sometimes, thinking about how to fail is the fastest way to understand how to succeed.

Workshops: AI and UX

We closed with focused workshop discussions, including:

AI Slop: When Automation Creates More Noise Than Value

One topic that surfaced in our discussions — and that clearly extends beyond Jenkins — is the growing pressure on maintainers in what some call the AI slop.

GitHub recently described this phenomenon: contribution has never been easier. Opening issues, submitting pull requests, and now even generating code with AI tools can be done in minutes. The barrier to entry is low — which is great for accessibility — but the review burden remains high. This creates a paradox: more contributions can mean more noise, not necessarily more value. If you are curious about this topic, check out the GitHub blog post: Welcome to the eternal september of open source.

Practical UI/UX evolution steps

There was also a workshop focused on practical steps for evolving the Jenkins UI/UX. The challenge is how to modernize the user experience without alienating existing users or breaking plugins. One way to test changes is with the feature flag system, allowing gradual rollout and feedback collection. If you are curious what is already possible, see what is already available in your Jenkins instance.

Feature Flags in Jenkins

Personal Reflections

For me personally, moderating the summit was a learning experience.

It required:

  • Managing time without suppressing energy

  • Encouraging quieter participants to speak

  • Navigating strong opinions constructively

  • Reading the room and adjusting pace

Most of all, it reinforced something I already knew but felt more strongly in Brussels:

Jenkins is sustained by people who show up.

The Contributor Summit wasn’t just a series of agenda items.

It was alignment.

It was trust-building.

It was shared responsibility.

And I’m grateful that this time, I got to help guide the conversation from the front of the room. Thanks to everyone who participated, shared their perspectives, and contributed to the discussions.

About the author

Stefan Spieker

Stefan Spieker

I started contributing regularly in 2019, with a focus on improving quality. I’m also keeping up with some older plugins that are still really popular, like the Thin Backup Plugin and the Job Configuration History Plugin. The community helped me to bring these back up to standard and I learned a lot along the way. Furthermore, I use these lessons to make regular improvements to the developer documentation.

In my day job, I’m a solution architect in a central team that provides Jenkins and DevOps consulting within a big automotive and industrial company.