The FAIR project was announced onstage immediately following this presentation. AspireCloud is the current reference implementation of FAIR, an independent federated repository. It’s still early days, so with more nodes coming online soon and more plans on our roadmap, keep watching for updates!

The post AspirePress Demo first appeared on AspirePress.

An immediate question for followers of AspirePress is what this means for us in light of the public release announcement we made at the same time. So glad you asked — we’ll respond by sharing a bit of background.

The AspirePress project to develop a distributed repository for WordPress was founded by Sarah Savage in the fall of 2024. Once work had begun, the AspirePress community began to grow and more contributors were added to the team. At that stage, Sarah shared A vision of a distributed package repository in WordPress, outlining where the project was headed. On the heels of an open letter from 20 leaders in the WordPress community In December of 2024, Joost de Valk posted about leadership in WordPress and called for Fair And Independent Repositories, or FAIR. At the same time, Karim Marucchi published his post about a new WordPress roadmap. Both posts included “Breaking the Status Quo”, and Joost stated that 2025 would begin with discussions about next steps. (Several other supportive posts appeared soon after; including my own take on breaking the status quo.)

As of Spring 2025, discussions were quietly underway among a slowly-growing group of individuals, many of whom did not feel free to speak about their involvement publicly. At that time, many people had been banned from contributing, blocked from logging into wordpress.org, and publicly maligned. The group fully respected this, and continues to maintain their confidentiality. Sarah Savage (AspirePress founder) and I (AspirePress project manager) were engaged in discussion with the group, which came to be known as FAIR. A handful of other contributors to AspirePress have also participated in creating FAIR.

For assistance governance structure, the group organized itself under the Linux Foundation. As stated by Carrie Dils (FAIR TSC Co-Chair) during the FAIR announcement this past weekend, rather than reinvent the wheel, when it came time to start coding the FAIR project began with the code written by the AspirePress team.

While respecting the confidentiality of many contributors, the work of AspirePress alongside the FAIR project has been close, cooperative, and collaborative. In many ways, AspirePress has become a part of FAIR — we share a common vision toward federated independent repositories, and are proud to be working on it together. At its launch, the FAIR plugin redirects API calls for wordpress.org for updates to plugins, themes, and WordPress core to our API server running AspireCloud via Fastly CDN, and serves package downloads from this alternative source — the same as the AspireUpdate plugin does.

Although the package update mechanism is the same, there are a few differences between the initial release versions of AspireUpdate plugin and the FAIR plugin. First, AspireUpdate includes a dropdown setting allowing the user to select between updating from wordpress.org or from the AspireCloud production server, and offers a text field where the url for any compatible mirror can be entered. The FAIR plugin also supports other compatible mirrors, but the configuration is done by setting a constant in wp-config.php. Second, the FAIR plugin includes some additional options for independence from wordpress.org, such as replacements for browse-happy, serve-happy, Gravatar, and dashboard RSS feeds. These were all well down the priority list for AspirePress, but because we had already tackled package updates, the FAIR team were able to tackle these additional features.

In short, we are where we are by working together.

What’s next? We’ll keep working together. In speaking about FAIR and the WordPress community, Karim Marucchi has used the phrase “groups of groups”, and we believe that’s the future for a healthy WordPress community and ecosystem. Like FAIR and AspirePress, organizations like the WP Community Collective, AltCtrlOrg, and the re-minted Post Status are all like-minded groups with different mandates. Each contributes to the whole, not as rivals, but as groups within a shared community, cooperating and collaborating in the stewardship of the Commons that we share.

This is the best and healthiest future we can imagine for the WordPress community and its ecosystem.

The post Aspiring to FAIR Package Management first appeared on AspirePress.

Today we are pleased to announce the release of AspireUpdate 1.0, a WordPress plugin that enables site owners to update their software from the repository of their choice — whether that’s wordpress.org, our own AspirePress mirror, or one of others to appear soon. AspireUpdate can be downloaded from our GitHub repository and easily uploaded to a WordPress site to enable user-selectable download repository sources, including wordpress.org. (WordPress.com sites are not compatible at this time.) AspireUpdate provides access to the full slate of plugins and themes as they exist today at wordpress.org.

We are also announcing today a preview release of AspireExplorer, which allows users to browse and search the software repository in much the same way as they would on wordpress.org to find extensions for WordPress that can be downloaded and installed manually. The plugin browser can be accessed now at aspirepress.org to locate available plugins from our repository. AspireExplorer is in active development, and will soon offer improved search capabilities as well as the ability to browse themes as well as plugins.

Powering Alternate Repositories

The repository we host is powered by two packages, which are available from our Github repository for anyone wanting to set up their own mirror.

AspireSync runs as a server-side application to gather packages and update them as new releases become available. This application can run from anywhere, and is made to gather and sync packages over time without overusing resources at either end of the file exchange.

AspireCloud is the server software for responding to API calls from AspireUpdate or from other compatible plugins which redirect API calls using the same format as wordpress.org. AspireCloud receives the API request and responds with the information necessary to download its copy of the requested package. This API also responds to queries from AspireExplorer, which runs independently of AspireCloud.

Without infrastructure, the software we’ve written would lie dormant, little more than a proof-of-concept that doesn’t actually expand the available options for updating software from an independent repository. For this reason, we felt it was important to stand up infrastructure, and Fastly has partnered with us to sponsor CDN services from its 97 points of presence globally. Together with Automattic’s 27 points of presence, this means that WordPress updates are now being served from 124 datacenters around the world. With more to come online, the supply chain for WordPress software updates is becoming more robust and more resilient as it decentralizes.

Why Climb this Mountain?

We’re calling this initial release our “Everest” milestone. We believe it represents the start of a sea change in how WordPress packages will be managed and updated in the future, securing the software supply chain for the future of WordPress by moving it past a single-vendor solution to help ensure its longevity, its independence, and its security.

As there has been some confusion in the past, it’s important to say that this is not is a fork of WordPress. What this suite of packages distributes is the same software as is available from wordpress.org, and does not usurp, replace, or modify the WordPress software, its plugins, or its themes. The effort we’ve undertaken here is presented as a gift to the WordPress community, for their benefit. As it distributes the same software from an alternate source, it is intended not to compete with, but to augment the software distribution channel. The same is true for the packages we distribute in this fashion.

Next Steps

Translations will be coming soon, as well as other features that diversify features available on wordpress.org with additional options for the WordPress community. Give us a star and a follow on GitHub, engage with us on social media and follow here for updates — and above all, you’re welcome to get involved and contribute to the ongoing effort.

All Due Credit

The AspirePress Slack channels currently have over 180 members, all of whom are considered part of the community supporting the work. Of those, it’s appropriate to single out a few who have made significant contributions to realizing this goal.

• Sarah Savage — project founder
• Brent Toderash — team lead, project management
• Chuck Adams — team lead (Sync, Cloud)
• Andy Fragen — team lead
• Namith Jawahar — team lead (Update, Explorer)
• Matt Leach — team lead
• Austin Meakin — project management team
• Alex Sirota — team lead
• Veerle Verbert — project management team

We also offer special thanks to Colin Stewart, Kyle Keevil, AltCtrl, Fastly, all of the donors and sponsors who helped with expenses, and everyone in the Slack channels, where a kind word or a cheerful emoji is a contribution that helps keep the code flowing.

Update: you can also browse and install packages from AspireCloud by downloading the FAIR plugin.

The post “Everest” (1.0 is not just a number.) first appeared on AspirePress.

Telemetry is a vital part of decision-making for developers. We see how important understanding who is using the software and understanding their decision-making. But we also believe strongly that this kind of data collection needs to be both disclosed up front, and done freely by the people making the disclousre.

AspirePress will be implementing features that both limit our collection of unnecessary telemetry as well as request permission from individual site owners. We will introduce three options: an option to share data just as before, an option to provide the data but require that it be anonymized, and an option to disable data sharing altogether.

As we approach our launch date, we will also revise our privacy policy and appropriate documents to reflect the fact that we collect certain data and outline the ways that we use it. Weaponizing the data against any individual or group will not be considered an authorized use of the information.

The world deserves privacy, and the freedom that WordPress offers both obligates and requires its maintainers to respect the need for anonymity and privacy. Using the data collected, without permission, in the way it’s being used currently, is not acceptable.

The post Telemetry in WordPress first appeared on AspirePress.

When I saw the news that lawyers for Matt Mullenweg and Automattic were filing a brief that stated plainly, “wordpress.org is not WordPress”, I was shocked. Like many of the members of the community, I had relied on the .org as the de facto place to find WordPress and the WordPress community. And I was angry and scared at the notion that it was all a sham.

As I reflected on the twenty years I’ve spent in software development, and PHP and WordPress specifically, I came to a realization: I realized that it was not our fault we didn’t understand. In fact, I firmly believe that the deception was intentional.

As I came to this realization, I faced a decision-point. I could be angry about it, sure. Or, I could do something about it. I decided to do something, which was make this commitment to you.

For those of you who are hurt and angry and feel betrayed, I want you to know this: if WordPress.org will not be there for you, then AspirePress will be. You’re welcome here.

I will also make the following promise. You can screenshot this, share this, post this, remind me of this, email me this, and hold me accountable to this promise. Here goes:

I promise that for as long as AspirePress exists, regardless of legal structure or governance model or leadership or finance, AspirePress will be a community, focused solely on the good of users of the software we distribute and support, regardless of name, and regardless of who they are, where they come from, or any characteristic besides their desire to be in community.

This isn’t some kumbaya lets-all-get-along promise, either. This is the foundation of our governance model and the basis of our existence. Community is messy, challenging, difficult and important. We are obligated – no, required – to work together to form healthy community and provide a space where everyone can participate with dignity and respect for all.

WordPress democratized publishing: if you have a blog, you can publish it anywhere that will host you and say anything within the bounds of the laws you are subject to obey. Your opinion doesn’t need to be right or politically correct or even widely accepted to be published. The voice of the minority can be heard.

I want to make clear that for participation in the AspirePress project we endorse a code of conduct. And while we may vehemently disagree with some uses of the tools we produce, as long as those uses don’t break the law the license we issued is the determining factor for the right to use them. But that is what community requires: a willingness to live with those you disagree with, sometimes strongly.

That’s why AspirePress doesn’t block people for expressing their bona fide (respectful) opinions, and that’s why we listen to feedback from our users and community before we act. And even when we have to make hard or controversial decisions, we will work to do so within the guidelines of our vision and values, with the best interests of the community, not ourselves, in mind.

We are not perfect, and we will never be. But we will do our best to build a welcoming, inclusive community where everyone is welcome, and everyone can live in harmony, even if we aren’t on the same page in every way. At the end of the day, community needs to be about more than dollars and cents, or profit and loss, or investors and open source advocates. We welcome equally the Silver Lake investors as we do those who advocate that the GPL should make everything free and no one should make money from free code.

The bottom line is this: if WordPress.org will not be for the community, then AspirePress will be your home.

Welcome home.

The post If WordPress.org is not for the community, then we will be first appeared on AspirePress.

AspirePress exists entirely to solve this problem.

Our focus is on building a sustainable, distributed, federated model of managing and distributing packages for WordPress.

The advantage of distributed over centralized

The internet is known for having core systems be distributed. In fact, the internet itself is a distributed system: any person can connect to the internet from anywhere and interact with essentially any other machine online today – if they know where to find it. How do they find those machines? That’s what DNS is for – another distributed system – which provides an easy translation layer for example.com to go to 93.184.215.14.

Distributed systems aren’t without their drawbacks: for example, eventual rather than instant consistency (think DNS). But they do offer one thing that we currently do not have in the WordPress ecosystem: an inability to be controlled by any single party.

While the internet surely has authorities for determining good actors from bad, it essentially allows all peers equal access to all other peers. The institution of authorities on the internet to determine good actors from bad was an add-on, not a design feature: the concept of spam filtering and mitigation of DDoS attacks come as later components, not originally built-in ones.

Distributed systems are designed to prevent any one person or system taking them over. If I drop the DNS records that I manage from the internet, the only thing that happens is that my (and anyone else’s records that I control) are lost from circulation. Anyone pointing those domains at new nameservers and replacing the missing records would effectively recreate the access that was lost.

Distributed repositories can work similarly. In a truly distributed, federated model there is no “single point of failure” or “authority”. Instead, each peer is responsible for determining the validity, acceptability, and authority of each peering node, and assigning levels of trust to the information they serve. Some peers may choose not to federate with other peers. Some peers may accept packages from peers while rejecting others.

How the ACF/SCF fiasco could have been avoided

Until now, the only source of truth for automatic updates to WordPress is through the WordPress.org API, which is hard-coded into every installation of WordPress out there. It’s not even configurable in the wp-admin.php file. And with plugins leaving the WordPress repository, and being blocked/closed by WordPress.org, we now have many sources of truth, and a fractured community ecosystem.

In that model, it was simple for the ACF/SCF fiasco to unfold: replacing ACF with SCF on the same slug meant that anyone asking for updates got SCF without any kind of checksum or signature being checked. It was implicitly trusted, and accepted by WordPress.

Contrast this with a distributed system where one system goes rogue and replaces a plugin with another plugin, perhaps containing malware (SCF did not contain malware). Upon discovery of the malfeasance, the distributed network could choose to defederate with the offending repository, as well as refuse to serve that content. For a short time this would create a system where some users are at risk and others are protected (a drawback of eventual consistency). But it would eventually resolve in favor of the authentic, genuine software being distributed to everybody.

In short, the kind of supply chain attack executed recently by WordPress.org would be difficult to execute. And there are ways of making it even more difficult to execute, as well.

Code signing and authenticity checking

One way of ensuring that users get what they’re asking for is to check – against a known good source – for authenticity.

For example, a plugin author would create a package of their asset, and then push it to the package repository of their choice with a signature that signs a hash of the file with a private key. The public key, known to the repository, can verify the authenticity of the signature.

Upon reciept, the repository would compare what it received with the hash, and if they match, validate the signature to ensure the hash is valid. It would then apply its own private key signature to authenticate that it verified the information, and distribute the entire chain to all the other mirrors for distribution.

With this system we have some advantages. First, we know that the plugin author authored the commit. Since a private key is kept secret by the plugin author, even if someone hard forked the repository they can’t authenticate the releases they produce (ACF couldn’t have been forked under this model).

Next, because the repository attests to the authenticity of the plugin, and the repository is trusted by other peers, that information can be trusted as authentic without rerunning the checks. If a repository is particularly paranoid, it can rerun the checks and even issue its own certificate of authenticity.

This isn’t new technology either: JWTs work similarly. The first two portions of a JWT are signed by either a symetric or asymetric key. We’re proposing an asymetric key to ensure no one party holds “all the keys.”

The best part is that this process can be entirely automated. For example, a private key stored as a secret in GitHub can be used to sign the package, and then GitHub publishes the public keys of users for authentication purposes. The repository can simply check a list of trusted public keys to verify that the right key was used for signing. If the private key is compromised, that key can be dropped from the public keys, and the mirror will no longer consider it a valid authentication source.

This process also significantly improves the current model, which offers no verification that a package was provided by the author other than the SVN account of the user being authenticated. This very system allowed the ACF/SCF crisis to occur.

Trust amongst peers

In order for a distributed model to work, there has to be trust between peers. Therefore, we am proposing a model that offers three levels of trust. Peers also always have the option of Zero Trust, meaning they do not trust a peer at all and ignore anything the peer provides.

1. Basic Trust. This level of trust requires verification of a peer through another more trusted peer. For example, if a Basic Trust peer were to publish a new plugin, the peer implementing Basic Trust would either have to check authenticity of the package for itself, OR trust another peer to have completed the same checks, befoere trusting that the peer is authentic. This is useful for new peers that the community does not know well.
2. Implicit Trust With implicit trust, a peer trusts that another peer does the verification required and generally is reliable as a source of truth. However, it still prefers the next level of trust over this peer. So, if another source provides information that conflicts with a peer at the Implicit Trust level, the higher level source controls and overwrites the information from the lower level peer.
3. Source of Truth Trust When a peer is a Source of Truth, it is considered an authority for all things related to packages and assets. For example, that might be AspireCloud itself, or another trusted partner that disseminates large numbers of plugin and theme updates from trusted sources. There should be few Source of Truth Trust levels set, and the goal of a distriuted system is to have >1 to ensure that the system is not vulnerable to a single source of truth, but at this level, the trust implied is absolute.

A peer must have at least one other peer that is an Implicit Trust peer in order to recieve updates. All peers generally start at the Basic Trust level, and must manually be elevated to the Source of Truth Trust. However, when creating a mirror, it would be assumed that mirrors would have the option to assert one or two Soruce of Truth Trusts to pull their data from.

Conclusion

This is a vision, not a technical architecture for the future. It outlines the goals of a distributed, federated system that implicitly and explicitly trusts other peers, and offers a vision of a world where the ACF/SCF fiasco would be impossible. AspirePress is looking for individuals interested in working on specification for this vision, and the development of a standard for mirrors to pass information to one another, not just in the WordPress space but in any space where code repositories are distributed over HTTP(S).

The post A vision of a distributed package repository in WordPress first appeared on AspirePress.

This is an unfortunate abuse of authority and only continues to highlight the significant vulnerability that the community faces with WordPress.org being the single-point-of-failure for WordPress asset distribution.

Announcing first-party plugin distribution

Today, I’m announcing that we are prepared to accept applications for first-party package distribution in the AspireCloud mirror that we are currently building.

Theme and plugin developers will be able to apply for us to mirror their work as a first-party plugin, rather than having it updated from WordPress.org’s repository. Any plugin or theme developer who elects to be hosted first-party will need to supply us with new releases of their product, and we will update our database accordingly. We will no longer trust the WordPress.org repository as canonical for that theme or plugin.

Additional security safeguards

Additionally, we will be instituting safeguards to ensure that plugins that are closed or removed from WordPress.org’s repository are reviewed by a team member prior to us distributing the version to end users. This process is in development, but is necessary to ensure the safety and security of mirror users.

If you are a plugin or theme developer, you can apply for us to host your theme or plugin first-party here. We’ll need to verify your identity and ownership of the component before we can host it first-party, and methodologies are being developed. However, we can assure you that we will be happy to serve as a distribution point for your plugin or theme.

One more thing…

When AspireCloud launches, we will be launching with Advanced Custom Fields restored to its original, pre-takeover condition in our repository. We will continue to encourage collaboration with WP Engine and ACF to receive updates of the plugin, and we encourage users who depend on ACF to switch to AspireCloud when it becomes generally available to ensure they receive genuine software.

This action does not imply partnership with WP Engine, and does not mean that WP Engine endorses or supports the AspirePress project. Rather, it is a reflection that a) we can authenticate plugin ownership of ACF through the publicly available ACF channels and b) we are aware of the latest versions of ACF that were present in the repository prior to the takeover.

We encourage someone from WP Engine and ACF to reach out to us directly to learn more about first-party support on AspireCloud.

The post Publishing and distributing first-party packages for WordPress first appeared on AspirePress.

Forking

Forking is an act that says “thank you for what you’ve done; we’re going to go a different direction, likely immediately introducing breaking changes.” It’s an act that says what the previous folks were doing wasn’t working for you and you want to build something different, with a different vision, but based off the original concept. ClassicPress removing Gutenberg is a classic fork.

Forking is hard. WordPress is big, complex, and requires contributions from a wide number of people with a wide variety of skills to make functional. Not to mention the community is well-established around plugins, APIs, etc., for better or for worse.

Branching

Branching is the act of taking the current project and saying “we like what you’re doing, we’re going to put some polish of our own on it and call it something different.” I imagine it to include maintaining backwards compatibility with the parent project as much as is feasible, and describing it as a flavor or branch of the original. For example, Ubuntu is a branch of Debian, and while it maintains its own APIs and distinctive nature, it is, at its core, Debian.

To branch a project might be simpler. It would get a new name, a new logo, and a new look and feel but the APIs and current plugin architecture would stay mostly the same. Backwards-incompatible changes would be limited and forward-looking changes would be made to add functionality without breaking what already exists.

Other options

I imagine that flavoring a project (rebranding it as something different but essentially keeping it the same) would be also on the table. It’s the least destructive, and is basically a `git pull wp-origin main` followed by `s/WordPress/NewBrand/g` and pushing a release.

Of course, this is one perspective in a multitude. What are your thoughts?

The post Forking, branching and flavoring WordPress first appeared on AspirePress.

The tool is currently released as version 1.0-alpha-4.

AspireSync is designed to be run as a fully containerized tool, meaning that you can download the container and go. It’s backed by a Postgres database, and it stores all the metadata about the plugins and themes.

Features include:

• Download themes and plugins from the WordPress .org repository and upload them to local or S3 storage.
• Store metadata and other information about every version of every plugin/theme.
• Download the latest version of a plugin/theme, or all versions, or a subset.
• Handles closed and not found plugins/themes.
• Updates only those items that are updated in SVN, so you don’t have to pull the entire dataset.
• Supports Postgres out of the box for metadata retention (SQLite coming eventually)
• Runs downloads in parallel tasks (24 max) to allow for speedy download of assets.

The tool remains under active development, as does AspireCloud and AspireUpdate, which are companion tools for the distributed mirror we are constructing.

We encourage you to try and test the tool, and report any bugs on our GitHub Issues tracker.

The post AspirePress releases AspireSync for downloading themes and plugins from the WordPress repository first appeared on AspirePress.

The problem

In the last few weeks, we’ve seen that every WordPress instance in the world has a single point of failure. That single point of failure creates a risk for security, reliability, and credibility for the entire ecosystem. Further, that single point of failure could be leveraged to distribute malware or damage the community as a whole.

This post is about laying out a vision for the future of WordPress, the future of distributing plugin and theme updates, and how we can improve the community as a whole.

To address this problem, we have to move in two major steps:

First, we have to get out of disaster mode. We need to assuage the fears of the community by providing a reliable, functional solution that they can use in days, not months.

Second, we should offer a truly distributed, federated and comprehensive update solution that benefits everybody in the community.

Getting out of disaster mode

The first goal of the project is to offer a viable solution to the centralized control of the .org website. Here is a short punchlist of my goals, and where we are in the process:

This list is a rough cut of the tasks that need to be completed to effectively launch a mirror of the .org site. It will be updated as we make progress, and also be updated on GitHub.

The thing is that for this to be a true community project, we need your help. we need people to commit to GitHub, write documentation, test and offer their feedback and critiques. This is a full-court press for the community, and it takes a lot of people to make an open source project work.

The long-term goals of the project are to effectively ensure three key elements of the mirror system:

• Fully Distributed – anyone can set up a mirror and host plugins;
• Federated – you can join a network of mirrors and have access to their plugins (and yours to them)
• Funded – there be an opportunity for commercial benefit for those who host mirrors, as well as providing open source contributions to the community.

What this looks like in full is for discussion and planning of Phase 2 and beyond, but right now we need to focus on getting something on the table that the community has contributed to and supports so that we can move forward.

None of these concepts is particularly ground-breaking. For example, DNS is distributed and federated. A good mirror should work like DNS: publication of a plugin to one mirror should result in propagation of that plugin to other mirrors that support it and wish to make it available.

This project cannot be done by me alone. While we think we have laid a good foundation, we need experts at devops, coding, marketing, social media, documentation and more to come together to help drive this to the finish line.

If you want to contribute, please contact me, file issues on GitHub, or submit pull requests. Your feedback and involvement is more than welcome.

The post A vision for AspirePress and a community-run .org mirror first appeared on AspirePress.