There’s something about the version number 1.0 that feels significant. It’s just a version number, a label, a tag in a git repository. But it carries weight. It says: this is ready. This is stable. This is something you can rely on.
For years, I avoided it.
Mozart has been running in production environments since 2017. It’s been downloaded over 3 million times. It powers the dependency management of some of the largest WordPress plugins in the ecosystem. By any reasonable measure, it’s been “ready” for a long time. But somehow, tagging it as 1.0 felt like a step I wasn’t ready to take.
Looking back, I think the code was ready long before I was. Today, I’m finally releasing Mozart 1.0.
Why Mozart exists
The WordPress ecosystem has a dependency problem. When multiple plugins use the same third-party library but in different versions, things break. Sometimes silently, sometimes spectacularly. It’s the kind of bug that’s almost impossible to reproduce and even harder to fix.
Mozart solves this by wrapping your dependencies in your own namespace. It’s not glamorous work — nobody’s winning awards for clever autoloader configuration. But it prevents a whole category of bugs that would otherwise make plugin developers’ lives miserable.
When I started building Mozart, tools like PHP-Scoper didn’t exist yet. And even now, Mozart remains deliberately focused on simplicity. It’s specifically tailored for WordPress projects, easy to implement, and opinionated in ways that make sense for this ecosystem. I’ve resisted the temptation to chase features that other tools offer.
Mozart does one thing, and it does it well.
That philosophy has held up. Five years later, I’m more convinced than ever that this focus was the right choice.
Five years of stability
Since the last release in February 2020, a lot has changed. PHP 8.0 came and went. PHP 8.1 through 8.5 followed. WordPress itself has evolved significantly. The broader PHP ecosystem has matured.
Through all of that, Mozart kept running. No showstopping bugs. No critical failures. Just quiet, reliable operation in the build pipelines of plugins serving millions of users.
That stability is exactly why this release is called 1.0. It’s not a major feature release. It’s an acknowledgment of what Mozart has been for years: production-ready software that you can depend on.
Where Mozart runs today
Mozart has found its way into some impressive projects. WooCommerce uses it and not just in their core plugin, but across their extensions ecosystem including WooCommerce PayPal Payments for example. For a plugin that powers a significant portion of online commerce, that’s not a responsibility I take lightly. There’s a certain irony there too: I spent two years as one of WooCommerce’s early developers, and now a project I maintain in my spare time is part of their infrastructure.
But WooCommerce isn’t alone. WP Media uses Mozart in WP Rocket, one of the most popular caching plugins available. Easy Digital Downloads, another major player in the WordPress e-commerce space, relies on it as well.
Perhaps most interesting is NextCloud. They’ve adopted Mozart in several of their products, which shows that the approach works beyond WordPress too. The problem Mozart solves, dependency conflicts in PHP applications distributed as packages, isn’t unique to WordPress. It just happens to be where the pain is felt most acutely.
What’s new in 1.0
While the core functionality remains the same, this release modernises Mozart for current PHP development:
The minimum PHP version is now 8.1. PHP 8.0 reached end of life in 2023, and it was time to move on. Mozart is tested against PHP 8.1 through 8.5.
The codebase has been significantly refactored. There’s a new configuration system with dedicated Config classes, a proper exception hierarchy for clearer error handling, and expanded test coverage with both unit and integration tests. Static analysis tools (PHPStan, PHPMD, PHPCS) are now part of the CI/CD pipeline.
For those using the Docker image, there’s now multi-architecture support covering linux/amd64, linux/arm64, and even linux/arm/v7 for Raspberry Pi. Images are published to both Docker Hub and GitHub Container Registry.
These aren’t flashy changes. They’re the kind of improvements that make a project maintainable for the long term.
The reality of open source
I won’t pretend the past five years have been easy. Maintaining an open source project that generates essentially no income, while working a regular job and having a life outside of code, is genuinely hard. Time spent on Mozart is time taken from somewhere else, be it paid projects, family or rest. That trade-off is constant.
I’ve written before about the broader challenges facing open source maintainers. Mozart is a small example of a much larger pattern: software that provides enormous value to others, maintained by someone in their spare time.
But moments like this, finally tagging 1.0, seeing where the project has ended up, knowing it’s running reliably in so many places… Moment like this make it worthwhile.
Thank you
Mozart wouldn’t be where it is without the people who contributed code, reported bugs, asked questions, and simply used it in their projects. Open source is a collaborative effort, even when most of the work happens in isolation.
To everyone who has been part of Mozart’s journey over the past years: thank you. This release is as much yours as it is mine. Here’s to the next chapter.