Forking is a Feature

There’s a new WordPress fork called ClassicPress that’s been making some waves recently, with various members of the Twitterati swinging between decrying it as an attempt to fracture the WordPress community, to it being an unnecessary over-reaction, to it being a death knell for WordPress.

Personally, I don’t think it’s any of the above.

Some years ago, Anil Dash wrote an article on this topic (which I totally ripped forked the name from), you should read it for some context.

https://anildash.com/2010/09/10/forking_is_a_feature

With that context, I genuinely applaud ClassicPress for exercising their fundamental rights under the GPL. The WordPress Bill of Rights makes it quite clear that forking is not just allowed, it’s encouraged. You can and should fork WordPress if you choose to. This isn’t a flaw in the system, this is how it’s supposed to work.

Forks should aways be encouraged.

Forks are a fundamentally healthy aspect of Open Source software. A relatively recent example is the io.js fork of Node.js, which resulted in significant changes to how the Node.js project is governed and developed. WordPress has seen forks in the past, too: Lyceum was a fork that added multi-site support, before it existed in WordPress. WordPress MU was something of a sibling fork which also added multi-site support, and was ultimately merged back into WordPress.

There are examples of forks that went on to become independent projects: WordPress itself is a fork of cafelog/b2. X.org is a fork of XFree86. LibreOffice is a fork of OpenOffice. Blink is a fork of WebKit, which in turn is a fork of KHTML. MariaDB is a fork of MySQL. XBMC has been forked dozens of times. Joomla is a fork of Mambo. (Fun historical coincidence: I very nearly accepted a job offer from Miro, the company behind Mambo, just a couple of months before Joomla came into being!)

Maintaining a fork is hard, thankless work.

All of these independent forks have a common thread: they started with a group of people who were highly experienced in building the software they were forking (often comprising of core developers of the original software). That’s not to say that non-core developers can’t drive a fork, but it does seem to require fairly fundamental knowledge of the strengths and weaknesses of the software, in order to successfully fork it into an independent product.

From a practical perspective, I can tell you that maintaining a fork of WordPress would require an extraordinary amount of work. For example, WordPress.com effectively maintains a fork (which happens to almost exactly match the Core codebase) of WordPress. The task of maintaining this fork falls to a talented team of devops folks, who review and merge each patch.

Now, WordPress.com is really only an internal fork. To maintain a product fork of WordPress would require so much more effort. You’d need to maintain the web infrastructure to push out updates. As the fork diverges from WordPress Core, you would need to figure out how to maintain plugin and theme compatibility. You’d likely need to do your own bug and security fixes, on top of what’s merged from WordPress.

I’m not saying this to dissuade anyone from forking WordPress, rather, it’s important to go into this aware of the challenges that lay ahead. For anyone who uses a fork (whether it be a fork of WordPress, or any other software product), I’m sure the maintainer would appreciate a word of thanks for the work they’ve done to make it possible. πŸ™‚

What’s next for ClassicPress?

Well, that’s ultimately up to the folks building it, and the people who use it. As a member of the WordPress core team, I certainly hold no ill-feelings towards them, and I hope they’ll be open to working with us in the future. I hope we’ll be able to learn from their work, to improve WordPress for everyone.

It’s humbling and inspiring to build something that’s used by so many millions of sites, but at times it involves accepting that we can’t build the tool that will work for 100% of people, 100% of the time. Regardless of WordPress’ future popularity, there’ll always be a place for alternatives, whether that be forks like ClassicPress, different CMSes like Drupal or Joomla, or even different publishing concepts, like MediaWiki or Mastodon.

Ultimately, we all share the same goal: creating a free and open web, for everyone to enjoy. While ClassicPress has styled itself as a protest against Gutenberg for now, I hope they’ll find their voice for something, instead of just against something. πŸ’–

9 comments

  1. I just want to applaud you on a very thoughtful and well argued post. I thoroughly enjoyed reading it and you made some points which will shape how I take ClassicPress forward. Thank you.

    1. I’m glad you saw this post, and were able to take something from it. πŸ™‚

      While I imagine much of your time will be focussed on getting ClassicPress up and running, you should know that you’re always welcome to contribute any ClassicPress development back to WordPress, should you feel that it would be valuable for everyone to use.

    2. I’m replying to my own comment as a LOT has happened since I last commented (and this article keeps getting quoted in a negative context)

      We have formed our democracy: https://www.classicpress.net/democracy/

      We have a clear plan: v1 will be a LTS version of WordPress without Gutenberg. v2’s future will be defined by the community via our democratic structure.

      We’ve got our voice and we’re much more than just a protest. ClassicPress is here to stay and we’re going to make a massive positive difference.

    1. While your comment is glib, you are asking a reasonable question: is the Gutenberg team prioritising their time correctly?

      Personally, I believe we’re doing a reasonable job, though we could probably lean a little more towards blogging than we are now. There’s been valid criticism that the Gutenberg team has been less communicative than it could be, which we’re working to address.

      As to the actual number of open issues, it’s valuable to look at other Open Source projects for a comparison. WordPress has 6k open issues. Drupal has 19k open issues. Chrome has 61k open issues. Yoast has 1k open issues. Jetpack has 1k open issues. I think open issue count is a poor measure of software quality or release readiness. Can we reduce the number of open issues? Sure! But it’s not going to be the determining factor for when WordPress 5.0 will be released.

      1. Issues β‰  Problems. Issues are developers, users, fans giving feedback and insight to a project they love and depend on. Inbox zero for an open source project typically means it’s abandoned, not well developed.

    2. I don’t think blogging about development is a waste of time. I often find that when I blog about issues, I come to understand them better and sometimes get valuable feedback from others. All that can ultimately help me avoid more issues.

    3. This is pretty much the opposite of wasting time.
      I don’t want the Gutenberg developers to act like ClassicPress or people’s reactions (including your comment ^^) do not matter at all.

      Communication is the key, for example a huge part of people “against” are simply ignoring the fact that Gutenberg packages (npm) will be reusable for other projects so this is global.

Comments are closed.