Why the Big Fuss

Gutenberg
What’s the Big Fuss All About?

For those who want to dig deeper into the topic about why WordPress has made this decision, and why discussions around Gutenberg have been so heated, these are our thoughts on the matter.

Why is WordPress launching Gutenberg?

Even though WordPress is a free CMS (WordPress.org), the founders of WordPress started a company called Automattic Inc.

Autmattic runs the commercial hosting service and blogging platform WordPress.com (note the .com at the end). Automattic also sells WordPress related plugins (WooCommerce among others) and contributes to the open source parts of the WordPress platform (WordPress.org). Automattic is funded by VC money, and like other companies feel the pressure to keep competitors at bay and make great profits.

The competitors for WordPress.com are other platforms where users for very little money can blog casually like Wix, Squarespace, and Medium. To keep up with competitors, WordPress needed to step up their game in terms of ease of use and editing experience. They needed to create an incentive to make users from competing services switch to WordPress.

Why the Big Fuss?

Conflicts of Interest

The audience for WordPress.com is not the same as for WordPress.org. The two products are serving different markets – WordPress.com catering to small casual bloggers and WordPress.org serving more established brands and businesses. The use case for the products are not the same, and forcing such an impactful change onto users that might see it as more of a nuisance than a feature has not been appreciated by the WordPress.org community.

WordPress.org is open source, and according to its rule of thumb, new features should only be included if they will be used and appreciated by more than 80% of all end users.

The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it. If we stick to the 80% principle then this should never happen.

And turning off and/or never using Gutenberg is exactly what a lot of WordPress.org users contemplate doing. At the moment of writing (November 2018), the Gutenberg WordPress plugin has a rating of 2.5/5 stars, where a majority (57%) of votes are 1-star votes. Check the current rating at the plugin page.

Technological & Economical Prioritizations

WordPress.org prides itself in being very backwards compatible. A drawback with being very backwards compatible is the cost of having an outdated codebase containing a fair amount of technical debt.

The project as a whole might rather benefit from carefully being brought up to date with a more modern version of PHP, which is the programming language used for most of the platform, than getting a new editor that is potentially incompatible with a lot of existing themes and plugins.

Updating the PHP version WordPress supports has however not gotten prioritized for years. When Automattic instead decided to add a feature to benefit their business rather than the community, and also choose to use the latest and hottest technologies to build this feature, their prioritizations were not generally appreciated.

Automattic has also been criticized for allowing a small clique of co-workers making too many too impactful decisions alone, not considering the community and WordPress as a whole.

There have been reports about friction within the Gutenberg working group, which has led to releasing a less functional product. Rian Rietveld was in charge of accessibility within Gutenberg, but left the project due to the team being unable and unwilling to include accessibility in their processes, getting ignored and ridiculed.

Rietveld’s replacement Matt MacPherson then stated that Gutenberg not being accessible for impaired users was not a reason to delay its release, since they could just use the old editor.

I don't view it as a good decision to delay the 5.0 release over accessibility concerns when the Classic Editor exists as a fallback.

Matt MacPherson Accessibility Lead, Gutenberg

To be clearly ignoring users with disabilities for a product that is powering about 30% of the Internet led to more criticism and heated debates.

I can’t stop thinking about the fact that @Wordpress (which “powers 31% of the internet”), is about to ship a massive overhaul of their interface without making sure that it’s accessible. Why was #a11y not a blocker for every new feature, so nothing inaccessible was ever allowed? https://t.co/YzNIhf26hJ

Changing the Work for Theme- and Plugin Developers

Themes and plugins that interact with the WordPress editor need to be rewritten in order to be compatible with Gutenberg. For developers that make a living on creating and selling themes and plugins, this means putting in unpaid work hours.

This might have been a smaller issue had the technologies used to build Gutenberg not been so very different from what is usually used for building WordPress themes and plugins.

The Gutenberg team really wanted to modernize the product and chose React, a JS framework created by Facebook. Relying on Facebook to continue to keep React open sourced caused a minor bump in the road earlier in 2017, but since then any licensing issues were resolved.

To be able to build WordPress features on a deeper level, developers will need to get grips on a sizeable amount of technologies that are new to WordPress development. Code packages with pre-configured settings for configuring the development environment needed to start building Gutenberg block plugins have become popular on GitHub.

Investing time and resources learning the new technologies required for Gutenberg compatible development is doable for large plugin development teams (like the ones at Automattic), but for smaller teams or companies it will be much more difficult.

Another concern with relying heavily on the latest, greatest and shiniest new framework for a product that is dependent on longevity, stability and backwards compatibility, is that the longevity of those frameworks cannot be guaranteed. Two years after the term Javascript Fatigue became an expression, developers are getting more aware of possible consequences of jumping on the bandwagon just too soon, without considering if it really is the right tool for the job.