Feeds

Author

Jun 05 2019
Jun 05

According to Drupal’s community documentation, “The Benevolent Dictator for Life (BDFL),” Dries Buytaert, is the “chief decision-maker for the [Drupal] project.” In practice, as Dries has pointed out, he wears “a lot of different hats: manager of people and projects, evangelist, fundraiser, sponsor, public speaker, and BDFL.” And he is chairman and chief technology officer of a company that has received $173,500,000 in funding. Recently I was wondering, how often does Dries wear his Drupal core code committer hat?

In this article, I will use data from the Drupal Git commit history, as well as other sources, to demonstrate how dramatically the Drupal core “code committing” landscape has changed. I do not intend to tell the entire story about power structures in the Drupal community in a single article. I believe that issue credits, for instance, offer more clues about power structures. Rather, my analysis below argues that the process of committing code to Drupal core is a far more complex process than some might assume of a project with a BDFL.

Understanding Drupal Core Committers

Whereas Dries used to commit 100% of the core code, he now leads a team of core committers who “are the people in the project with commit access to Drupal core.” In other words, core committers are the people who can make changes to Drupal core. We can get an idea about the work of core committers from sites such as Open Hub or the GitLab contributor charts, but those charts omit key details about this team. In this analysis, I’d like to offer more context.

The Drupal core committer team has grown exponentially since the start of the Drupal codebase more than 19 years ago. At present, there are 11 core committers for Drupal 8, and from what I can tell, these are the dates that each new core committer was announced:

Unsurprisingly, one task of a core committer is to commit code. For a Drupal core committer to consider a change to Drupal, the proposed change must advance through a series of “core gates,” including the accessibility gate and the performance gate. Code must pass Drupal’s automated tests and meet Drupal’s coding standards. But even after making it through all of the “gates,” only a core committer can add, delete, or update Drupal code. At any given time, there might be 100 or more Drupal core issues that have (presumably) gone through the process of being proposed, discussed, developed, tested, and eventually, “Reviewed & tested by the community,” or RTBC.

Core committers can provide feedback on these RTBC issues, review and commit code from them, or change their status back to “Needs work” or “Needs review.” Just because core committers have the power to commit code does not necessarily mean they view their role as deciding what code gets into core and what does not. For example, Alex Pott told me, “I feel that I exert much more influence on the direction of core in what I choose to contribute code to than in what I commit.” He said that he views the RTBC queue more as a “TODO list” than a menu from which he can select what he wants to commit.

Many people might not realize that core committers do a lot more than just committing code. On the one hand, as Dries shared with me, “The hard work is not the actual committing – that only takes a few seconds. The hard work is all the reviews, feedback, and consensus building that happens prior to the actual commit.” Indeed, core committers contribute to the Drupal project in many ways that are difficult to measure. For instance, when core committers offer feedback in the issue queue, organize initiative meetings, or encourage other contributors, they do not get any easily measured “credit.” It was Jess who suggested that I work on the Configuration Management Initiative (CMI) and I will be forever grateful because her encouragement likely changed the course of my career.

The core committers play significant roles in the Drupal project, and those roles are not arbitrary. Each core committer has distinct responsibilities. According to the community documentation (a “living document”), “the BDFL assigns [core committers] certain areas of focus.” For instance, within the team of core committers, a Product Manager, Framework Manager, and Release Manager, each has different responsibilities. The “core committers are a group of peers, and are expected to work closely together to achieve alignment, to consult each other freely when making difficult decisions, and to bring in the BDFL as needed.”

Part of my goal here is to show that the commit history can only tell part of the story about the team of core committers. I’d also like to point out that in this article I limit my focus to Drupal 8 core development, and not, for instance, the work of the Drupal 7 core committers, the maintainers of the 43,000+ contributed modules, the Drupal documentation initiative, conference selection committees, or any of the other groups of people who wield power in the Drupal community.

This work is one component of my larger project to evaluate publicly-available data sources to help determine if any of them might be beneficial to the Drupal community. I acknowledge that by counting countable things I risk highlighting trivial aspects of a thoughtful community or shifting attention away from what the Drupal community actually values. Nevertheless, I believe that interpreting Drupal’s commit history is a worthwhile undertaking, in part because it is publicly-available data that might be misinterpreted, but also because I think that a careful analysis reveals further evidence of a claim that Dries and I made in 2016: Drupal “is a healthy project” and “the Drupal community is far ahead in understanding how to sustain and scale the project.”

Who Commits Drupal Core Code?

The Git commit history cannot answer all of our questions, but it can answer some questions. As one GitLab employee put it, “Git commit messages are the fingerprints that you leave on the code you touch.” Commit messages tell us who has been pushing code and why. The messages form a line by line history of the Drupal core codebase, from the very first commit to the “birth” of Drupal 1.0.0, to today.

The commit history can answer questions such as, “Who has made the most commits to Drupal core?” Unsurprisingly, the answer to that question is “Dries”:

However, since 2015 Dries has dramatically reduced his core commits. In fact, he only has 4 commits since October 2015:

If someone just looked at the contributor charts or a graph like the one above, they might not realize the fact that Dries is as committed to Drupal as ever. He spends less time obsessing about the code and architecture and more time setting strategy, helping the Drupal Association, talking to core committers, and getting funding for core initiatives and core committers. In recent years he has dedicated considerable time to communication and promotion, and he has been forthcoming with regards to his new role. He has been writing more in-depth blog posts about the various Drupal initiatives as well as other aspects of the project. In other words, he has intentionally shifted his focus away from committing towards other aspects of the project, and his “guiding principle” is to “optimize for impact.”

Another part of the reason that Dries has had fewer commits stems from the recent shift in effort from Drupal core to contrib. Overall commits to Drupal core have decreased since their highest point in 2013, and have been down considerably since the release of Drupal 8 in 2015:

But once again, we must interpret these data carefully. Even if the total number of commits to Drupal core has declined since 2015, the Drupal project continues to evolve. Since Drupal 8.0.0, BigPipe, Workflows, Migrate, Media, and Layout Builder are just a few of the new modules that have become stable, and the list of strategic initiatives remains ambitious. So while the data may seem to suggest that interest in Drupal core has waned, I suspect that, in fact, the opposite is true.

We can, on the other hand, use the git commit history to get a sense for how the other core committers have become involved in committing code to Drupal core. We can visualize all commits by day over the entire history of the Drupal codebase for each (current) individual core committer:

We get a better sense of the distribution of work by looking beyond total commits to the percentage of core commits per committer for each year. Using percentages better demonstrates how the work of the code committing has become far more distributed (in this chart, "colorful") than it was during the early years of Drupal's lifespan:

You might notice that the chart above does not include past core committers such as the Drupal 5 core committer, Neil Drumm (406 commits), or the Drupal 4.7 core committer, Gerhard Killesreiter (193 commits). I’m more interested in recent changes.

When we shift back to looking at total commits (rather than percentages) we can watch the team grow over the entire history of the Drupal project in the following animation, which stacks (ranks) committers by year based on their total number of commits:

 

One fact that caught my attention was that Alex Pott’s name topped the list for 6 of the last 7 years. But I’d like to stress again that this visualization can only tell part of the story. For instance, those numbers don’t reflect the fact that Alex quit his job in order to work on Drupal 8 (before becoming a core committer) or his dedication to working on “non-technical” issues, such as a recent change that replaced gendered language with gender-neutral language in the Drupal codebase. I admit to a particular bias because I have had the pleasure of giving talks as well as working with him on the Configuration Management Initiative (CMI), but I think the correct way to interpret these data is to conclude simply that Alex Pott, along with Nathaniel Catchpole and Angie Byron, are a few of the members of the core committer team who have been spending more of their time committing code.

We find a slightly different story when we look beyond just the number of commits. The commit history also contains the total number of modified files, as well as the number of added and deleted lines. Each commit includes entries like this:

2 files changed, 4 insertions(+), 15 deletions(-)

Parsing the Git logs in order to measure insertions and deletions reveals a slightly different breakdown, with Nathaniel Catchpole’s name at the top of the list:

Differences in the ranking are largely the result of just a few issues that moved around more than 100,000 lines of code and significantly affected the totals, such as removing external dependencies, moving all core files under /core, converting to array syntax, not including vendor test code, and removing migrate-db.sh.

The commit history contains a wealth of additional fascinating data points that are beyond the scope of this article, but for now, I’d like to discuss just one more to suggest the changing nature in the land of core committing: commit messages. Every core commit includes a message that follows a prescribed pattern and includes the issue number, a comma-separated list of usernames, and a short summary of the change. The syntax looks like this:

Issue #52287 by sun, Dries: Fix outdated commit message standards

Combining all commit messages and removing the English language “stopwords” – such as “to,” “if,” “this,” and “were” – results in a list of words and usernames, with one core committer near the top of the list, alexpott (Alex Pott’s username):

 

Only one other user, Daniel Wehner (dawehner), is mentioned more than Alex Pott. I find it mildly interesting to see that “dawehner” and “alexpott” appear in more commit messages than words such as “tests,” “use,” “fix,” “entity,” “field,” or even “Drupal.” It also caught my attention that the word “dries” did not make my top 20 list. Thus, I would suggest that a basic ranking of the words used in commit messages does not provide much value and is not even a particularly good method to determine who is contributing code to Drupal – DrupalCores, for instance, does a much better job.

Nonetheless, I mention the commit messages because they are part of the commit history and because those messages remind us once again that core committers like Alex Pott do a lot more than commit code to the Drupal project – they also contribute a remarkable amount of code. Alex Pott, Jess, Gábor Hojtsy, Nathaniel Catchpole, and Alex Bronstein are each (as of this writing) among the top 20 contributors to Drupal 8. Moreover, this list of words brings us back to questions about the suitability of a term such as “BDFL.”

BDFL Comparisons

While Dries could still legitimately don a hat that reads “Undisputed Leader of the Drupal Project,” it seems clear that the dynamics of committing code to Drupal core have shifted and that core committers assume a variety of key roles in the success of the Drupal project. During the process of writing this article, someone even opened an issue on Drupal.org to “Officially replace the title BDFL with Project Lead.” Whatever his official title, the evolving structure of the core committer team has allowed Dries to focus on the overall direction of the Drupal project and spend less time involved in choices about the code that gets committed to Drupal core on a daily basis. And it’s a considerable amount of code – since Drupal 8 was released there have been more than 5719 commits to Drupal core, or roughly 4.42 commits per day.

While other well-known free software projects with a BDFL, such as Vim, only have one contributor, numerous other well-known projects have moved in a direction comparable to Drupal. As of this writing, Linus Torvalds sits at #37 on the list of contributors to the Linux kernel. Or perhaps more related to Drupal, Matt Mullenweg, who calls himself the BDFL of WordPress, is not listed as a core contributor to the project and is not the top contributor to the project – that honor goes to Sergey Biryukov, who has held it for a while.

Further, one could reasonably conclude that Drupal’s commit history calls into question a concern that many people, including me, have raised regarding the influence of Acquia (Dries’s company) in the Drupal community. Acquia sponsors a lot of Drupal development, including core committers. Angie Byron, Jess, Gábor Hojtsy, and Alex Bronstein are all paid by Acquia to work on Drupal core full-time. However, I still believe what Dries and I wrote in 2016 when we stated that we do not think Acquia should “contribute less. Instead, we would like to see more companies provide more leadership to Drupal and meaningfully contribute on Drupal.org.” On this topic, the commit logs indicate positive movement: since Drupal 8 was released, Alex Pott and Nathaniel Catchpole – the two most active core committers – have made 72% of the commits to Drupal core – and neither of them work for Acquia. So while everyone in the Drupal community owes a debt of gratitude to Acquia for their sponsorship of the Drupal project, we should also thank companies the sponsor core committers like Alex Pott and Nathaniel Catchpole, including Thunder, Acro Media, Chapter Three, Third and Grove, and Tag1 Consulting.

And the other core committers? Well, I can’t possibly visualize all of the work that they do. They are helping coordinate core initiatives, such as the Admin UI & JavaScript Modernisation initiative and Drupal 9 initiative. They are working on Drupal’s out-of-the-box experience and ensuring consistency across APIs. They are helping other contributors collaborate more effectively and efficiently. They are coordinating with the security team and helping to remove release blockers. The core committers embody the spirit of the phrase that appears on every new Drupal installation: “Powered by Drupal.” I am grateful for their dedication to the Drupal project and the Drupal community. The work they do is often not highly visible, but it’s vital to the continued success of the project.

A deeper appreciation for the work of the Drupal core committers has been just one of the positive consequences of this project. My first attempts at interpreting Drupal’s commit history were somewhat misguided because I did not fully understand the inner workings of the team of core committers. But in fact, nobody can completely understand or represent what the core committers do, and I personally believe that the “Drupal community” is little more than a collection of stories we choose to believe. However, we live in a time where people desire to understand the world through dashboards that summarize data and where we gloss over complexities. Consequently, I feel more motivated than ever to continue my search for data that more accurately reflect the Drupal community for which I have so much respect. (Incidentally, if you are a statistician with an interest in free software, I would love to collaborate.) If we want a deeper understanding of who contributes to Drupal, we need more and better sources of information than Drupal’s “contributors” page. I accept that I will never concoct the magical visualization that perfectly represents “Drupal,” but I am enjoying the search.

Code for this project is available on GitLab. I would like to thank Cathy Theys, Megh Plunkett, Dries Buytaert, and Alex Pott for their thoughtful feedback on earlier drafts of this article.

Apr 05 2019
Apr 05

When I attended my first DrupalCon in San Francisco I brought three suits. At that point, I had been speaking at academic conferences for a decade, and in my experience, conferences were places where attendees dressed formally and speakers literally read their papers (here's a real example from a 2005 Women's and Gender Studies Conference where I spoke). I arrived in San Francisco thinking I would spend some time exploring the city while I was there, but I ended up spending nearly all of my extra time in the ChX Coder Lounge learning everything I could about Drupal from kind people in the Drupal community. I never really left the conference other than to eat or attend a party. In fact, I was so excited about Drupal that some of my friends had to stop following me on social media.

DrupalCon San Francisco changed the course of my life. That said, the Drupal community feels very different today, and that's okay with me. As I wrote in 2015, "Drupal is always changing. The community constantly reinvents Drupal with new code and reimagines Drupal with new words." This week, some people feel "excited" while others are "frustrated." Next week at DrupalCon, we will hear a lot more choice adjectives to describe Drupal and its community. Of course, none of them will be correct.

Every once in a while, I find it helpful to remember that there is no such thing as Drupal. Certainly, we need to use words like "Drupal" so we can talk to each other, but I have yet to find even a single, unchanging characteristic that constitutes Drupal. Even if I am demonstrably incorrect, I have discovered over the past couple of years that I experience the most happiness when I don't expect anything from DrupalCon or Drupal. Instead, I try to focus on a single goal: find ways to use Drupal to help other people. Naturally, I fall short of this goal regularly, but just having the goal has produced beneficial results.

I have invested considerable effort trying to "find Drupal" by talking to people in the Drupal community, writing about Drupal, studying commit credit data, and every time I look, I find something different. After processing so much data, I started to wonder if any possible metric could tell us something about, for example, the diversity of the community. I even opened an issue in drupaldiversity (which was moved to drupal.org) asking about the prospect of finding specific, measurable diversity goals. If there is no such thing as Drupal, then it might seem as if the answer to my question about metrics doesn't matter. But I believe that moving forward together with goals in mind offers incredible benefits and that agreeing on goals is a serious challenge. If "finding Drupal" is difficult, trying to grasp all of Drupal's communities -- and the distinct challenges that each of them faces -- is nearly impossible.

To counter thoughts of that kind, I find tremendous benefit in focusing on the here and now. What can I do today? What benefit does understanding all of Drupal do if I don't take the time to help this person that turned to me for advice? Who can I turn to when I'm stuck? The frustration caused by the Drupal code and the Drupal community is real, but in the face of such feelings, it seems like my best option is often to let go and move forward. It can feel like letting go of anger and frustration is not always possible, but I am not ready to give up on the idea that letting go is always an option.

While I believe that Drupal doesn't actually exist, I also believe that people's actions have real consequences. Harassing people in the issue queues causes pain. Insecure and non-functional code causes headaches. Unwanted advances are actually unwanted. As important as it is for us to all read the DrupalCon Code of Conduct, it's equally important to scroll down on that page for the reminder that "We're all in this together."

During my time in the Drupal community, I have witnessed the suffering produced when we use labels that separate us. "Drupal Rock Star" is one of those labels, and as much as I'm flattered that someone thinks I could potentially "end the myth of the Drupal rockstar with [my] DrupalCon presentation, The Imaginary Band of Drupal Rock Stars," I can't. But I can demonstrate how the rock star myth causes pain and I can offer alternative constructions.

In the course of my research over the past few months, I've been exploring what actions the Drupal community values and how some other musical metaphors such as "arranger" or "improviser" might help reframe our understanding of useful Drupal contributions. If that sounds interesting (or not), yes please come to my talk or introduce yourself at DrupalCon next week.

In my experience, DrupalCon can create both excitement and frustration, so my goal this year is to let go of expectations. I don't find them helpful. Drupal is a process, and for some, an ongoing struggle. But just because our community traffics in 1s and 0s doesn't mean I should transfer binary thinking to the people with whom I interact. I'm not suggesting that everyone prance around the conference as if everything that everyone does is acceptable. I have witnessed some seriously unwelcome behavior at past DrupalCons that needed to be addressed. The Drupal community is awash with thoughtful people, and I frequently turn to them to help me continue to recognize my considerable privilege and bias. I can only hope that having a goal of helping other people while I'm at DrupalCon -- rather than focusing exclusively on maximizing the value of my expensive ticket -- will, in turn, improve my week.

While I recognize not everyone shares my worldview, I hope to improve my time at DrupalCon by recognizing my essentialist ideas and instead focus on the people and situations in front of me -- a bit more like I imagine I did at DrupalCon San Francisco.

Feb 25 2019
Feb 25

Matthew Tift talks with James Sansbury and Matt Westgate about the history of Lullabot, building a team of Drupal experts, and moving away from the phrase "rock star." Ideas about "rock stars" can prevent people from applying to job postings, cause existing team members to feel inadequate, or encourage an attitude that doesn't work well in a client services setting. Rather than criticize past uses of this phrase, we talk about the effects of this phrase on behavior.

Feb 21 2019
Feb 21

Drupal has a great reputation as a CMS with excellent security standards and a 30+ member security team to back it up. For some Drupal sites, we must do more than just keep up-to-date with each and every security release. A Drupal site with private and confidential data brings with it some unique risks. Not only do you want to keep your site accessible to you and the site’s users, but you also cannot afford to have private data stolen. This article provides a checklist to ensure the sensitive data on your site is secure.

Keeping a Drupal 8 site secure requires balancing various needs, such as performance, convenience, accessibility, and resources. No matter how many precautions we take, we can never guarantee a 100% secure site. For instance, this article does not cover vulnerabilities beyond Drupal, such as physical vulnerabilities or team members using unsafe hardware, software, or networks. These suggestions also do not ensure General Data Protection Regulation (GDPR) compliance, a complex subject that is both important to consider and beyond the scope of this checklist.

Rather than systems administrators well-versed in the minutia of securing a web server, the list below targets Drupal developers who want to advise their clients or employers with a reasonable list of recommendations and implement common-sense precautions. The checklist below should be understood as a thorough, though not exhaustive, guide to securing your Drupal 8 site that contains private data, from development to launch and after.

The information below comes from various sources, including the security recommendations on Drupal.org, articles from Drupal Planet that discuss security, a Drupal security class I took with Gregg Knaddison and his 2009 book Cracking Drupal, a review a numerous internal Lullabot documents regarding security, and other sources. This list was reviewed by Lullabot's security team. That said, for more comprehensive content and considerations, I recommend learning more about securing your site on Drupal.org and other security sources.

Infrastructure

  • Configure all servers and environments to use HTTPS.
  • Install the site following the Drupal guidelines to secure file permissions and ownership (using the fix-permissions.sh included with the guidelines is a quick way to do this).
  • Hide important core files that may allow attackers to identify the installed version (the point release) of Drupal, install new sites, update existing sites, or perform maintenance tasks. For example, when using Apache add something like this to your .htaccess configuration file:
<FilesMatch "(MAINTAINERS|INSTALL|INSTALL.mysql|CHANGELOG).txt">
  Order deny,allow
  deny from all
  Allow from 127.0.0.1  <-- your domain goes here
</FilesMatch>
<FilesMatch "(authorize|cron|install|update).php">
  Order deny,allow
  deny from all
  Allow from 127.0.0.1  <-- your domain goes here
</FilesMatch>

  • In settings.php:
    • Configure a hard-to-guess table name prefix (e.g. 5d3R_) in the $databases array to deter SQL injections (this suggestion comes from KeyCDN).
    • Check that $update_free_access = FALSE; to further prevent using the update.php script.
    • Configure trusted host patterns (e.g. $settings['trusted_host_patterns'] = ['^www\.example\.com$'];).
    • In each environment (development, staging, and production) configure a private files directory located outside of the web root.
  • If you are running MariaDB 10.1.4 or greater with a XtraDB or InnoDB storage engine on your own hardware (as opposed to a hosting provider such as Linode or AWS), enable data-at-rest encryption.
  • Establish a regular process for code, files, and database off-site backup using an encryption tool such as GPG or a service such as NodeSquirrel.
  • If a VPN is available, restrict access to the administrative parts of the site to only local network/VPN users by blocking access to any pages with “admin” in the URL.
  • Note that these recommendations also apply to Docker containers, which often run everything as root out of the box. Please be aware that the Docker Community -- not the Drupal Community or the Drupal Security Team -- maintains the official Docker images for Drupal.

Development: Pre-Launch

  • Before launching the site, calibrate security expectations and effort. Consider questions such as, who are the past attackers? Who are the most vulnerable users of the site? Where are the weaknesses in the system design that are "by design"? What are the costs of a breach? This discussion might be a good project kickoff topic.
  • Establish a policy to stay up-to-date with Drupal security advisories and announcements. Subscribe via RSS or email, follow @drupalsecurity on Twitter, or create an IRC bot that automatically posts security updates. Use whatever method works best for your team.
  • Create a process for keeping modules up to date, how and when security updates are applied and considers the security risk level. Drupal security advisories are based on the NIST Common Misuse Scoring System (NISTIR 7864), so advisories marked "Confidentiality impact" (CI) are especially crucial for sites with private and confidential data.
  • Establish a process for handling zero-day vulnerabilities.
  • Review content types to ensure that all sensitive data, such as user photos and other sensitive files, are uploaded as private files.
  • Implement one or more of the Drupal modules for password management. The United States National Institute of Standards and Technology (NIST) offers detailed guidelines about passwords. Here are some policies that are easy to implement using submodules of the Password Policy module:
    • At least 8 characters (Password Character Length Policy module)
    • Maximum of 2 consecutive identical characters (Password Consecutive Characters Policy module)
    • Password cannot match username (Password Username Policy)
    • Password cannot be reused (Password Policy History)
  • Consider having your organization standardize on a password manager and implement training for all employees.
  • Consider using the Two-Factor Authentication (TFA) module.
  • Change the admin username to something other than admin.
  • Enable the Login Security module, which detects password-guessing and brute-force attacks performed against the Drupal login form.
  • Enable Security Review module, run the Security Review checklist, and make sure all tests pass. Disable this module before site launch, but use this module to perform security reviews each time core or contributed modules are updated.
  • Carefully review Drupal user permissions and lock down restricted areas of the site.

Development: Ongoing

Matthew Tift

Thumbnail

Senior developer, musicologist, and free software activist

Apr 25 2018
Apr 25

In this episode, Matthew Tift discusses DrupalCon Nashville, the movie The Matrix, and various ways to understand the Drupal community. He plays clips from the Driesnote and Steve Francia's keynote, describes some of his experiences at DrupalCon, and offers ideas for what it might mean to understand "the real" Drupal.

Mar 26 2018
Mar 26
In this episode, Matthew Tift talks with Jen Lampton about the Backdrop project, the differences between the Drupal and Backdrop communities, helping people, organizing software communities, and much more.
Jan 27 2018
Jan 27

In this episode, Matthew Tift talks with Tom Grandy, who oversees websites for 23 school districts. Tom describes himself as a journalist, a teacher, and a non-coder who helps out with documentation and marketing for Backdrop. He describes his experiences using proprietary software, finding Drupal, his involvement with Backdrop, and the challenges of using free software in K-12 education. Tom shares why people working in schools make decisions about technology most often based on cost, but that he believes we should also considers software licenses, communities, and other more philosophical factors.

Jan 05 2018
Jan 05

This episode explores the "paradox of tolerance," and what it means for free software communities, business, conference organizing, and our daily interactions. This episode offers six propositions about tolerance:

  1. Free software requires certain kinds of tolerance
  2. Tolerance has limits
  3. The paradox of tolerance sets up clear distinctions between good and evil
  4. Business can utilize the paradox of tolerance
  5. In practice, tolerance is messy and arbitrary
  6. Kindness outweighs tolerance

The theme music used in this episode comes from the Open Goldberg Variations, performed by Kimiko Ishizaka.

Apr 23 2017
Apr 23

In this episode of Hacking Culture, Matthew Tift talks Clayton Dewey about Drutopia, an initiative to revolutionize the way we build online tools. Clayton talks about Drupal distributions, activism, the Industrial Workers of the World, Backdrop CMS, and more!

This episode is released under the Creative Commons attribution share alike 4.0 International license. The theme music used in this episode comes from the Open Goldberg Variations, performed by Kimiko Ishizaka. The musical interludes all come from ccMixter.org. "Chillin' With Jeris" by copperhead and "Naturally" by Vidian, featuring Michael Burns and Morea Arthur under CC BY-NC license.

Jan 27 2017
Jan 27

In this episode of Hacking Culture, Matthew Tift talks with Matt Westgate and Seth Brown about Lullabot, the Drupal community, and how people who build free software improve the world. This episode is as much about the hacking of culture as it is about the culture of hacking. Learn more at hackingculture.org. The theme music used in this episode comes from the Open Goldberg Variations. This episode is released under the Creative Commons attribution share alike 4.0 International license.

Dec 07 2016
Dec 07

What it would mean to "make the world better" is up for debate. We cannot be experts in all subjects, and a group of Drupal developers might not fully understand, for example, the policies that allow tax havens, the economic implications of a $15 minimum wage, how to combat predatory lending, or the solutions to climate change. Perhaps we have strong opinions on these topics, but many of us would begrudgingly admit that we know more about dependency injection, re-rolling patches, or even the hook system. That is, we know how to build Drupal websites. More importantly, to succeed in the Drupal community we are required to be considerate, respectful, and collaborative. We, as a community, vigorously reject bigotry, racism, sexism, homophobia, and xenophobia. This, in my view, makes the world better.

What is more, I would argue that Drupal blurs traditional boundaries. While certainly there are market forces that determine how Drupal is constructed, powerful legal and cultural nonmarket forces push back. Some Drupal agencies exist to turn a profit, but do so working primarily with public sector or non-profit organizations. Drupal agencies can be seen as capitalist in the sense that they accumulate surplus value by "exploiting the working class," but socialist in the sense that they produce goods that are owned collectively. Some have stated goals to invest value back into the community and others are "benefit corporations," required to make the world a better place. While I am tempted to place new labels on the Drupal community, such as "post-capitalist," I find such terms to be of limited use, and I am far more interested in finding common ground that unites our community.

Drupal code has only limited value without the community, and our community stands for values that transcend our code. I participate in the Drupal community because I believe it represents ideals that are consistent with my own. One of the beliefs that we hold in high regard is "doing good." It would be difficult to convince me that people, such as George DeMet and Tiffany Farriss, Todd Ross Nienkerk, or Lev Tsypin, have anything but the best intentions in the way they run their businesses. More importantly, these individuals, like so many others in our community, actually do make the world a better place through their work, compassion, and advocacy.

In some respects, the well-intentioned subset of our community exemplifies what Luc Boltanski and Eve Chiapello describe as "the new spirit of capitalism." In their study of management textbooks, they find this "new spirit" is characterized by, among other things, a "high moral tone" (58), a belief that workers should "control themselves" (80), structures where managers are essentially replaced with customers (82), and where bureaucracy represents a kind of "totalitarianism and arbitrariness" that should be avoided (85). While Boltanski and Chiapello find many faults with this "new spirit," generally, I would suggest that is has become more important than ever to acknowledge the many benefits that the people and organizations in our community have for the world. While critique and criticism will surely be needed, we should also continue to celebrate the impact that our software and colleagues plays in efforts towards ending poverty, empowering independent journalists, defending the free and open Internet, and educating people. Even though Drupal has been used for nefarious purposes, and there are many reasons to critique the Drupal community, I feel emboldened knowing that when people came together to build websites for DeanSpace, the United Nations, Amnesty International, Greenpeace, Oxfam, the ACLU, the Electronic Frontier Foundation, National Public Radio, Free Press, and the White House, they choose Drupal.

More than just software, part of the reason we "stay for the community" is because we place such a high premium on human interaction. Drupal contributors create public goods (free software) that can be used by one person without reducing the availability to others. If the public relations departments of mega-corporations extol the value of business and markets, while criticizing government and fair labor, the Drupal community takes an alternative approach that values solidarity. In this sense, our democratic practices threaten unjust power. Throughout history people in power have pushed back against the democratizing effects of solidarity to defend their positions of power. In his 1776 magnum opus on political economy, Wealth of Nations, Adam Smith famously observed, "All for ourselves and nothing for other people, seems, in every age of the world, to have been the vile maxim of the masters of mankind." With every Drupal Camp, DrupalCon, code sprint, community summit, and user group meeting we gather together in solidarity. Let us not forget all we do to encourage hope and camaraderie.

If you are discouraged by a world that turns workers against each other and treats citizens as consumers, pushing them to the malls rather than the public library, remember that we as a Drupal community are pushing back against the "masters of mankind." In the 1970s, Buckley v. Valeo may have determined that money is a form of speech, but because we work together, Drupal becomes another kind of speech. Most of us (the working class) must sell our labor in return for a wage or salary. So what I am arguing is not for our community to become noncommercial or anti-commercial, but instead that we consider expanding our horizon of expectations to allow for a conception of Drupal as a political act. I want us to celebrate our community and stand up against hate, inequality, corruption, and depoliticization. If that idea makes you uncomfortable, then perhaps consider the words of the historian Howard Zinn and his suggestion that what matters are "the countless deeds of unknown people who lay the basis for the events of human history." I hope that we can find common ground, build on what we have accomplished, and organize against the forces that seek to divide us against ourselves.

Sep 06 2016
Sep 06

There exist millions of Open Source projects today, but many of them aren't sustainable. Scaling Open Source projects in a sustainable manner is difficult. A prime example is OpenSSL, which plays a critical role in securing the internet. Despite its importance, the entire OpenSSL development team is relatively small, consisting of 11 people, 10 of whom are volunteers. In 2014, security researchers discovered an important security bug that exposed millions of websites. Like OpenSSL, most Open Source projects fail to scale their resources. Notable exceptions are the Linux kernel, Debian, Apache, Drupal, and WordPress, which have foundations, multiple corporate sponsors and many contributors that help these projects scale.

We (Dries Buytaert is the founder and project lead of Drupal and co-founder and Chief Technology Officer of Acquia and Matthew Tift is a Senior Developer at Lullabot and Drupal 8 configuration system co-maintainer) believe that the Drupal community has a shared responsibility to build Drupal and that those who get more from Drupal should consider giving more. We examined commit data to help understand who develops Drupal, how much of that work is sponsored, and where that sponsorship comes from. We will illustrate that the Drupal community is far ahead in understanding how to sustain and scale the project. We will show that the Drupal project is a healthy project with a diverse community of contributors. Nevertheless, in Drupal's spirit of always striving to do better, we will also highlight areas where our community can and should do better.

Who is working on Drupal?

In the spring of 2015, after proposing ideas about giving credit and discussing various approaches at length, Drupal.org added the ability for people to attribute their work to an organization or customer in the Drupal.org issue queues. Maintainers of Drupal themes and modules can award issues credits to people who help resolve issues with code, comments, design, and more.

example credit issue on drupal.orgA screenshot of an issue comment on Drupal.org. You can see that jamadar worked on this patch as a volunteer, but also as part of his day job working for TATA Consultancy Services on behalf of their customer, Pfizer.

Drupal.org's credit system captures all the issue activity on Drupal.org. This is primarily code contributions, but also includes some (but not all) of the work on design, translations, documentation, etc. It is important to note that contributing in the issues on Drupal.org is not the only way to contribute. There are other activities — for instance, sponsoring events, promoting Drupal, providing help and mentoring — important to the long-term health of the Drupal project. These activities are not currently captured by the credit system. Additionally, we acknowledge that parts of Drupal are developed on GitHub and that credits might get lost when those contributions are moved to Drupal.org. For the purposes of this post, however, we looked only at the issue contributions captured by the credit system on Drupal.org.

What we learned is that in the 12-month period from July 1, 2015 to June 30, 2016 there were 32,711 issue credits — both to Drupal core as well as all the contributed themes and modules — attributed to 5,196 different individual contributors and 659 different organizations.

Despite the large number of individual contributors, a relatively small number do the majority of the work. Approximately 51% of the contributors involved got just one credit. The top 30 contributors (or top 0.5% contributors) account for over 21% of the total credits, indicating that these individuals put an incredible amount of time and effort in developing Drupal and its contributed modules:

How much of the work is sponsored?

As mentioned above, from July 1, 2015 to June 30, 2016, 659 organizations contributed code to Drupal.org. Drupal is used by more than one million websites. The vast majority of the organizations behind these Drupal websites never participate in the development of Drupal; they use the software as it is and do not feel the need to help drive its development.

Technically, Drupal started out as a 100% volunteer-driven project. But nowadays, the data suggests that the majority of the code on Drupal.org is sponsored by organizations in Drupal's ecosystem. For example, of the 32,711 commit credits we studied, 69% of the credited work is “sponsored.”

We then looked at the distribution of how many of the credits are given to volunteers versus given to individuals doing "sponsored work" (i.e. contributing as part of their paid job):

graph showing coptributions of top x

Looking at the top 100 contributors, for example, 23% of their credits are the result of contributing as volunteers and 56% of their credits are attributed to a corporate sponsor. The remainder, roughly 21% of the credits, are not attributed. Attribution is optional so this means it could either be volunteer-driven, sponsored, or both.

As can be seen on the graph, the ratio of volunteer versus sponsored don't meaningfully change as we look beyond the top 100 — the only thing that changes is that more credits that are not attributed. This might be explained by the fact that occasional contributors might not be aware of or understand the credit system, or could not be bothered with setting up organizational profiles for their employer or customers.

As shown in jamadar's screenshot above, a credit can be marked as volunteer and sponsored at the same time. This could be the case when someone does the minimum required work to satisfy the customer's need, but uses his or her spare time to add extra functionality. We can also look at the amount of code credits that are exclusively volunteer credits. Of the 7,874 credits that marked volunteer, 43% of them (3,376 credits) only had the volunteer box checked and 57% of them (4,498) were also partially sponsored. These 3,376 credits are one of our best metrics to measure volunteer-only contributions. This suggests that only 10% of the 32,711 commit credits we examined were contributed exclusively by volunteers. This number is a stark contrast to the 12,888 credits that were “purely sponsored,” and that account for 39% of the total credits. In other words, there were roughly four times as many “purely sponsored” credits as there were “purely volunteer” credits.

When we looked at the 5,196 users, rather than credits, we found somewhat different results. A similar percentage of all users had exclusively volunteer credits: 14% (741 users). But the percentage of users with exclusively sponsored credits is only 50% higher: 21% (1077 users). Thus, when we look at the data this way, we find that users who only do sponsored work tend to contribute quite a bit more than users who only do volunteer work.

None of these methodologies are perfect, but they all point to a conclusion that most of the work on Drupal is sponsored. At the same time, the data shows that volunteer contribution remains very important to Drupal. We believe there is a healthy ratio between sponsored and volunteer contributions.

Who is sponsoring the work?

Because we established that most of the work on Drupal is sponsored, we know it is important to track and study what organizations contribute to Drupal. Despite 659 different organizations contributing to Drupal, approximately 50% of them got 4 credits or less. The top 30 organizations (roughly top 5%) account for about 29% of the total credits, which suggests that the top 30 companies play a crucial role in the health of the Drupal project. The graph below shows the top 30 organizations and the number of credits they received between July 1, 2015 and June 30, 2016:

graph of contributions of top 30 organizations

While not immediately obvious from the graph above, different types of companies are active in Drupal's ecosystem and we propose the following categorization below to discuss our ecosystem.

Category Description Traditional Drupal businesses Small-to-medium-sized professional services companies that make money primarily using Drupal. They typically employ less than 100 employees, and because they specialize in Drupal, many of these professional services companies contribute frequently and are a huge part of our community. Examples are Lullabot (shown on graph) or Chapter Three (shown on graph). Digital marketing agencies Larger full-service agencies that have marketing led practices using a variety of tools, typically including Drupal, Adobe Experience Manager, Sitecore, WordPress, etc. They are typically larger, with the larger agencies employing thousands of people. Examples are Sapient (shown on graph) or AKQA. System integrators Larger companies that specialize in bringing together different technologies into one solution. Example system agencies are Accenture, TATA Consultancy Services, Capgemini or CI&T. Technology and infrastructure companies Examples are Acquia (shown on graph), Lingotek (shown on graph), BlackMesh, RackSpace, Pantheon or Platform.sh. End-users Examples are Pfizer (shown on graph), Examiner.com (shown on graph) or NBC Universal.

Most of the top 30 sponsors are traditional Drupal companies. Sapient (120 credits) is the only digital marketing agency showing up in the top 30. No system integrator shows up in the top 30. The first system integrator is CI&T, which ranked 31st with 102 credits. As far as system integrators are concerned CI&T is a smaller player with between 1,000 and 5,000 employees. Other system integrators with credits are Capgemini (43 credits), Globant (26 credits), and TATA Consultancy Services (7 credits). We didn't see any code contributions from Accenture, Wipro or IBM Global Services. We expect these will come as most of them are building out Drupal practices. For example, we know that IBM Global Services already has over 100 people doing Drupal work.

graph that displays contributions by organization type

When we look beyond the top 30 sponsors, we see that roughly 82% of the code contribution on Drupal.org comes from the traditional Drupal businesses. About 13% of the contributions comes from infrastructure and software companies, though that category is mostly dominated by one company, Acquia. This means that the technology and infrastructure companies, digital marketing agencies, system integrators and end-users are not meaningfully contributing code to Drupal.org today. In an ideal world, the pie chart above would be sliced in equal sized parts.

How can we explain that unbalance? We believe the two biggest reasons are: (1) Drupal's strategic importance and (2) the level of maturity with Drupal and Open Source. Various of the traditional Drupal agencies have been involved with Drupal for 10 years and almost entirely depend on on Drupal. Given both their expertise and dependence on Drupal, they are most likely to look after Drupal's development and well-being. These organizations are typically recognized as Drupal experts and sought out by organizations that want to build a Drupal website. Contrast this with most of the digital marketing agencies and system integrators who have the size to work with a diversified portfolio of content management platforms, and are just getting started with Drupal and Open Source. They deliver digital marketing solutions and aren't necessarily sought out for their Drupal expertise. As their Drupal practices grow in size and importance, this could change, and when it does, we expect them to contribute more. Right now many of the digital marketing agencies and system integrators have little or no experience with Open Source so it is important that we motivate them to contribute and then teach them how to contribute.

There are two main business reasons for organizations to contribute: (1) it improves their ability to sell and win deals and (2) it improves their ability to hire. Companies that contribute to Drupal tend to promote their contributions in RFPs and sales pitches to win more deals. Contributing to Drupal also results in being recognized as a great place to work for Drupal experts.

We also should note that many organizations in the Drupal community contribute for reasons that would not seem to be explicitly economically motivated. More than 100 credits were sponsored by colleges or universities, such as the University of Waterloo (45 credits). More than 50 credits came from community groups, such as the Drupal Bangalore Community and the Drupal Ukraine Community. Other nonprofits and government organization that appeared in our data include the Drupal Association (166), National Virtual Library of India (25 credits), Center for Research Libraries (20), and Welsh Government (9 credits).

Infrastructure and software companies

Infrastructure and software companies play a different role in our community. These companies are less reliant on professional services (building Drupal websites) and primarily make money from selling subscription based products.

Acquia, Pantheon and Platform.sh are venture-backed Platform-as-a-Service companies born out of the Drupal community. Rackspace and AWS are public companies hosting thousands of Drupal sites each. Lingotek offers cloud-based translation management software for Drupal.

graph of contributions by technology companies

The graph above suggests that Pantheon and Platform.sh have barely contributed code on Drupal.org during the past year. (Platform.sh only became an independent company 6 months ago after they split off from CommerceGuys.) The chart also does not reflect sponsored code contributions on GitHub (such as drush), Drupal event sponsorship, and the wide variety of value that these companies add to Drupal and other Open Source communities.

Consequently, these data show that the Drupal community needs to do a better job of enticing infrastructure and software companies to contribute code to Drupal.org. The Drupal community has a long tradition of encouraging organizations to share code on Drupal.org rather than keep it behind firewalls. While the spirit of the Drupal project cannot be reduced to any single ideology — not every organization can or will share their code — we would like to see organizations continue to prioritize collaboration over individual ownership. Our aim is not to criticize those who do not contribute, but rather to help foster an environment worthy of contribution.

End users

We saw two end-users in the top 30 corporate sponsors: Pfizer (158 credits) and Examiner.com (132 credits). Other notable end-users that are actively giving back are Workday (52 credits), NBC Universal (40 credits), the University of Waterloo (45 credits) and CARD.com (33 credits). The end users that tend to contribute to Drupal use Drupal for a key part of their business and often have an internal team of Drupal developers.

Given that there are hundreds of thousands of Drupal end-users, we would like to see more end-users in the top 30 sponsors. We recognize that a lot of digital agencies don't want, or are not legally allowed, to attribute their customers. We hope that will change as Open Source continues to get more and more adopted.

Given the vast amount of Drupal users, we believe encouraging end-users to contribute could be a big opportunity. Being credited on Drupal.org gives them visibility in the Drupal community and recognizes them as a great place for Open Source developers to work.

The uneasy alliance with corporate contributions

As mentioned above, when community-driven Open Source projects grow, there becomes a bigger need for organizations to help drive its development. It almost always creates an uneasy alliance between volunteers and corporations.

This theory played out in the Linux community well before it played out in the Drupal community. The Linux project is 25 years old now has seen a steady increase in the number of corporate contributors for roughly 20 years. While Linux companies like Red Hat and SUSE rank highly on the contribution list, so do non-Linux-centric companies such as Samsung, Intel, Oracle and Google. The major theme in this story is that all of these corporate contributors were using Linux as an integral part of their business.

The 659 organizations that contribute to Drupal (which includes corporations), is roughly three times the number of organizations that sponsor development of the Linux kernel, “one of the largest cooperative software projects ever attempted.” In fairness, Linux has a different ecosystem than Drupal. The Linux business ecosystem has various large organizations (Red Hat, Google, Intel, IBM and SUSE) for whom Linux is very strategic. As a result, many of them employ dozens of full-time Linux contributors and invest millions of dollars in Linux each year.

In the Drupal community, Acquia has had people dedicated full-time to Drupal starting nine years ago when it hired Gábor Hojtsy to contribute to Drupal core full-time. Today, Acquia has about 10 developers contributing to Drupal full-time. They work on core, contributed modules, security, user experience, performance, best practices, and more. Their work has benefited untold numbers of people around the world, most of whom are not Acquia customers.

In response to Acquia’s high level of participation in the Drupal project, as well as to the number of Acquia employees that hold leadership positions, some members of the Drupal community have suggested that Acquia wields its influence and power to control the future of Drupal for its own commercial benefit. But neither of us believe that Acquia should contribute less. Instead, we would like to see more companies provide more leadership to Drupal and meaningfully contribute on Drupal.org.

Who is sponsoring the top 30 contributors?

Rank Username Issues Volunteer Sponsored Not specified Sponsors 1 dawehner 560 84.1% 77.7% 9.5% Drupal Association (182), Chapter Three (179), Tag1 Consulting (160), Cando (6), Acquia (4), Comm-press (1) 2 DamienMcKenna 448 6.9% 76.3% 19.4% Mediacurrent (342) 3 alexpott 409 0.2% 97.8% 2.2% Chapter Three (400) 4 Berdir 383 0.0% 95.3% 4.7% MD Systems (365), Acquia (9) 5 Wim Leers 382 31.7% 98.2% 1.8% Acquia (375) 6 jhodgdon 381 5.2% 3.4% 91.3% Drupal Association (13), Poplar ProductivityWare (13) 7 joelpittet 294 23.8% 1.4% 76.2% Drupal Association (4) 8 heykarthikwithu 293 99.3% 100.0% 0.0% Valuebound (293), Drupal Bangalore Community (3) 9 mglaman 292 9.6% 96.9% 0.7% Commerce Guys (257), Bluehorn Digital (14), Gaggle.net, Inc. (12), LivePerson, Inc (11), Bluespark (5), DPCI (3), Thinkbean, LLC (3), Digital Bridge Solutions (2), Matsmart (1) 10 drunken monkey 248 75.4% 55.6% 2.0% Acquia (72), StudentFirst (44), epiqo (12), Vizala (9), Sunlime IT Services GmbH (1) 11 Sam152 237 75.9% 89.5% 10.1% PreviousNext (210), Code Drop (2) 12 borisson_ 207 62.8% 36.2% 15.9% Acquia (67), Intracto digital agency (8) 13 benjy 206 0.0% 98.1% 1.9% PreviousNext (168), Code Drop (34) 14 edurenye 184 0.0% 100.0% 0.0% MD Systems (184) 15 catch 180 3.3% 44.4% 54.4% Third and Grove (44), Tag1 Consulting (36), Drupal Association (4) 16 slashrsm 179 12.8% 96.6% 2.8% Examiner.com (89), MD Systems (84), Acquia (18), Studio Matris (1) 17 phenaproxima 177 0.0% 94.4% 5.6% Acquia (167) 18 mbovan 174 7.5% 100.0% 0.0% MD Systems (118), ACTO Team (43), Google Summer of Code (13) 19 tim.plunkett 168 14.3% 89.9% 10.1% Acquia (151) 20 rakesh.gectcr 163 100.0% 100.0% 0.0% Valuebound (138), National Virtual Library of India (NVLI) (25) 21 martin107 163 4.9% 0.0% 95.1%   22 dsnopek 152 0.7% 0.0% 99.3%   23 mikeryan 150 0.0% 89.3% 10.7% Acquia (112), Virtuoso Performance (22), Drupalize.Me (4), North Studio (4) 24 jhedstrom 149 0.0% 83.2% 16.8% Phase2 (124), Workday, Inc. (36), Memorial Sloan Kettering Cancer Center (4) 25 xjm 147 0.0% 81.0% 19.0% Acquia (119) 26 hussainweb 147 2.0% 98.6% 1.4% Axelerant (145) 27 stefan.r 146 0.7% 0.7% 98.6% Drupal Association (1) 28 bojanz 145 2.1% 83.4% 15.2% Commerce Guys (121), Bluespark (2) 29 penyaskito 141 6.4% 95.0% 3.5% Lingotek (129), Cocomore AG (5) 30 larowlan 135 34.1% 63.0% 16.3% PreviousNext (85), Department of Justice & Regulation, Victoria (14), amaysim Australia Ltd. (1), University of Adelaide (1)

We observe that the top 30 contributors are sponsored by 45 organizations. This kind of diversity is aligned with our desire not to see Drupal controlled by a single organization. The top 30 contributors and the 45 organizations are from many different parts in the world and work with customers large or small. We could still benefit from more diversity, though. The top 30 lacks digital marketing agencies, large system integrators and end-users — all of whom could contribute meaningfully to making Drupal for them and others.

Evolving the credit system

The credit system gives us quantifiable data about where our community's contributions come from, but that data is not perfect. Here are a few suggested improvements:

  1. We need to find ways to recognize non-code contributions as well as code contributions outside of Drupal.org (i.e. on GitHub). Lots of people and organizations spend hundreds of hours putting together local events, writing documentation, translating Drupal, mentoring new contributors, and more — and none of that gets captured by the credit system.
  2. We'd benefit by finding a way to account for the complexity and quality of contributions; one person might have worked several weeks for just one credit, while another person might have gotten a credit for 30 minutes of work. We could, for example, consider the issue credit data in conjunction with Git commit data regarding insertions, deletions, and files changed.
  3. We could try to leverage the credit system to encourage more companies, especially those that do not contribute today, to participate in large-scale initiatives. Dries presented some ideas two years ago in his DrupalCon Amsterdam keynote and Matthew has suggested other ideas, but we are open to more suggestions on how we might bring more contributors into the fold using the credit system.
  4. We could segment out organization profiles between end users and different kinds of service providers. Doing so would make it easier to see who the top contributors are in each segment and perhaps foster more healthy competition among peers. In turn, the community could learn about the peculiar motivations within each segment.

Like Drupal the software, the credit system on Drupal.org is a tool that can evolve, but that ultimately will only be useful when the community uses it, understands its shortcomings, and suggests constructive improvements. In highlighting the organizations that sponsor work on Drupal.org, we hope to provoke responses that help evolve the credit system into something that incentivizes business to sponsor more work and that allows more people the opportunity to participate in our community, learn from others, teach newcomers, and make positive contributions. We view Drupal as a productive force for change and we wish to use the credit system to highlight (at least some of) the work of our diverse community of volunteers, companies, nonprofits, governments, schools, universities, individuals, and other groups.

Conclusion

Our data shows that Drupal is a vibrant and diverse community, with thousands of contributors, that is constantly evolving and improving the software. While here we have examined issue credits mostly through the lens of sponsorship, in future analyses we plan to consider the same issue credits in conjunction with other publicly-disclosed Drupal user data, such as gender identification, geography, seasonal participation, mentorship, and event attendance.

Our analysis of the Drupal.org credit data concludes that most of the contributions to Drupal are sponsored. At the same time, the data shows that volunteer contribution remains very important to Drupal.

As a community, we need to understand that a healthy Open Source ecosystem is a diverse ecosystem that includes more than traditional Drupal agencies. The traditional Drupal agencies and Acquia contribute the most but we don't see a lot of contribution from the larger digital marketing agencies, system integrators, technology companies, or end-users of Drupal — we believe that might come as these organizations build out their Drupal practices and Drupal becomes more strategic for them.

To grow and sustain Drupal, we should support those that contribute to Drupal, and find ways to get those that are not contributing, involved in our community. We invite you to help us figure out how we can continue to strengthen our ecosystem.

We hope to repeat this work in 1 or 2 years' time so we can track our evolution. Special thanks to Tim Lehnen (Drupal Association) for providing us the credit system data and supporting us during our research.

Apr 07 2016
Apr 07

The GPL Protects Software Freedoms

Before offering my analysis, I should start by acknowledging the obvious reason why paid Drupal modules fail: the General Public License (GPL). The Drupal Association clearly states that “Drupal modules and themes are a derivative work of Drupal. If you distribute them, you must do so under the terms of the GPL version 2 or later.” Consequently, anyone who wishes to sell a Drupal module must provide the source code.

Drupal community members are standing by with their credit cards ready to purchase those modules – and then post the code to Drupal.org so that everyone else can use it. These principled individuals believe that copyleft provides a powerful tool for ensuring software freedom and will exercise their right guaranteed by the GPL that allows the recipient (buyer) “to copy, distribute or modify” the module or theme purchased. The seller “may not impose any further restrictions on the recipients’ exercise of the rights.” The GPL greatly curtails most plans to sell Drupal modules, and these would-be capitalists might have more success selling popsicles during a blizzard.

Yet the GPL does not close the debate on this subject. I have heard many reasons provided to justify revisiting this conversation, and most frequently they come down to money. Let me share some direct quotes used to justify the pursuit of a “Drupal Marketplace,” “paid Drupal apps,” or “paid modules”:

I have read and listened to a great deal of arguments defending these commercial endeavors, and I remain unconvinced that the potential upsides outweigh the considerable drawbacks.

A History of Failure

The words of the American literary critic Fredric Jameson influence my thinking on this topic: “always historicize!” A look at attempts to sell Drupal modules reveals a distinct lack of success, and yet people continue to claim they have found a solution. Consider SubHub, who announced in 2011 to great fanfare the “World’s First Drupal-Powered App Store.” They hoped to offer some of their “apps” at no cost, while other “apps” would require a small recurring charge. This plan failed and SubHub abandoned their initiative in 2013, lamenting the fact that the Drupal community “simply didn’t share the same motivation to make Drupal a highly commercial, competitive alternative to WordPress.” My apologies to anyone who built a Drupal site with integral SubHub functionality.

Also in 2011 – a big year for “apps” in the Drupal community – Phase2 announced the Open App Standard initiative. The title contains the word “open” so surely this plan would find traction with Drupal people, right? While Phase2 found some success with OpenPublic, which uses apps, I don’t see evidence that “apps” ever found traction in the Drupal community, and certainly not adoption with alacrity.

Keep in mind that many people make money selling Drupal services and that the community generally supports such efforts. I work at a company filled with people who make money building Drupal websites. Rather, I think this evidence shows that paid module schemes tend to fail, that others have found Drupal to be “actually a horrible solution to build apps,” and that when people ask the question, “Is a Drupal App Store a good idea?” the community generally responds with a decisive “no” (unless it features ponies). We absolutely want people to succeed in the community, just not by selling modules.

Certainly exceptions exist. For instance, some companies have found success selling Drupal themes. A case could be made that Acquia, a company founded by Drupal’s creator, peddles its own variety of “paid apps.” The Acquia Connector module “enhances the Drupal experience by providing the support and network services to operate a trouble-free Drupal website.” However, the module does little without an Acquia Subscription, which requires regular payments.

Acquia, and other similar services, get around the restrictions of the GPL by taking advantage of something known as the “application service provider (ASP) loophole.” When the Free Software Foundation published GPL version 2 (all Drupal code must be GPL version 2 or later) in 1991 we did not use web services like we do today. Because providing a subscription service (such as Mollom or New Relic) does not involve distributing software, Acquia need not provide any additional code than that which connects the site to the service.

The Drupal community could adopt a stronger copyleft license that closes the ASP loophole, such as the Affero General Public License (AGPL). Just do not expect this to happen anytime soon. Dries Buytaert, the founder and project lead of Drupal, built a business that takes advantage of this loophole and he made his opinion clear a decade ago in a blog post titled, “Long Live the Web Services Loophole.”

Consequently, the focus of the discussion around paid modules often revolves more around the merits and problems of what Richard Stallman calls “Service as a Software Substitute (SaaSS)” than on actually selling Drupal modules that address common challenges. While some companies have found success with the SaaSS model, why do so many others fail? To answer this question, we must look beyond code and licenses to the Drupal community.

Products and Practices

I wrote at length about the Drupal community in previous articles such as “The Cultural Construction of Drupal” and “Better, then Bigger: Cultivating the Drupal Community,” and I do not intend to re-hash those same ideas here. Rather, I would like to examine why “paid module” schemes have flopped.

As I see it, one fundamental explanation for failure has to do with when business people misunderstand Drupal as a product rather than an organic accumulation of practices, or more broadly, when they ignore the differences between machines and humans. I deliberately add the qualifier “business” to describe these people because all efforts to create paid products are intended to generate revenue. Efforts to sell Drupal modules, in the Marxist sense, epitomize efforts to create capital, to accumulate money – a goal that comes off as at odds with a community that values participation.

All modules that come with a fee are intended to generate revenue, but we must not forget that “free” modules (that are also “Free”) have the potential to do the same. Many people, including me, enjoy getting paid to write Drupal code. For the paid module argument to work, its defendant must demonstrate that existing models are somehow lacking. Defending a new commercial approach necessitates, in my view, demonstrating the unsatisfactory nature of a free software project with more than 33,000+ shared modules that has existed for more than 15 years and has a vibrant marketplace of vendors offering Drupal services. Such an argument not only requires a high level of mental gymnastics, it, at least tacitly, represents an affront to years of successful collaboration.

Because some of those recommending that Drupal re-evaluate its commercial ecosystem are contributing members of the community, I open myself up to the critique of constructing inaccurate divisions, pitting Drupal and its community against business people who desire to convert Drupal into a revenue-generating product. But we know too well that many of us in the Drupal community could represent either side. We aim to balance our need to support our families with our desire to defend Drupal and fight for its freedom. Luckily, we can often choose both.

Drupal as Art

Moving away from discussions of licenses and capitalist motives, I would now like to venture beyond the typical boundaries of the “paid module” discussion to explore why people feel so connected to Drupal. I get the sense that many people in the Drupal community do not actually understand the intricacies of the GPL and how it differs from other free software licenses such as the AGPL. I believe that the community is protecting something more ephemeral. Consequently, this part of my argument ventures into much more abstract topics and requires thinking about Drupal differently, less as a “technology” and more as an artistic practice.

I am not the first person to notice Drupal’s artistic side. For example, a DrupalCon session had the title “Zen and the Art of Drupal.” Someone else even created a new word, “Drupl’Art,” to describe “Drupal code that is both beautiful and artistic.” The conception of “Drupal as art” is not new, but I am going to be using it here in order to offer new insights into how the Drupal community works.

More than just a thought experiment, the idea of Drupal as art becomes useful when we position it within another long-running debate, namely the effect of technology on art. For instance, when proponents position technological advances as something that improves the lives of many, critics will sometimes note that those advances also threaten the purity of art – for example, photographs (the “new technology”) were seen as a threat to portraiture (“pure art”). Ironically, Drupal, as I construct it here plays the role of art, even as we cannot deny that most people would label Drupal “technology” well before they would ever call it “art.” And yet when members of the Drupal community react negatively to the suggestion of paid modules, it is not simply because of the GPL, it is because the community is defending its perceived “purity.”

Drupal and art have both been understood as pure expressions, deeply tied to their predecessors, consisting of ever changing practices, and driven by community. Yet it would be idle to suggest that concerns about the threat of technology to art are exactly the same as concerns about the effect of paid modules on Drupal’s ecosystem. Nonetheless, I believe that we can better understand the Drupal community’s typical allergic reaction to “paid modules” by interrogating previous debates about technology and art.

This line of reasoning follows a long history of thinkers who have conflated art and technology that goes at least as far back as Ancient Greece. The Greeks did not enjoy art for aesthetic reasons. The word “technology” refers to a “treatise on a practical art or craft” and its Greek root is techne. For the Greeks, techne also referred to art. Aristotle described techne as both practical knowledge and practical art. And what Drupal enthusiast would not admit that most websites convey practical knowledge?

In his 1954 essay, “The Question Concerning Technology,” the German philosopher Martin Heidegger variously described both art and technology as a “mode of revealing,” a way of “bringing forth.” A painting reveals another person’s point-of-view and a website “reveals” information. As uncomfortable as it may seem to some among us to describe Drupal as art, it helps explain why people feel so connected to Drupal and vigorously defend its purity. The community wants to work together and reveal its solutions rather than hide them behind a web service. Developers treasure not just revealing websites, but revealing (sharing) the code in the modules that enables their functionality.

Another well-regarded German philosopher, Walter Benjamin, provided valuable insights that are useful for our purposes in his 1936 essay, “The Work of Art in the Age of Its Technological Reproducibility.” Therein Benjamin explores when inventions such as photography and film (both being kinds of “mechanical reproduction”) “separated art from its basis in cult, the semblance of its autonomy disappeared forever.” Not only did these products threaten the group, they also threatened the group’s output (its art). He believed that “the unique value of the ‘authentic’ work of art always has its basis in ritual.” Likewise in the Drupal community we value ritual: we discuss issues, post patches, review the work of others, attend camps and cons, celebrate the accomplishments of new members, and create code with unique value – code that lives with other Drupal code on Drupal.org. Hiding code threatens our rituals.

Paid modules or services revoke our access, our autonomy, and our beloved practices. Drupal is something people do, and we cannot learn by doing when we cannot see the code. Products are purchased, while practices are lived. Drupal, like other forms of techne, is communication, and we cannot communicate in the same manners with black boxes as we can in the issue queue.

In addition to affecting what we do, the existence of paid modules could negatively affect perceptions of the Drupal community. Benjamin writes of a “decay of the aura,” which sounds much like what the Drupal community works against. While some may argue, as one Slate writer did, simply that “Drupal hates change,” many in the Drupal community still believe that Drupal exudes a sort of magical aura. We hold the community close to our hearts and defend its name. We do not half-heartedly promote our community, we instead speak of our “unique, diverse Drupal community,” say that “Drupal has made a big difference in my life,” and that “I’m truly proud to be part of this community.” We protect our people, practices, and reputation by following the Drupal Code of Conduct, in the hope that “we preserve the things that got us here.”

Our current system for creating modules on Drupal.org values the work of humans. Benjamin observes, “What matters is the way the orientation and aims of that technology differ from those of ours. Whereas the former made the maximum possible use of human beings, the latter reduces their use to the minimum.” Drupal is not so much the thing that is built but the way it is built by people. In fact, one of Lullabot’s most frequently quoted core values is “be human.”

The Drupal software will never be complete, and we hope the sharing continues indefinitely. In the same spirit, Benjamin believes, “It has always been one of the primary tasks of art to create a demand whose hour of full satisfaction has not yet come.” The Drupal community wants to continue building, to keep moving forward, never content that we have finally arrived at an “end” where our interactions have been replaced by web services.

Fredric Jameson once warned that “machines are indeed machines of reproduction rather than of production.” The Drupal community has produced a great deal of code that powers much of the web. Few among us would want to shift from production to reproduction, from working together to solve problems to purchasing solutions to problems. Repeatedly and continuously solving the sames problems – building the same websites – breeds boredom. We like to create new and shiny things, producing not reproducing. Our rituals, our process, and our freedom to tinker allows us to continuously move forward.

The Contrasting Case of WordPress

Even if these theories accurately describe the Drupal community, they do not fully account for the success of paid WordPress plugins. Do paid plugins make WordPress unpure, inhabited by a community of dispassionate contributors? Absolutely not. Does the availability of paid plugins somehow cheapen the WordPress community or imply that WordPress lacks meaningful rituals? Certainly no. WordPress powers a huge chunk of the web with GPL-licensed code. It would be fruitless to deny the overwhelming success of a project with a vibrant community. Rather, I hope to convey how the WordPress community’s embrace of paid plugins informs my argument that the Drupal community understands its practices as a kind of artistic expression.

Simply suggesting that WordPress and Drupal are different helps about as much as arguing that Drupal and WordPress are words that contain an incommensurable number of letters. We could go a step further, as Dries Buytaert often does and argue not only are they different, but that WordPress and Drupal target different markets, with “WordPress dominating the small business segment” and Drupal geared toward the “larger organizations with more complex requirements” (an idea I dispute). If that were true, one would think the community that caters to “large organizations” would have the customers with the funds to purchase modules rather than get them at no cost. Then again, the reverse argument seems equally defensible, and that small businesses would rather pay for plugins than for those reportedly expensive Drupal developers. None of these avenues feel satisfactory.

One might expect that WordPress and Drupal espouse contrasting ideas about paid add-ons and the GPL. Quite the contrary, the Wordpress.org licensing page provides clear guidance about how plugins should be licensed: “derivatives of WordPress,” including plugins and themes, “inherit the GPL license.” While they admit to “some legal grey area regarding what is considered a derivative work,” they “feel strongly that plugins and themes are derivative work and thus inherit the GPL license.” The community leaders back up their assertions with thoughtful discussion as well as expert analysis from the Software Freedom Law Center. The WordPress licensing page even provides a link to Drupal’s “excellent page on licensing as it applies to themes and modules (their word for plugins).” Thus, WordPress and Drupal provide almost exactly the same guidelines.

Remarkably, certain members of the WordPress community completely ignore the advice on the licensing page. They claim “the GPL FAQ has no legal validity.” Some sellers proudly declare, “got my own licensing terms” and others offer code with terms and conditions that make no mention of the GPL. Some explain the norm thusly: “Premium WordPress plugin and theme developers usually sell you a license key, which allows you access to support and automatic upgrades.” One store believes it takes advantage of GPL loopholes and sells plugins under a default split license ostensibly to “protect authors.” In other words, the WordPress.org plugin directory that lists over 40,000 plugins is not a comprehensive directory of WordPress plugins. If this sounds a bit like the Wild West, then you may be a Drupal developer.

If Drupal modules are about process, then WordPress plugins – at least a portion of them – are products. Members of the WordPress community write at length about the benefits of "premium products." Some stores offer plugins that are “guaranteed to work, always updated, top quality plugins. Beautifully coded, packed with features, and easy to use.” They offer “free trials.” Another store proudly trumpets its “professionally developed and supported options not found on WordPress.org.” Ventures of this nature are justified with such syllogisms as “‘free’ doesn’t make me rich.” Plugins like these are products, plain and simple, and clearly the WordPress community (“happy customers,” as one site put it) willingly pays.

In comparison, Drupal developers get modules from Drupal.org. More than just a “best practice,” this is the norm in the Drupal community. It keeps things simple, and has a practical benefit: acquiring a new module requires typing drush dl module-name.

Incidentally, another kind of software facilitates an analogous workflow: GNU/Linux. For example, to install software on my operating system, Debian, I type apt install package_name. I would never consider downloading software to my computer from some random website, let alone software that I could not inspect. For me, at least, these two processes (drush dl and apt get) feel nearly identical, and I could make a good argument that the Drupal community is more like the Debian community (i.e., that many of the commitments outlined the Debian Social Contract are lived in the Drupal community) than the WordPress community.

Once again, the words of Benjamin feel relevant: “It might be stated as a general formula that the technology of reproduction detaches the reproduced object from the sphere of tradition. By replicating the work many times over, it substitutes a mass existence for a unique existence.” App stores for paid plugins fragment traditions established on WordPress.org. The Drupal community, on the other hand, has decided not to purchase paid Drupal modules, not to depart from its tradition of keeping Drupal as close to 100% free as possible. Whenever this issue arises, the Drupal community votes with its voices and its wallets to favor practices over products, to reveal the modules it creates rather than conceal them behind paywalls, to work with – rather than sell to – each other. The fact that WordPress customers have chosen a different path reveals contrasting, not misplaced, priorities.

While it is difficult to generalize a community with more than a million users (or at least user accounts), Holly Ross, Executive Director of the Drupal Association, believes “the one thing we all have in common is that we care about the fate of Drupal.” It might be fate that someday paid modules will find success in the Drupal community, and that would not necessarily be wrong. It would mean, however that the essence of Drupal has changed. That may even signal the end of Drupal. But history suggests that day will not soon come. Until then, the Drupal community will continue to defend its practices. It will band together to resist paid module schemes, treat its software with a reverence that others reserve for works of art, share code, and encourage others to do the same.

Works Cited

Benjamin, Walter. The Work of Art in the Age of Its Technological Reproducibility, and Other Writings on Media. Edited by Michael W. Jennings, Brigid Doherty, and Thomas Y. Levin. Cambridge, Mass: Belknap Press, 2008.

Heidegger, Martin. The Question Concerning Technology and Other Essays. New York: Harper Perennial, 1977.

Feb 26 2016
Feb 26

In many cases, the mobile web is a slow and frustrating experience. The AMP Project is an open source initiative that embodies the vision that publishers can create mobile optimized content once and have it load instantly everywhere. When AMP was first introduced last October, many commentators immediately compared it to Facebook's Instant Articles and Apple's News app. One of the biggest differentiators between AMP and other solutions is the fact that AMP is open source.

AMP HTML is, essentially, a subset of HTML. And it really makes the web fast. AMP HTML is designed to support smart caching, predictable performance, and modern, beautiful mobile content. Since AMP HTML is built on existing web technologies, publishers continue to host their own content, craft their own user experiences, and flexibly integrate their advertising and business models -- all using familiar tools, which will now include Drupal!

One of the most touted features of Drupal is its flexibility, so making Drupal produce AMP HTML has required a lot of careful consideration of the design approach. To make Drupal output AMP HTML, we have created an AMP module, AMP theme, and a PHP Library.

When the AMP module is installed, AMP can be enabled for any content type. At that point, a new AMP view mode is created for that content type, and AMP content becomes available on URLs such as node/1/amp or node/article-title/amp. We also created special AMP formatters for text, image, and video fields.

The AMP theme is designed to produce the very specific markup that the AMP HTML standard requires. The AMP theme is triggered for any node delivered on an /amp path. As with any Drupal theme, the AMP theme can be extended using a subtheme, allowing publishers as much flexibility as they need to customize how AMP pages are displayed. This also makes it possible to do things like place AMP ad blocks on the AMP page using Drupal's block system.

The PHP Library analyzes HTML entered by users into rich text fields and reports issues that might make the HTML non-compliant with the AMP standard. The library does its best to make corrections to the HTML, where possible, and automatically converts images and iframes into their AMP HTML equivalents. More automatic conversions will be available in the future. The PHP Library is CMS agnostic, designed so that it can be used by both the Drupal 8 and Drupal 7 versions of the Drupal module, as well as by non-Drupal PHP projects.

We have done our best to make this solution as turnkey as possible, but the module, in its current state, is not feature complete. At this point only node pages can be converted to AMP HTML. The initial module supports AMP HTML tags such as amp-ad, amp-pixel, amp-img, amp-video, amp-analytics, and amp-iframe, but we plan to add support for more of the extended components in the near future. For now the module supports Google Analytics, AdSense, and DoubleClick for Publisher ad networks, but additional network support is forthcoming.

While AMP HTML is already being served by some of the biggest publishers and platforms in the world — such as The New York Times, The Economist, The Guardian, BBC, Vox Media, LinkedIn, Pinterest, and many more! — you don't have to be a large publisher to take advantage of AMP. Today, any Drupal 8 site can output AMP HTML using the AMP module. We invite you to try it out and let us know what you think!

Finally, if you are interested in this topic and want to learn more about publishing AMP with Drupal, please leave a comment on our DrupalCon New Orleans proposal.

Nov 04 2015
Nov 04

While the new configuration system in Drupal 8 strives to make the process of exporting and importing site configuration feel almost effortless, immensely complex logic facilitates this process. Over the past five years, the entire configuration system code was written and rewritten multiple times, and we think we got much of it right in its present form. As a result of this work, it is now possible to store configuration data in a consistent manner and to manage changes to configuration. Although we made every attempt to document how and why decisions were made – and to always update issue queues, documentation, and change notices – it is not reasonable to expect everyone to read all of this material. But I did, and in this post I try to distill years of thinking, discussions, issue summaries, code sprints, and code to ease your transition to Drupal 8.

In this article I highlight nine concepts that are key to understanding the configuration system. This article is light on details and heavy on links to additional resources.

  1. It is called the “configuration system.” The Configuration Management Initiative (CMI) is, by most reasonable measures, feature complete. The number of CMI critical issues was reduced to zero back in the Spring and the #drupal-cmi IRC channel has been very quiet over the past few months. Drupal now has a functional configuration management system, but we only should call the former a CMS. While it is tempting to think of “CMI” as an orphaned initialism, like AARP or SAT, we aspire to avoid confusion. Our preferred phrase to describe the result of CMI is “configuration system.” This is the phrase we use in the issue queue and the configuration system documentation.

  2. DEV ? PROD. Perhaps the most important concept to understand is that the configuration system is designed to optimize the process of moving configuration between instances of the same site. It is not intended to allow exporting the configuration from one site to another. In order to move configuration data, the site and import files must have matching values for UUID in the system.site configuration item. In other words, additional environments should initially be set up as clones of the site. We did not, for instance, hope to facilitate exporting configuration from whitehouse.gov and importing it into harvard.edu.

  3. The configuration system is highly configurable. Out of the box the configuration system stores configuration data in the database. However, it allows websites to easily switch to file-based storage, MongoDB, Redis, or another favorite key/value store. In fact, there is a growing ecosystem of modules related to the configuration system, such as Configuration Update, Configuration Tools, Configuration Synchronizer, and Configuration Development.

  4. There is no “recommended” workflow. The configuration system is quite flexible and we can imagine multiple workflows. On one end of the spectrum, we expect some small sites will not ever use the configuration manager module to import and export configuration. For the sites that utilize the full capabilities of the configuration system, one key question they will need to answer regards the role that site administrators will play in managing configuration. I suspect many sites will disable configuration forms on their production sites – perhaps using modules like Configuration Read-Only Mode – and make all configuration changes in their version control system.

  5. Sites, not modules, own configuration. When a module is installed, and the configuration system imports the configuration data from the module’s config/install directory (and perhaps the config/optional directory), the configuration system assumes the site owner is now in control of the configuration data. This is a contentious point to some developers because module maintainers will need to use update hooks rather than making simple changes to their configuration. Changing the files in a module’s config/install directory will have no effect on the site.

  6. Developers will still use Features. The Features module in Drupal 8 changes how the configuration system works to allow modules to control their configuration. Mike Potter, Nedjo Rogers, and others have been making Features in Drupal 8 do the kinds of things Features was originally intended to do, which is to bundle functionality, such as a “photo gallery feature.” The configuration system makes the work of the Features module maintainers exponentially easier and as a result, we all expect using Features to be more enjoyable in Drupal 8 than it was in Drupal 7.

  7. There are two kinds of configuration in Drupal 8: simple configuration and configuration entities. Simple configuration stores basic configuration, such as boolean values, integers, or texts. Simple configuration has exactly one copy or version, and is somewhat similar to using variable_get() and variable_set() in Drupal 7. Configuration entities, like content types, enable the creation of zero or more items and are far more complex. Examples of configuration entities include views, content types, and image styles.

  8. Multilingual needs drove many decisions. Many of the features of the configuration system exist to support multilingual sites. For example, the primary reason schema files were introduced was for multilingual support. And many of the benefits to enabling multilingual functionality resulted in enhancements that had much wider benefits. The multilingual initiative was perhaps the best organized and documented Drupal 8 initiative and their initiative website contains extensive information and documentation.

  9. Configuration can still be overridden in settings.php. The $config variable in the settings.php file provides a mechanism for overriding configuration data. This is called the configuration override system. Overrides in settings.php take precedence over values provided by modules. This is a good method for storing sensitive data that should not be stored in the database. Note, however, that the values in the active configuration – not the values from settings.php – are displayed on configuration forms. Of course, this behavior can be modified to match expected workflows. For example, some site administrators will want the configuration forms to indicate when form values are overridden in settings.php.

If you want more information about the configuration system, the best place to start is the Configuration API page on api.drupal.org. It contains numerous links to additional documentation. Additionally, Alex Pott, my fellow configuration system co-maintainer, wrote a series of blog posts concerning the “Principles of Configuration Management” that I enthusiastically recommend.

I hope you will agree that the configuration system is one of the more exciting features of Drupal 8.

This article benefitted from helpful conversations and reviews by Tim Plunkett, Jennifer Hodgdon, Andrew Berry, and Juampy NR.

Sep 16 2015
Sep 16

It was certainly not the first discussion about scaling the Drupal community, but when Dries first made his case for “scaling” in Amsterdam in 2014, many seasoned Drupalers immediately realized this was not a typical Driesnote. Dries referenced a variety of economic theories, covering topics such as “public goods,” the “free rider problem,” “self-interest theory,” “collective action theory,” “selective benefits,” and “privileged groups.” He was not talking about the average number of times Drupal had been downloaded each day or charting the number of contributed modules, as he often did in previous “states of Drupal” talks. Dries was engaging in analysis. He warned the audience that he had been reading “lots of economic papers,” admitted that “there’s an academic hidden inside me,” and pleaded, “please don’t fall asleep.” That such a talk required these disclaimers revealed the level of patience our community typically has had for academically-oriented analysis. Dries proceeded in his keynote (but not his blog post) to cite peer-reviewed articles from the economist Paul Samuelson and the American ecologist Garrett Hardin, and he extrapolated ideas from economist Mancur Olson’s well-known 1965 book, The Logic of Collective Action. Rather than just see Dries presenting, the audience witnessed Dr. Buytaert historicizing. The British journalist Will Self once remarked, “Visionaries, notoriously, are quite free from ratiocination and devoid of insight.” With his new ideas based on economic theories, Dries contested the stereotype. The reaction from the community was generally positive, with his talk garnering such accolades as “historic” and “the best Dries keynote ever.”

This Driesnote signaled a more nuanced critique from an entrepreneur more accustomed to discussing books about Drupal than books from academic presses. More important, since Dries started promoting his ideas about economic theory, some of what he suggested has become reality. It probably comes as little surprise that this “benevolent dictator” can get things done. On his blog and in his talks he suggested various changes to Drupal.org, such as improved organizational profile pages featuring more statistics and adding corporate attributions to individual commit credits in Drupal code (a topic he had blogged about previously). He offered other concrete suggestions that might very well still be in the works, including new advertising opportunities on Drupal.org in exchange for fixing bugs, the opportunity for organizations to get better visibility on the job board, and the ability to sort the marketplace page by contributions rather than just alphabetically. All of his suggested improvements were technical in nature, and ostensibly designed to benefit organizations.

To his great credit, Dries maintains an openness to other ideas. In his Amsterdam keynote, Dries said, “these are not final solutions. These are just ideas, and I hope they will be starting points for discussion” (34:53). He said, “this is just me brainstorming” (43:49), and that we should keep working at building our community, “even if it takes us years to get it right” (47:27). Accordingly, here I try to adopt a constructivist approach that adds to – rather than subtracts from – what Dries suggested. I am here to assemble, not debunk. I bring the same attitude that I aspire to when dealing with any of my colleagues, which is to assume positive motivation – I assume that Dries, like my co-workers, has good intentions (others of Dries’s critics seem to forget this). Like Dries, I care deeply about the Drupal community and I would like to understand more about the problems we face, what Drupal means, and how various changes might affect our community dynamics. In the remainder of this article, I will spend most of my effort dissecting Dries’s suggestions, the logic behind them, and how they compare to the theories of the economic theorists he cites. Finally, I will offer a few of my own suggestions. I believe that we will be most successful not merely by convincing more people to work with us through technological manipulations, but instead by focusing on improving interactions within the community and a goal of cultivating social solidarity. In other words, I will argue that instead of using technology to grow our community, we should focus our efforts on adjusting our culture in order to improve our technology.

What Is the Problem?

Before we can discuss solutions, we should consider the problems that need solving. Dries mentions generalized goals of attracting “more contributors” to the Drupal project in order to “try more things and do things better and faster,” without interrogating what “better” means or why “faster” should be a goal. His solutions seem to suggest that we should lure organizations to get more involved by hiring Drupal core developers, although Dries admits that “hiring Drupal talent is hard.” That Dries does not make explicit the benefits of growing the community beyond increasing our capacity to do things “better and faster” indicates that he understands the problem to be obvious. But is the problem actually that straightforward? Does bigger mean better? Should we consider goals beyond growing the community?

Evgeny Morozov, a rigorous thinker with a combative style, would label Dries’s approach “solutionism.” In To Save Everything, Click Here: The Folly of Technological Solutionism, Morozov writes, “Solutionism presumes rather than investigates the problems that it is trying to solve” (6). Morozov is frustrated by the prevalence of solutionism in technology debates and he dislikes any debate that presupposes the inherent worth of technologies such as “the Internet” (nowadays, Morozov always puts “the Internet” in scare quotes) or Open Source. I agree, and for our purposes, we should not assume that scaling open source, or Drupal, is a venture of unquestionable worth. Do we grow Drupal for social reasons? Are we politically motivated? Is this activism? Is this a philosophical debate? Or should we all just assume economic motivations? Whatever the impetus, I feel that when we talk about growing Drupal, we should not approach this activity as one with absolute value.

One potential benefit might be to increase business. Perhaps Dries feels it unnecessary to explain his motives. Dries is not just a developer, he’s also a successful entrepreneur. Dries discusses his ideas about “scaling” on his blog, which is also the place where he posts his annual “retrospectives” about his Drupal company, Acquia. In other words, Dries uses his blog not just to share personal information and news related to the Drupal project, he also uses his blog for business. So it seems quite probable that he wants to do more than grow the community, and that his goal is also to grow his company. Dries has fully committed himself to Drupal, and as the value of the Drupal software increases, so does the value of his Drupal company. One can hardly fault someone who has to answer to investors and who seeks to take his company public.

Another possibility is that Dries needs to defend his company. Dries is keenly aware that Acquia contributes disproportionately more to the Drupal project than any other company, and he understandably seeks to change this situation. Indeed, multiple times during his presentation Dries discusses the ratio of contributors. Dries says that it is “all about this ratio” (26:29 minutes into his talk) and that changing the ratio “will fundamentally change the dynamics of the community” (26:40). I agree with the latter part of his suggestion in that growing the community beyond Acquia will ease the “exploitation” of Acquia. While “exploitation” may seem a bit strong in this context, I borrow this word from one of Dries’s primary informants, Mancur Olson, who uses it repeatedly in The Logic of Collective Action. Olson believes there exists a “systematic tendency for ‘exploitation’ of the great by the small” (29). So applying Olson’s idea to Dries’s subject, we could understand why Acquia – run by the founder of Drupal, offering Drupal services, and employing more Drupal contributors than any other organization – has to carry the most weight. We should not feel too bad, however, because while it may be that Acquia contributes disproportionately to Drupal, it is also true that Acquia benefits disproportionately as Drupal gets better. Arguably, Dries and his company have the most to gain when others participate in Drupal.

While Acquia grows with Drupal, there are certainly many others in the Drupal community that stand to benefit as well, especially the many other Drupal “agencies” (including Lullabot, where I work) as well as Acquia’s many partners. Dries writes, “my company Acquia currently employs the most full-time contributors to Drupal but does not receive any exclusive benefits in terms of monetizing Drupal. While Acquia does accrue some value from hiring the Drupal contributors that it does, this is something any company can do.” Certainly another part of Dries’s project is to entice Drupal agencies to contribute. But doesn’t this happen already? Don’t agencies understand that the prospect of scaling Drupal will lead to more clients and that it is in their best interest to contribute to Drupal? This topic of individuals contributing to groups is, in fact, one of the main subjects in Olson’s book, with his main point being that as groups get larger, rational individuals are less likely to participate. Olson’s thesis is that in large groups, “rational, self-interested individuals will not act to achieve their common or group interests” (2). Consequently, it is not difficult to understand why Dries was drawn to Olson’s theories – Olson’s study offers multiple perspectives on why individuals do not contribute to large groups, which Dries can use to help understand why all of these Drupal agencies do not fund as many Drupal core developers as Acquia. Even better, it offers multiple ideas about how to entice these agencies to help make Drupal “better and faster.”

While it would seem that Dries is focused primarily on growing Acquia and other Drupal businesses, he would also like to attract individuals. He later clarified his goal in a comment of a curious blog post, maintaining that he “proposed ways to increase the social capital of both individuals and organizations.” His most immediate goal is not, in fact, to “scale Open Source.” Rather, he seeks to encourage individuals and organizations to contribute to Drupal. And from Olson, Dries learns more methods for coercion, another term that Olson uses frequently in his book. Olson believes that members of a group will not “act to advance their common or group objectives unless there is coercion to force them to do so, or unless some separate incentive, distinct from the achievement of the common or group interest, is offered to the members of the group individually on the condition that they help bear the costs or burdens involved in the achievement of the group objectives” (2). Olson talks at length about various types of incentives – social, selective, economic, etc. – that would make participation in a group more rational.

It can be quite tricky to grok the motivations of the organizations and individuals that contribute to the Drupal project. Olson focuses primarily on individuals who are rational and self-interested. Olson’s subjects are individuals that “rationally seek to maximize their personal welfare” (2). In a similar manner, Dries believes “modern economics suggest that both individuals and organizations tend to act in their own self-interest,” even as he admits that contributions to Drupal are “often described as altruistic.” Dries’s discussion of “self-interest” hints at the difficulties in characterizing the motivations for participating in our community, and the need for subtlety. Especially with Drupal agencies, it can be difficult to generalize motivations. For example, I was recently talking with a senior member of the Drupal community, and a former Lullabot employee, who described Lullabot as a “lifestyle company” that seemingly puts the needs of its employees ahead of profit, and that is extremely selective when evaluating potential projects. His description of Lullabot feels apt, and by no means exclusive to Lullabot. Four Kitchens takes a similar approach with its employees by striving to cultivate a “culture of empowerment.” Think Shout goes a step further, having recently become a B Corp, which is a type of for-profit company that is required to make a positive impact on society and the environment. Or consider Enjoy Creativity, a nonprofit organization – required to act for the public good – that builds Drupal sites for churches and ministries. These kinds of Drupal agencies seem motivated by goals that are different from – if not in conflict with – traditionally capitalist goals where “the common good” is, as Ayn Rand put it, “merely a secondary consequence.” We might conclude that sometimes we just help others for no rational reason, and that, as Nietzsche famously observed, “in everything one thing is impossible: rationality.” Or we might adopt a more optimistic view, as Dries did in The Next Web, and conclude that “capitalism is starting to become more collaborative rather than centered around individual ownership.”

So it seems there exists a wide variety of potential problems that need solving, although few of them feel urgent. First, Acquia has too much control. One of our goals should be to ensure that Drupal is understood as institutionally independent and that no single company dictates its future. I agree with Dries in that we should work to change the ratio of developers contributing code to Drupal. Second, we should ensure that Drupal continues to welcome a wide variety of individuals and organizations, both those that have the resources to contribute to core and those that do not. Drupal must not be construed as something only for business. After all, we do not know if Drupal will survive without individual contributors. Finally, we should strive to adapt to change and continue to make decisions that are understood as welcoming as well as benefiting a broader community. It is fine to desire more individual and organization participation, but not if that means alienating significant groups within the community. In other words, rather than asking if a change will grow the Drupal project, we should ask if it will improve the Drupal project.

Drupal: Public Good or Collective Good?

Perhaps even more confounding than articulating Drupal’s problems is the task of determining what Drupal is. Previously I explored the “cultural construction of Drupal” and various narratives about Drupal in our community. Dries offers yet another narrative when he states clearly his belief that “Open Source projects are public goods.” He arrives at this conclusion because he feels that open source meets the two relevant criteria of “non-excludability” (“it is impossible to prevent anyone from consuming that good”) and “non-rivalry” (“consumption of this good by anyone does not reduce the benefits available to others”). Again, this is Dries borrowing from economic theory, and on the surface this seems like a useful way of thinking about Drupal, as well as free software.

Dries’s use of the term “public good” is not problematic in that a large body of research uses this term. However, returning to Olson, it seems unlikely that he would call Drupal a “public good” and that he would have instead used the term “collective good” or “common good.” Olson characterizes public goods as government goods. I arrived at this conclusion not only because Olson based his research on Paul Samuelson’s work – whose essay mentioned “collective,” not “public,” goods – or because the title of Olson’s book is the Logic of Collective Action, but also because Olson made statements like this in his book: “The common or collective benefits provided by governments are usually called ‘public goods’ by economists” (14, emphasis added). Olson was actually quite specific about this distinction between “public” and “collective” goods: “A state is first of all an organization that provides public goods for its members, the citizens; and other types of organizations similarly provide collective goods for their members” (15). Even so, Dries very clearly compared Drupal to other public goods that eventually became the purview of the government – on one slide he placed Drupal alongside roads, schools, parks, streetlights, and defense. He was clear that each of these goods went from “invention” to “product” to “utility,” and that each was controlled by “volunteers,” then “business,” then “government.”

While Dries certainly was not suggesting that the government take over control of Drupal, it seems a curious choice to compare Drupal to government projects. It makes for an interesting thought experiment to consider what happens when we understand Drupal as a public good, controlled by the government. Olson’s study, after all, concerns groups (representing individuals) that work for common interests. So to begin, it would make sense that the Drupal Association – a nonprofit “dedicated to helping the open-source Drupal CMS project flourish” – would be the group that represents we, the Drupal community. Partially akin to one of Olson’s labor unions, the Drupal Association works for a common interest. But what branch of the government would control Drupal? Would this also be the Drupal Association, with Dries as its president, moving under the purview of the government? Or would the government hire the core committers, with Dries still in his role as the benevolent dictator? But enough of that. One could (and should) object that comparing Drupal to the government is obtuse, and that it suggests a kind of economic determinism in which Drupal would become a government utility, which is clearly not anyone’s goal. I would agree, and while this may seem silly to construct a building with the lights on and nobody home, it helps to reveal what we already know – we do not actually want the government involved in Drupal. Many people in our community, including Dries, do not really consider Drupal to be like other government projects. Drupal is our project. We make it what we want and we do not want to (nor can we, really) hand the keys over to the government.

So what happens when we shift the focus to free software as a “collective” good? To be clear, this use of “collective” does not signify “the collective life of humanity” (as Philip Gilbert Hamerton once put it), but rather a group of individuals acting together. Conceiving of Drupal as a “collective” rather than a “public” can be helpful for a variety of purposes. For one, it helps to explain why Holly Ross, the executive director of the Drupal Association, talks openly and thoughtfully about why she is starting to question whether the most appropriate tax classification for the Drupal Association is 501c3 – an organization that exists for the public good – or if it should more appropriately be classified as a 501c6, a trade organization whose purpose is to grow the businesses that support it. While I was quite taken aback when she admitted this to me, I can understand the thesis. It seems quite likely that our community is moving away from the notion of Drupal as something for the public and instead something for our collective. The internal deliberations of the Drupal Association are yet another indication that our group is gradually becoming more business focused.

In the end, it does not especially matter if Drupal is a public good or a collective good if our focus is on improving the Drupal project. Our group, like the large organizations that Olson analyzes, is growing not just in members and contributors, but also in complexity of problems. We have a wide variety of ways to understand our community and its corresponding problems. A growing percentage of our membership is both self-interested and economically motivated, while other factions lean toward the selfless or the seemingly irrational. How one understands our community, and the problems that need solving, greatly informs how we go about finding solutions.

The Trouble with Technical Fixes

Dries likes to fix problems with technology because, like countless entrepreneurs before him, Dries has great faith in technology. He writes, “We truly live in miraculous times. Open Source is at the core of the largest organizations in the world. Open Source is changing lives in emerging countries. Open Source has changed the tide of governments around the world.” Talk of “miraculous times” is a bold assertion. It’s also an example of an attitude that Morozov, that pugnacious and insightful technology critic, describes in his book, To Save Everything, Click Here, as “epochalism”, or “to believe one is living in truly exceptional times” (36). The problem with this attitude, Morozov claims, is that it leads to unhealthy beliefs about technology. What Dries claims for Open Source is quite similar to what others had envisioned for the telegraph, radio, telephone, television, personal computers, and countless other technologies, which Morozov takes up in his book, The Net Delusion. Morozov cites a bevy of ideas with eerily familiar conjecture, some of which are worth noting here. For example, in 1858, a New Englander editorial proclaimed: “The telegraph binds together by a vital cord all the nations of the earth” (276). In 1921 the president of GE predicted that radio would be “a means for general and perpetual peace on earth” (278). And just a few years later, the New York Times critic Orrin Dunlap would foresee that “Television will usher in a new era of friendly intercourse between the nations of the earth” (280). Fast forward to 2014 and we read Dries making similar prognostications about open source changing organizations and governments. This belief in technology entices us into using it for new purposes.

Dries’s choice of a technical solution is confusing. In addition to works by Samuelson and Olson, Dries cites in his keynote a well-known article by Garrett Hardin titled “Tragedy of the Commons” (20:45). Dries is vague about how he understands this article (he accidentally calls it a “book”), which makes it all the more curious why he would mention it. The epigraph of the article reads, “The population problem has no technical solution; it requires a fundamental extension in morality” (emphasis added). What is more, Hardin’s first sentence contains the following quotes from Weisner and York: “It is our considered professional judgment that this dilemma has no technical solution. If the great powers continue to look for solutions in the area of science and technology only, the result will be to worsen the situation” (1243). Hardin was bullish in his suspicion of “technical solutions,” reiterating his position four years later in the preface to his 1972 book, Exploring New Ethics for Survival: “For too long have we supposed that technology would solve the ‘population problem.’ It won’t.” Like Morozov, Hardin is suspect of technical fixes to complex problems. Since Hardin’s essay focused on “a class of human problems” that he described as “no technical solution problems,” perhaps there was another aspect that Dries found helpful.

Hardin, who contends “it takes courage to assert that a desired technical solution is not possible” (1243), had agonized over how to convey his conclusions. Hardin also believes that we cannot succeed by appealing to conscience or by making people feel guilty. Hardin, like Olson, speaks of “coercion” to counteract the effects of self-interest. Hardin recommends that we cannot appeal to a person’s “sense of responsibility” but rather that in order to make changes we instead need a “mutually agreed upon coercion,” and that it may require infringing on personal liberties. He talks of the need to take away freedoms for the common good. Thirty years later, in 1998, Hardin would describe the ideas he presented in his earlier essay as his “first attempt at interdisciplinary analysis.” He felt that he was trying to solve a problem so large – the human overpopulation problem – that he could not employ simple, technological fixes, and that it would be necessary to draw on conclusions derived from multiple disciplines. People, not computers, would have to work together.

Moreover, there are pitfalls with technological fixes beyond what Hardin construes (and again, I draw inspiration from Morozov and others). For example, introducing technological fixes can irritate existing social conflicts. Organizations that have long flourished in the Drupal community might be embarrassed by the new profile pages and might be less inclined to contribute, not more. Technological fixes can also distract, or act as mechanisms for denying the existence of deeper social problems – higher listings on the marketplace page, for example, will not distract individuals and organizations that are upset by Acquia’s sales techniques or who have concerns about its influence on Drupal Association webinars. When technological fixes do not work, they can have the effect of making us think that we just need a different technological fix. Dries seems to express just this attitude when he writes, “There are plenty of technical challenges ahead of us that we need to work on, fun ideas that we should experiment with, and more.” If these are intellectually challenging problems that require serious discussions, and not just “fun ideas,” we will never get to the point of solving our problems.

Perhaps the most troublesome trait of technological fixes is when they close down thoughtful contributions by people with knowledge about addressing social and political problems. Dries broaches the topic of “social capital” in his Amsterdam keynote (28:24), saying, “this is where we are good.” But he follows that up, suggesting that “altruism” and “social capital” are not scalable (31:37) and that these are not solutions for Drupal (31:55). Why close down discussion of these topics and abandon ideals that have served the community so well? What would happen if, rather than discarding these modes of investigation, we dug deeper to find alternative answers? What if the solution to scaling Drupal lies not with technology? What if, rather than use technology to change our community and culture we reverse our efforts and instead focus on making adjustments to our culture in order to improve our technology? Or perhaps we should only consider technological fixes that support broader efforts to improve the Drupal project rather than simply grow it? As the German philosopher Martin Heidegger put it, “the essence of technology is by no means anything technological.”

Sprouting Social Solidarity

When I suggest we need to look beyond technical solutions, this is not necessarily contra Dries. In another, much shorter blog post on “Open Source and social capital” – posted less than a month before his post about “scaling Open Source” – Dries concluded, “social capital is a big deal; it is worth understanding, worth talking about, and worth investing in. It is key to achieving personal success, business success and even happiness.” Plus, Dries has written about “fostering inclusivity and diversity” on his blog. Like Dries, I do not believe that there is only one way to grow the Drupal community. We can use technology to support our broader goals, so discarding all technological fixes is not my objective. Rather, I am suggesting an approach to cultivating our community that mirrors how we make changes to Drupal code – we carefully consider how each change will improve the overall project, never assuming that more automatically means better.

What is more compelling to me than technological fixes is to examine how Drupal and cultures around the globe shape each other, and how we can create more situations where more individuals make the choice to start participating in our community. This mode of investigation requires a multidisciplinary approach, a broader understanding not just of economic transactions, but also human interactions. I agree with Lars Udéhn’s assessment that “Olson’s theory of collective action has proved inadequate and must be replaced by a theory assuming mixed motivations” (239). The last time I checked, Drupal’s unofficial slogan is not “come for the code, stay for the economy” – it’s about community, and that is where I believe we should concentrate our efforts.

While I found Dries’s turn to analysis refreshing, I also question that his informants offer the most helpful of ideas. Hardin changed his mind many times over his career, a fact he readily admits, so it would seem reasonable to explore his later ideas. Samuelson’s article, with its thick prose and mathematical formulas, feels quite unrelated to Drupal. It seems reasonable that someone like Dries, with all his responsibilities, should not be compelled to trace the history of theories of rationalism and social action from Aristotle to Descartes to Kant to Max Weber and beyond – especially not in a single Driesnote. If only we did not have those pesky clients to help and 529s to fund, we could explore more of these ideas. All of this is but a reminder that Dries’s sources are certainly not the last words on these subjects.

Not to pick on Olson, but it also does not seem as though he considered the full force of social solidarity to Marx’s thinking about motivation. In his Economic and Philosophical Manuscripts, Marx writes of workers who get together to further their shared goal, “but at the same time, they acquire a new need – the need for society – and what appears as a means had become an end.” For Marx, building relationships was another form of production, and social solidarity was a key component for bringing about change (for more detailed critiques of Olson’s interpretation of Marx, see, for example, Gomberg or Booth below). Likewise, social solidarity is a significant force in the Drupal community. In my local Drupal community we not only have a monthly “user group” meeting, but every month we also have a “jam session” (coder meetup), community “lab hours,” and a social meetup at a bar. Many individuals in our community help organize the Twin Cities DrupalCamp, attend the nearby DrupalCorn or DrupalCamp Midwest, and travel to the annual North American DrupalCon (DrupalCons, organized by the Drupal Association, are the largest Drupal conferences in the world). The people we interact with become important to our lives – not just collaborators, but friends. “It is not the consciousness of men that determines their existence,” Marx wrote in A Contribution to the Critique of Political Economy, “but their social existence that determines their consciousness.”

We, as a community, would benefit from questioning our own unexamined beliefs, no matter what discomfort it may cause. We should continue to ask if successful programs like D8 Accelerate – a project that funds Drupal core development through grants – truly benefit our community, or if they might foster a collective motivated primarily by money. The way Drupal production is organized affects our understanding of it, and how we choose to coerce individuals matters. While many would prefer economic incentives and hard science over humanities, some in our community are marginalized and brushed aside by such priorities. Perhaps we will determine that it is in our best interest to ensure that our community exists more for the public than for our collective. It could be that programs like D8 Accelerate negatively affect solidarity.

If IRC and issue queues online beget lively debates at conferences and code sprints in person, we should continue to examine each of those interactions. For instance, I agree with Larry Garfield when he writes, “The new contributor first commit is one of #DrupalCon’s most important rituals.” At the end of a week-long conference, the community code sprint occurs on the final day. During this sprint, veteran Drupalers train new contributors about the peculiarities of contributing code to the Drupal code base. Near the end of the day, one or more lucky individuals are picked to go in front of everyone else where Dries commits that person’s contribution. Personally, it was this event that got me hooked on the Drupal community. This symbolic act welcomes people to our community, demonstrates their worth, and gives future contributors some extra motivation as they work toward finding problems to solve.

Moreover, we should promote a wide variety of events, encouraging more meetups, social events, and quasi-productive gatherings where code and conversation flow freely. The Drupal Association has already made steps in the right direction when they announced the results of their survey and their resulting “new approach to community at DrupalCon.” The community theme in this announcement was comprehensive: “Community Keynote,” “Community Kickoff,” “Community BoFs,” “Community Training,” and “Community Sprints.” One could argue that the Drupal Association is bringing these activities back, and that previously they did not require the “community” prefix.

Finally, I hope to see more thoughtful writing from our community about our community. The complexity of our community makes this a difficult task for an outsider. In addition to recommendations about “how to configure a View” and “how to make a page load faster” on Planet Drupal, many of us would like to know how other local Drupal communities work. What has been successful? How do they grow their membership? What does it mean to grow membership? The problem is not that we never discuss these issues, it is that we tend not to interrogate these issues more thoroughly “in print.” Drupal Watchdog is a step in the right direction, with its slightly longer form articles that allow the community to share their ideas in a more considered manner than a traditional blog post. While sharing ideas is nice, it can be even more helpful to share our ideas after they have been improved by an editor. While there are many issues of Drupal Watchdog that contain content that I find less engaging, I am glad that it allows for a wider range of voices.

All too often we incorrectly describe Drupal as a means to an end, detached from a political agenda. We forget that organizations use Drupal not only as a tool, or even because of the community. Some organizations, such as the Free Software Foundation, clearly choose their software, including Drupal, for philosophical reasons first. Or consider the American Booksellers Association (ABA), an organization engaged in political and trade-related efforts geared toward helping independently owned bookstores. The ABA’s hundreds of Drupal websites represent just one component of their larger political project. Like so many nonprofits, the ABA has a staff of passionate individuals dedicated to the cause, and their conception of Drupal must not conflict with their ideals. Consequently, I would like to see more posts on Planet Drupal that test the boundaries of the guidelines, which discourage “posts that don’t provide valuable, actionable content.” It would be nice to see more thoughtful articles that discuss political agendas and activities, and then describe how Drupal supports those activities. Countless people are inspired to use Drupal for reasons that have nothing to do with technology, and we should consider encouraging more of these stories.

While I have many other ideas that I am tempted to suggest here, those ideas are more properly topics for another article. That said, I think we can certainly benefit from studying other free software communities. When I was sitting in the audience for the DriesNote at DrupalCon Los Angeles in May, I suggested on Twitter that it “sounds like @Dries gets lots of inspiration from proprietary products (Pinterest, Pandora), rather than from other free software.” Dries later saw my tweet and clicked the “Favorite” button. I think we would benefit not just from discussing other free software projects, but also interrogating the thinking about them. The kind of scholarship that I have found most illuminating is not that of economists, but rather work like Gabriella Coleman’s anthropological studies of the Debian community and groups associated with Anonymous, as well as Christopher Kelty’s ethnographic research into free software. There is a great deal to be gained by considering our ideas about Drupal in light of what we know about the Linux community, the Fedora project, OpenStack, and other large free software communities, while acknowledging that the Drupal community is complex and that there are no easy answers or solutions.

The distinguished literary theorist Terry Eagleton has remarked, “most people are too preoccupied with keeping themselves afloat to bother with visions of the future. Social disruption, understandably enough, is not something most men and women are eager to embrace” (194). I understand why many in our community would not be quick to embrace any sort of radical change, but I also think it’s important that we talk about these issues. We cannot offload all of our problem solving to technology. To change what we think, we must change what we do. Making the case that the Drupal project should focus on its community and culture might seem less exciting the innovative technical solutions, but I hope to have highlighted just a few of the approaches to understanding our community that could prove beneficial, and that we should be careful as we consider which of them to adopt. Dries, in his recent turn to historicizing, is on the right track, and I hope the conversation continues.

Works Cited

Booth, Douglas E. “Collective Action, Marx’s Class Theory, and the Union Movement.” Journal of Economic Issues 12 (1978): 163-185.

Coleman, Gabriella. Coding Freedom: The Ethics and Aesthetics of Hacking. Princeton: Princeton University Press, 2012.

Coleman, Gabriella. Hacker, Hoaxer, Whistleblower, Spy: The Many Faces of Anonymous. New York: Verso, 2014.

Eagleton, Terry. Why Marx Was Right. New Haven: Yale University Press, 2011.

Gomberg, Paul. “Marxism and Rationality.” American Philosophical Quarterly 26 (1989): 53-62.

Hamerton, Philip Gilbert. The Intellectual Life. New York: Macmillan, 1875.

Hardin, Garrett. Exploring New Ethics for Survival: The Voyage of the Spaceship Beagle. New York: Viking Press, 1972.

Hardin, Garrett. “Extensions of ‘The Tragedy of the Commons.’” Science 280 (1998): 682-683.

Hardin, Garrett. “The Tragedy of the Commons.” Science 162 (1968): 1243-1248.

Heidegger, Martin. The Question Concerning Technology and Other Essays. New York: Garland, 1977.

Kelty, Christopher. Two Bits: The Cultural Significance of Free Software. Durham: Duke University Press, 2008.

Morozov, Evgeny. The Net Delusion: The Dark Side of Internet Freedom. New York: PublicAffairs, 2011.

Morozov, Evgeny. To Save Everything, Click Here: The Folly of Technological Solutionism. New York: Public Affairs, 2013.

Nietzsche, Friedrich. The Portable Nietzsche. Translated by Walter Kaufmann. New York: Penguin Books, 1977.

Olson, Mancur. The Logic of Collective Action: Public Goods and the Theory of Groups. Cambridge, Mass.: Harvard University Press, 1971.

Rand, Ayn. Capitalism, the Unknown Ideal. New York: New American Library, 1966.

Samuelson, Paul. “The Pure Theory of Public Expenditure.” The Review of Economics and Statistics 36 (1954): 387-389.

Self, Will. How the Dead Live. New York: Grove Press, 2000.

Udéhn, Lars. “Twenty-Five Years with ‘The Logic of Collective Action.’” Acta Sociologica 36 (1993): 239-261.

Jun 10 2015
Jun 10

In this episode of Hacking Culture, Matthew Tift talks with Holly Ross, the Executive Director of the Drupal Association, about the Drupal community, the Drupal Association, non-profits, business, tax codes, and more. They get into some controversial issues, and some of Holly's answers may surprise you!

This episode is released under the Creative Commons attribution share alike 4.0 International license. The theme music used in this episode comes from the Open Goldberg Variations. The musical interludes all come from ccMixter.org. "See You Later" by Pitx featuring Fireproof Babies and Bmccosar (http://ccmixter.org/files/Pitx/17154), "I dunno" by grapes (http://ccmixter.org/files/grapes/16626), “ Prism in the Ether" by Fireproof_Babies (http://dig.ccmixter.org/files/Fireproof_Babies/27213) under CC BY-NC license.

May 07 2015
May 07

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 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.

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 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.

Senior Developer

Want Matthew Tift to speak at your event? Contact us with the details and we’ll be in touch soon.

Access professional Drupal training at Drupalize.Me

A product of Lullabot, Drupalize.Me is a membership-based instructional video library. It can be supplemented with on-site training workshops, custom built for any organization.

Go to Drupalize.Me
Feb 11 2015
Feb 11

In this second episode of Hacking Culture, Matthew Tift talks with Bill Haenel from North Country Public Radio about free software in public media.

All music used in this episode comes from the Open Goldberg Variations, performed by Kimiko Ishizaka.

This episode is released under the Creative Commons attribution share alike 3.0 United States license.

Jan 14 2015
Jan 14

Lullabot has a new monthly show, hosted by Matthew Tift, featuring in-depth interviews with open source and free software advocates.

This inaugural episode of Hacking Culture introduces the idea of software forking, one of the fundamental characteristics of free software, and Matthew talks with Nate Haug about Backdrop, a Drupal fork.

This episode (which augments Drupalize.Me episode 26) explores a variety of topics, including how Nate got involved in free software development, the philosophical and structural differences between Backdrop and Drupal, similarities that Backdrop shares with other well-known software forks, and the release of Backdrop 1.0 on January 15, 2015.

All music used in this episode comes from the Open Goldberg Variations, performed by Kimiko Ishizaka. This episode is released under the Creative Commons attribution share alike 3.0 United States license.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web