Last year I wrote a post about what the WordPress community could learn from the State of Drupal, Dries’ annual address at DrupalCon (aka the Driesnote, carrying a similar importance as Matt’s State of the Word in the WordPress community). It’s time for a 2015 update.
What can the WordPress community learn from the state of Drupal?
- The Drupal Association, which organizes DrupalCon and promotes Drupal adoption via marketing and developer outreach – offers a model for the potential evolution of the WordPress Foundation
- Outreach is critical. We can’t just speak to the WordPress community but need to reach out to potential users/customers and sell the benefits of the platform in a language they understand
- A willingness to experiment – with fundraising approaches, with the hiring of paid teams to supplement the open source core project (Mark Boulton design’s work on Drupal 7 for example) – has helped the Drupal community move forward. This doesn’t mean all those experiments would work for WordPress, but we should be open to new approaches
- The potential for organizational and client attribution on contributions is an interesting idea for rewarding companies who give back – though with caution about unintended consequences in terms of motivation
- There are benefits to the epochal release cycle from a marketing point of view – differentiating the old platform from the new. I don’t think WordPress should change to a four year re-architected platform cycle, but we should be doing a better job of articulating the more complex platform WordPress is today
I’ll apologize in advance for the length of this post, but there’s much to cover. The Driesnote from DrupalCon 2015 in LA has been published to YouTube and Slideshare:
I’d highly recommend watching it end to end, whether you think of yourself as part of a Drupal community or a WordPress community.
Some interesting takeaways for the WordPress community
My impressions here are driven by my experiences over the last 8+ years in both communities. Though I now spend the majority of my time with WordPress, I worked with and in Drupal for many years, and have great fondness and respect for the communities of people working on Drupal. (Per Drupalcores, I even have 3 commits in Drupal 8 core under my drupal.org username jeckman).
The intent is not to say the WordPress community should be more like the Drupal community, nor that the Drupal community should be more like the WordPress community, but that both can learn from each other. (And of course neither is really a single community – both are made up of multiple internal communities that sometimes share interests and sometimes compete).
Drupal Association vs. WordPress Foundation
The most immediate thing you’ll notice is that the first 15 minutes of the video isn’t Dries but an intro by Holly Ross, the Executive Director of the Drupal Association. The DA is similar to the WordPress Foundation, describing itself as:
an educational non-profit organization that tasks itself with fostering and supporting the Drupal software project, the community and its growth.
Dries retains ownership of the Drupal trademark, but the association has a right to use and defend the usage of the trademark; similarly, he retains ownership of the drupal.org domain, but allows its use by the association. (Automattic transferred the trademark for WordPress to the Foundation in 2010).
Unlike the WordPress Foundation, though, the Drupal Association feels more community driven and accountable: holding open board meetings, electing leadership from the community, publishing budgets and minutes, etc. Check out their pages on accountability, meeting minutes, and the 2015 elections.
In part this is the legacy of how the DA came to be – during what Dries described as the great server meltdown of 2005. This necessitated community fundraising to buy servers to host drupal.org – and in the absence of a dominant commercial company behind Drupal (Dries’ company Acquia would not be formed until 2007) there was a need for a foundation to take more ownership of the project’s community assets. In contrast, the WordPress Foundation was established in 2010, five years after Automattic.
(The Drupal community refers to “dee-dot-oh” for Drupal.org, in much the same way the WordPress community refers to “dot-org” for WordPress.org or “the make blogs” for make.wordpress.org).
The WordPress Foundation did publish a 2012 Tax Year review and said they “hope[d] to publish 2013 data sometime in the first half of 2014.” But overall the governance of the Foundation has been far less transparent and offered fewer clear paths to leadership for community members. (Could make.wordpress.org be owned by the WordPress Foundation the way Drupal.org is owned by the Drupal Association? Could the WordPress Foundation own organizing WordCamp US?). Of course community members can and do take leadership roles as volunteers in various community subgroups: training, community, meta, documentation, and the like – so maybe it is more an issue of clarifying the relationship between the community of volunteers, the Foundation, and Automattic – a perennial topic of fascination in the WordPress world).
To be clear, I’m not suggesting or implying the WordPress Foundation or Automattic has done anything inappropriate or unseemly. I think the Foundation has done tremendous work shaping and supporting WordCamps and other training opportunities. I’ve personally benefited from their guidance on multiple years forWordCamp Boston. Further, the WordPress Foundation has (through make.wordpress.org and community outreach) always been engaged directly with the community, especially in relation to WordCamps.
I do believe, however, that a more transparent and democratic approach to the WordPress Foundation’s governance and engagement with the community would be a step forward. It isn’t that I don’t believe the Foundation has the best long-term interest of the WordPress project at heart – I honestly do, and have admired the work the Foundation has done – but that open source communities tend to view secrecy as pathology. A more democratic function with specific and visible paths for community involvement (not just as volunteers but as leaders) could also accomplish more.
Promoting Drupal 8.0
The second thing I noticed was the approach the Drupal Association takes to promoting Drupal. Check out the landing page for Drupal 8 – including downloadable infographics, and specific sub-landing pages for developers, sitebuilders, CIOs, marketers, content administrators, and themers. (OK, so the “themer” and “sitebuilder” terms are a bit inside baseball – terms not really used in the same way outside Drupal – but still a strong attempt to market the software somewhat similarly to how proprietary offerings are marketed).
There’s also an introductory slideshow (61 slides) folks can use to walk clients/prospects through what is coming in the next release.
Drupal 8 Accelerate Program
Finally, the DA is also driving the Drupal 8 Accelerate program, raising over $200,000 to help push Drupal 8 over the finish line. (To be clear the DA is supporting the program, while the core maintainers actually get to decide what to support with the funds). It’s an interesting approach – not sure it’s one I’d like to see replicated in the WordPress community. We’ve seen our own share of crowdfunding campaigns and other mechanisms for funding core development and plugin development. I like that the program is able to award grants to folks who might not otherwise have the opportunity to dedicate themselves to contributing – which theoretically helps keep development more democratic.
I’d worry though about the message this sends to volunteers and to the community at large – that the program was necessary because the contributions of the existing teams weren’t enough.
Aaron Winborn Award
Real communities are made up of passionate, motivated individuals. Unfortunately one thing the WordPress and Drupal communities share is that sometimes the individuals we come to know and respect pass away.
The Drupal community chose to honor Aaron Winborn with an annual award, designed to recognize “an individual who demonstrates personal integrity, kindness, and above-and-beyond commitment to the Drupal community.” The award includes a scholarship and stipend to attend DrupalCon with recognition during the event.
Providing more ways for the community to officially recognize each other, as well as help fund travel to events (which the WordPress Foundation has also done as travel scholarships) is a great way to memorialize those we’ve lost in the spirit of their contribution.
The majority of the Driesnote intertwined a history of how the software came to be and reached maturity alongside a set of seven lessons extracted from that history:
Each of these lessons could also be applied to WordPress:
1. Everyone Lives By Selling Something
Early in the history of Drupal, Dries reached out directly to Jeremy Andrews from KernelTrap.org and pushed Drupal as a potential solution. Dries traces the downstream impact of that on the community to show the impact of one early bit of advocacy.
It’s an excellent reminder. It’s not that commercialization is more valuable than community effort, but that we need to be passionate advocates for the things we care about, whether that’s platform adoption for WordPress or a specific direction in the community. We cannot take a “build it and they will come” approach but need to consistently strive to build in the direction(s) we’re passionate about.
2. Improving User Results Results In More Users
Dries recounts the Dean Spaces -> Civic Spaces history, and traces the impact that ultimately had on the community. The more we make any platform easy to use, and empower our end users, the more users we can attract.
Cultivating and celebrating successes in the community isn’t just about making those inside the community feel good, it’s also about speaking to those outside the bubble and demonstrating the power of the platform.
3. If You Attract Amazing People, Prepare To Be Amazed
The community is ultimately the sum of overlapping communities, each of which itself is ultimately made up of people. There’s a long-tail of contributors of course, but the power of a well placed individual to have a huge impact shouldn’t be underestimated.
While retaining our humility, of course, let’s celebrate some of the amazing folks in the WordPress community.
4. Recognize Trends Early And Embrace Them
Paying attention to the broader web community and open standards community is part of what drove Drupal’s success (and of course WordPress’s as well). Following what is happening with other platforms (open source and proprietary) and digital businesses is a critical part of ensuring the long-term future of the platform.
Much of that innovation will happen at the edges not at the core – leveraging plugins and APIs to enable support that later gets considered for integration to the core platform.
5. If You Want To Go Far, Go Together
This one will sound familiar to many in the WordPress community from iThemes’ Cory Miller.
Dries associates this with the growing commercial ecosystem around Drupal, including Acquia, and the decision to hire Mark Boulton Design for Drupal 7, as well as usability studies conducted at the University of Minnesota on Drupal. Recognizing the need to cultivate certain kinds of expertise and being willing to bring others into the community even through unusual approaches was key.
6. Honest Disagreement Is Often a Good Sign Of Progress
Good community management doesn’t seek to eliminate conflict or disagreement but to channel it toward productive paths. We have to have a community that can support legitimate disagreements but not let those disagreements stall progress.
WordPress is not well served by trying to be all things to all people, but with a simple out-of-the-box experience and powerful APIs (which can be safely build upon by development teams) it can serve a wide variety of audiences.
7. Obstacles Don’t Block The Path, They Are The Path
Dries walked through some of the challenges the project has faced as it has grown: how the cost of contributing goes up (as project complexity grows) and the benefits of contributing shrink (as the pool of contributors grows).
The Drupal community has experimented with several approaches to addressing this:
- Reducing “costs” of development: better project governance, integration of symfony, twig, and guzzle, having Drupal.org maintained by the DA instead of core developers, etc.
- Adding “selective benefits” for contributors – enabling individual contributions to indicate organizational credit and customer credit as well as volunteer. This would enable various kinds of badges and credits to the sponsoring organizations (see below).
- Fundraising – to enable bounties on specific bugs and to accelerate development on key blocking issues.
The “organizational credit” item is an interesting one for the WordPress community to consider.
Boone Gorges’ keynote at WordCamp NY 2014 and San Francisco 2014 both included a high level analysis of where code contributions to WordPress come from, including individual freelancers/independents as well as those working for large agencies (like 10up). When we track commits/props at the individual level, that obscures the fact that an individual might be contributing as a paid employee of an agency, for a client of that agency, or simply as a volunteer.
I like that the model the Drupal community has developed allows for significant granularity of “attribution” – a single account might be working on behalf of different organizational sponsors or sometimes on their own.
Having organizational attribution in the system at this level would allow for different kinds of display of organizational involvement. Dries shared an example mockup of how this might work:
As an agency CEO, I love the idea that we’d be able to differentiate against other agencies that use WordPress but don’t contribute to it. As a community member, though, I worry about the unintended consequences of such a move in terms of motivation.
I don’t want people contributing to WordPress in order to get better ranking in a directory or credits in a list for their company. I want people contributing because they’re passionate about making the software better and enabling end users.
This approach also might over-favor code contributions over meetup and WordCamp organizing, forum support, documentation, marketing, themes & plugins, and other kinds of contribution we see throughout the community.
The Big Reverse of the Web
The final section was about what Dries has been calling the big reverse of the web: the broader shift from a pull model (you go find what you are interested in) to a push model (what you are interested in finds you). He articulates in a series of slides why he feels Drupal is well positioned to capitalize on and support this shift – supporting rich profiles for users, structured metadata for content, and flexibility of delivery to multiple endpoints, as well as more complex caching strategies for dynamic personalization.
It’s a compelling argument, though I think it overstates the replacement of pull by push, and I’m not certain I find all the examples compelling. It does put the platform in a context, and outlines a direction for the platform’s development – even perhaps a justification for the kinds of complexity the platform has chosen to introduce.
Of course WordPress is also well situated to support this trend, with custom post types and taxonomies, the REST API and ongoing efforts around how metadata is edited and stored.
Matt’s vision, focused on the broader and more general “democratizing publishing,” grounds the WordPress project core in a similar fashion. It’s more of a “big tent” approach in political terms – capable of incorporating and being in line with a broader set of community goals, less narrowly defined. That said, the “right information to the right people at the right time via the right channel” may be a mission that resonates more in the market, for organizations with complex communications goals.
When will Drupal 8 be done?
Of course, what many people are really looking for in a Driesnote is the update about Drupal 8 readiness. In some ways this is absurd, since there are numerous and frequent public updates about the state of the release. Nevertheless, it is a very public stage for the project leader to make pronouncements, so folks pay attention.
Stretch goal for Drupal 8 release: Barcelona (Sept. 21-25 2015)
Dries identified this as a stretch goal – achievable but not easy, and not achievable without additional help from the community.
This is perhaps the starkest contrast between Drupal and WordPress – the idea that Drupal 8 has been underway for the past four years (started officially in March 2011) and is still not past beta status.
Drupal takes an “epochal” approach – where the major version numbers (6, 7, 8) represent fundamentally re-architected platforms, breaking backward compatibility for modules, themes, and APIs in order to create new possibilities.
WordPress takes an “incremental” approach – each release is simply another iteration on the underlying platform (so 4.0 is no more different than 3.9 than 3.9 was from 3.8). There is a significant focus on backward compatibility, deprecating functions and APIs and giving plugin, site, and theme developers significant time to adjust before killing deprecated approaches.
The benefit of the Drupal approach is they don’t have to carry technical debt from one platform into the next, and can fundamentally shift the architecture, as they’ve done between Drupal 7 and Drupal 8, rewriting core APIs entirely. The benefit of the WordPress approach is that you don’t have to completely rebuild your site(s) or application(s) when a new major version gets released. (There is no “migration” path from WordPress 4.1 to 4.2 because there is no need).
Honestly I’ve come to greatly prefer the WordPress community’s approach, given the length of time and effort the complete re-architecture represents both for the community and for the end users / clients.
There is something to be said, however, for the marketing benefit of the completely new platform. I’ve often talked to folks dismissive of WordPress only to find their experience was back on 2.8 or so era WordPress. There’s no simple way to say “that was the old platform – it’s all new now” as cleanly as the break from Drupal 6.x to 7.x. It requires more complexity to point to milestones like the merge of mu, or custom post types, or the REST API.
Assuming you’ve had the endurance to make it through this entire post AND watch the keynote, what are your takeaways?