📖 Developer Satisfaction 2026 Report

☁️ Cloud Services

tl;dr

Which tools – Like last year, the majority of respondents are working on web apps and bots.
↑ Tools for Wikidata – Like last year, the majority of respondents build tools for Wikipedia. There was a continued trend of an increased number of respondents' tools built to work with Wikidata (from 63% to 65%).
Toolforge – Like last year, the majority of Toolforge users use Python 3; the majority use Git; and the majority have almost all of their Toolforge work done locally (as opposed to remotely on Toolforge).
Cloud VPS – Like last year, the most common reason given for using Cloud VPS was hosting one or more tools or other public services. Compared to last year, more respondents said they use Cloud VPS for running a backing service (44%, up from 35% last year)
↑ Documentation – Compared to last year, there was an increase in the percentages of respondents who said Cloud Services documentation is easy to find, up to date, and clear.

# Cloud services use

“Do you use Toolforge or Cloud VPS to run or develop tools?”

Of the 201 who responded to the question, the majority (54%) said they use Toolforge (either exclusively or with Cloud VPS) and 27% said they use Cloud VPS (either exclusively or with Toolforge).

More specifically,

35% said they use Toolforge exclusively
37% said they use neither Toolforge nor Cloud VPS
19% said they use both Toolforge and Cloud VPS
8% said they use Cloud VPS exclusively

top

# Previous cloud services use

Questions for respondents who don't currently use Toolforge or Cloud VPS
“Have you previously used Toolforge and/or Cloud VPS?”

For respondents who said they do not use Toolforge or Cloud VPS, we asked if they have ever used either of these platforms. Of the 66 who answered, more than half (53%) said they had never used either.

top

# Which tools

“What kind of tools do you work on?”

Respondents were able to select multiple tools. Of the 126 who responded, a majority (73%) said web apps, and half (50%) said bots.

top

# Which wikis

“Which Wikimedia projects are your tools built to work with?”

Respondents were able to select multiple answers (with the exception of "All wikis", which was exclusive). Of the 126 who responded, * 73% said they build tools for or including Wikipedia (40.5% Wikipedia + 32.5% all wikis)

65% said they build tools for or including Wikidata (32.5% Wikidata + 32.5% all wikis)
54.8% said they build tools for or including Wikimedia Commons (22.2% Commons + 32.5% all wikis
32.6% said they build tools for all Wikimedia projects

top

# How many tools developed

“How many tools have you developed on Toolforge or Cloud VPS?”

Of the 116 who responded, a majority (76%) said they have developed 1-5 tools.

top

# How many tools maintained

“How many tools do you actively maintain on Toolforge or Cloud VPS?”

Of the 117 who responded, a majority (79%) said they actively maintain 1-5 tools.

top

# Storage/caching

“What storage/caching services do you use when running your tools?”

Respondents could select more than one service.

Of the 126 who responded, while there was no majority response, the two most common responses were MySQL/Maria DB (37%) (down from 46% last year) and no storage/caching service (33%).

top

# Time spent on tool building

“Thinking about your work developing and maintaining tools on Toolforge or Cloud VPS over the past year, roughly what percentage of your time goes into building/improving your tools vs. making your tools work with Wikimedia Cloud Services infrastructure?”

Of the 106 who responded,

a majority (73%) said they spent 66-99% percent of that time "building or improving tools
a majority (73%) said they spent 1-30% of that time "making tools work with WMCS infrastructure"

“When building or improving your tools, which activities are the most time consuming?”

Based on the rankings of the 102 respondents who answered this question, "adding new features" was the top action ranked as most time consuming, followed by "fixing bugs".

“When making your tools work with Wikimedia Cloud Services infrastructure, which activities are the most time consuming?”

Based on the rankings of the 84 respondents who answered this question, "debugging infrastructure or performance issues" was the top action ranked as most time consuming.

☁️🔨 Cloud Services: Toolforge

# Toolforge tenure

“How many years have you used Toolforge?”

Of the 101 who responded,

37% said they have used Toolforge for 8 or more years (similar to last year)
18% said between 4 and 7 years (down from 32% last year)
45% said 3 years or fewer (up from 34% last year)

top

# Source control

“Which source control mechanism do you use to manage your tools’ source code?”

Respondents could select more than one response.

Of the 168 who responded, the majority said they use Git for managing their tools’ source code. Specifically, 68% said they use GitHub, and 44% said they use Wikimedia's GitLab.

top

# Programming languages

“Which programming languages do you use on Toolforge?”

Respondents could select more than one language.

Of the 109 who responded:

the majority (73%) said they use Python 3
44% said they use Javascript
42% said they use static HTML+CSS
36% said they use PHP (down from 42% last year)
14% said they use TypeScript
smaller percentages said they use other languages (e.g., Perl, Java, and Rust)

top

# Local development

“When you develop a tool, how much of your work developing code to run on Toolforge is done locally on your machine (as opposed to remotely on Toolforge)?”

Of the 99 who responded, more than two-thirds (70.7%) said almost all of the work is done locally (up from 66.4% last year).

top

# Challenges

“Which Toolforge challenges most limit or slow down your work? (Select up to 3)”

This question temporarily appeared incorrectly in the survey, and we had to discard the responses from that time period. Once the question was fixed, we received 30 responses to the question. Due to this methodological inconsistency, the results should not be compared with last years'.

Of the 30 who responded, the most common challenge selected was "documentation and communication gaps." The next most common challenges selected were "tool maintenance burden" and "limited tool monitoring and analytics".

“What is your biggest challenge when starting work on a new tool in Toolforge? (Select up to 2)”

Of the 109 who responded,

34% said finding documentation for specific use cases (up from 22% last year)
32% said understanding deployment requirements (up from 23% last year)
26% said initial platform access and environment setup (same as last year)

For respondents who answered this question, we asked "Would you like to share more details about the challenge(s) you selected?" This was an open-ended (free response) question. From the responses, multiple themes emerged.

Documentation & Onboarding Complexity (9 responses)

Some respondents have difficulty with finding documentation. There is some struggle around first deployment, job submission, interactive sessions, etc. Some participants want to know the preferred “golden path” from GitLab to deployment, understanding preferred workflows versus possible workflows.

"Finding the right documentation for my specific use case is hard. In the end, I failed to find it, so I had to dig through someone else’s source code that was similar to my use case and modify it to fit my needs."

Observability, Logging & Monitoring Gaps (6 responses)

Observability is a recurring theme. Respondents mentioned challenges with logs, lack of metrics tracking, absence of alerting systems (e.g., notifications when jobs are stuck), and the lack of tooling comparable to Elastic or Sentry.

Tool maintainers of growing or critical tools especially feel the absence of a robust multi-tenant monitoring stack.

"Observability is complex, no Elastic to perform query in the logs, and no Sentry to receive notification on new bug occurences"

Positive Developer Experience & Growth Potential (2 responses)

Some respondents find Toolforge pleasant and empowering. One respondent highlighted how AI tools have accelerated their development velocity and enabled onboarding of others. Another noted that local development + GitLab + deployment utilities worked well overall, with challenges being manageable rather than structural.

"They are not really big challenges. I've found it pleasantly easy to develop locally using VSCode, push to Wikimedia's GitLab and use the various toolforge utilities to update the webservice."

top

# Limitations

“Is there anything you have tried but not been able to do in Toolforge?”

For the first time, we asked respondents if they've been unsuccessful attempting to do something in Toolforge. This was an open-ended (free response) question. From the responses, multiple themes emerged.

Deployment & CI/CD Friction (9 responses)

A number of users want smoother, more standardized deployment workflows — particularly around GitLab CI integration, push-to-deploy, webservice deployment, buildpacks, Docker image control, and modern tooling support (e.g., uv, nix). The feedback suggests that while deployment is possible, it often requires workarounds or deeper system knowledge than expected. Users are essentially looking for parity with modern DevOps experiences they’re familiar with elsewhere.

"I tried to setup a fully automated deployment from wmf gitlab to a toolforge web app… I wish I could just use the same workflow."

Observability, Logging & Monitoring Needs

Users express desire for more observability — including logging, monitoring, alerts, custom metrics (e.g., StatsD), and more predictable service behavior (e.g., services not respawning or getting stuck)

"Have tool observability (monitoring/alerts with logs)"

Positive Experiences & Self-Resolution (3 responses)

Several users report eventually resolving their challenges, often with community or staff support. This suggests that while some workflows may initially be unclear, the ecosystem and support structures are effective once users engage with them. This is a strong foundation to build on.

"I found my way out… recently I figured a way out and deployed a tool I created."

Resource, Performance & Infrastructure Constraints (9 responses)

Respondents highlight infrastructure restrictions: quota restrictions, lack of GPUs, database constraints (analytical/OLAP workloads), inability to host certain services (Postgres, triple stores).

"Certain analytical queries are very hard or impossible to run on Wikireplica databases… columnar databases would have far superior efficiency for analytical queries."

☁️🦄 Cloud Services: Cloud VPS

# Cloud VPS tenure

“About how many years have you used Cloud VPS?”

Of the 48 who responded,

40% said they have used Cloud VPS for 8 or more years
29% said between 4 and 7 years
31% said 3 years or fewer

top

# Cloud VPS use purpose

“What do you use Cloud VPS for?”

Respondents could select more than one use case.

Of the 54 who responded,

The majority (69%) said they use it for "hosting one or more tools or other public services"
44% said "running a backing service (database, cache, etc.)" (up from 35% last year)
40% said "testing and experimenting with software" (down from 50% last year)
16% said "running one or more MediaWiki instances" (down from 28% last year)

top

# Cloud VPS NFS use

“Do you use NFS to access the same files across different servers?”

Of the 48 who responded, the majority (58%) said no, 13% said yes, and 29% were unsure.

top

# Cloud VPS improvement

“If the Wikimedia Foundation could improve one thing in Cloud VPS in the next year, what should that be?”

This was an open-ended (free response) question. From the responses, multiple themes emerged.

Platform Features & Operational Tooling (7 responses)

Some respondents want secrets management, observability, backups, automated alerts, and smoother OS upgrades.

"Add managed observability, like a Sentry-equivalent service"

Infrastructure Capacity & Instance Flexibility (4 responses)

There is interest in expanding resource options — including larger RAM instances, high-storage/low-CPU configurations, and increased capacity for CI or new tools.

"Larger instances (128 or 256 GB) would be nice."

Advanced Data & Hosting Capabilities (3 responses)

Some feedback centers on enabling more advanced data use cases — triple stores, cross-database virtualization, and better object-store hosting/proxy capabilities.

"Support moderatly sized triple stores with Fuseki or QLever for subsets of Wikidata or custom datasets"

☁️✍️ Cloud Services: Documentation and Services

# Documentation experience

Agreement with: Cloud Services documentation is “easy to find”, “up to date”, and “clear.”

Of those who responded, more than half (65%) agreed or strongly agreed that it is easy to find. Additionally, 54% agreed or strongly agreed that it is up to date, and 50% agreed or strongly agreed that it is clear.

top

# Services experience

Agreement with: “Services provided by Wikimedia Cloud Services, including Toolforge and Cloud VPS, have high uptime.”

Of those who responded, the majority (86%) strongly agreed or agreed that the services have high uptime.

Agreement with:“It is easy to have code run on Toolforge or Cloud VPS.”

Of those who responded, about two thirds (66%) strongly agreed or agreed that it is easy to have code run.

Agreement with: “I feel that I am supported by the Cloud Services team when I contact them via cloud@lists.wikimedia.org, the #wikimedia-cloud IRC channel, or Phabricator.”

Of those who responded, three-quarters (71%) strongly agreed or agreed that they feel supported by the Cloud Services team when they contact them.

Agreement with: “I receive useful information via the “cloud-announce” and/or “cloud” mailing lists.”

Of those who responded, the majority (68%) strongly agreed or agreed that they receive useful information via the mailing lists.

top

# Why WMCS?

“Wikimedia Cloud Services is one of many providers of cloud computing resources. What made you decide to choose Wikimedia Cloud Services as opposed to other options.”

Respondents could select more than one answer.

Of the 126 who responded,

73% said access to Wikimedia-specific resources, including wiki replicas
61% said cost
53% said ease of collaborating with other Wikimedians
44% said philosophical or ideological reasons
33% said ease of use
32% said privacy and security considerations
6% said something else

☁️👪 Cloud Services: Community and Support

# Discussion channels

“When discussing WMCS issues with other users, what channels do you use?”

Respondents could select more than one channel.

Of the 126 respondents who answered, the majority (51%) said they use Phabricator, 37% said IRC, 28% said on-wiki Talk pages, and 25% said Telegram (which was a new response option this year).

“When seeking help from WMCS staff, which support channels do you use.”

Respondents could select more than one channel.

Of the 126 respondents who answered the majority (56%) said they use Phabricator, 49% said IRC, and 23% said Telegram.

top

# Feedback

“If you have any other comments about WMCS, please share them with us here.”

Strong Appreciation and Gratitude for WMCS (10 responses)

A significant number of respondents expressed sincere appreciation for WMCS, describing it as fantastic, critical, supportive, and valuable to the open knowledge ecosystem.

"Generally, WMCS is a fantastic resource, and I think it's a huge boon to the open knowledge movement. Thanks for doing what you do!"

Communication & Support Channels (3 responses)

A few respondents suggested modernizing or expanding communication channels. While IRC support was praised by one respondent, others expressed interest in alternatives such as Matrix or Slack integrations to reduce friction.

"Please move away from IRC as a primary mode of communication, or at least provide an easier way to communicate about issues over slack."

Capacity, Visibility & Ecosystem Strength (4 responses)

Some comments touched on scaling capacity (e.g., hiring more engineers), improving visibility of WMCS services, and reinforcing the broader ecosystem. At the same time, users emphasized that WMCS is critical infrastructure for projects like openZIM/Kiwix and valued community tools such as PAWS.

"Keep going on! The VPS service is a critical part of our infrastructure at openZIM/Kiwix"