Google Open Source Blog

Maintainer support is becoming a practical project risk

The key point from Google’s post is not that open source needs a new slogan. It is that maintainers are asking for more predictable support, especially financial support, while the mechanics of paying individuals remain complicated across different countries and legal setups.

Google notes that fiscal hosts and programs such as Open Collective, GitHub Sponsors, and the LFX Mentorship Program can simplify parts of this process. However, the post is careful not to present them as a complete fix for sustainability and predictability.

For WordPress professionals, we can translate that into a very familiar dashboard problem. Look at the right sidebar of your own stack: Core, Gutenberg blocks, build tools, Composer packages, npm scripts, payment gateways, security plugins, image optimization, backup tooling. Each item has a maintainer surface. If one of those maintainers burns out, changes direction, or loses funding, your client site may not break today — but your update path becomes less certain.

So the practical step is straightforward. Firstly, list the open source components your agency or store depends on most. Then mark which ones are business-critical: checkout, authentication, caching, forms, search, migrations, block editor workflows. Finally, check whether the project has a clear way to receive support, sponsorship, or contribution. We do not need to turn every site owner into a foundation. We do need to stop treating maintenance as invisible.

Etiquette matters as much as money

Google’s post also highlights something quieter but just as important: respect and etiquette between creators, contributors, users, and corporations. The discussion asked whether maintainers are clearly communicating their preferences, and whether companies are actively respecting them.

That lands directly in the WordPress ecosystem. We often see the same pattern in plugin support threads, issue queues, and GitHub repositories: a bug report arrives with urgency, but without reproduction steps; a feature request is framed as an obligation; a compatibility issue is pushed onto a maintainer who may not be paid by the business depending on the plugin.

Here is the healthier workflow I recommend we use with our teams.

First, before opening an issue, reproduce it on a clean install when possible. Use a default theme, disable unrelated plugins, and write down the exact toggle, panel, block, or setting where the problem appears. Secondly, describe the expected result and the actual result. A maintainer should not have to guess which screen you are looking at. Thirdly, check the project’s contribution or support preferences. If the maintainer asks for discussions in one place and bug reports in another, follow that structure.

This is not just politeness. It lowers the cost of maintenance. A clear report is a contribution. A rushed complaint is extra work.

What WordPress teams should watch next

Google says it cannot make promises, but wants to keep learning and has created a form to collect further thoughts, including interest in another open meeting. The company also says it plans to share learnings back with the community.

There is another useful signal in the same source material: Google describes sponsoring Alejandro “Alex” Colomar’s work on the Linux Kernel man-pages project, framing documentation as critical infrastructure rather than glamorous side work. That is a strong reminder for WordPress builders. Documentation, release notes, migration guides, and boring compatibility notes are part of the product surface. They are not decoration.

Consequently, the next time we evaluate a plugin or block library, we should not only ask, “Does this feature work?” We should also ask: is the documentation maintained, are support expectations visible, is the issue tracker usable, and does the project show signs of long-term care?

The open source news cycle often focuses on big AI models, large vendors, and dramatic security headlines. This update is more practical. It asks us to configure our own habits: support the projects we rely on, communicate with maintainers clearly, and treat documentation and maintenance as real infrastructure. That is how we build WordPress sites that are faster, safer, and easier to keep healthy after launch.