“All The Word That's Fit To Press.”
A WP Engine

I Will Never Fork WordPress

There’s been a handful of posts this week that have focused on the theory and possibility of forking WordPress. Instead of reacting immediately to some of the posts I’ve spent a bit of time in introspection reading these posts and asking myself if I would ever, myself, seriously consider forking WordPress.

What I’ve come away is pretty clear and I’ll go ahead and say it for the record (as if the title of this blog post didn’t give that away):

I will never fork WordPress.

I will spend a little bit of time explaining my position as follows:

via Morten Rand-Hendriksen

via Morten Rand-Hendriksen

Theory and Practice

I understand where Morten is coming from and I want to very much stand up and applaud the way that he outlined his own position and used such nice and concise graphics to create his argument. I like how he sets it up and how he poses questions that are both universally understood and important:

This 10 year anniversary should also be a time for review, revision, and vision for the future. Should WordPress remain a one-size-fits-all CMS grown out of a blogging platform? Or is it time to rethink the structure of the application and modularize it to meet the demands of different user groups? I say it’s time for a fork.

As stated, he thinks that it’s time to fork WordPress and begins to systematically lay out his position that I believe is, for the most part, philosophically-sound.

But there is a difference between theory and practice, and when I say “difference” I mean that in every sense of the word. There is a gap that exists here that is so large that it’s hard, if not impossible, to fully reconcile.

You see, if you’ve ever looked in Trac and if you’ve ever looked at Core (not just glazed over it or TL;DR’d it) then it’s almost impossible to come away thinking, on easy terms, that forking would be anything but exceptionally difficult.

There are pieces of code in there that are 10 years old, some of which is incredibly grotesque and ugly, but some of which is as good as it’s going to get. I don’t give WordPress a “pass” on being 100% amazing at every single level, especially from an engineering perspective, but it’s not bad either.

You must simply not forget that some of the conventions of PHP that we believe in today were not present 10 years ago. Newer developers seem to dismiss this (or ignorantly overlook this) and scream that WordPress is not “best practice” – to those I just shake my head because they just need to grow up (and learn a bit of history).

But to fork it, and even stripping it out to the “core” Core and then building modularly would, practically speaking from an engineering perspective, be akin to adding a fifth wheel to a car or, as a friend suggested, making the steering wheel square. It just doesn’t make sense from a pragmatic point of view, and this isn’t even talking about dependencies, like server configurations and the like. Forking could jeopardize those staples overnight.

But I get the theory behind it (and the intention) and I agree principally that things have definitely changed in the last 10 years and that arguments about bloat, focus, and even normative use cases (and fringe) have begged these questions.

If I were to ever endeavor anything close to a fork I would much rather spend that allotted time pulling out a Ghost, where a new and different (radical?) vision would begin to take shape, simply because the time to refactor and fork would be practically stupid in light of what could be done from scratch.



The Ecosystem

When I say the “ecosystem” I include two things namely, the first being the overall product and service offerings that are available to WordPress, which would include themes and plugins. I secondly include the overall culture and historicity that have been created and cultivated within the last decade (and then some, if you include WordPress’ original fork of b2/cafelog).

The first point is that the themes and plugins (namely the latter) provide such rich and valuable add-on experiences in a ‘modular’ approach that I find it hard to even want to consider forking WordPress in anyway that might jeopardize the use and pragmatic utility of such an incredible library.

Can you imagine saying goodbye to all of those plugins that you count on for not only for yourself but for your clients and customers? When I consider forking something I consider the ecosystem that I may (or may not) be abandoning as a result of my decision.

Secondly, the culture and historicity of an application is also something that is “forked” when you functionally fork an application. This is not necessarily required to happen but it is, again, a possibility. 10 years is a long time in software and to divorce it has it’s consequences, both good and bad. But there is something to be said abou the maturity of a platform and technology, that has survived many ups and downs, that no app or culture can acquire through brute force or even purchase.

It take time and experience over that time is an valuable source of learning, insight, innovation, and progress. Forking WordPress would, again, invite the possibility of a schism that is not something that I personally am interested in inviting. I would much rather start anew and being loading up the history books on fresh and new pages than borrowing from a decade’s worth.

I love the thoughts and ideas that are being proposed and I support the right for everyone to have their opinion (as this piece is very much my own opinion). Let’s not squelch or silence others just because we have a different perspective. Like another friend mentioned recently, collaboration without critique is dead:

There appears to be an idea current that a community, which is really just a team on a macro scale,  can collaborate without healthy, and sometimes jarring, critique. I emphatically disagree!

Collaboration without critique is dead.

As a team, it is imperative that we critique each other even if the recipient of the critique isn’t ready to take ownership of the news.

Likewise, as a community, or very specifically as a WordPress community, we must critique one another. Sometimes when invited. Sometimes not.

Yes, it will be messy. Yes, candor must be balanced with decorum. But in the end we must be bold with one another, and engage in true collaboration, for the betterment of our respective teams, and the larger community of which we are a part.

Well said, well said.

Some other resources that have come up again for your reading pleasure:

Read on my friends, critique and collaborate!

More WordPress News From Torque:
  • http://www.wptavern.com Jeffro

    First off all, that Forking picture is hilarious. Do you know the circumstances behind it such as where was it taken? Secondly, forking has to be akin to the nuclear option. After I wrote my article and have read some others about the entire idea of Forking, I agree that creating a Ghost or starting from scratch would be a much better use of time and resources versus forking WordPress. The only scenario I can think of where Forking would be a good option is if Matt and the core developers take WordPress into a direction that’s counter to everything the user base wants. But why in the world would he or the devs do that? A scenario that’s 99.9% likely to never happen.

    • http://john.do/ John Saddington


      Hey buddy! That’s actually the Technical Editor of WP Daily (Partner of 8BIT), so yes, I do know the circumstance and where it was taken…!

      Hah! I asked him to pose in our office for it because I was hurting for a featured image!

  • http://designisphilosophy.com Morten Rand-Hendriksen

    You present a well argued counterpoint to my argument John. This discussion exemplifies exactly why I love WordPress: Not only does it spark real discussion about the future of itself and the web, but it also allows us all to share our ideas in comments and linked blog posts with ease. And that’s what it’s all about: Making the publishing of ideas as easy as possible.

    I have a few minor points:

    You say that “(..) if you’ve ever looked in Trac and if you’ve ever looked at Core (…) then it’s almost impossible to come away thinking, on easy terms, that forking would be anything but exceptionally difficult.”

    While I agree that it would be exceptionally difficult, that is also part of my point: If we continue down the path we are headed right now we are going to end up with a behemoth that will be hard to manage and even harder to evolve. In every application’s evolution you come to a point where you need to reset and start over to get rid of old cruft, implement elements that have been impossible to include due to said cruft, and also solve long outstanding issues. Every major platform does this from time to time, and yes, when it’s done there are always issues with backwards compatibility and legacy support. Windows is a prime example. So is Apple switching to Intel architecture.

    Even if you ignore the fork argument, this is still the time to start over and rewrite core, probably from scratch. It’s a massive undertaking, but if we don’t do it now chances are it won’t be done at all. My fear is that 10 years from now we will look back and say “Wow. Why are image galleries still marked up as definition lists?” or even worse “Wow. Remember when we were all using WordPress to publish content to the web?”

    When I wrote the article I intentionally used the term “fork” because I knew it would grab people’s attention and get the conversation going. The problem with the term itself is that it often has a very limited interpretation, as in “entirely separate spinoff off the original”. That doesn’t have to be the case. Far from it. A smart fork is one that relies on the updates of the point from where it originated and inherits its updates etc. Done right, and with proper oversight, a forked system like the one I suggest wouldn’t mean more development or double/triple/quadruple work but rather a departmentalization of the work being done. Core team works on core, Blog team works on Blog fork, CMS team on CMS fork etc. It’s effective, and it’s the way application development (and WordPress development) is done.

    That said, I am not saying forking is the only option. It’s just one of the options we need to discuss. From the feedback I have gotten over this article and the discussions that are happening all over the place it’s pretty clear that people are very much in favour of some sort of simplification of WordPress. I keep seeing people talk about “WordPress Lite” and “WordPress CMS” and there are lots of input on carving out elements to be put in plugins and taking elements that are currently in plugins and putting them into the core. There are also many that agree with my point that WordPress is becoming too complex, and I think that’s where we need to start.

    I teach WordPress for a living and a large percentage of my students are beginners with little to no experience with web publishing. From what I have seen it is a fact that WordPress in its present state is too complex for these users. And based on the current philosophy of WordPress, these users are part of the target audience.

    It’s true what’s been said before: When WordPress was simplistic, people requested new features. Now that all the features are included, it’s gotten too complex. What we need to do now is a) figure out what the people who use WordPress actually use, need, and want and b) boil the application down to its essence, clean it up, and rebuild it to fit those uses, needs, and desires.

  • http://enConnected.com Travis

    I really don’t think forking WordPress would be a best case scenario. I think a better thing to do would be to go back in and spend a couple of release cycles applying those new approaches to PHP coding that you mention.

    In my opinion, the problem isn’t that WordPress does so much, it’s that it does so little of the things that writers need without installing a random plugin. A great example of this would be the way Ghost approaches sharing on social networks. I shouldn’t need a plugin to do this, especially since it’s so vital to maintain a modern publication.

  • http://newlocalmedia.com Dan Knauss

    What I’m hearing you say is that there’s so much legacy code (and culture) in WordPress that anyone who wants to modernize, trim, and/or reorient its focus would be better off just abandoning it and starting over.

    This seems to imply WordPress is going to be pretty much what it is for the foreseeable future. Is that a competitive position, or is it’s inertia it’s only real advantage?

    Keep in mind that surveys show a lot of people who make money from WordPress in some way say it is not how they make their living. Maybe they love WordPress, but they really don’t have a food-on-the-table reason to love it best. So perhaps the competition that matters is not about brand pre-eminence and market share (how many sites use X) but market value and how that value is distributed among people who sell WordPress-related products and services.

  • Robert Lilly

    Call it what you will, forking, rewriting, whatever, it’s clear to me as developer that WordPress is still a blogging platform at its core (page, posts, custom post types, etc.) are all stored in the database as posts. However its other features make it clunky if all one wants to do with it is run a blog. As a CMS its internal logic is kind of weird and without the addition of plugins it still can’t be used as a real CMS out of the box. I think all those who are looking at it as an app engine are probably doing it because its what they know, not necessarily because it’s the best framework to build an app on.

    I like Morten’s suggestion to have a really efficient and small core, and then add modules (complete packages) that turn it into something suitable to the use case. As Morten pointed out that’s already being done with bbPress and BuddyPress.

    • http://newlocalmedia.com Dan Knauss

      Totally agree with all that you say Robert. I like Morten’s suggestions a lot, but what is actually feasible within technical and cultural/political limits, I have no idea.

      This seems like the same crisis of decision that Joomla had to face, except Joomla has always been more of an application framework with a CMS-ish layer built on top of it, so it was probably easier to face that and finally split the two apart. That opens the door for Joomla to be the garden of forking paths exactly as Morten describes instead of having a quasi-CMS with a massive and confusing market of add-on software that eclipses the core and starts to influence it in all kinds of complicated ways, both technical and political-economic.

      Growth of any kind is always a good problem, but sooner or later it pushes a costly and confusing mix of needs and wants to the fore that will challenge even the most conscientious and cooperative community. Just like a sprawling boomtown, the community leadership and the “commercial” and “residential” stakeholders of the community have different ideas about how to address infrastructure needs, new wants, and how to direct future growth. If I want to build a meat packing facility, I’m focused on stuff like the lack of capacity in the city water supply, just like someone trying to make WordPress into a huge application is focused on things like the limitations of core caching. Other people think this is irrelevant and distracting from their wants and needs. There are always ethical concerns in the mix, and above all it is a fairly existential choice: what do we want to be?

      Morten’s suggestion might be as radical as trying to impose northeastern urban planning and zoning on a southern/southwestern city. It’s like saying, if you want to build a certain kind of site, you do it over here in an area that caters to the category you’re in. You don’t just plug your prefab fertilizer factory into the street grid and then complain about traffic or water capacity, or how the community is too focused on the neighboring schools and hospitals. For political leadership it’s about managing constituents efficiently. For business leadership it’s about managing resources and maximizing business efficiency. For residential community members it’s about getting safe, economical service delivery from both of these other sectors and not having to worry about your neighborhood suddenly having a feed lot or fertilizer factory next to the retirement home.

      • http://designisphilosophy.com Morten Rand-Hendriksen

        I love your analogy of city zoning and political decision making. Speaks to my political brain in a very real way. While I don’t think there are any technical limits that prevent WordPress from being modularized, forked, split, versioned, there are indeed major political blockages and conflicts that need to be resolved. Like in any major projects there are fiefdoms, inherited opinions, and strong minds at work that all have to be considered, placated, and brought into the fold to get anywhere. I have an extensive background in politics and I can tell you what I see in the Open Source community is very similar to what you see in political organizations and decision making processes. The only way out of it is strong leadership, aggressive democratic processes, extensive surveying of the user base, and voting.

        I guess the question this all boils down to for me is if WordPress should be a professional grade web publishing platform or if it should be a cool experiment that never really grows out of the experimental phase.

        • http://newlocalmedia.com Dan Knauss

          I suppose that really is the question.

          I got most heavily into open source CMS projects when I moved from Movable Type to WordPress and Mambo, which then forked to Joomla. I quickly realized how much these projects can be like my experiences during the same time on non-profit community groups, neighborhood associations, or at meetings about controversial land use and development in the city where I lived at the time.

          Clarity and grace in communication are the key, and it seems like you’ve got a good handle on both. Not everyone does. It’s tough.

  • http://www.thetaprofits.com George Quinones

    I would agree not forking WordPress, but I think having a simpler core and adding core features/modules as needed ( CMS , Entrerprise, Network ) would enhance the performance.

  • http://www.mathewporter.co.uk Mathew Porter

    The possible emergence of Ghost (Kickstarter backed blogging platform project) suggests that WP has been evolved into a beast that people don’t need, moving away from a pure blogging platform or having blogging as its core function.

  • http://www.erickdanzer.com Erick Danzer

    This is a nice reply, John, and it’s a great discussion in the comments. As Morten said, that’s one of the great things about the WordPress community.

    For what it’s worth, I think creating a “lite” version of WP, or creating multiple branches in any way, is likely to solve one problem only to create many other, more severe ones.

    *Creating more complexity, not less, by fracturing the ecosystem. Which branch do I start with? What’s the difference? Are all plugins compatible with all branches? What if I started with Blogging Lite and now need CMS – is migration seamless? I think new users would have a harder time facing this, and facing the initial learning curve with WordPress as is.

    *Increasing the burden on the volunteers that support WordPress and contribute code. code contributors and others who support WordPress.

    *Siphoning off development energy in multiple directions so that the main WP frontier moves forward more slowly.

    I also have to wonder if the motive for this is what users want. While some new users experience frustration with the learning curve, I think most users love WordPress, especially compared to any other existing platform. Rather than users, it seems to me that the push from this comes from developers and from that overwhelming instinct that good developers have for clean, light, consistent, purpose-aligned code. In other words, it’s what developers see when the dig into the code that’s bothersome, not anything most users are experiencing when they just use WordPress.