(This article was cross-posted on lullabot.com. The comments on this article are disabled in order to centralize all feedback in one place.)
Each year at the largest Drupal conferences in the world, Dries Buytaert, the creator and project lead of Drupal, presents keynotes about the current “State of Drupal.” These events are well known in the Drupal community as “Driesnotes” (Dries, obviously influenced by Steve Jobs, has quoted Jobs in his keynotes and has even ended multiple Driesnotes with “one more thing,” much like a Stevenote). Frequently, Dries will clarify ideas from his keynotes on his personal blog, which was the case in a post from last year titled “Scaling Open Source communities.” While his title suggests a focus on open source software, his more immediate ambition is scaling Drupal. Indeed, Dries conflates “Drupal” with “Open Source” in his article, concluding, “we can scale Drupal development to new heights and with that, increase Open Source’s impact on the world.” Dries would like to grow Open Source (he likes to capitalize these words) by growing Drupal.
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 than 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.
Comments