The Cultural Construction of Drupal

(This article was cross-posted on lullabot.com. The comments on this article are disabled in order to centralize all feedback in one place.)

Drupal is always changing. The community constantly reinvents Drupal with new code and reimagines Drupal with new words. This article seeks to examine the current narratives about Drupal. By examining the stories we tell about Drupal — the so called cultural constructions — we can better understand what is going well and what should be making us uncomfortable.

The dominant narrative surrounding Drupal 8 is that it will leave small websites behind, but that oversimplifies the situation. Focusing on this narrative ignores some of the more important issues facing Drupal, such as the influence of paid Drupal core developers on volunteerism, the personal connection that many people have with Drupal, or the importance of the GPL to Drupal’s longevity. The cultural constructions of Drupal sometimes change as quickly as the code, and this article will attempt to bring together a wide variety of competing narratives to reconsider why we use Drupal and challenge some of the prevailing constructions.

Drupal is for business

There have been quite a few articles published recently about Drupal and the enterprise, and many of them seem to take, as their point of departure, the following question: "Is Drupal 8 built for the enterprise?" When we dig a bit deeper into some of these narratives, it even starts to sound like the question might be, "Is Drupal 8 built by and for Acquia?"

Part of the answer to these questions seems rather settled. Yes, Drupal 8 is built with enterprise needs in mind. Yes, Acquia contributes a great deal of time and money to Drupal 8. I don't think these facts are in dispute.

Indeed, when Dries Buytaert, the creator of Drupal and co-founder of Acquia, talks to publications like Computerworld, he does not hide his intentions. He unabashedly makes statements about Drupal's future in the enterprise, such as:

"I think with small sites I'm not willing to give up on them but I think we just need to say we're more about big sites and less about small sites."

It would be fair to say that not all "big sites" are "enterprise" sites, or "corporate" sites, or even "money-making" sites, but I think we can also assume that many of them are. A quick look at the biggest sites on the web shows that most of them are the sites of for-profit companies. Big sites are generally big business.

Further, when Dries talks about his company, Acquia, he clearly identifies his intentions to grow and serve an ever larger, more cash-rich, clientele:

"We wanted Drupal to be what Red Hat is to Linux, that's why we started Acquia.... I see us as being the next large open source business model to reach $1 billion in revenue, like Red Hat. We're on the IPO track — even though it's still early days, but we are getting ready."

To call Drupal 8 "enterprise-focused" is not controversial, especially if one believes that Dries and Acquia have any influence on Drupal. Drupal 8 will likely be a boon to large, for-profit companies, and Drupal will continue to attract companies that seek a robust, open source, enterprise content management system (CMS).

Nevertheless, Acquia is not the only large enterprise that affects the future of Drupal. When Dries announced Acquia's Large Scale Drupal (LSD) program, he began:

"Acquia works with many large enterprises that bet on Drupal. These organizations are doing amazing things with Drupal and innovating by breaking through prior limitations. However, in talking to our customers, we noticed that there is limited knowledge sharing and discussion happening among the heaviest Drupal users."

The LSD businesses conduct behind-closed-door meetings, share knowledge, decide what problems they want to solve, pay developers to create solutions, and eventually share those solutions with the broader Drupal community. As the LSD website tells us, these initial decisions are made by "key community leaders and developers as well as their peers at other leading organizations running Drupal." Following this process, the broader Drupal community receives these gifts, which it can then help grow. Dries wrote, "once contributed, anyone is welcome to discuss and assist the project." The advertised benefit of LSD, according to the Vice President of Large Scale Drupal at Acquia, is that we all get "significantly better software built by some of the most talented people in the community."

We are led to believe that LSD has the brains, the money, and the talent to make things happen efficiently. LSD reminds me of the early meetings of the open-source movement in 1998 that brought companies to gather in private and find ways to "monetize" the efforts of all contributors, as the New Yorker put it, "putatively in the name of progress and standardization." LSD might actually help solve what my colleague at Lullabot, Jeff Eaton, has called Drupal's "Platypus Problem," it's inexplicable, emergent complexity.

While Drupal clearly benefits Acquia and its large, enterprise clients, there is much more to this story. When we change the question to something like, "Is Drupal 8 built only by Acquia and its partners?" we get a very different answer: absolutely not.

As we move progressively closer to things like corporate credits in commit messages, create more opportunities for advertising on Drupal.org, and as Acquia certifies more developers, we can see the desire to bring more organizations into the Drupal ecosystem, which I think is an excellent goal. A wide variety of corporate influence can help free software.

Drupal is not Acquia. Acquia employs four of the six people that can actually push code changes to Drupal 8, but thousands of people submit patches for consideration. While we cannot know for sure — since we do not have that history of organizational commit credits — it seems very likely that the number of people contributing code to Drupal 8 that work for Acquia is much smaller than the number of people who have contributed at least one patch to Drupal 8 and do not work for Acquia.

By virtue of the fact that Dries created Drupal and co-founded Acquia, he gets the biggest megaphone. For example, I suspect that a lot more people will remember when Dries tweeted "Breaking news: out of the box, Drupal 8 is 2x to 200x as fast as Drupal 7 for anonymous users" than will remember the lengthy Twitter discussion that followed, suggesting flaws in the logic of his tweet. Dries, and his company, probably have the most power to shape messages about the essence of Drupal. But are they correct? Is Drupal actually "more about big sites"?

Drupal is for everyone

Larry Garfield has noted that Drupal 5, Drupal 6, Drupal 7, and Drupal 8 have all been accused of "leaving small sites behind." Larry also believes that it's "largely true, from a technical perspective," that Drupal 8 is more complex, but that for non-developers Drupal 8 is also "a huge leap forward." Larry is quite optimistic about the future of Drupal, for everyone.

So is the Drupal Association. Look no further than Drupal.org where the headline is "Drupal 8 Will Have Something for Everyone to Love." In spite of my opinion that Drupal 8 will be understood by many to be an "enterprise-friendly" CMS, it is not merely an enterprise CMS. I also agree with my fellow Drupal 8 configuration system co-maintainer, Alex Pott, when he writes, "Drupal is open-source software and I'm excited that enterprises, not-for-profits, schools, individuals and Captain Kirk can use Drupal 8." (I also find it laughable for me to be comparing my contributions to Drupal 8 to Alex's, but more on that later.)

The public criticism leveled at Drupal 8, and the responses to those criticisms, has tended to be only vaguely technical — the APIs keep changing, the configuration system does not work like the Features module, Drupal 8 is slow, small sites do not need web services, more object-oriented code favors professional developers, etc. As Drupal becomes more capable of tackling increasingly complex projects, certain individuals feel that it will become less capable of handling more simple projects. From my perspective, that logic is flawed.

Let's briefly consider the hugely complex topic of the Configuration Management Initiative (CMI). There is no configuration management system in Drupal 7, although we do have Features and Strongarm as contributed (non-core) Drupal modules. As I have said many times, the configuration system in Drupal 8 is not the Features module. There is an extremely complicated configuration management system in Drupal 8, and one of the biggest influences on the configuration system was the new translation system, which seeks to make Drupal more accessible to more people who speak more languages. As a result of the configuration management initiative, we eliminated the need for roughly 50 database tables from Drupal 7 to Drupal 8 because we standardized on one system. I believe that one extremely well-thought-out system is more useful than dozens of competing solutions within one CMS. It feels specious to argue that these changes somehow favor the enterprise over the so-called "little guys."

Nedjo Rogers disagrees with me, especially with regards to the configuration management staging model. He writes:

"It's hard not to conclude that Drupal 8 ties configuration management to a (primarily, enterprise-focused) single-site staging model."

His point is well taken that smaller sites — and, by extension, the non-enterprise developers who build those sites — do not generally require a development >> staging >> production workflow in the same way that a large enterprise would. Where I disagree is that the mere presence of a configuration system will negatively affect smaller sites.

Consider Backdrop, a Drupal fork. Like Nedjo, the Backdrop developers seemingly reject the notion that "Drupal is for everyone." On the pages of Drupal Watchdog, Jen Lampton and Nate Haug (another colleague of mine at Lullabot) wrote:

"As Drupal moves itself closer to the Enterprise market, Backdrop CMS emerges to meet the needs of the little guys."

Backdrop includes the configuration system, albeit without the translation system. Backdrop caters to Drupal 7 developers by trying to be more like Drupal 7 than Drupal 8. "We like to think of Backdrop CMS as the next logical step in Drupal's evolution," they write. The Backdrop community has been pushing this message as much as they can, in as many places as allow. They want you to believe that Backdrop is, as the Backdrop website announces, "the comprehensive CMS for small to medium sized businesses and nonprofits." (For more about Backdrop, listen to my interview with Nate Haug.)

As much as I would like to see Backdrop succeed, I have my doubts. I do not see a compelling technical reason for small businesses and nonprofits to use Backdrop rather than Drupal. I feel like I'm in a somewhat unique position where I can root for both Drupal and Backdrop, and I look forward to seeing how many people maintain contrib modules for Drupal and Backdrop at the same time, how many clients ask for Backdrop, how many people try Backdrop on Pantheon, what sort of community develops around Backdrop, etc. If Backdrop does succeed, I don't think it will have much to do with Drupal's code being more suited for corporate interests.

Over the past few years, I have given a variety of presentations covering Drupal 8, doing my best to step back from the minutia and instead consider the broader picture. Each time I have reviewed the changes, I have felt that the majority of the new features would benefit everyone. Drupal 8 is more mobile friendly, includes a WYSIWYG editor, has views in core, supports HTML5 markup, and is more accessible. While I have a lot of ideas about these particular issues, most of them have been debated extensively, and I would instead like to take a step back to consider Drupal's identity from a less technical perspective.

Drupal is personal

This simplistic "big site" vs "small site" construction overlooks some fairly significant factors, such as the fact that for many people Drupal is personal. In technology, ontological exploration tends to be driven by discussions of code rather than cultural considerations. We're very good at asking questions like "Will Drupal 8 be slower?" or debating "Is it more user-friendly?" We are less good at asking what influences our understanding of a piece of software. We believe that individuals "come for the code, stay for the community," but rarely do we interrogate the individuals in the community (although there are exceptions).

To ignore the influence of these outside forces paints an incomplete picture. I don't think, for example, that it's a coincidence that Nedjo Rogers, one of the people who keeps asking good questions about how Drupal 8 will work for small sites and distributions, is also the lead developer for Open Outreach, a Drupal distribution for "small nonprofits and grassroots movements." He openly admits how he is conflicted, personally:

"Abstract questions of saving the world or working for capital accumulation of course translate into real-lived experience. For me personally, the tensions between free software and working for 'the man' are ones I feel every day."

Or consider how Dries described Drupal seven years ago:

"I've been working on Drupal for many years and Acquia is my company. I know how Open Source works, I know the Drupal community inside out, I know how companies should work with the community, and I have no intention whatsoever to destroy my own child."

If Dries understands Drupal as his "child," imagine how that must have felt for him to have other people take his child and decide to raise it as their own — such as the case with Backdrop.

Many others have made similar comments regarding the personal nature of Drupal. xjm, who works in the Office of the CTO (OCTO) at Acquia for Dries, wrote, "Core contribution was a life-changing experience for me." There is a touching picture of webchick, who also works in OCTO, hugging a giant Druplicon, and I fondly remember how her bio on Twitter and elsewhere used to read "Powered by Drupal." chx, one of the most prolific Drupal contributors ever, wrote a post in 2009 entitled "Why I love Drupal" and then five years later had to explain why he changed his avatar to a crying Druplicon. I know most of these people personally. I've sat next to some of them for hours and days writing code. Some of them have stayed at my house. I feel confident that Drupal is not something they do just a little bit.

xjm contends that her team in OCTO has worthwhile personal motivations, and she defends them on her blog:

"People are individuals, not automatons operating within a corporate machine. Even the six of us in OCTO contribute outside of paid time, to things that are not part of our jobs but that we care about. Gábor leads the multilingual initiative because he wants to make Drupal support all languages; Acquia did not prioritize it. Tim voluntarily works on core problems that bug him based on experience building sites and contributed modules, in addition to critical issues Acquia pays him to help fix. And Acquia doesn't own what I think or what I do with my spare time. So while we should recognize the influences organizations may exert over contribution, we should give individuals the credit for their own work."

What is perhaps more fascinating to outsiders is that the Drupal community is brimming with people about whom I could say similar things, such as many of the compassionate, dedicated people that I worked with, year after year, planning the Twin Cities DrupalCamp. There is likely a similar group of people in your community.

In free software communities, as Eric Raymond reminds us, "attacking the author rather than the code is not done" (90). The individuals offering these competing narratives about Drupal do so in good faith. While it is tempting to construct Drupal as a battle of big vs small, I think that's far too limiting to understand what's happening in the Drupal community. Much like other wildly-simplistic binaries such as FSF vs OSI, Microsoft vs GNU/Linux, or even more nuanced "oppositions," such as Debian vs Ubuntu, it's important to keep in mind that Drupal is personal without attacking individuals.

Some of us work on Drupal during the day, contribute to Drupal in our free time, and spend a lot of time teaching others about the wonders of Drupal. This might not change our code, but it helps me understand these competing constructions.

Drupal is not personal

It could be a threat to the Drupal community if it continues to become less personal.

By default, all of the code in Drupal core is accessible to everyone. The problem is not about accessibility of code, but rather about concerns regarding influence. It's ridiculous to think that Drupal could not be used, studied, modified, or distributed by any particular group. The problem, as I see it, is that Drupal is moving in a direction where people continue to fear what Benjamin Mako Hill has recently described as "access without empowerment." It is quicker and more efficient to discuss a new feature or a design decision in a video call than on IRC. A room with just the OCTO developers can make decisions much more quickly than battling it out in an issue queue. But I have already tried to establish that Acquia is not some faceless Mega Corp, insensitive to the needs of the Drupal community.

Drupal is distributed under the terms of the GNU General Public License (GPL), which is the preferred license of the Free Software Foundation (FSF). So there is a certain sense of irony that the FSF uses Drupal, and so does the Open Source Initiative (OSI). The Catholics use Drupal and so do the Unitarian Universalists. Public media stations use Drupal, and so do NBC Universal brands. These are groups with conflicting agendas and messages, all using Drupal. Drupal creates meaningful interactions by involving a wide variety of people, with myriad viewpoints, and somehow continues to attract new users, both not-for-profit and for-profit, both individual and institutional.

Even the most well-intentioned individuals can disturb a free software community. Gabriella Coleman, in her dissertation-turned-book, Coding Freedom, recounts a story about when some of Debian's key members got together at a conference and concluded that Debian should end its universal architecture support. The resulting email proposal suggested by these well-intentioned individuals caused a "monumental" crisis in the Debian community. Coleman examined thousands of emails in response to the proposal, in addition to IRC communications and blog posts, and found that "one of the most significant complaints, stated over and over, was about its tone" (153). The community must believe that they can influence the decision-making process. She concluded:

"What this event revealed is that Debian's implementation of meritocracy, like all meritocracies, is a fragile framework easily overtaken by the threat of corruptibility" (154).

The threat can be real or imagined, intentional or not. In this particular case, hundreds of Debian developers were left imagining "smoky backrooms" where the decisions were made without their input.

Dries wrote, "My motive is to do well and to do good. I admire organizations like Doctors Without Borders and strive to emulate them." I believe that Dries has done an excellent job of balancing Acquia's needs with the needs of the community. I believe he is trying "to do good."

I still have concerns about Acquia, the company. When Acquia has its IPO, it will no longer be able to act like "Doctors Without Borders" — it must answer to its investors. Then again, maybe the IPO will not change Acquia all that much given the large amount of funding that Acquia has already raised. Acquia, the company, is forcing the Drupal community to raise questions about the consequences of capital investment. It forces us to wonder if Drupal can continue to benefit both the global rich and global poor. Can a startup that aspires to be a billion dollar company avoid exerting undue influence on software that is used by both large, profit-driven enterprises and small, activist organizations?

What makes more sense to me is that some of the uneasiness with Drupal 8 stems from worries that by doing so much to make Drupal better, Acquia might be, in essence, limiting the flexibility of Drupal core, and that it is placing pressures on Drupal core that may have more to do with Acquia's own financial or organizational limitations than perceived needs of the broader Drupal community. We fear that Acquia could be making Drupal impersonal.

I first became really interested in free software after reading Glyn Moody's Rebel Code and Eric Raymond's The Cathedral and the Bazaar. Words like "rebel" and "bazaar" intrigued me. When I first started using Drupal professionally, at Wisconsin Public Radio, I was largely drawn to the software because of its much-discussed connection with nonprofit, academic, and governmental institutions. Drupal distributions such as CiviCRM, Open Outreach (maintained by Nedjo), and Open Media were all geared toward NGOs, nonprofit, activist, and grassroots organizations — groups that, in many circumstances, situate themselves in opposition to corporate interests. I get the feeling that many people who were originally drawn to Drupal because of its perceived status as nonprofit-friendly are now conflicted by the strong influence of business at the very core of Drupal.

If Drupal continues to be understood as more about business, it is potentially less about individuals, and more about the needs of the businesses for whom those individuals work. I cannot imagine, for instance, that Dries or Angie would commit code to Drupal core that they genuinely believed to be against the interest of their corporate partners.

Drupal is a community of volunteers

With the recent upswing in paid, full-time Drupal core developers, I'm concerned that Drupal risks attracting the necessary volunteers to continue its growth. Nowadays there are more people getting paid to work on Drupal full time than there were just a few years ago. If one believes that unpaid labor is unethical, this change is welcome. It might benefit certain individuals to have a day job working on Drupal rather than getting burned out working nights and weekends on Drupal. However, as the cultural construction of Drupal moves from something associated with weekend hacking and grassroots movements to something associated with corporations — or worse, a single corporation — then we potentially create other problems.

Certainly questions about Acquia's influence are not new. Objections to Acquia's position were raised, loudly, at least as early as 2007. It is a credit to Dries that as Acquia has continued to grow, the Drupal community has grown right alongside it, allowing more people to create meaning in code.

It's a well-known fact that programmers will contribute to projects for no reward other than to make the software more useful. When Acquia decides that it wants to change something about Drupal, has the votes, talent, and funding to make those changes a reality, it seems like it would necessarily limit the types of other contributions that others can make. Yet that does not seem to be the case.

Holly Ross, the Executive Director of the Drupal Association (DA), was recently discussing the D8 Accelerate project, which aims to put $250,000 toward accelerating the release of Drupal 8. She described this initiative as replacing an "underground economy" of companies paying individuals to work on Drupal core. She and the DA are definitely aware that putting money toward Drupal core development could undermine volunteerism. They hope to fund ideas, not individuals, that push Drupal 8 closer to release.

The DA wants to help keep developers focused on finishing the issues that will get Drupal 8 out the door. Dries, who is the president of the board of the DA, told the New York Times:

"Open source is Darwinian. Eventually the best idea wins, but it is much more wasteful. A regular company couldn't have experimented with creating 10 versions of an online photo album, then picked the best one."

Angie Byron, who is also on the board of the DA, wants to keep Drupal 8 development moving forward, and she's careful not to tell people what specifically to do. On Twitter she asked, "If you're a developer, and you aren't fixing #Drupal 8 critical bugs, care to share why? Curious what we can do to help momentum." She wants to keep things moving in a certain direction, but she knows she cannot simply tell people what to do.

There are pitfalls with picking solutions. For example, the creator of GNU/Linux, Linus Torvalds, famously described it as something that he does "just for fun." The GNU/Linux kernel is understood as beyond the control of any one company because many companies pay developers to work on it. There are lots of developers that are motivated to work on Drupal simply because they want to make it better. It's no longer just for fun to work on Drupal core if it is also for money.

Benjamin Mako Hill, a prolific developer and highly-regarded free software advocate, wrote about the influence of paid developers in volunteer-oriented free software communities in an article entitled, "Problems and Strategies in Financing Voluntary Free Software Projects." He recounts stories of numerous communities that were pulled apart by the mere presence of paid developers. Hill believes, "when it comes to voluntary work and paid labor, you can have one or the other but not both." He acknowledges the importance of volunteerism:

"Perhaps the most important benefit of volunteerism in free software development is institutional independence. Institutional independence in a free software project means that no company or organization has a monopoly on the ability to define specifications or to direct the project. To users and developers, institutional independence means that they get to define the specifications; it is a broad perceived autonomy. Projects that are driven or directed by volunteers are more easily able to appear institutionally independent than corporate or organizationally directed projects or any projects that incorporate paid labor."

Projects like Debian — which benefit from companies that pay employees to make Debian better — are viewed as institutionally independent because no one organization can direct the project.

Perspectives like these induce some level of worry for me about the future of Drupal. Perhaps more frightening is that I am personally affected. Since the recent growth of paid laborers in the Drupal community, I, personally, have felt less motivated to work on Drupal core because I know that others who are being paid to do the work will get it done, eventually, if I do not.

Don't misunderstand me: I love working on Drupal during the day and getting paid. I have my dream job and I love it. Maybe it's burnout. Maybe it's my upbringing. Maybe it's fear of smoky backrooms. It could be that I never really did that much anyway — that's certainly how I feel when I'm hanging around with people like Tim Plunkett or Alex Pott, both of whom worked tirelessly on Drupal core well before they were ever paid to work full time on core.

Drupal is the GPL

There are a many reasons for hope. One could point to Dries's ability to lead the Drupal community, the respect he is afforded, and the respect he extends. One could look to the ever-growing number of Drupal core contributors. More than any other factor, though, I have faith in the GNU General Public License, and its 30-year track record of making the world a better place.

If we believe that the fundamental reason for free software licenses is to deny anyone the right to exclusively exploit a work, then what programs like LSD are doing is still in the spirit of free software licenses because they eventually share their code, even if their methods ruffle some feathers.

Drupal, however it is constructed, has a powerful bodyguard keeping it safe. The meticulousness of the GPL ensures that Drupal will always be free of restrictions. It prevents any company that would desire to commercialize and profit from distributing derivative versions of Drupal that are proprietary. While the community can be threatened by commercial interests, the code will be free.

If factions of the community feel sufficiently disenfranchised, they can take the code and do as they please. Backdrop, the Drupal fork, was possible because the GPL explicitly allows forking. The GPL protects your right to tinker — in small ways and in really big ways.

Most importantly, the spirit of the GPL remains strong in the Drupal community, and in spite of my recent hesitation, I sense that many people want to play their part. For example, I have the pleasure to work everyday alongside another one of Drupal's most prolific contributors, Dave Reid. Recently, Dave and I were working on finding ways to process data more quickly. In the course of our work for a large enterprise, Dave created a method to process records concurrently rather than sequentially. Once we sorted out the bugs and got things working, Dave contributed the module back to the community. The Concurrent Queue module is fantastic, and anyone can use it. It's no less useful to someone who needs it because we did it while getting paid by a corporation. This kind of thing happens everyday, across the community.

We did not come up with these ideas on our own. We learned them from the Drupal community.

The Drupal community is not a special snowflake. The Drupal community is a group of individuals that build GPL software together. Drupal 8 will be free as in freedom. It's software that can be deeply personal. It's software that can benefit organizations. It's software that can benefit our enemies. The GPL ensures that everyone is free to use Drupal.

So as I see it, we have a multitude of competing cultural constructions of Drupal, none of which can claim to be correct. It's software for websites large and small. It's built by paid developers and volunteers. Many of us have a personal connection with Drupal. Because Dries brought us down this road — this joyride that is Drupal — with software licensed under the GPL, everyone is free to study, use, modify, and distribute any of the files on Drupal.org. And that has made all the difference.