[HN Gopher] The FAIR Package Manager: Decentralized WordPress in...
___________________________________________________________________
The FAIR Package Manager: Decentralized WordPress infrastructure
Related: https://github.com/fairpm,
https://www.linuxfoundation.org/press/linux-foundation-annou....
Author : twapi
Score : 204 points
Date : 2025-06-07 04:45 UTC (1 days ago)
(HTM) web link (joost.blog)
(TXT) w3m dump (joost.blog)
| tobinfekkes wrote:
| This is very exciting to see momentum going in this trajectory.
|
| Kudos to all involved behind the scenes to even get to this
| point. Ideas are cheap, execution is hard, especially across so
| many disciplines, so major props for the coordination and
| collaboration.
| samename wrote:
| this is awesome, congrats on the launch
| mastazi wrote:
| Linux Foundation's announcement here
| https://www.linuxfoundation.org/press/linux-foundation-annou...
|
| EDIT - HN Discussion about it here
| https://news.ycombinator.com/item?id=44205865
| dang wrote:
| Thanks! I've added that link to the top text as well.
| snthpy wrote:
| Very cool!
|
| I have spent the last few months on and off thinking about
| creating something like this for some projects of mine. I've
| been looking into ATProto [0], IPFS [1], Radicle [2], and Iroh
| [3]. I was tending towards Iroh lately but I also like ATProto
| so going to check out this FAIR [4] protocol because I'm all
| for having widely adopted common protocols.
|
| 0: https://atproto.com/
|
| 1: https://www.ipfs.tech/
|
| 2: https://radicle.xyz/
|
| 3: https://github.com/n0-computer/iroh
|
| 4: https://github.com/fairpm/fair-protocol
| supriyo-biswas wrote:
| After looking at their repos, especially [1], I think it'd
| probably have been better if they made a soft-fork of Wordpress
| with its own infrastructure instead of the current setup where
| they try to hijack core wordpress with alternative
| implementations. This approach is doomed to fail, as the core
| Wordpress developers would be forced by executive directives to
| break said mechanisms.
|
| Also, the jkpress post by Matt Mullenwegg linked in TFA has to be
| one of the most unprofessional and caustic things I've ever seen
| someone write, and reflects poorly on his character.
|
| [1] https://github.com/fairpm/fair-plugin
| lawik wrote:
| Seems smart to start by contributing a more openly governed
| path. If Matt starts to fight, sabotage and shut that down it
| gives the important yeah-we-did-try style cover to the
| reasonable next step of forking.
|
| By being unreasonably reasonable in this way I would expect
| they bring the most members of the community with them if a
| fork has to happen.
|
| They also leave a door open for Matt to leave this effort alone
| or even welcome it. A potential road to recovering trust over
| time.
| luckylion wrote:
| I don't think it's likely that core will actively break these
| things. If they removed the ability to filter HTTP requests,
| they'd break a lot of plugins and likely a lot of sites, which
| would become a nightmare, because their main selling point is
| "one click install, never worry about it again" -- they
| primarily compete with Wix, Jimdo etc, not with other CMS.
|
| If they changed their backend to disallow this implementation
| from accessing it, they'd also break it for older versions of
| WP (which feels like the majority) and cut off the upgrade-path
| for those sites.
|
| WP's heavy use of filters & actions are what makes it bearable
| to work with for developers, and without the plugin ecosystem,
| Wordpress would be no serious competitor to anything.
|
| I don't know if this will work out, the code looks worrying -
| they support all the way down to php 7.2, but OOP and composer
| don't require php8. On the other hand, so do most WP plugins,
| and core does too.
| rmccue wrote:
| The contributors who worked on this project (including myself
| - I'm one of the TSC co-chairs) are very familiar with the
| internals of WordPress - we were the ones who wrote them :)
|
| Blocking the way that FAIR works would break the way that
| premium plugins work, which would break a huge amount of the
| ecosystem, so we think it's unlikely - WordPress core would
| need to be patched.
| nchmy wrote:
| > the jkpress post by Matt Mullenwegg linked in TFA has to be
| one of the most unprofessional and caustic things I've ever
| seen someone write, and reflects poorly on his character.
|
| Evidently you haven't been paying much attention to Matt or
| WordPress. Matt Mullenweg is - and seemingly always has been -
| simply a caustic, manipulative, dishonest, petty, etc...
| person. He was generally good at hiding it, but it always
| peeked through on an annual basis. But it's simply been the
| norm for the past 9 months - sometimes on a daily basis.
|
| Another gold nugget here (has archived links)
| https://news.ycombinator.com/item?id=41839864
|
| But the best reading is the initial lawsuit from wp engine.
| It's just overflowing with screenshots of self-incriminating
| toxicity.
|
| Goodtime line of events here
| https://gist.github.com/adrienne/aea9dd7ca19c8985157d9c42f7f...
| pessimizer wrote:
| I suspect, without knowing anything, that WPEngine's lawsuit
| will put wordpress in a position where they can't do anything
| to suppress alternative implementations of their
| infrastructure.
|
| I'm suspicious of the Linux Foundation, and am pretty much on
| the side of wordpress in the big dispute, but I'd switch to a
| distributed solution in a second if it worked 75% as well. The
| difference in management risk between a) dealing with a single
| CEO of a single organization who behaves that way in public,
| and b) a distributed Linux Foundation sponsored apt-style
| plugin repository, is huge.
|
| If a lot of people are like me, that means wordpress is doomed.
| People don't want to fork because they don't want to pay for
| wordpress development. Taking away revenue from wordpress is
| going to stagnate it (even more, and it's a dinosaur anyway.)
| The parasites will have killed the host.
| luckylion wrote:
| > People don't want to fork because they don't want to pay
| for wordpress development.
|
| People don't fork because they wouldn't stay compatible with
| core, and thus not keep compatibility with most of the
| plugins if they do anything meaningful to improve the code
| (and if you don't, why would you fork?)
|
| core and plugins are handcuffed together: plugins are nothing
| without core, but core is just a horrible mess of spaghetti
| code with no value without plugins. yet core can't really be
| improved without abandoning a bunch of plugins (on which they
| depend for being viable as a CMS).
|
| So far, core seems to err on the side of plugin authors
| (unless they're deemed competitors to .com), i.e. rug-pulls
| and replacing the plugin with malware-adjacent "new
| functionality" is totally fine for .org's plugin masters.
| nchmy wrote:
| > am pretty much on the side of wordpress in the big dispute
|
| This essentially discredits you completely... A judge already
| granted an injunction against Matt to revert all his
| nonsense, which only really happens when the case is
| overwhelmingly strong against them.
|
| > The parasites will have killed the host.
|
| The problem is that the "host" IS the parasite in this case.
| roelj wrote:
| Somewhat unfortunate naming as it may be confusing with the FAIR
| Principles (Findable, Accessible, Interoperable, Reusable), for
| which software package managers are emerging as well.
| lawik wrote:
| All names are unfortunate. There are too many things.
| hajimuz wrote:
| Connection fail.
| sensahin wrote:
| "What we are doing is adding a new distribution layer and putting
| our own governance on top of it."
| daitangio wrote:
| Sad to say, but for the meantime Wordpress is a dead end at least
| for my personal needs.
|
| I wrote about it in my blog [1]. It is an amazing tool with an
| unstable company behind.
|
| Time will show us if the FAIR Package Manager will be able to
| improve the overall ecosystem status.
|
| [1]: https://gioorgi.com/2024/liberta-come-aria/
| KronisLV wrote:
| Migrating to SSG is definitely one of the options!
|
| I do wonder what other CMSes people do enjoy, though. My blog
| runs on Grav, a flat file CMS that still allows me to easily
| keep the content in Git, while also having some dynamic content
| and search (and optionally an admin UI): https://getgrav.org/
| aquariusDue wrote:
| I feel like Grav was waaay ahead of its time. For the past
| year I've been chipping away at something inspired by it but
| written in Rust with KDL as the format for storing pages (and
| page data).
|
| Hopefully I'll be able to release it by the end of the
| summer.
|
| Grav was what convinced me that ultimately a CMS doesn't have
| to be married to a database, at least for what could be
| conventionally considered small websites.
| homarp wrote:
| about KDL https://news.ycombinator.com/item?id=28510031 kdl
| stands for 'cuddly' document language
| wingmanjd wrote:
| I wrote a Wordpress to Grav exporter [1], which brings over
| most content (posts, pages, users, groups, attachments, some
| site-metadata, etc). I also wrote a Drupal 7 one, but I
| haven't touched that in a long while.
|
| After exporting from either CMS, it's pretty close to drag/
| drop onto the grav instance and everything should "Just Work
| (tm)".
|
| - [1] https://github.com/jgonyea/wp2grav_exporter - [2]
| https://www.drupal.org/project/grav_export/
| JimDabell wrote:
| Related:
|
| WordPress.org bans WP Engine -
| https://news.ycombinator.com/item?id=41655967 - Sep 2024 (490
| comments)
|
| If WordPress is to survive, Matt Mullenweg must be removed -
| https://news.ycombinator.com/item?id=41676653 - Sep 2024 (245
| comments)
|
| WP Engine is not WordPress -
| https://news.ycombinator.com/item?id=41613628 - Sep 2024 - (165
| comments)
|
| Filed: WP Engine Inc. v Automattic Inc. and Matthew Charles
| Mullenweg [pdf] - https://news.ycombinator.com/item?id=41726197 -
| Oct 2024 - (659 comments)
|
| The ACF plugin on the WordPress directory has been taken over by
| WordPress.org - https://news.ycombinator.com/item?id=41821400 -
| Oct 2024 (224 comments)
|
| So long WordPress - https://news.ycombinator.com/item?id=41974637
| - Oct 2024 (211 comments)
|
| WordPress.org's latest move involves taking control of a WP
| Engine plugin - https://news.ycombinator.com/item?id=41826082 -
| Oct 2024 (211 comments)
|
| Is Matt Mullenweg defending WordPress or sabotaging it? -
| https://news.ycombinator.com/item?id=41872628 - Oct 2024 - (143
| comments)
|
| Mullenweg threatens corporate takeover of WP Engine -
| https://news.ycombinator.com/item?id=41712617 - Oct 2024 - (120
| comments)
|
| Matt Mullenweg cries foul and threatens me with legal action -
| https://news.ycombinator.com/item?id=41727888 - Oct 2024 - (43
| comments)
|
| Matt Mullenweg temporarily shuts down some Wordpress.org
| functions - https://news.ycombinator.com/item?id=42469708 - Dec
| 2024 - (122 comments)
|
| WordPress Is in Trouble -
| https://news.ycombinator.com/item?id=42687121 - Jan 2025 (439
| comments)
|
| Matt Mullenweg deactivates WordPress accounts of contributors
| planning a fork - https://news.ycombinator.com/item?id=42667766 -
| Jan 2025 (236 comments)
|
| Mullenweg Shuts Down WordPress Sustainability Team, Igniting
| Backlash - https://news.ycombinator.com/item?id=42672675 - Jan
| 2025 - (172 comments)
|
| Matt Mullenweg, Automattic's CEO, Seems Bound and Determined to
| Wreck WordPress - https://news.ycombinator.com/item?id=42773311 -
| Jan 2025 - (57 comments)
| nchmy wrote:
| Doing the lord's work!
|
| Here's another timeline
| https://gist.github.com/adrienne/aea9dd7ca19c8985157d9c42f7f...
| Flimm wrote:
| This is the official website for FAIR: http://fair.pm/ . It
| currently redirects to https://github.com/fairpm . Here's a
| description:
|
| > The FAIR Package Manager is a decentralized alternative to the
| central WordPress.org plugin and theme ecosystem, designed to
| return control to WordPress hosts and developers. It operates as
| a drop-in WordPress plugin, seamlessly replacing existing
| centralized services with a federated, open-source
| infrastructure.
|
| > There are two core pillars of the FAIR system:
|
| > - API Replacement: It replaces communication with WordPress.org
| APIs (such as update checks and event feeds) using local or FAIR-
| governed alternatives. Some features--like browser version checks
| --are handled entirely within the plugin using embedded logic
| (e.g., browserslist).
|
| > - Decentralized Package Management: FAIR introduces a new
| package distribution model for themes and plugins. It supports
| opt-in packages that use the FAIR protocol and enables hosts to
| configure their own mirrors for plugin/theme data using
| AspirePress or their own domains. While stable plugins currently
| use mirrors of WordPress.org, future versions will fully support
| FAIR-native packages.
|
| You can try the FAIR plugin at this link:
| https://github.com/fairpm/fair-plugin/releases
| jacooper wrote:
| It's unfortunate that WordPress.org has to be replaced, it
| requiring plugins to be gplv2 licensed has forced the ecosystem
| be almost fully open source.
|
| Doubt this is going to be the case if FAIR takes over.
| homarp wrote:
| FAIR plugin is gplv2. They will continue to use the core of
| Wordpress, also gplv2.
|
| Can you explain how this would allow any other license than
| gplv2 for the plugins?
| sjs382 wrote:
| I think what the parent is saying is:
|
| WordPress.org demands that plugins they host are GPL.
|
| FAIR is a protocol that allows access to additional
| repositories. These other repositories may not have this same
| demand.
| homarp wrote:
| and what I am saying is: wordpress core is gplv2. A plugin
| is therefore under gplv2 per the definition of the gplv2 of
| derivative work.
|
| https://wordpress.org/support/topic/are-wordpress-plugins-
| au...
|
| https://wordpress.stackexchange.com/questions/406337/does-
| wo...
| Tomte wrote:
| No, it must be according to the core's license, but if
| the plugin author doesn't license it as GPLv2, it isn't.
|
| The plugin's author breaches the core's license, but that
| doesn't make the plugin GPLv2 by itself.
| luckylion wrote:
| Has that ever actually been tested though? Ultimately, to
| work, a plugin only needs to call a handful of WP
| functions, if at all -- hard to argue it's a derivative
| work, just because it can be used _with_ WP. Is grep a
| derivative work of bash because you can use bash to
| execute grep?
|
| Something like the following would be a valid plugin, but
| it doesn't directly or indirectly use _any_ code by WP.
| It's only executed by WP. I don't believe that it would
| be considered a derivative work of WP, because that file
| would happily run without WP as well.
|
| <?php /* Plugin Name: My Plugin Version: 0.1 */
|
| if($_SERVER["REQUEST_URI"] === "/my-url") { // do
| something interesting, use curl to fetch some content }
| sjs382 wrote:
| I've always been confused by this assertion, too. It's
| often the justification for privacy of paid plugins, too.
|
| In addition to your example, I can imagine a very
| defensible scenario where a plugin is "standalone" with a
| shim layer to connect to WordPress (and maybe other
| CMSes, too).
| luckylion wrote:
| Yeah, the infectious nature can hardly infect a third
| party software, even if the shim itself would be
| infected.
|
| The one case I just remembered where it was remotely
| challenged was Thesis [1], but Automattic chose to throw
| money into bullying the challenger rather than going
| after the alleged license violation.
|
| [1] https://wptavern.com/mullenweg-and-pearson-square-
| off-on-pat...
| bravetraveler wrote:
| Hey, look at that: a foundation that offers development time
| without demanding it back
| kassner wrote:
| Any TLDR on how actually use it, from the plugin developer
| perspective? I was immediately put off by having to run a WP
| plugin just to obtain a "did", and having to run WP to host the
| repository is also far from ideal.
|
| I wish this was an evolution from bedrock, or that it used some
| composer infrastructure (which works with just static files).
| rmccue wrote:
| The protocol repository [1] has more documentation on how to
| implement your own repository and we expect there'll be many
| implementations of it over time - for launch, our proof-of-
| concept repo is built on WP since it integrates with Git
| Updater which is already widely used. (We'll try and publish to
| Packagist now that it's public too!)
|
| [1]: https://github.com/fairpm/fair-protocol
| 0xbadcafebee wrote:
| I currently work for a multi-million dollar company that is
| completely dependent on this lumbering geriatric. A design from
| the turn of the century, that limits how we can configure it,
| modify it, test it, version it, deploy it, roll it back. A
| rotting piece of fruit with so many bugs and holes we need to
| constantly look for a newly-announced bug so we can rush to patch
| it so the rot doesn't spread to our business.
|
| Even the managed hosters have barely adopted modern practices. Do
| you know it's actually easy to treat the database as an
| ephemeral, versioned object? Nobody I've talked to does. You just
| back up the logical database, and rename the database name in the
| backup to a unique string (including a version, or datestamp,
| etc). Now you have versioned, uniquely-named database, so you can
| do immutable infrastructure. Load this backup into a database
| server (even the "live" database server, as it won't conflict
| with the old db name). Start a new WordPress container and pass
| env vars pointing to the new database name. Now you can pair a
| snapshot of the code with a snapshot of the database. Upgrade or
| downgrade in seconds, with confidence. (that is, after you've
| done all the manual work to upgrade, test, and fix in an
| ephemeral environment)
|
| This simple method makes operations more robust and predictable,
| makes dev & testing easier, and is used by.... nobody, as far as
| I'm aware. All the managed hosters I've seen just give you an
| admin portal, and a "dev", "test", and "live" instance. No
| ephemeral environments. No snapshots or diffs of configs or
| databases. Plugin upgrades are largely left to the user, because
| there's no way to know other than by manual testing if any change
| breaks everything. There doesn't even seem to be an open source
| project for containerizing & deploying it immutably (or there
| wasn't wasn't when I created one 4 years ago). Because everyone's
| mind is stuck in this box from 2003. Of the bad designs and
| cloistered practices that were passe 10 years ago.
|
| Organisms can't evolve if they live forever. In order for CMS to
| evolve, WordPress needs to die. Please just let it die.
| vntok wrote:
| > Do you know it's actually easy to treat the database as an
| ephemeral, versioned object? Nobody I've talked to does. You
| just back up the logical database, and rename the database name
| in the backup to a unique string (including a version, or
| datestamp, etc). Now you have versioned, uniquely-named
| database, so you can do immutable infrastructure. Load this
| backup into a database server (even the "live" database server,
| as it won't conflict with the old db name). Start a new
| WordPress container and pass env vars pointing to the new
| database name. Now you can pair a snapshot of the code with a
| snapshot of the database. Upgrade or downgrade in seconds, with
| confidence. (that is, after you've done all the manual work to
| upgrade, test, and fix in an ephemeral environment)
|
| There is a good reason why nobody does that: it makes very
| little sense on any sort of web platform more complex than a
| static website. Indeed, as the WordPress database schema is
| quite normalized especially around metadata and taxonomies,
| there are many INSERT/UPDATE queries running/queued basically
| all the time on a busy website.
|
| For example, 1ms after you've snapshot your DB and "versioned
| it" (renamed it rather) locally, it's already obsolete because
| 2 users have just logged in and their last logon timestamp got
| updated as metadata stored in the _usermeta table. Switch to
| the versioned snapshot in the meantime and you lost that
| information. This is Bad(r).
|
| Even then, say 30s after making the snapshot and before you've
| "deployed" the code upgrade, a cronjob has triggered an image
| optimizer plugin, inserting various optimized copies of the
| image objects in the main _posts table (it also updated the
| metadata of all those images). Rollback the DB because your
| deployment caused a crash and you've lost images. Again, a big
| no-no.
|
| The simplest WordPress-safe upgrade path in case of code
| changes impacting the database is for the code to support
| rollup/rolldown migration queries on the database: rename a
| meta_key when upgrading and rename it back when downgrading.
|
| Use WP abstraction functions to interact with the database, and
| generally treat the database itself as a blind storage medium,
| to be restored only in extreme cases.
| nchmy wrote:
| Are there any particular plugins you could point me to that
| implement a db rolldown functionality?
| 0xbadcafebee wrote:
| > The simplest WordPress-safe upgrade path
|
| This is my point. The problem is WordPress's design. Despite
| that, there are better practices... but the best practice
| would be not to use a design from 20 years ago.
| runningmike wrote:
| " a federated and independent repository of trusted plugins and
| themes for web hosts, commercial plugin and tool developers in
| the WordPress ecosystem and end users." The goal of this project
| is blurred. They want to move away from WP and allow commercial
| plug-ins. Both are very hard to accomplish. Forking WP and build
| a community was more transparant and easier to do. Since WP is
| gpl , there has for a long time been too many violations by
| commercial plugin sellers. You can sell your plug-in, but you
| must apply with the gpl terms. So release all the code. Too many
| plugins are malware, since code is loaded by an api call. No
| trust, no security and no privacy.
| ollybee wrote:
| Are they going to be able to maintain the volunteer team who
| curate the catalogue? Currently a fair amount of work goes into
| making sure that hosted packages do not contain malware and also
| add value in that they don't replicate the features of existing
| packages. This workload has increased recently with AI generated
| submissions.
| rmccue wrote:
| TSC co-chair here - one of my fellow co-chairs (Mika Epstein,
| aka Ipstenu) was the lead of the plugin review team for a long
| time, and several other contributors have been very involved in
| the plugin review processes, so definitely something that's top
| of mind for us.
| Coala15 wrote:
| Kill wordpress please, it's abomination
___________________________________________________________________
(page generated 2025-06-08 23:01 UTC)