Forking, branching and flavoring WordPress
There’s been a lot of discussion in the community – on Twitter, Reddit, in the Slack community for AspirePress – about forking the WordPress project and taking it away from the Powers That Be(tm) and making it truly community oriented. I wanted to share some thoughts that have come up around this in our community with the broader WordPress community.
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?
There’s ClassicPress already.
Yes, ClassicPress is mentioned here as a classic fork of a project. AspirePress doesn’t see the need for a fork at this moment, and we’re not pursuing forking the project at this time.
I’m super stoked about these proposals to fix the biggest WordPress issue. It’s absolutely critical to tackle the full reliance on wordpress.org, which was already an issue before the recent drama, but now it’s obvious to anyone.
IMO, the massive WP ecosystem of devs, plugins/themes, hosting providers, etc., is its strongest asset. That’s why I think it’s crucial not to break any compatibility with WP right now. My short-term vision would be a simple effort to ditch wp.org asap. Even if it’s not easy, this seems like the least complicated part (thanks for the ongoing efforts on this btw!). Then we can see how the community embraces the option, how it’s funded, and so on.
Depending on how that goes, my mid-term ideal solution would be to be able to add/remove repositories for each individual WordPress site (for themes, plugins, blocks, core, etc.), with nothing hardcoded so. Having multiple repo sources, transparently from the UI perspective, meaning the same single unified plugin/theme browsing UIs (like F-Droid does for Android), would make sense and have tons of benefits. For example, hosting providers could offer exclusive content repos, plugin/theme devs could use it to distribute premium versions using a common and robust update/distribution system with core functions, designers could offer pattern repositories, etc.
This would also allow for new plugin repositories with different rules, like no freemium plugins, or only plugins compatible with newer PHP or WP versions, or not updated too long ago (unlike wordpress.org!). From my experience, this would help non-tech-savvy users who struggle to spot good and bad or abandoned plugins for instance.
It should even be possible to add the main wp.org repos if needed for any reason.
In the end, this would bring way more diversity to the ecosystem, making the new WP more versatile and stronger. Of course, keeping a default main repository would probably still be necessary, and that’s cool.
I think this should be possible without breaking any core compatibility with the original WordPress. Only the plugin/theme/core/etc. repositories sources and the update/install process would be revamped.
Also, adding a better filter options (with rules like mentioned above) to the UI would be awesome.
Finally, depending on the success of these efforts, the community, the needs, etc., a full fork of WP in the long term would still be possible, based on previous efforts. But IMO, this should only happen with stable and durable foundations.
Thank you for forking WordPress! I added a link to AspirePress here: https://wordpress.org/news/2024/10/spoon/
Matt, I think the post made clear that a fork is a serious decision and one that requires serious thought.
We love WordPress and we’d like to see it continue.
We have reached out in DM on X. We will meet you any time, anywhere (Zoom?) to hear your side and see what way forward exists. All we want is a healthy, thriving WordPress ecosystem.