(Photo credit: Schipulcon 2011 Day 2 Photos under CC Attribution Share-Alike license)
Two recent posts got me thinking about the Drupal community and the WordPress community.
First, Mendel Kurland (whom I’ve been seeing at every WordCamp lately from London to Maine to Minneapolis) wrote on WP Tavern about “A WordPress Veteran’s Take on DrupalCon LA“:
As I flew from DrupalCon Los Angeles, CA to WordCamp Maine, I thought a lot about what the Drupal and WordPress communities could learn from each other. WordPress and Drupal are two community-built platforms and each community is powerful. We stand to learn a lot from each other, because all open source projects matter.
It’s an experience I’ve had many times, having spent much of the last 7-8 years in both communities. (I attended DrupalCon each year from Boston in 2008 through Portland in 2013, and spoke at a number of DrupalCamps throughout the Northeast, while also organizing WordCamp Boston and speaking at WordCamps all over the US).
I used to joke about wearing my WordPress hoodie to DrupalCamps, and my DrupalCamp shirts to WordPress events – but the reality was, in my experience, there was very little overlap in attendees. At Drupal events, people would joke about WordPress as being “fine, for a blog,” implying or sometimes stating outright it wasn’t powerful enough for “real” web needs. At WordPress events, people would joke about Drupal being big and expensive, and fine if you had a team of twelve developers and 6 months or more to throw at a site build.
In reality, the thing which stood out the most to me was how little the members of each community actually knew about the other – as communities or as software projects. (I also spent time in the Sitecore community – where the gap is even greater. At open source events it is common to hear “no one really uses .NET anymore” but at .NET events it is common to hear “businesses don’t really use open source.” Both, of course, are demonstrably false).
The second recent post that spurred me to write was when Dries Buytaert covered the acquisition of WooCommerce by Automattic, concluding:
To me, this further accentuates the division of the CMS market with WordPress dominating the small business segment and Drupal further solidifying its position with larger organizations with more complex requirements. I’m looking forward to seeing what the next few years will bring for the open source commerce world, and I’d love to hear your opinion in the comments.
In some ways Dries’ take on the acquisition actually mirrors my own. The acquisition of Woo by Automattic will improve the ability of WordPress as a platform (and at some point one assumes WordPress.com as a service) to compete with Squarespace, Wix, and Shopify at the level needed by consumers, prosumers, and small businesses. (I also agree with Brian’s coverage at PostStatus – ultimately some of the WordPress.com VIP customers will want ecommerce).
On the other hand, though, I can’t help but see Dries’ post as a not-so-veiled message I’ve been hearing for years in the Drupal community: WordPress is for small businesses, Drupal is for enterprises.
Obviously as the CEO of an agency focused on designing, architecting, and delivering content management solutions for enterprises on WordPress, I take exception to that message. WordPress can be is leveraged regularly by enterprises.Data from places like BuiltWith and W3Techs shows the dominance of WordPress extends well beyond the small business sector, and remains strong even when filtered to just the top 10k sites by traffic. (One can quibble with the methodology for measurement here, as with anything at web scale, but I don’t see anyone claiming Drupal having a similar dominance of a filtered slice). Of course many large organizations end up using both in different scenarios, often alongside a half-dozen other platforms.
Drupal, historically, was also a contender for small businesses, non-profits, and independents. My first Drupal-based site I built from the ground up was for a local vegan society, and I later regularly built Drupal sites for academic departments or programs and other non-profits. Within the Drupal community there is a very vocal segment which feels Drupal is at risk of betraying its commitment to smaller organizations.
In other words, in both communities there are a variety of smaller communities of interest, whose interests sometimes overlap and sometimes diverge. There is no single, monolithic WordPress community and there is no single monolithic Drupal community.
WordPress, as an open source project, has a defined philosophy of development which includes “Design for the Majority,” “Out of the Box,” and “Striving for Simplicity.” Each of these in its own way (plus the often stated importance of backwards compatibility) represents a desire to serve the broadest majority with a simple clean core and a well defined set of APIs for plugin developers. That philosophy, combined with Automattic’s highly visible services for consumers, can lead to a perception that WordPress doesn’t serve the enterprise market. (Of course Automattic also offers WordPress.com VIP, and there are, in addition to 10up, many agencies, hosting providers, and other third parties serving the enterprise market explicitly).
Growing broad adoption of WordPress as a platform is generally valued by the community more than specific targeting of one market segment over another. Matt Mullenweg’s approach and philosophy has always supported that, across both his role at Automattic and his role in the WordPress project.
In the Drupal community, Acquia (Dries’ company) has pushed hard and fast in the direction of the Enterprise market, from day one. The initial announcements around Acquia positioned them as akin to the way RedHat serves the Linux market. That influence, supported by many other agencies (and individual agents) in the community, has pushed the Drupal platform in version 7 and even more so in version 8 (still due out soon), in the direction of what are perceived to be “Enterprise” concerns around technical architecture. (So much so, in fact, that there is a fork in the Drupal community, called Backdrop CMS, which is designed to better serve the smaller organizations and development teams for whom Drupal has become unnecessarily complex).
My point is not to counter Dries’ “WordPress is for small business; Drupal is for Enterprise” with my own “WordPress can do both more effectively than Drupal can do either” – though I guess I’ve made my own choice clear by joining a WordPress-centric agency and skipping DrupalCon 2014 and 2015.
I do still believe the WordPress community and the Drupal community can learn a lot from each other: about technical architecture, about the user experience of content management systems, about community governance, about how to design and hold conferences, about how to sell effectively against proprietary content platforms, and about how to keep innovating while moving forward large communities of contributors and stakeholders with (sometimes) competing interests.
Ultimately maybe the best thing to recognize here is that neither community is monolithic.
There are, in both the Drupal space and the WordPress space, multiple communities, with interests that often overlap and sometimes compete. The open source nature of both projects means that often, those communities within communities can broadly ignore each other and go about doing what they believe needs doing. Occasionally, we see a healthy debate between communities within the larger platform community – and that’s good, as that’s how open communities evolve.
Hi John,
Thanks for picking up on the conversation. I agree neither community is monolithic. We can all point to success stories with simple and complex sites. Having said that, I do believe Drupal is better suited for complex websites and that WordPress is better suited for simpler websites.
In my blog post and comments, I purposely try to avoid words like “enterprise”. Instead, I try to talk about “complex websites requirements”. As I explained in the comments of my blog post, there are a plenty of enterprises using WordPress for high-traffic websites, but these sites tend to be fairly straightforward in functionality. WordPress.com’s VIP customers are a great example of that; high traffic, well-known brands/enterprises, but relatively simple site requirements. When we talk about Drupal’s or WordPress’ target audience, I believe the primary dimension is (a) the website requirements, followed by (b) the skill level required to develop the website. Note the absence of ‘size of organization’ (small businesses or enterprises) as a dimension. Large multi-billion dollar businesses have websites with simple requirements and often use WordPress for them. On the flip-side, a relatively small business may have complex website requirements that favors Drupal over WordPress.
I don’t understand why people insist on thinking of it as Drupal *vs* WordPress, or WordPress *vs* Drupal. I’ve been using Drupal since 2004 and WordPress since 2007. Each has strengths and weaknesses when it comes to best matching the required functionality of a site. It’s a developer’s job to choose the best CMS (or CMS framework, if you wish) for the job at hand.
My only gripe with Drupal is, where on earth is Drupal 8? We’ve been waiting for years. The delay is so great now that I’m advising my Drupal clients to re-platform onto WordPress instead of doing an equivalent upgrade from Drupal 6 and 7. While I still look at Drupal as a viable solution I’m quite disappointed in the long, drawn-out release of Drupal 8.
Thanks Dries for commenting. I’ve always had and continue to have great respect for you and Matt both in how you encourage our communities in the direction of open professional dialogue.
While I get how the distinction between “simple/complex” requirements is different than an organization’s size, to be fair, your post did start with “This is a very interesting move that I think cements the SMB/enterprise positioning between WordPress and Drupal.”
Ultimately I’d agree Drupal build projects are more complex – and the “overhead” (for lack of a better term) of development complexity on a Drupal project makes more sense in a complicated build than in a simple one.
I’ve also found, however, that WordPress is capable of serving way more complex requirements than many folks realize. People who have “used” WordPress at some point in its history (often several years ago, often based on a simple out of the box experience) tend to dismiss it based on that simple experience, without exploring the full API, custom content types and taxonomies, and the like.
It’s the double-edged sword of the success of the consumer-facing WordPress.com: we benefit from the name recognition but suffer from the “simpler” version being taken for the whole.
Just because the WordPress project focuses on simplicity and clarity of user experience (along with backward compatibility) does not mean the underlying platform is limited in terms of what it can be used to accomplish.
I’m always reminded of Ed Begley Jr in the film Who Killed the Electric Car saying: “What the detractors and critics of electric vehicles have been saying for years, is true. The electric vehicle is not for everybody; . . . it can only meet the needs of 90% of the population.”
Cameron – thanks for commenting.
I agree it really shouldn’t be framed as an either/or, though obviously on a specific project you’re more likely to choose one than use both. Also, in many companies, there really is a need to standardize their team so they can concentrate training and skill building on a single platform.
The reality is the best developers (and experience designers, and content strategists, and even clients) come out of experience in multiple platforms, and the community benefits more from having healthy Drupal communities and healthy WordPress communities than it would from some theoretical monoculture.