📖 Developer Satisfaction 2026 Report

🌀 Overall

Update 2026-04-27 – On initial release, numbers for Productivity, Satisfaction with Software Development Life Cycle, and Community characteristics had not been updated from the previous year. These numbers are now up-to-date.

tl;dr

Feeling productive – 68% feel they were very or moderately productive over the past year, compared to 71% last year.
Satisfaction with Software Development Life Cycle – 65% satisfied, similar to 66% last year.
Community characteristics
- More than two thirds agree the Wikimedia developer community is welcoming, dedicated, and collaborative, similar to last year.
- 66% agree the community is diverse, up from 56% last year.
Areas of improvement - Respondents suggested improvements related to staff-volunteer interactions, decision-making, code review latency, and more.

top

# Productivity

“Overall, thinking of your role as a member of the Wikimedia developer community in the past year, how productive do you feel?”

More than two thirds (68%) of respondents indicated that they felt very or moderately productive. Additionally, 20% felt not very productive or not productive at all, 10% felt neutral, and 2% were unsure.

top

# Satisfaction

“Overall, thinking of your role as a member of the Wikimedia Developer Community in the past year, how satisfied are you with the overall Software Development Life Cycle?”

Almost two thirds (65%) of respondents were satisfied (similar to 66% last year). Additionally, 14% were neutral, 15% were unsatisfied, and 6% were unsure.

top

# Perception of Wikimedia's developer community

“How much do you agree with the following statements?

The Wikimedia developer community is welcoming
The Wikimedia developer community is diverse
The Wikimedia developer community is dedicated
The Wikimedia developer community is collaborative."

More than two thirds of respondents agreed that the community is dedicated (84%), collaborative (77%), and welcoming (71%), with percentages similar to last year. Approximately two thirds respondents agreed that the community is diverse (66%), up from 56% last year.

top

# Building volunteer connections

“How do you build connections with (other) volunteer developers in the Wikimedia developer community?”

Of the 166 who responded, 11 said they do not interact with volunteers. Of the 155 who indicated that they do interact with volunteers, they said the following are the top ways they build connections:

58% said "Working on a shared project"
57% said "In-person events (like hackathons, meetings, etc)"
38% said "Requests for support from fellow developers"
37% said "Requests for support from the Wikimedia community"
34% said "Online spaces (Zulip, mailing lists, Telegram, etc)"

top

# Most important

“In your opinion, the most important thing the Wikimedia Foundation could do to improve the Wikimedia developer experience over the next year is...…”

64 respondents answered this question. Multiple themes emerged from the responsnes:

Onboarding, mentorship and learning

Comments focused primarily on the need to “invest more in junior developers” through mentorship, scholarships, and sharing clear opportunities for initial contributions.

Make a plan for a developer life cycle instead of a software life cycle. How to onboard, welcome, give and take tasks to/from newbees, and specially how to [retain them and help them] so that one day he/she could able to solve the things that community needs because that's the whole point

(...) I think there are plenty of software developers out there looking for new and interesting projects, who love Wikipedia, but aren't aware of the huge ecosystem of tools and projects that they could contribute to. Especially if they don't want to write PHP! https://developer.wikimedia.org/ is a great start, but it should have a contact form front and center where potential contributors could be paired with volunteer mentors.

Supporting the developer community

Comments focused on three main areas:

1. The need to listen to the developer community, especially when it comes to prioritizing the projects they deem important

Centralize all the existing wishlists for new features or apps so developers can vote on the items they care about and potentially organize themselves to bring those ideas to life

Listen to the community (eg. via Community Wishlist).

2. The request to help strengthen the developer community, through regular social events, knowledge sharing and creating one place for devs to connect

Strengthen the Wikimedia developer ecosystem as a whole, since it currently feels scattered and many people work alone. Holding weekly or monthly social events where developers can share what they’re working on could help, even if it’s something as simple as a forum post. And if we don’t already have a dedicated forum platform for community members to interact socially, creating one might be a necessary first step.

3. The need to better share with the developer community about future plans, especially changes and product iterations

Communicate future plans (for probable changes, for the next planned project...)

In-Person Events, including hackathons

There appeared to be some consensus in the comments around the need for more in-person events and the need to hold those in-person events in a wider variety of locations around the world.

Organize more developer events (around the world)

There was also the need expressed that these events should focus on onboarding newcomers

Take the opportunity of the next hackathons to onboard as many newcomer devs as possible and improve the maintenability of existing tools.

Finally, there was one comment that expressed strong dislike of the new hackathon model, tied to WMF priorities and requesting a return to community-owned and Chapter-organized hackathons

Code review

Comments on code review generally focused on the need for a clearer process, ownership and possibly shorter review timelines.

Please make a process for volunteers to follow to get their patches reviewed.

There were also a series of comments requesting that WMF staff be required to undertake code review as part of their job requirements, either within a specific period of time or that specific staff be assigned to code review.

Require WMF employees to, when requested for review on Gerrit, either review code or state that they are declining to do so. Radio silence is not really acceptable.

Documentation

Comments on documentation generally fall within two broad categories:

1. The need for more documentation

Just continue to make things clearer in the documentation and easier to discover help/examples. Tools like Code Search are amazing and the reality is that we just need more document-a-thons and curation of all the existing documentation (and deprecation of stuff that's no longer useful etc.)

2. The need for more centralized documentation that is easy to find, especially when it comes to API documentation.

Please for the love of god create a centralized space for APIs and their documentations. (...) I really want to create things that draw contributors and users into the wiktionary space but the API is an arcane mess and there is no instruction manual.

Maintenance, modernization and specific tools

Responses generally fell into three broad categories:

1. Issues with the product lifecycle and things languishing

One of the most frustrating things is to spend hours or days debugging some hard to diagnose issue, only to find that it was reported 20 years ago (...)

2. Requests for better, more efficient and modern tooling

Streamline and modernize the tooling and processes

3. Specifics on different tools or workflows (Gerrit, CI, test environments, etc)