Are too many cooks spoiling the WordPress soup?

This is a guest contribution from Spencer Forman, the founder of WPLaunchify.

Nearly everyone at some point has heard the proverb “Too many cooks spoil the soup!” 

The implied meaning is simple. If too many people are involved in doing the same things, the results will not be good. 

Most restaurants solve this problem by implementing a strict hierarchy of authority, decision making and specialization. 

Everyone has a job, and the kitchen is run in a centralized manner… sometimes like a boot camp! 

By comparison, WordPress is a magical, organically grown, decentralized ecosystem.

It’s a bit more like a Potluck Dinner, where open source code and open minded thinking have led to great success… so far.

But is the decentralized nature of our beloved WordPress potentially the cause for most of the urgent problems we face today?

In other words, are too many cooks spoiling the (WordPress) soup?

There are three places where the issue reveal themselves most clearly:

1. The roadmap(s)
2. The components
3. The user experience

[midroll_1]

The roadmap is supposed to be a plan of action for how a product or service will evolve over time. It acts as a source of shared “truth” among all those concerned.

But it requires the organizational “muscle” of a top-down leadership, where required tasks are triaged by a hierarchy of authority and delegated logically to the most qualified team member.

This hierarchy also improves the customer experience by setting expectations and inspiring confidence. There is only one message, from one source, optimized for maximum profit and customer satisfaction. 

In our kitchen example, that’s one dish, from one menu, served the same way to each customer, delivering a satisfying user experience.

But a singular roadmap doesn’t exist in WordPress. Instead, there are infinite roadmaps, being managed by parties with often competing and conflicting interests.

Though WordPress core has a roadmap, it is but one of many components and services required by a typical WordPress user facing an extraordinarily complex matrix of decisions, typically with little or no prior experience.

Here are just a few of the things a new WordPress user must overcome to get started:

1. Choosing a hosting company and plan
2. Choosing a theme, page builder, plugin stack
3. Understanding that software is “free” but they are actually paying for updates and support
4. Understanding that some free software then requires multiple paid add-ons purchased from many sources
5. Understanding that some software is purchased for one month, but others for a year or for lifetime
6. Understanding that one software component support may have no ability to help with another component
7. Understanding that there are currently three or four generations of page builders, themes and dashboards
8. Understanding that paid authors are not allowed to suggest paid help or services in the .org forums
9. Understanding that the plugin and theme repositories have no modern faceted search or discovery

Imagine the Yelp rating our example restaurant would receive if new patrons had to encounter such things before eating there for the first time? Did you say “zero?” Exactly.

The decentralized nature of the WordPress ecosystem has created too many cooks, all participating in their own roadmaps, driven by competing interests. 

This has left us with too many companies competing to solve the same problems (outside of core), without the meaningful coordination of a centralized roadmap. Usually because they are the most profitable or popular.

So instead of one dish, from one menu, served the same way to each customer, delivering a satisfying experience, the WordPress user experience is random and in conflict, depending on how lucky one is to find qualified help along the way.

Some would argue that the problem is made worse by the lack of unified documentation, support and marketing from a centralized location.

Instead of WordPress being presented to the public as a complete “product” or “service”, with all the components treated like features, prospective customers instead find something that looks and acts more like a flea market or bazaar.

[midroll_2]

Why?

Because the components that run on top of core, including themes and plugins, are all left to the decision-making and marketing savvy of independent creators. The “cooks” in our kitchen example. 

There is no central sales mechanism, support mechanism, promotional mechanism, or head chef to coordinate the contributions of tens of thousands of creators into the cohesive “product” of WordPress.

While this decentralization may have been one of the strengths of WordPress in the past, it has now devolved into a “hoard the toilet paper” mindset amongst creators, especially as the competition increases and the economy slows down.

Instead of cooperation, a component creator is now required to think strategically from day one about whether and to what extent to share with others. 

If one has limited resources, and no centralized guarantee that the work will result in receiving a paycheck, there is limited incentive to cooperate. This is the exact opposite mindset from the principals of open source.

In WordPress we are also seeing powerful and well funded corporations consolidate components at a rapid pace, and use their strength and market exposure to put smaller creators at a competitive disadvantage. 

Unfortunately, this has even applied to Automattic itself.

In a few cases, it has offered its own products and services directly to consumers in ways that are not available to ordinary WordPress creators and yet in competition with them nonetheless. This type of unfair advantage by the “parent” organization evokes memories of the company store from America’s past.

So what is the solution?

The evolution of WordPress from a decentralized community to a “more” centralized community is a step in the right direction. 

I suggest that the creators in the WordPress community will be more empowered and engaged if Automattic moves towards a model that aligns with real world financial incentives for creators.

For example, most product and service companies provide a public roadmap and feature “wishlist” for identifying the most desired and important features that need to be added. 

It would not be hard to imagine how WordPress.org could publish a public directory of paid features that were created in response to this roadmap and wishlist. And unlike the current free repository, these paid features would be properly indexed with faceted search, documentation, and the ability for creators to offer support without penalty or admonition from forum administrators.

This small accommodation would deliver three immediate benefits to the WordPress community:

1. Incentivize the sharing of information as to what features are needed and why, via public comment
2. Provide a financial reward to creators for building paid solutions to add these features, while leveling the playing field for creators of all sizes and financial capabilities
3. Simplify the discovery process for WordPress user for the premium features they desire

There would be no need for WordPress to be responsible for taking payments or managing customers.

Just the mere consolidation of the paid feature information, in a way that allows creators to reasonably support inquiries and offer their own competitive solutions, would be enough to solve many of the problems WordPress faces today.

Perhaps this would be one small step towards getting all of the cooks in the decentralized “kitchen” of WordPress to work together as a team, providing features for the WordPress community as a whole, instead of competing against each other.

What do you think?