A WordPress Hard Fork Could Be Made Painless for Plugin/Theme Developers – Semantically Secure
Previously, I wrote about how code-signing and threshold signatures could allow the WordPress community (whether they continue to support WordPress or decide to hard-fork the project onto something else) to mitigate the risk of another Mullenweg tantrum (which are in surplus this season) leading to another successful violation of community trust.
One reason why the community might not want to do a hard-fork is that it could be disruptive to the entire WordPress Developer job title. Namely, it would make plugin and theme development and maintenance painful to support both WordPress and whatever the fork is named.
Because WordPress (and, by extension, its plugin and theme ecosystem) is copyleft licensed, the Forkers could easily write some infrastructure involving Rector (or a more specialized fork of Rector, heh) to plumb plugin/theme updates into the forked ecosystem.
That is to say, because of the existing work into helping open source software support wider ranges of PHP versions, I believe the “supporting WordPress and ForkPress” is not a significant technical challenge.
