tl;dr: this is a roadmap of what a fork could look like of the WordPress project. While it's not an active call to create a fork, it's intended to provide guidance for governing, designing and distributing a fork.

The events of the past week and a half have laid bare the problems with "benevolent dictators" in open-source projects.

Open-source projects like WordPress are extremely important, both to the people who work on them and the people who depend on them for their livelihoods. When more than 40% of the web runs on a particular platform, it's important that the governance of the platform run well.

Unfortunately, WordPress leadership has demonstrated a disregard for its community and future that damages the project overall.

This is not to say that the project cannot be saved. It may be something that can be fixed. But if the community were to elect to create a fork, here is a roadmap for getting started. 

Community

Any good open-source project requires a dedicated community of contributors, supporters and users. Any successful fork of the WordPress project will inevitably fracture the community that exists. Care must be taken to limit that fracture as much as possible.

The fork should be warm and welcoming to the community members who make the switch. It should work to make them as comfortable with the new community as possible, through both technical and governance that respects their choice.

Outlining a clear technical roadmap, governance structure, funding source and feature plan is a good first step. Embracing existing plugin authors, and making the fork as compatible with the old version of WordPress as possible, are two important aspects of building a welcoming community.

Commercial Community

The current project is both well-known and well-supported by a variety of commercial vendors. Siteground, WP Engine, GoDaddy and others provide commercial support, hosting and, on occasion, funding to drive the project forward. No fork can succeed without an equal investment and buy-in from these sources.

It would be critical to ensure that, at least at the beginning, both the original project and the fork are seen and treated with equal footing by the hosts and commercial supporters of the project. This means actively recruiting their involvement, and courting their technical resources to support the fork's progress.

Much has been made about the limited contributions of a particular hosting company. While no project can survive without contributors, what's often missing from the discussion is the fact that adoption of the original platform is a symbiotic relationship between the open-source authors and the hosting providers that make the platform available. Widespread distribution by those who offer hosting will be an important aspect of growing the fork, regardless of who contributes time or money to the forked project.

Governance

The biggest challenge facing WordPress is the fact that the project is led by a small group of individuals who have almost total control over the project and its direction. The existence of the organization and the commercial corporation creates an untenable conflict of interest for the de facto leader of WordPress.

The fork would elect a board of directors that is neither beholden strictly to commercial interests, or the interests of the open-source community.

For example, a board of directors for a fork might consist of a plugin developer, a core developer, a commercial service provider (like a hosting provider), a commercial publisher, and a small business owner or non-business publisher. Their mission would be to determine the direction of the project, and to steward the fork through the future. Board members would be selected by their constituencies based on bylaws that would be publicly developed and published.

Having a clear set of rules in the form of bylaws, would ensure that the organization responsible for the fork would remain accountable to the various communities and constituencies that rely on the project, rather than being subject to the whims and wants of any one person. 

Licensing

The current project is famously released under the terms of the GNU Public License Version 2. This means that derivative works of the original must be licensed under the same terms. However, there are opportunities to adjust the licensing to be more friendly towards the community, as well as fair to the users of the fork.

The fork could be released under a dual-licensing scheme. 

Original core code would remain under the GPL, as would any code that calls directly into the original API. This is in keeping with the spirit and legal obligations of the original license.

Under a dual licensing scheme, new code that does not call into the original core API, or code that is called by the modified core API would be licensed under a new license to be determined by the community. Over time, this license would be the predominant license of the fork, as core code was removed and replaced with updated, modern code. New features could be developed, and as long as they did not call into the original GPL core functionality, they could be licensed under the new license as well.

Of course, this scheme would need clearance from copyright and intellectual property attorneys. Whether or not the entire platform would be a "derivative work" regardless of whether the code was rewritten would be a matter for discussion. But choosing a license more friendly to the community while ensuring the licensing cannot be used as a cudgel against the community would be in everyone's best interests.

One tricky aspect of this model is the "hook and filter" model currently employed by the project. This model is predominantly what makes it possible to deploy plugins and modifications to the core without hacking on the core, and it would need to be determined if calling hooks named in the original core constituted writing GPL'ed code. In my opinion it does not; others may disagree. It's something that would need to be resolved.

Technology

One of the most powerful features of the current project is its full-featured API that allows for the creation, installation and use of plugins for extending the platform.

The fork would need to carefully preserve this API while introducing new concepts that have evolved with the underlying language since the original was developed and written.

The fork should commit to maintaining the plugin API in its current form, and adopting some features from future versions of the original project. In this way, existing plugins can be made compatible with the forked project.

At the same time, core maintainers need to be cognizant of the fact that the underlying language has changed in the last two decades. Introduction of concepts such as a fully featured object-oriented model, autoloading, namespaces and more have revolutionized PHP and made it possible to do far more with less effort.

Efforts should be made to support modern tools like Redis, Postgres, queueing and containerization. Packages could be distributed with Composer, along with plugins. In this way, the fork can move into the future while retaining compatibility with the past.

Regarding the hook and filter model previously discussed, it's important that it be both modernized and left compatible with existing plugins for as long as possible. For example, a new hook model could be developed, and a mapping written from old hooks to new hooks; the original hook functions then would be rewritten to call the new hook methods. In this way, the original (GPL'ed) API would remain, but the new (re-licensed) API would be able to co-exist. Once plugins started being developed with the new API, the old API could eventually be deprecated and removed entirely.

Funding

Open-source projects are not free to create, maintain or develop. Open-source requires funding, and this funding should be supplied freely by the commercial entities that rely on the project.

One option for funding the open-source project could be to introduce a third license class that applies to commercial users of the project. This might apply to hosting companies or businesses that make a profit. A small licensing fee per running instance could be collected and used to fund the open-source project. The fee should be no larger than is required to reasonably fund the open-source effort.

There are numerous ways to potentially fund an open-source project that doesn't require shaking down users of the project. Whatever method is applied, it should be fair to all users.

Intellectual Property

Clear rules should be established, and trademarks obtained, for intellectual property, names, domains and other assets of the project. Established rules should be written and enforced even-handedly. Modifications to the rules should require consent of all board members after the rules have been established, to ensure that all communities are respected and heard when it comes to the "rules of the road" for using intellectual property and assets associated with the project.

In general, commercial use of the intellectual property (besides the code base) should not be permitted by any person or company. Licensing of the marks should not be granted to commercial entities. Community projects need to be community-oriented, and work in the best interests of the community at large.

The Way Forward

This is neither a comprehensive nor complete list of the elements of developing a project fork. There would be other issues at play, some that can be forecast, and some that cannot. Any successful fork is likely to face strident opposition from the existing status quo, and fork maintainers need to be ready and able to defend against their attacks.

I'm most certainly not encouraging a fork of the project. I believe that incorporating many of these items could in fact save the project in its current form: modernization of the backend, improved governance that removes one person from control, and reconsidering the licensing and business model. The problems come when those currently in power refuse to consider the ramifications of their actions and the damage they do to their communities. In that case, something like a fork may be necessary.

As mentioned, this piece is neither comprehensive nor complete. What are your thoughts on the way forward in the WordPress community?