Why WooMattic is big news for small businesses

Earlier this week Matt Mullenweg, founder and CEO of Automattic, parent company of WordPress.com, announced the acquisition of WooCommerce. This is a very interesting move that I think cements the SMB/enterprise positioning between WordPress and Drupal.

As Matt points out a huge percentage of the digital experiences on the web are now powered by open source solutions: WordPress, Joomla and Drupal. Yet one question the acquisition may evoke is: "How will open source platforms drive ecommerce innovation in the future?".

Larger retailers with complex requirements usually rely on bespoke commerce engines or built their online stores on solutions such as Demandware, Hybris and Magento. Small businesses access essential functions such as secure transaction processing, product information management, shipping and tax calculations, and PCI compliance from third-party solutions such as Shopify, Amazon's merchant services and increasingly, solutions from Squarespace and Wix.

I believe the WooCommerce acquisition by Automattic puts WordPress in a better position to compete against the slickly marketed offerings from Squarespace and Wix, and defend WordPress's popular position among small businesses. WooCommerce brings to WordPress a commerce toolkit with essential functions such as payments processing, inventory management, cart checkout and tax calculations.

Drupal has a rich library of commerce solutions ranging from Drupal Commerce -- a library of modules offered by Commerce Guys -- to connectors offered by Acquia for Demandware and other ecommerce engines. Brands such as LUSH Cosmetics handle all of their ecommerce operations with Drupal, others, such as Puma, use a Drupal-Demandware integration to combine the best elements of content and commerce to deliver stunning shopping experiences that break down the old division between brand marketing experiences and the shopping process. Companies such as Tesla Motors have created their own custom commerce engine and rely on Drupal to deliver the front-end customer experience across multiple digital channels from traditional websites to mobile devices, in-store kiosks and more.

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.

Comments

Robert van Kemenade (not verified):

I wonder if WordPress will be able to deliver the flexibility that Drupalcommerce offers. Most companies have the wish to grow and require their application to grow with them without having to jump through hoops, my strong believe is that Drupal is the better solution in such cases.

We work with Drupal for all our projects, from the smaller websites up to large webservice based projects and Drupal has never let us down with regards to the possibilities without hacking core.

It really is a shame that Drupal is only seen as a solution for larger projects, for the long term Drupal, imho, is a better more scalable solution and if a projects outline is documented correctly using Drupal shouldn't require much more work than WordPress and offer more options for the future of an application.

One thing for me is certain, Open Source will be the only way to go in the future. As more companies realize they are responsible for their data, it will, hopefully, be a requirement that they know what an application is doing with their (customers) data. Backdoors and such in closed source software pushes Open Source popularity. With that, although I prefer Drupal, I hope this acquisition will further the Open Source cause.

Ryan (not verified):

I'm very happy to read your comment first, Robert. I know there's a lot of debate around the usefulness of eCommerce solutions on Drupal (even in the comments below), and having led the development of both major systems in use today, I'm well aware of the drawbacks of what we've produced.

However, it's satisfying and affirming to know that there are folks out there like yourself who are successfully using these tools to solve real world problems for themselves and their clients. That ability to help people grow their businesses and better themselves through free software has always been one of my primary motivations in contributing to the Drupal community, and it's good to be reminded that it's paid off for plenty of people. : )

Kristof Van Tomme (not verified):

While it is already a reality that WordPress is the preferred tool for SMBs and Drupal for enterprise, I think we should be very careful in accepting this situation.

Many industries have seen low cost, less feature rich solutions come in at a lower price point, and then flush out more expensive competitors. Drupal has done this to proprietary CMSs, WordPress could do this to Drupal.

We need to keep Drupal accessible and useful for the DIY SMB crowd. If we don't, we will be out-innovated. WordPress is not going to stop at SMBs they also want the enterprise market.

Dries:

I agree we have to be careful about that, and I believe we have been (e.g. by focusing on UX improvements in Drupal 8). I subscribe to Clayton M. Christensen thinking in the The innovator's dilemma.

Kristof Van Tomme (not verified):

I know you have Dries, I didn't mean it as a criticism.

But I wonder if we could do more to foster a community where we can keep a rich diversity of small companies living next to the large businesses that are emerging.

I guess that the improvements to the site building experience will help with that. But I wonder what else we could do to celebrate the cottage industry of semi-professionals, people for who Drupal is not a corporate job. I think they are the growth bed of a lot of the innovation in the community.

Larry Garfield (not verified):

Despite the rather strong pushback pointing out all the things he got wrong?

(Not that the small player eating the big player from the bottom doesn't occur a lot, but it's not the sum total of product markets.)

Kristof Van Tomme (not verified):

Strictly speaking WordPress disrupting Drupal would not classify as a clear-cut case of disruptive innovation. Drupal is not a monolithic organisation. We are able to undercut ourselves, there is no single player that has the dilemma. Because we are a distributed community that welcomes new entrants that not yet have vested interests in higher prices we are by default somewhat immunised against this.

That is why I prefer to think about this as the Japanese Gambit, rather than disruptive innovation, referring to the way the Japanese car manufacturers destroyed the American car industry.

The recipe for a Japanese Gambit is:

  • Find a market with a large group of customers with unmet needs because of a too high price point of existing solutions.
  • Make a cheap product that marginally fulfills their requirements.
  • Use the learning curve of a higher volume market to out-innovate the established competitors.

The centralisation of Drupal developers in larger and larger companies is I think a clear risk to Drupal, especially if this doesn't come with an equal increase in the number of smaller companies.

I think that we should be paying more attention to the health and growth of our grassroots:

  • A too competitive job market makes it hard for small companies to hold on to professionals they help train for the system. If people are siphoned off into larger conglomerates, this undermines the health of the community.
  • If too many deals flow to the same companies in the eco-system, this will make Drupal more centralised.

Centralisation makes communities more fragile, 2 great reads on this subject are:

  • The starfish and the spider - that explains how the Apaches were able to withstand the attention of the US army for so long and how they ultimately failed.
  • Antifragile: Things That Gain From Disorder - about how small bets with an asymmetrical down and upside help make systems antifragile. One of the key points in the book is that bigger systems are by default more fragile and that it's better to have a large group of small bets in a noisy unpredictable environment. That way you don't need to know what the future will bring, because at least some of your bets will address it and pay off.

Drupal distributions are a group of small bets, not for the companies that build them because it costs too much resources to make a distribution, but for Drupal as a whole they are low risk high upshot bets. As a community we should be helping the risk takers in the community that are making these bets for us, I think this is as important as contributions to Drupal core. The long term future of Drupal depends on it. I think that Acquia's efforts to help distributions like DKAN and earlier WalkHub are an important effort in this direction.

Maybe we need a grant program that encourages consultancies to develop and release distributions. With at least a partial support this could help to make the community more robust.

Dries:

Great reply, Kristof! I haven't read these two books yet, but Antifragile has been on my reading list for a couple of years.

You wrote: "The centralisation of Drupal developers in larger and larger companies is I think a clear risk to Drupal, especially if this doesn't come with an equal increase in the number of smaller companies."

While it is true that we have larger and larger Drupal companies, I also see (a) new Drupal companies emerge and (b) existing non-Drupal agencies starting up Drupal practices in addition to their Adobe/Sitecore/.../WordPress work.

The lack of good data on Drupal's growing and evolving ecosystem is one of the reasons I'm so excited about the organizational commit credits. Soon we will be able to start studying how our ecosystem evolves, how much of the Drupal project is volunteer driven, the impact of large Drupal companies vs small Drupal companies, and more. It's all pretty exciting to me so let's hope the commit credit tools get adopted widely!

Gabor Lutor (not verified):

Drupal has an amply capable SMB ecommerce solution – it’s called Ubercart – that seems to have been thrown under the bus to help Drupal Commerce get off the ground. Now that Drupal Commerce is on its feet maybe it’s time to give some love back to its predecessor!

just-passin-thru (not verified):

You should get your facts right. No one "threw Ubercart under the bus". Indeed the founder of Drupal Commerce tried to bring the improvements and reorganized code to Ubercart first. it was only after they refused, that Drupal commerce was born. And no one's going to go backwards to Ubercart I don't think.

Gabor Lutor (not verified):

If you read Dries’ post, his main point is that the ecommerce landscape is getting delineated such that Drupal with Drupal Commerce is more competitive in the enterprise segment, while WordPress now with WooCommerce is poised to make inroads in the SMB segment. Although he says

“Drupal has a rich library of commerce solutions … “

it’s implied by omission that Ubercart is not a viable SMB alternative, though in my experience it is. It’s the omission of Ubercart in any current discussion of ecommerce on Drupal that to my mind constitutes “throwing under the bus” despite it being used on almost the same number of sites as Drupal Commerce and being under development for Drupal 8.

Ryan (not verified):

Hey Gabor, it's certainly good to point out that Ubercart still solves a problem for many business. I wrote it to migrate the small business I was on from osCommerce into Drupal, and many young businesses in the same spot that ours was will still find it to be a suitable starting point.

I won't presume to speak for the continued development of Ubercart. TR and longwave picked it up and ran with it, and I haven't kept close tabs on it for some years. However, I do know that an eCommerce platform needs two things to succeed: some entity (it doesn't necessarily need to be commercial) driving it forward with a vision for its future and a communication channel / the means to make it a reality, and a growing, active user base that drives continuous innovation of the platform. The company that sponsored me in developing Ubercart is not a major force in its development any more, and the user base is slowly migrating to Drupal Commerce or non-Drupal solutions. There are still thousands of sites on it, but I think it's fair to say that a majority of contributors switched to Drupal Commerce a while ago.

Drupal Commerce doesn't perfectly fit the Ubercart use case because it forces a more rigorous product data model. However, Commerce Kickstart 2.x (or the modules that make it up, used outside of the distribution) went a long way toward recreating the previous feature set on the new architecture; this was always our goal, but we couldn't make it a reality without a real business case to drive it. Most of our contributed module development has been customer funded, and our customers just continued to skew higher in the market or toward other use cases (e.g. digital commerce, Commerce API servers, centralized product enrichment portals, etc.). I'm very proud of the Inline Entity Form module we developed, though, and I'm excited to make it a dependency for Commerce 2.x on D8 to provide a much easier user experience for new users.

At the bottom end of the market, though, I personally think most SMBs would be better served by Shopify or a similar SaaS offering. There are still plenty of businesses that that doesn't make sense for (non-profits raising donations, event websites selling a mixture of other products, digital commerce / premium content businesses, etc. - Drupal is still a better fit than most SaaS solutions), but there are plenty of small businesses where it's perfectly valid. Consider the feature set the Drupal Association takes advantage of in Shopify - it's a no-brainer for them to use that vs. spend months of their own engineering time or thousands of dollars on contractors just to achieve near feature parity... and they get it all for tens of dollars a month now with no maintenance cost through a SaaS vendor.

Enter the promise of a WooCommerce acquisition by Automattic. You now have a large organization buying a vendor of a tool used by hundreds of thousands of merchants, clearly with a vision to provide ongoing support and integration of said tool into its SaaS platform used by millions of people. I'm not familiar with WooCommerce's ecosystem or maintenance requirements, but as Dries said, this at least gives Automattic the tools they need to fend off Shopify, Squarespace, Wix, etc. Drupal has never come anywhere near this scale with all of its eCommerce solutions combined, and in fact our monetization model for modules really prevents it - I prefer our model, but I'm willing to admit it just won't support a vibrant competitor at the low end of the market.

Anyways... I've spilled too much ink in this comment. I'm sure I'll flesh out some ideas in other responses below. Moving on and starting afresh on D7 with Drupal Commerce was honestly one of the most difficult decisions of my professional life, and though I believe we've created a more robust solution in Drupal Commerce, I'm still glad to know you're experiencing continued success implementing Ubercart for your clients.

Gabor Lutor (not verified):

Thanks for the perspective, Ryan. You’re clearly right in pointing out the diverging trends pertaining to Drupal Commerce and Ubercart. Whatever their respective merits, I think it’s safe to say Drupal is richer for having both.

Steve Purkiss (not verified):

Providing solutions to SMBs is where I started 25 years ago and I'm excited about Drupal 8 and the possibilities for industry-specific distributions providing tailored solutions for SMBs. Each small business type (think hairdressers, coworking spaces, life coaches, etc.) has its own workflows which can be easily implemented and extended with Drupal, and whilst software like WP/WooComm provide (currently) low-cost solutions, it's still putting the onus on end clients and (mostly) less technical people to implement. It reminds me of the age of many car manufacturers - at the moment everyone seems to be building a custom car for someone who simply needs a Ford Escort to get from A to B.

ATEOTD businesses want to focus on what they do well (accountants, B&Bs, etc.), not supporting their software infrastructure. By providing an eco-system of 'out-of-the-box' configurations for different businesses (think car/van/truck etc.) plus a network of local suppliers and support you end up with products made by experts which just do the job they are made for. There's not much in terms of functionality under most the 'themes' I see for small businesses, and I also think they are missing out on what Drupal does best - sharing expertise. Bringing groups of SMBs together is a change in the world which Drupal could bring, and who knows what the outcome would be? Sharing knowledge and growing the commons is what Drupal's all about, I see much, much less of that in other projects.

So it's great WP is catering for people now, but in the long run it's my belief a better answer can be made with the project you started Dries!

Ryan (not verified):

Steve, I think you have the right idea. If I'm an independent Drupal developer or small shop, I'd be picking a vertical and developing a custom distribution addressing its needs. I'd personally opt to sell it as a managed service, which means I wouldn't be aiming as low in the market as you're describing here, but you could always front load the sales work and get a handful of customers together to fund the development of a light distribution instead.

The big question I ask myself is: why should a small business with limited capital and maybe an unproven track record in the market invest either time or money in a custom solution? Why not Eventbrite? Why not Shopify?

I'm hardly a pessimist - writing Drupal based eCommerce solutions is kind of my bread and butter - but in the interest of helping small business owners make wise decisions, I believe I owe it to them to at least present these alternatives while they're just launching their businesses.

Steve Purkiss (not verified):

Thanks Ryan - there are examples-ish starting to appear - look at rooms and their now three offerings. I went to the BoF in LA and hopefully gave them a few ideas re productising and what people are looking for ;)

My feeling is we do it through bringing groups together - industry-specific events, for SMBs, to teach them how to collaborate. They must be able to have clear benefits from the collaboration - for example B&Bs in Brighton - wonder how many different systems they pay for & how good/bad they are? What do they like? What do they want? What could they gain from collaboration? Lower costs or something more like sharing capacity knowledge for larger events? Who knows what the outcome will be when you Drupalize an industry ;) No point in us guessing those, we just need to go out and do it.

Which reminds me...

Mario Peshev (not verified):

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.

Hey Dries, I'm not following here - how is the partnership between the platform powering 24% of the Internet with WooCommerce running 24% of the eCommerce market (https://trends.builtwith.com/shop - "The Entire Internet" on the right) solidifying the fact that WordPress dominates the small market?

It's obvious that the vast majority of those websites are blogs, small business sites and generally solutions that could be built in a matter of days, if not hours. But I would not necessarily say that WordPress isn't focused on large organizations as well - giving WordPress.com's VIP portfolio of clients, and thousands of other large portals built by leading community agencies for top brands and organizations.

Even though Drupal is still a preferred choice for various verticals, I wouldn't rule out WordPress as a competitor and I don't believe that it is incapable of handling those large projects. As a matter of fact the partnership with WooCommerce will probably lead to more strategic partners such as international chain stores running their eCommerce business on WordPress as well.

I won't comment on the final bit covering "complex requirements" since I don't see any evidence of that or facts supporting the lack of extensibility or scalability of a WordPress-driven project.

Dries:

When I use the words like "large" and "enterprise" I generally mean "more complex" and not "high traffic".

I agree there are a plenty of large organizations 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 brand, but relatively simple site requirements.

Drupal has features not (easily) available in WordPress, making its scope larger, broader and often more suitable to handle more complex projects. The flip-side is that Drupal can be more difficult to use and develop for.

Mario Peshev (not verified):

I'm curious about some specific examples here. I've built Drupal solutions for two years as well (and spoken at a DrupalCamp even), so I'm not trying to be offensive here.

However, I'm also interested in shedding some light on "complex". What do you understand by "complex" and something that's not common or straight forward with WordPress?

Dries:

It's hard to provide a solid comparison of Drupal and WordPress without getting into specific details. Another time, I should write a dedicated blog post, or blog post series, to do such a comparison justice.

Fundamentally, Drupal has better support for content types, content relations, content versioning, taxonomies, localization, fine-grained access control, configuration management and more. Out of the box, WordPress simply doesn't provide the same level of functionality. I realize that you can do similar things with a combination of third-party WordPress plugins but that is often not as robust or well-integrated.

For a concrete example, take a look at Drupal 8's built-in caching functionality: see https://dri.es/making-drupal-8-fly and https://www.youtube.com/watch?v=NHe9JtIp5fk. Drupal's out-of-the-box or built-in caching infrastructure is much richer than WordPress', and as a result, every module developer is forced to build modules with more advanced cache-ability in mind. For complex websites with lots of authenticated user sessions and lots of personalized content, Drupal 8 will provide much better scalability than WordPress.

All the functionality mentioned above really defines the platform and the module ecosystem, and can be hard to bolt on through third-party modules or plugins. You want that richness and robustness to be an integral part of the core platform, so it is available to every module developer and leveraged in every third-party module.

Mario Peshev (not verified):

Thanks for the detailed response Dries, it's appreciated.

In a practical environment I don't think that Drupal or WordPress can serve a complex website simply "out of the box", without a lot of additional work for each of the platforms. That said, the underlying framework has to be stable and extensible enough, but there's a lot going on when it comes to additional modules (and building custom ones). And both platforms are scalable and extensible enough in order to provide (one way or the other) a flexible and feature-rich infrastructure - including the granular permission management, controlling post types (nodes), taxonomies, or anything else.

There are indeed some nice improvements coming in Drupal 8, fragment caching and purging cache on a per-user basis is not supported in WordPress right now, that's solved with different plugins and libraries. I also like the idea of Drupal embracing Symfony which could drastically increase the Drupal community and simplify the core model for new developers.

I concur with the point that a powerful caching API could serve as a guideline to module developers which generally enhances the module infrastructure.

Looking forward to more detailed posts on the subject.

Dries:

The caching API is only one example of how Drupal's out-of-the-box APIs are more powerful compared to WordPress', and how that affects the entire third-party module/plugin ecosystem. Most of Drupal's subsystems are more advanced or more powerful than WordPress'.

For example, Drupal's built-in custom content types are more powerful compared to WordPress', and just like it is the case with the caching API, that cascades down to thousands of third-party modules that leverage those APIs. The result is that Drupal tends to be a better choice for websites that have to manage complex content types, content relations, etc. Building the same site using WordPress is likely to be more work and less robust.

When building a simple website, Drupal's more powerful APIs might not be an important differentiator. Simple sites might not need more advanced caching or more extensible content types. In fact, Drupal's extra complexity is likely to get in the way. People generally want to use the simplest solution to solve their problem and as a result WordPress is likely to be preferred; see Ockham's Razor Principle of Content Management Systems for my thoughts on that.

Greg Boggs (not verified):

WordPress has some great things going for it. A big pain point on Enterprise Drupal sites is the cost of maintenance for updates. It's not uncommon to spend 40-80 hours to update a module and test it throughout a giant site. By contrast, WordPress has a one click upgrade between Major and Minor versions and automated security updates. This feature in Drupal would save a certain fortune 100 company millions of dollars in maintenance and avoid tedious work for Drupal developers.

On the other hand, building Search API or Workbench Moderation in WordPress would be an extremely daunting task.

Larry Garfield (not verified):

It takes you 80 hours to update one Drupal module? What are you doing, typing it in by hand, reading off of the git log? :-) Routine module updates for me, if doing a couple modules at once, generally take an hour or two if I'm being thorough.

If you have Drush installed, it's a one line command: drush up modulename. If you have the pecl ssh extension installed on the server you can even trigger it through the UI, if you enter your shell credentials. (Not doing that is a security hole.)

Yes, you should still test it before deploying to production. That's true regardless of your platform. If you have automated tests for your site, that's pretty easy. That's true regardless of your platform. If you don't, that can be pretty hard. That's true regardless of your platform.

Bear in mind, Wordpress's "one click update" of a module, if done on live, is very quick and easy and also dangerous because you're updating code on live. Please don't do that, regardless of your platform. You can do that with Drupal just as easily, or nearly so, and it's just as bad an idea in each case. A proper test environment is recommended for both, and should be pretty low overhead for both.

Really, if your developer takes 80 hours to update a bugfix for a module, fire your developer and hire someone competent. :-) The problem isn't Drupal, it's a bad developer.

Greg Boggs (not verified):

If this were true for every upgrade, I'd never talk about upgrade paths. In fact, I'm hesitant to mention the module because the developers are brilliant and committed, and it's been fixed in recent versions. I expect the next upgrade of the same module to be easy.

Mario Peshev (not verified):

There's one more point I'd like to touch on speaking of core APIs.

The caching API in D8 is pretty awesome, and that's obviously true. Discussing the content type and taxonomy management in both platforms is something that I find subjective, mostly due to the different use cases.

Having a solid API or even core modules that are fully customizable is great, makes the platform easier to use, more unified, and also sets some work standards for all developers interesting in extending the core platform.

But there are things in both WordPress and Drupal that are integrated in one of the platforms and decoupled as modules/plugins in the other one - and sometimes it's for a reason.

An example is the multilingual support. There are plenty of ways to do that, and that depends a lot on the context. A site with 12 languages has a specific data management that makes sense which may not be the case for a site with 2 languages and 10 different node/post types to manage. Different sites may actually be bundled in a multisite if they are quite different, depending on a language. The multisite UI being a part of the WP core may be implemented in other ways that may be easier for specific groups of projects.

It's similar for post type/taxonomy management and caching. WordPress for one provides at least 10 different ways to extend post types or taxonomies, or implement different caching layers. They are not core add-ons, but some options are preferable for large clients, especially if the platform is to be integrated with other platforms. For example, if Memcached support was in core, who says that Redis is not a better option for a given large platform? It's all context-dependent.

And if we take a look at the big picture, it's similar to what different vendors do in different programming platforms. For instance, the .NET guys have ASP.NET Web Forms and ASP.NET MVC. These are the two frameworks that one can use. They're controlled by Microsoft (and the top players around them).

PHP has hundreds of frameworks and CMS that solve problems in different ways. Even if Zend have their framework (being a top player behind PHP), it's definitely not that dominant as compared to Microsoft's stack.

Java also provides a lot of frameworks and a few CMS, and the Java EE standard defines JSF as the main framework. The coming Java EE standard will also include Spring MVC as an alternative preferred option, similarly to ASP and their MVC, but in my opinion the Java case is a mix between the freedom in the PHP world and the lockdown in the .NET one.

What I'm saying here is that a good discussion would be to what extend including "decisions" as a part of the core platform is a better choice than creating it modular and clean, and easier to extend in a different way based on the use case?

Correct me if I'm wrong, but I think that Drupal 4 had an install path at first where you can pick the type of Drupal setup that you need: just a framework, blog, CMS or something else. If that was the case, I find that a great way to use the platform and extend it in a way similar to your "Distributions" that let you build a project with a combination of the Core platform and a bunch of modules - just like Ubuntu or other popular Linux distributions ship packages with X environments and extra software within them.

Ryan (not verified):

Acknowledging my ignorance re: Wordpress, it's at least been my impression as a casual user / supporter of WordPress that the strength of Drupal over WordPress for complex applications wasn't just in its core framework. It's also in its contributed module ecosystem that favors interoperable sub-systems over the silos of functionality that I see in ecosystems driven by premium plugins (e.g. Wordpress, Magento). I spoke briefly about this at DrupalCamp Florida a couple years ago.

In Drupal, the most popular contributed modules are those that enable developers to do exponentially more due to integrations with modules / sub-systems maintained by other developers and organizations: for example, you can combine Views + Rules + View Bulk Operations to program bulk update operations for any entity list in Drupal. There is no financial incentive to over-enrich a single module or set of modules and a strong social incentive to write modules that work with others' modules.

Drupal Commerce followed this paradigm, focusing on providing the minimal set of building blocks you need to build an eCommerce application and the integrations with other modules needed to let developers build out a wide variety of features on their sites. A concrete example would be a simple table based shipping calculation. In Drupal Commerce, you just need the Flat Rate Shipping module to give you the ability to define a shipping rate, and then you take advantage of the Rules module to create the "table" or set of conditions that must be met for a rate to be made available for an order. In WooCommerce, you grab a $149 extension and can use the conditions determined by the plugin author.

Now, $149 isn't a lot to pay to add mission critical functionality to your site, though I don't know how much developers spend on average across all of their plugins to launch a WooCommerce site. But what if I want to combine it with some other plugin maintained by another developer that uses a GeoIP lookup to pre-select a shipping service before I know a customer's shipping address? In Drupal, I'd use a Rules condition from the GeoIP module, but in WooCommerce I don't know what my recourse is given there isn't a generic third party module being utilized by all plugin developers to expose conditional behaviors through the UI.

This is probably an overly simplistic example, unfortunately, but I think it illustrates my understanding well enough. (Please let me know if I'm wrong - you have a lot more experience on the flip side. : )

By focusing on abstract interoperable sub-systems in our contributed module ecosystem, we have common solutions for building web services, international stores (encompassing multiple languages, currencies, and domains and Rules based tax / shipping / payment method determination by region), constructing data models to match back-end fulfillment / analytics / accounting systems, etc.

While I think most small businesses will probably save money by hitting the plugin buffet and adapting their businesses to fit the constraints of the plugins, larger organizations with budget to develop custom web applications that accommodate their complexity will (most likely) get a lot further using the Drupal ecosystem as a foundation. Simple vs. complex organizations are looking for something different "out of the box", and while Drupal won't give them more OOB functionality, it will provide a very rich OOB development framework.

Semi-related thought here - I bet we spend as much time on some projects ensuring we can manage / deploy the code and new features as we do developing the features themselves. That isn't OOB functionality in D7 but will be closer to a reality in D8. On any given project today, the majority of our time is third party service integration and data migration.

dougvann (not verified):

Kristof said: "We need to keep Drupal accessible and useful for the DIY SMB crowd. If we don't, we will be out-innovated. WordPress is not going to stop at SMBs they also want the enterprise market.".

I couldn't agree more. But the "DIY SMB" crowd is simply NOT the target audience for what Drupal 8 is. Drupal 8 is already awesome and I very much enjoyed giving a demo-session at SxSW this year. I'm looking forward to my 1st Drupal 8 project! I'm also looking forward to seeing what these large, and getting larger, shops are going to do in the enterprise!

However ... If I'm realistic and honest about all of this, I also recognize the fact that the CMS I fell in love with in 2007 has moved on. Yes, we expect progress and innovation. Yes, we expect abstractions layers. Yes, we expect getting further off of the island.

I am among the growing many who believe that our clear departure from "DIY SMB" was inevitable and, if we're honest here, a little late. As I progressed along my Drupal career, I clearly saw those, who I've coined as the "Comp-Sci crowd", move from frustration with Drupal's architecture to borderline disdain. Indeed, we all saw many cross that line, some of them quite publicly.

Thus ...

We now cater to the "comp-sci" rather than the "DIY SMB." Are there crossovers in these two camps? Definitely. But that is a marginal group for sure.

What then?

Faithful followers of my rants are now expecting me to bring up Backdrop CMS so I shall! I believe that Backdrop CMS is the natural, "more accessible", solution decision for those who love the power of Drupal 7 and don't want to re-tool, re-hire, or re-learn to the extent that Drupal 8 requires. I know it's not rocket surgery or brain science. However, it is NOT architected towards the "the DIY SMB crowd".

WP is innovating, collaborating, and acquiring. Having watched Matt and the gang for years, I have the utmost respect [as do we all!] for his vision, his team, his product, and his brand. Drupal is "moving out of the neighborhood" and leaving money on the table. We are seeing the WP community wringing their hands in anticipation of decreased competition on smaller projects. At the same time, WP continues to move up the scale to remain competitive on the larger projects.

Conclusion ...

WP will remain even more competitive at the lower end and will become more competitive, still, in the larger. To rephrase that, WP is getting more competitive across the board!

When Kristof says "we need to keep Drupal accessible and useful for the DIY SMB crowd", I have to conclude that what is being described is not, in fact, Drupal.

- Doug Vann

Dries:

When you or other people in the Drupal and WordPress community use a term like "DIY SMB", I get confused. For all of us to have a meaningful conversation about Drupal's target audience, we'd benefit from tightening up our vocabulary and definitions.

The terms "micro-business", "SMB" (small and midsize businesses) and "large business" are defined differently in each country. For example, the European Union defines "micro-businesses" as those that have fewer than 10 employees and less than 2 million EUR in revenue. The United States government defines a micro-business as a business with five or fewer employees. In Australia, a "micro-business" or "micro-enterprise" refers to a business with up to 20 employees. A "small business" is usually defined as an organization with more than 5 employees but fewer than 100 employees; a "midsize business" is an organization with 100 to 999 employees. The second most popular attribute used to define the SMB market is annual revenue: small businesses are usually defined as organizations with less than $50 million USD in annual revenue; midsize businesses are defined as organizations that make more than $50 million USD but less than $1 billion USD in annual revenue.

When you or other people use the term "DIY SMB", what exactly do you mean? First, using the definitions above, do you mean micro-businesses instead of SMBs? Second, what exactly do you mean with DIY? Does DIY mean the business does not have access to experienced web developers and that the business owner may be responsible for building his/her website?

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' as a dimension. Per my earlier comment, large multi-billion dollar businesses have websites with simple requirements and often use WordPress for them. On the flip-side, a small business may have complex website requirements that favors Drupal over WordPress. I believe we can fold "size of organization" into"(a) the website requirements"; e.g. large organizations may have different security requirements than micro-businesses.

If you agree that (a) and (b) are the most meaningful dimensions when we talk about Drupal's target audience, we should probably flush out the underlying vocabulary some more. The conversation would benefit from a well-defined shared vocabulary.

Either way, I'd love it if you could restate some of your thoughts with (a) and (b) in mind. It sounds like your primary concern with Drupal's evolution relates to (b) instead of (a)?

dougvann (not verified):

I wholeheartedly agree with Dries' statement that the most meaningful dimensions are (a) the website requirements, followed by (b) the skill level required to develop the website.
Within both of those distinctions, Drupal 7 [and earlier] has proven highly flexible.

There are D7 sites of a size and complexity that only a big Drupal shop could create. Likewise there are D7 sites that look beautiful and get the job done but were built solely by the client or with minimal assistance from a freelancer.
On the simpler end, I believe Drupal 7 [and earlier] presents itself as a DIY solution. Whereas a WP theme for $99 may get you quite close to your vision, it may employ techniques and solutions which require a unique learning curve outside that of WP as a whole. Building that same site in Drupal affords the opportunity to do so with a single, knowable architecture that is the same, or very similar, architecture you will use on your next projects.

Understanding content-types, fields, views-displays, etc. becomes a core competency that empowers organizations to innovate very quickly in a short period of time. As the need arises [and we know it does] to dig into the Drupal API, again the client is faced with a well documented mostly homogenous system which allows them to "hook" into a given point of Drupal's workflow then to conditionally check for some state then to alter that work flow. What's crazy is that many things I used to write 10 or less lines of code for in Drupal 5 & 6, can now be handled by simple modules in Drupal 7. Still though... That oh-so-flexible hook system is GOLD when I teach it to Universities, Governments, private industry, etc. They realize that they now OWN their website, OWN their code, and OWN the future of their website. They can quickly learn more by watching a buildamodule.com or drupalize.me video OR a video from DrupalCon or DrupalCamp. They can also show up to these events and make sense of it all. Power begets power begets power as they seek to avoid becoming a full fledged Drupal mega-shop while, at the same time, accomplishing their web publishing and web applications needs.

I have just accurately described the DIY crowd. This is the crowd that I believe D8 is leaving behind. [I freely admit that "some" percentage of the D7 DIY crowd will make the move, but I want to serve what I expect to be the very large remainder] I believe it was time to leave them behind. We know the famous faces of Drupal who have wanted this for a very long time. I've heard the complaints that Drupal is built on a 1990's architecture and I agree. But I also know who doesn't care. Weather.com, and major media organizations and major governments of the world and major pharmaceutical companies of the world. None of them care that we're passing variables by reference. None of them care that the $user object is not in scope by default. They launched on D7 and they're very happy with it. They have learned the ins and outs of the API and they're getting the job done. When they want to move beyond D7 will they go with D8 or switch platforms? If they're going to switch, I say "keep it in the family" and switch to the natural evolution of D7 which is Backdrop CMS.

I fight for the users!
[Said of Tron in the 1st movie & spoken by Tron in the 2nd]
As one who fights for the users, I need to position myself with a solution that can empower them and meet them where they live. WP is not that solution. Users require a more robust core API and a system architecture that is within reach. D8 is for shops and the ever-growing mega-shops. I KNOW they will do marvelous things with D8 and I am very anxious to see it!

I make a comfortable living as a sub-s corporation with one employee, me. Throughout the years, I have grown my business skills and Drupal skills to achieve a level of success that I never thought possible, and all that with no degree and only a couple college credits. All this was possible, thanks to the DIY nature of Drupal and the Drupal community. As I push on, I will attempt to live in both the D8, the D7, and the Backdrop CMS world.

Time will tell if the new ecosystem around D8 will be inclusive to the DIY clients that are the foundation of my success. I'm not so sure. A growing number of us Drupal people feel that Drupal 8 is not "our" CMS. I don't believe the mega-shops need D8 to cater to the DIY crowd. Rather than have DIY clients move to WP, I'm promoting Backdrop CMS!

Larry Garfield (not verified):

Doug, I'm going to ask you to unpack that a bit. I know Backdrop adherents keep repeating the line that Drupal 8 is "not good for the DIY crowd", or "only for pros", or other such lines. However, I see no evidence that's true. At all.

What exactly about Drupal 8 makes it less-good for casual users, small businesses, etc?

Is it that it's mostly OOP under the hood? As you say, end users don't give a damn. They care about the functionality it offers; if being OOP makes it easier for us to offer that functionality, great, but they still don't care.

Is it that a lot of things how happen without hooks? If anything, Drupal 8 is *more* "hackable" than any version before, precisely because we're not using hooks for everything. It's now possible to remove and replace code, not just pile it on. We have a number of extension mechanisms now, each one suited for a particular purpose rather than a sledge hammer of "alter all the things!"

Is it that the code base is larger? Really, when you add in all of the contrib modules that D7 needs that D8 bakes in, it's not a dramatic difference. But now it's all there out of the box, so the DIY crowd *doesn't need to know* that they have to install Views and Date and Entity Reference in order to make Drupal useful. It is useful as soon as you install it.

Is it that WYSIWYG is baked in finally? :-)

Really, no one has given a reason I can see that Drupal 8 is supposedly not-good for smaller players. If anything, it's better. The only place it's harder is for developers already fully versed in Drupal 7's idioms, for whom the idoms have now changed and are accessible to *more* developers, not fewer.

So please enlighten me: *Why* do you think Drupal 8 is leaving DIYers behind? Because I see the exact opposite...

Ryan (not verified):

FWIW, I see D8 as more hackable, and more predictably hackable (i.e. fewer unintended side effects when hooks fire out of order), but it does require a different skill set than most PHP developers start with to know how to hack it. The hook system, for all its drawbacks, is a very easy concept to understand and implement. :)

Larry Garfield (not verified):

That statement hinges on the definition of "most PHP developers".

I've spent more time in the last 3 years talking to non-Drupal PHP developers than probably most other core developers. (No doubt someone in the top 50 is going to come along and point out that he's secretly a Joomla and Zend developer by day, just to prove me wrong...) At least the "most PHP developers" I know are very excited for Drupal 8.

The hook system, for all its benefits, makes sense to *absolutely no one* except Drupal developers, and those that Drupal developers have trained. I've given early (some would say premature) training sessions on Drupal 8, and had developers from PHP and even other languages look at Drupal 8 and go "oh, this makes sense, OK", right up until they hit hooks. Then they flip out. I believe Angie Byron has similar stories.

While 10 years ago "most PHP developers" might have looked at hooks and gone "wait, what? eh, OK", today they look at hooks and go "WTF is this sh1t?"

Testable, injectable classes are very much the skillset that "most PHP developers" have coming to Drupal, or really most programming these days. That's what's changed in the 10 years that I've been involved in Drupal, and we're finally catching up.

Ryan (not verified):

To be fair, I said than "most PHP developers start with." I'm not trying to contend against you (I'm excited for D8 and eager to learn more), but I believe my experience of starting with playing around in source files and learning PHP as I went is what a majority of folks do (given how broadly PHP is used in the web development community).

We all mature, but I literally learned PHP while hacking on osCommerce and then writing modules for Drupal 5 (betas), and the hook system never bothered me. I'm fairly confident I couldn't have done the same starting with Drupal 8 - it just requires a lot more domain knowledge about programming in general (and then about Symfony and Drupal in particular) than us script kiddies started with. ; )

dougvann (not verified):

Larry, I accept the challenge.
My goal here appears to be to convince you that D8 ROCKS for ppl who work in shops -- people like you. My closely related 2nd goal is to convince you that D8 will not be so welcomed by non-shop types. Call them SMB. Call them Micro-biz. Call them DIY. Call them hobbiests. It makes no difference what you call them. I call them a collective group who, collectively, spends a hell of a lot of money on improving their internal ability to own their site and related processes. Another name for this group is my bread-n-butter.

Point 1:
"As you say, end users don't give a damn."
Not exactly what I said. My position was that little to no one cares that D7 is NOT OOP or catering to the Comp-Sci crowd. Now that D8 DOES [finally] use more modern architectures and models, I have stated repeatedly that many DO care. Some welcome it and some do not. What are the numbers? None of us know.

Point 2:
"if being OOP makes it easier for us to offer that functionality..."
This is exactly where your perspective [as a senior developer of a worldclass "boutique" shop] on this limits you. When you say "easier for us" you are presumable referring to the shops. I am not talking about shops. I fight for the users. Yes. I am on record as saying that D8 is considerably easier for developers. I am among those who can not believe it took this long to get here. I am a supporter of the notion that there was no conceivable middle step to where D8 is now. D8 necessarily HAD TO make this quantum leap forward. Piecemealing these many changes across D8 and D9 and D10 could have spelled disaster. Bravely and boldly, the plunge was made. I am here to tell you that that change comes with a cost.

Point 3:
"alter all the things!"
That method got Drupal to where it is today. It moved millions & millions of dollars in oh so many countries. That approach won over entire companies, entire states and entire countries. Backdrop CMS takes that highly "hackable" idea & improves upon in ways that are a more natural evolution of the existing architecture.

Point 4:
Budget!
Budget is a limiting factor for smaller operations like SMBs, non-profits, autonomous departments of larger operations, DIYers, etc. They can't afford Acquia (or sometimes even Pantheon) hosting, they can't even afford to hire "developers", what they can afford are their own interns, and when those people are put in charge of the website, they choose WordPress.
Backdrop CMS positions itself as an upgrade path that keeps the organization in a familiar space that is continuing to innovate. In that way Backdrop CMS will benefit from D6 and D7 upgrades that either cannot afford the move OR do not want to leave a familiar architecture.
As far as non-Drupal based growth, Backdrop CMS again positions itself as an affordable and more "hackable" solution. And before you argue that D8 is more "hackable" than D7, please don't forget that you're a senior developer at a largely successful shop who has a pretty decent price-floor. Granted, I do not know your price-floor, but believe me. You do not want to the projects that I do with D7 and the projects I'm going to do with Backdrop CMS!

Point 5:
Who cares!?!?
In the end, we all win here. If the DIYs and SMBs or Micros, or "whatever" end up leaving the Drupal space, it is a calculated cost. The mega-shops wont feel it. The shops wont really feel it. The CQ5 shops and other platform shops who are actively retooling to cash in on D8 won't care whatsoever.

The way I see it Larry, you can say one simple sentence that will end this debate. "D8 simply will not appeal to ALL the fans of D7, especially those end-user organizations who take high levels of ownership of their site and are in any way resistant to the dramatic change in architecture."
To refuse to say that and mean it is to imply that all end-user organizations are excited enough at the D8 changes to invest the money they don't have and the time they don't have to re-tool their modest internal developers to be more like the developers you might find sitting in the same room with you.
I know you don't believe that.

Last point....
I would have no dog in this fight if it were not for the fork.
Without Backdrop CMS I would simply be resolved that, moving forward, WP is going to gobble up some [many?] of the smaller D7 sites.
BUT Because there is a Backdrop CMS 1.1 at the time of this writing, there IS a alternative to WP. There IS an alternative to major re-tooling. There IS a path forward that doesn't require casting away the former and highly successful idioms.
I believe in the market viability of Backdrop CMS. I believe in the demand for it. I believe in the positioning to sell it. I believe in the growing number of people surrounding it. I believe in the leaders of it.
I believe I've made my point...

Larry Garfield (not verified):

Sorry Doug, but I think you answered the wrong question. :-) None of what you said implies that D8 is going to be a weaker offering than D7 for "smaller" customers.

Well, one exception: Hosting budget. At the moment, yes, D8's hosting requirements are higher than D7's. That is certainly true, although D8's performance is improving continually (thanks in no small part to the fantastic work of people like Wim Leers and Fabian Franz). Drupal 8 will require more than $5 hosting... but that was already true of Drupal 7. Really, no one should be running Drupal 7 without an opcode cache, for instance; if your web host doesn't offer it, get a new web host. That hasn't changed for Drupal 8. Drupal 8 should not require Acquia/Pantheon hosting to run. It will require a non-bargain-basement host, but not an "enterprise" host. However, the difference from Drupal 7, especially given the evolution of the market and of PHP itself, should not be all that dramatic.

I will grant you, though, that customers who are looking at $5 hosting will not be well served by Drupal 8. (However, I'd argue they would be best served by Wordpress.com, not Wordpress.org, or by DrupalGardens.com, not Acquia Hosting.)

You also say:

The way I see it Larry, you can say one simple sentence that will end this debate. "D8 simply will not appeal to ALL the fans of D7, especially those end-user organizations who take high levels of ownership of their site and are in any way resistant to the dramatic change in architecture."

Ah, now we get to the crux of the issue! To answer this properly, we need to talk about two different use cases separately: NEW site builds and site UPGRADES.

I would submit that for a new site build, Drupal 8 is, and will be, a much better system for the small customer than Drupal 7 is/was. Far more functionality is baked in, well-integrated, well-tested, and ready-to-go. It will require less custom code than D7 for "mundane" sites. It will have an easier content editor experience, allowing editors to focus on their content, not on Drupal. It will have an easier site building experience, because so many first-class tools are baked in and don't need to be hunted for. It will be much easier to write themes for.

To paraphrase from my DrupalCon Bogota keynote, "We refuse to accept the idea that only big institutions can have configuration management that works". Hence, CMI, which is such a massive improvement over Features in D7 it's not even funny. (We have a new-to-Drupal developer at Palantir who is suffering through working with Features. It's really quite painful to watch and be able to do nothing to ease his suffering other than say "D8 will be better, I promise".)

So for the new site, the only way in which D8 is a regression for SMBs, indy's, or whatever you want to call them is, maybe, in slightly higher but not obscenely high hosting/system requirements. In every other capacity, it will be better. If you disagree, please give precise examples of how and why so we can fix them. :-)

For upgrades from a D7 site, on that point I will agree. It's going to be a very bumpy ride. There will be some sites that choose not to make that jump, or choose to make the jump elsewhere.

However... that's not new. Do you not remember the wailing and gnashing of teeth when D7 was released, about how hard the upgrade was? I certainly do. And when D6 was released. And D5. And D4.7. (I joined Drupal after 4.6 was released, so my memory doesn't go back any further.) Every version of Drupal, we hear that the difficult upgrade process is going to be the death of Drupal. And that we'll lose people. And every version we do lose a few, but the number of Drupal sites and Drupal developers in the world goes up.

Even with that, we advise our clients (and no doubt you advise yours) to skip versions. We have clients on D6 that we actively encourage to wait for D8; the clients we've built on D7 we will discourage from jumping to D8 unless there's some very specific new functionality they need. And so on. A Drupal 7 investment is valid for several more years, at least. It's not going anywhere.

Yet that's being addressed, too, with the switch to semantic versioning and feature releases within the D8 cycle, something made possible by our new architecture. For the first time in Drupal's history, core will be able to evolve and improve without breaking everyone's site. Honestly, I think that, more than any individual feature, may be the biggest thing about Drupal 8: We're finally in a place where we don't have to have boom-bust-break-allthethings releases. That makes it a better long-term investment than Drupal 7. (That doesn't help someone on Drupal 7 now, I grant, but it shows that D8 is for the long term.)

Which leaves the last point of contention: Drupal 7 developers who don't want to or can't relearn a new architecture. You are very correct that for them, Drupal 8 will be a radical, perhaps too radical, change. I have never claimed otherwise. In fact, I have in the past called out that the only group really harmed by D8's reinvisioning is those developers whose only programming background is Drupal 7 (which is, admittedly, a not-small number of people). For those people... I would submit that being so different than the rest of the PHP or programming world for so long means that *Drupal has already done harm to those people by making them learn completely untransferable skills*. By now directing our developer base toward more standard tools, we are trying to repair that damage. An investment in Drupal 7 skills is an investment in Drupal 7 skills. An investment in Drupal 8 skills is an investment in PHP skills.

Drupal 7's global mutable state model is a dying architecture. The world has moved on. Developers who cannot move with it... are doomed. The answer for Drupal is not to hold back; it's to actively work to help those developers we've helped train move forward with us.

The target audience for Backdrop, as I see it, is those developers "stuck" in a Drupal 7 mindset who do not or cannot move forward. That is, however, a finite set of people with an upper bound, and a population that will only ever decrease as time goes on.

Quite simply, I believe everyone is served by looking forward. I believe everyone is served by Drupal 8. I believe Drupal 8 will be easier -- for site owners, for site builders, for developers -- than Drupal 7. I believe developers, by and large, will be able to move forward with a more approachable, learnable, self-documenting architecture. I believe it will attract far more new developers than it scares off. I believe, firmly, that claims that Drupal 8 is unsuable by "small" sites or independent developers are unfounded FUD.

I believe I've made my point. :-)

Ryan (not verified):

Echoing Larry's comments a little, I don't understand how arguing in favor of Drupal 7's knowable architecture (granting that it's really only knowable by long time Drupal developers, not outsiders) represents fighting for the users. I don't think you'll find many users writing code, and if they're having to, we should probably be helping them not have to, not preserving the current way of writing it.

Dries has presented on this before. Drupal as part of the open source CMS landscape has helped deprecate the webmaster. The next step will be for it to deprecate the casual web developer. I believe he made that point explicitly at a Do It With Drupal event years ago, but you can also read his thoughts on this more recently from his blog post on the assembled web:

https://dri.es/the-assembled-web

Alex Vasquez (not verified):

This is an interesting topic. I haven't had many discussions with Drupal developers (WordPress dev myself) but the two recent ones I've had definitely hover around Drupal being more ideal for highly complex types of websites, where WordPress would have to contort in such a way to achieve similar functionality that Drupal may be able to do quite easily.

The custom field, taxonomy and content-type support provided by Drupal out of the box definitely makes me envious, especially where it pertains to content relationships. We have to do some creative gymnastics to achieve some of the same functionality.

There's a push in the WordPress eco-system to go after enterprise accounts. I do that myself (primarily in the education space). One conversation I had was with someone regarding what I specifically built with WordPress that I considered "complex." I'd pointed to some LMS implementations I'd worked on. The reply was that Drupal could easily do that. I have no doubt and an LMS is certainly not highly-complex, where it concerns the examples you have in mind I'm sure. In any case, WP continually moves to enter new spaces and enterprise is one I see more and more, as I see more talks given on how to approach and architect for such projects.

WordPress continues to build a stronger solution against the competitors you've noted such as Wix and SquareSpace. But, again, I see it still growing into more complex use-cases.

That said, is WordPress right for every use-case? Nope. In any case, I loved the article. Next time you're in Los Angeles, you should come speak at one of our meetups or WordCamps. Would love to have you. =)

Mario Peshev (not verified):

Thanks for sharing the other side of the coin with your readers Dries.

As someone who's been following the Drupal development over the past 7 years (at least the major innovations publicly announced), I can confirm that there is a pinch of subjectivity here whenever people are not equally familiar with both platforms.

And the fact that it's actually possible to build anything in Web with both platforms makes it hard to justify the fact that Drupal may be more mature in terms of architecture, modularity, granularity and more.

I'd be happy to read a detailed technical overview on both platforms that's objective enough to cover the pros and cons in both technical decisions. Including things like the Multisite part of WordPress since you got to admit that it's way better than Drupal's one.

A side-by-side comparison with more details for the achievements of both platforms would benefit both communities.

Dries:

We're getting a bit off-topic talking about multi-site but WordPress and Drupal both have good multi-site capabilities. Drupal has had multi-site capabilities in core since 2001, starting with Drupal 2. So multi-site support is not new in Drupal and there are many examples of large organizations using Drupal's multi-site functionality: Warner Music, Johnson & Johnson, Pfizer, etc.

Drupal's out-of-the-box multi-site allows you to run all the sites in a single database, give each sites its own database, or a combination thereof where you share some but not all database tables. By default, WordPress shares one database for all sites. Some enterprises will prefer Drupal's "one database per site" approach because it has security benefits (better resource isolation), scalability benefits (run different databases on different servers), and flexibility benefits (different sites can have different versions of a particular theme or module). On WordPress you can get some, but not all, of the same benefits by using the HyperDB plugin.

WordPress' multi-site support is better in that it provides an administration UI. Drupal's built-in multi-site support is operated from the command line. Acquia's Site Factory product provides an administration UI and specialized multi-site staging and code deployment tools on top of that, but it is a commercial offering. There are also open source solutions like Aegir that provide an administration UI for Drupal multi-site management.

All things considered, I wouldn't say that WordPress' multisite is "way better" than Drupal's. As you appear to disagree, I'd love to know why you think that is.

Mario Peshev (not verified):

It is indeed offtopic, but the short version is - I've been following the guide at https://www.drupal.org/documentation/install/multi-site for multisite setup in Drupal, doing some PoC project of mine. Unless there's some automation involved that I can't see from the outside, all of the work is fairly manual, or requires shell script (or some CLI) automation for new sites.

WordPress's multisite is installed with a single line of code + .htaccess or nginx.conf entries for the web server resolution. That's it.

New sites are controlled from within the admin, which means that you can create unlimited subsites, assign plugins and themes to them, apply globally used non-deactivatable plugins across the entire network, use drop-in plugins that let you switch your global logic for various things, including caching layers, the MySQL adapter, S3 storage and other things like that.

Let me know if that's not the case and you can do everything automatically after a core Drupal install is provided. With all the admin options for new sites, decoupled subsite management without code and so forth. The UI part aside (you've mentioned Acquia's Site Factory which I don't think that we can count here), but the overall work required isn't straight forward and I think that it's important, essentially for institutions like universities or SaaS companies that want some control - and it's part of WordPress's core.

On top of that there are free (and not only) plugins such as http://www.paidmembershipspro.com/add-ons/ for paid multisite membership levels, selling different accounts with limited granular access to data or plugins and more. Since we're in the multisite/SaaS development business, the majority of our projects are related to self-hosted SaaS solutions with users signing up and paying for different membership level with lots of limitations.

Now, we charge a lot for these obviously since it involves a lot of "external" work, server management, code reviews and what not. But if I'm a regular user interested in, say a membership website or a distributed CMS that's incredibly easy to set up for each independent user, that would not require any coding.

The resource isolation is a fair point, but so is WordPress's automatic updates (and generally updates) which are quite easier on a single database. And like you said plugins such as HyperDB let you distribute your database in several ways.

Keep in mind that I'm not ranting here since I actually like Drupal a lot. I also have a talk coming in September discussing architecture for different languages and platforms (PHP ones like WordPress and Drupal included) and some additions that are in progress for D8 will likely be included in my slides.

Martin from MKSE.com (not verified):

Sorry guys. While you look for references to your role in the market WooCommerce is taking world class client case after case. Every week.

Talking about the DemandWare (yeah, not Drupal) reference cases and *one* major Drupal Commerce site won't cut it. Your own "semi-large" client focus has been closer to the integration of e-commerce solutions (as well as Marketing automation and other Customer Experience technology) than WordPress for several years by now. Seeing what Sitecore (Commerce.net 2014), EPiServer (Mediachase 2012), SAP (hybris 2014) Adobe (close partnership hybris, Elastic path 2013) has done the last years you should have been better prepared than "just" offering Drupal Commerce and Ubercart.

Ryan (not verified):

I may be reading this comment incorrectly, but I don't really understand the disparaging tone or how it's responding to Dries' article. In one breath you seem to tout WooCommerce over Drupal based eCommerce solutions, and in the next you attack Drupal without really understanding the sheer number or complexity of eCommerce sites built on it. (I've taken part in more than your "*one*" that would make any eCommerce vendor jealous. : )

Were you just fishing for an admission that we should be doing better?

100% agreed.

Ron Northcutt (not verified):

Thats true, but I think it also validates the greater point that Dries is making.

While Drupal Commerce is an incredibly robust and flexible system, it does have limits (just like Drupal itself does). One mistake people sometimes make is to think that just because Drupal *can* do something, that it should. Its more about using the right tool for the right job.

In this case, large platforms like Demandware, ATG, Hybris, etc., are all purpose built for very large and complex ecommerce needs with fulfillment, store management, inventory controls, pricing changes, and so on. Trying to replicate all of this functionality in Drupal or WordPress would be expensive and would probably never reach the same degree of full functionality that the commercial platforms have for large, complex, Enterprise level businesses.

However, small to medium sized businesses with either simpler or very specific needs are often well served by Drupal Commerce or even WooCommerce. The nice thing about DC is that its modular and flexible enough to adapt quite well to a variety of situations... but again, its important to use the solution that fits.

My point is this - its not about "one system to rule them all"... thats a legacy thought process and leads to breadth of limited functionality instead of depth. When an organization is using Demandware/Hybris/ATG and getting the functionality they need out of the ecommerce management, they often find that Drupal fits in really well as an integration system for content.

Its the flexibility and ease of integration that Drupal offers that makes it so incredibly useful for large/complex/Enterprise customers... because of the way its designed, it can fit well into a variety of situations and can adapt to a changing landscape. This is why its often a good tool for complex sites - it is adept at managing the complexity.

WordPress and WooCommerce are widely used when the site requirements and system environments are simpler... and rightly so. Again - its all about using the right tool for the right job. There is a very broad spectrum of use cases where WP is a great fit! Thats why it has such huge marketshare - the longtail of smaller sites.

I think Dries will agree with me here - its not a question of which one is "better"... its a question about which solution makes the most sense for this *particular* use case today and in the foreseeable future. Sometimes thats Drupal, and sometimes its Wordpress. Sometimes its even a "legacy" or proprietary system (though I prefer OSS whenever possible).

But - if we get stuck on the "which one is better" train, then we are missing the entire issue.

David Aponovich (not verified):

I’ve been in many “what’s the right CMS for the job” discussions. I agree with Dries that this is more about website “complexity,” (or “capabilities” or “ability to meet requirements” or however else you want to describe it) and less about size of organization or traffic volume, etc.

On the issue of complexity…How about doing an objective analysis of the relative complexity of a subset of Drupal vs. WordPress sites. (Perhaps the 1k-traffic sites using those systems is the subset. Or some other subset.) Is it provable that Drupal is or isn’t used for more complex sites more frequently than WordPress? Or at least gain findings that establish guardrails for a discussion when it comes to comparing these CMSes?

Bring some rigor to the discussion. A "Website Complexity Index" – a scale that defines dimensions and factors of sites – could be created and tap into BuiltWith or other crawler info for analysis of the applications and integrations that exist on the sites. Add some subjective measure while we’re at it. Define a set of capabilities present across those Drupal and WordPress sites (from the basics to deeper, more complex functionality) and assign a score on that dimension, too.

Would a transparent objective analysis benefit each community and add clarity and insight? Would it help outsiders? Yes and yes. What would the research say about the meaningful differences in practice between Drupal and WP?

Go further. Even greater would be the chance for Drupal and WordPress users to hold community-to-community dialog --- challenge site owners using Drupal or WordPress to share even deeper details of their sites. Let everyone show their work, so to speak. Thoughts?

Georg Huber (not verified):

I'm a micro-sized "company" of two struggling developers who made the mistake to favor Drupal instead of WordPress. We liked the flexibility of Drupal 7 and that it can cheaply be hosted with GreenGeeks. Drupal 7 is well enough documented to make the often small changes that customers want, e.g. "add a Back-Button to forms".

All that talk about how wonderfully superior Drupal 8 is going to be under the hood due to declaring classes and using Symfony and Twigs and what else won't help us to convince the local library or Alpinist association to use Drupal and contracting us. They go for WordPress (this has just happened).

All this super duper fancy stuff about the internal workings and more expensive hosting reminds me of the hype about Windows Vista.
I will either switch to Backdrop CMS or WordPress. And who knows, maybe a new CMS surfaces within the next years giving us another option.

So keep on talking your big talk - but with that you won't win the hearts of really small businesses such as mine. (You may be paid for talking big, I'm paid for getting results as quickly as possible.)

Oh and before someone starts to say that I'm simply to stupid or to dim to tackle new technologies: I'm a physicist and earn my money also with inventions. So I can wrap my mind around new things. And by the way: I do code since 1980 so I have seen a lot of concepts come and go. But what I don't have is the time necessary to find out all the new ways things are done in Drupal 8. I don't get paid for the time to get to know Twigs, Symfony and all that. Nobody is paying me to learn new tricks and my reading about Drupal 8 as well as my experience with Drupal 7 tells me that this period of learning may take some months. Hey, in this time I need to make a living. And: None of my customers will understand why I simply can't "upgrade" their website. They point to WordPress and think that I just want to spend more time on their expenses. Everything I say sounds like an excuse to them.

I really loved Drupal 7. I' don't think I will ever say the same about Drupal 8. But thank you for developing Drupal per se.

Best regards,
Georg Huber