Introducing Troy: Freedom of Code Distribution for WordPress

This project was drafted on October 14th, 2024. Its first line of code was written on January 12th, 2025. Today, 37,347 lines later, I'm excited to share it with you.

Free for All

I've built many plugins people depend on. Open source. Free to use, free to modify, free to share. People chose my work. They trust me to maintain it. But between me and you stands a platform that can sever that connection at any moment, for any reason, with no accountability.

This can't be right. We need a better way.

The Problems

WordPress has a wonderful ecosystem. Millions of sites, thousands of plugins, a vibrant community. But plugin distribution has always been centralized. One directory. One set of guidelines. One approval process. One organization deciding who gets to ship code.

This works—until money gets involved.

Commercial interests have crept into every corner. Plugin authors lie, break the law, buy out competitors, and even deactivate rival plugins on customer websites—often without consequence. Some of the people enforcing policies have commercial interests that compete with the plugins they review. Commercial plugins get featured. Independent developers don't even get basic analytics.

The plugin ranking system makes it worse. It's based on opaque installation counts that snowball early entrants, enabling buyouts purely for install base—after which an entirely different plugin takes its place. The plugin index is hidden from the public.

For independent developers, the experience is bleak. No recommendations, no "rising star" highlights, no suggestions, no shoutouts. Policy enforcement is arbitrary, plugins are blocked without explanation, communication is poor, and accountability is nonexistent—right down to plugin support emails being sent anonymously. Raise an issue publicly, and you get blocked.

I've watched good developers caught in situations they didn't create—and I've been one of them. Why should we rely on a platform that doesn't have our best interests at heart?

A Different Path

Troy is built on a simple idea: developers should control their own distribution.

With Troy, you host your own plugin repository. You decide when updates ship. You own the relationship with your users. There's no approval process, no waiting period, no uncertainty about whether your plugin will still be available next month.

Troy Server turns any WordPress installation into a plugin repository. Upload a ZIP, connect GitHub, and your plugins are ready to distribute.

Troy Client connects WordPress sites to Troy servers. Install it once, and every plugin with a Troy header receives updates automatically—right in the WordPress dashboard, just like plugins from WordPress.org.

Troy is an opt-in sideloading system. Developers choose to use it by adding a Troy: header to their plugins. It doesn't replace WordPress.org or affect plugins that don't opt in—it's an additional distribution channel for developers who want independence.

Why MIT?

WordPress is GPL. Most of its ecosystem follows that license. I chose differently.

The GPL has served open source well, but it comes with obligations. Code under GPL must stay GPL. Derivatives inherit the license. For some projects, that's fine. For others, it constrains decisions in ways that don't always serve users.

MIT is simpler. Use the code. Modify it. Ship it in commercial products. Build something new. The only requirement is keeping the copyright notice.

I believe open source works best when it's freely given—not because a license demands it, but because sharing makes the ecosystem stronger. Troy is a gift. Do what you will with it.

Privacy, Totally Impersonal

Troy collects statistics—download counts, version distribution, installed locales, WP versions, and PHP versions. This helps developers understand their user base. But it does so thoughtfully:

No domain names. Troy doesn't track where plugins are installed.
Rotating IDs. Every week, each site generates a new anonymous identifier.
HTTPS only. All communication is encrypted.
Data filtering. Troy Client only sends each plugin's statistics to its respective repository.

You'll never see a dashboard with your users' domains. That information doesn't exist because Troy doesn't collect it.

The Technical Bits

Briefly, Troy consists of three components:

For site owners, Troy Client is a standard WordPress plugin. Install it, activate it, done. Any plugin with a Troy: header in its main file will receive updates automatically. That's it. It doesn't require configuration, accounts, or fuss. It does not involve itself with any other plugins unless their plugin authors explicitly opt in. It never gets in the way of WordPress Core updates.

For developers, Troy Server needs a bit more horsepower. WordPress 6.8+, PHP 8.4+, MySQL 8.0.19+. Modern requirements for a modern system. Upload plugins manually, connect GitHub repositories for automatic releases, or use the REST API for custom integrations.

For network admins, Troy Client Daemon ensures that Troy Client is installed and active to prevent data leakage to WordPress.org. To protect plugin author privacy, it will block any outgoing requests to WordPress.org if Troy Client is not active.

I also prepared a few code snippets:

Troy Client Hide hides Troy Client from the plugins list.
Troy Client Channel sets the update channel (beta/tag) for Troy Client.
Troy Embed embeds Troy Client with your plugin automatically—without the Installer.

Who's Behind This?

I'm Sybre Waaijer, director of CyberWire B.V.. I have contributed over 30,000 hours to the WordPress ecosystem. You might know me from The SEO Framework—a WordPress SEO plugin I've maintained since 2014, known for its performance and clean security record. It's used by NVIDIA, Kaspersky, the U.S. Social Security Administration, Qualys, Vivaldi, Santos, the Linux Foundation, Ars Technica, and MariaDB, among many others.

In 2017, without warning, one of my plugins was removed from WordPress.org over a policy dispute. I complied to keep my business online and quietly built my own update server that closely mimics WordPress.org's responses. A year later, I jumped ship. Now it's serving 20,000+ sites, with server load barely above idle.

That experience taught me what developers actually need. Troy fixes every issue I encountered: It can update deactivated plugins, it can serve updates across multisite networks, and it has a proper user interface built in Gutenberg! I estimate it can serve a million sites on hosting costs under $50/month.

Troy is the infrastructure I wish had existed years ago. Now, it finally does.

What's Next

This is version 1.4.1184. A stable foundation, ready to trot. I have plans:

Unbridled theme support (hay—enough puns, barn it!)
On-demand translation package distribution
GitLab and Bitbucket integration
Data visualization using graphs

But first, I want Troy to work reliably for the developers who need it. If you've ever worried about your update pipeline, if you've ever wanted independence from centralized directories—give Troy a try.

Getting Started

Site owners: Install Troy Client. That's it.

Developers: Set up Troy Server. Add your plugins. Distribute them with Troy Client bundled in via Packages, or use Troy Embed to add it retroactively. You decide where your users get updates.

Everyone else: Read the introduction. Ask questions on GitHub Discussions. Explore the code—it's all open source.

A Final Thought

The WordPress ecosystem is stronger when developers have choices. When distribution is decentralized. When the tools for sharing code are as free as the code itself.

Troy isn't a replacement for WordPress.org—it's an addition. Another option. A backup. A parallel path for developers who want independence.

Welcome to the new normal.

Troy is available now. MIT licensed. Free forever.