= libre content management system for the Web
URL = http://drupal.org.
- 1 Definition
- 2 Description
- 3 Status
- 4 Governance
- 5 History
- 6 Discussion
- 7 More Information
Drupal is an Open Source web application. It is commonly described as a content management system. Drupal is designed for use as a web application, destined for installation on a web server. Drupal can be installed in a LAMP, the most commonly available web hosting environment.
"Drupal is a FLOSS content management framework: a software designed to build dynamic websites, web applications, web resources and web services, providing a set of common functionalities that can be adapted and extended (Docforge.com, n.d.). It is based on the programming language PHP14 and the source code is licensed under a GPL license." (https://davidrozas.cc/sites/default/files/publications/files/phd_thesis_drupal_cbpp_pre_viva.pdf)
- "Drupal’s main collaboration platform offers a large pool of more than 20,000
modules and nearly 2,500 themes under a GPL license." 
Drupal's user community is well developed and widely varied. While the site at http://drupal.org is primarily in English it is possible to find a great many user groups and companies on and offline that develop, share, re-use, or otherwise take part in the global community. One site to find groups specific to countries is http://groups.drupal.org , a Drupal project website that allows users to form groups around specific areas of interest.
The foundation of the Drupal Association
"Months after the first F2F meeting, another milestone in the history of the community occurred: the initial discussions that led to the foundation of the Drupal Association. The intensity of these discussions increased after a severe technical incident with Drupal.org. On the 7th of July 2005, the server hosting the main collaboration platform suffered a security attack and the site remained offline for five days (Dolin, 2011). Initiatives to improve the technical infrastructure had already begun before the attack, for example to host Drupal.org at the Oregon State University Open Source Lab (OSUOL), whose staff had already evaluated the criteria and approved the proposal. However, the Drupal community was required to provide the hardware, with an estimated cost of 3,000 US$, and was exploring possible ways to raise funds to cover these costs. Immediately after the incident, a call for donations was posted on a temporary site and submitted to Slashdot.org. In sixteen hours 10,000 US$ were received, and the company Sun Microsystems donated a server. The money was transferred from Dries’ Paypal36 account to OSUOL, and on the 25th August the migration of Drupal.org to the new server was completed (Dolin, 2011).
Although the technical incident was resolved, it added weight to the argument of those who advocated for the creation of a more formal organisation.
Formal organisation would alleviate issues, such as receiving donations in personal accounts because of tax regulations. The debate was seen most prominently during DrupalCon Portland, in August 2005, and would continue for approximately one year and a half. These discussions were carried out in online groups and F2F meetings at different events with the aim of reaching a point of consensus about what the goals and structure of the Drupal Association should be. The creation of the Drupal Association was officially announced on the 15th of January 2007 (Drupal Association, 2007).
The main objectives of the Association were to promote, communicate and distribute the Drupal project, as well as deploying and maintaining infrastructure, such as Drupal.org, that support the project and foster the community (Drupal Association, 2006, pp. 3-5). The scope of the Association was limited with regard to possible influences on the technical direction of the project (Dolin, 2011): “The Drupal Association has no authority over the planning, functionality and development of the Drupal software” (Drupal Association, n.d.-a).
The foundation of the Drupal Association also involved a more explicit definition of previously informal roles and rules regarding governance (Drupal Association, 2006, pp. 6-10), such as the role of Dries as Benevolent Dictator For Life (BDFL37). For example, it established more explicit functions and roles, such as permanent and admitted members; governing bodies, such as the General Assembly and the Board of Directors; as well as explicit rules and processes to regulate them, for example, stating that permanent members could be admitted or expelled with two thirds of the votes from the General Assembly.
Overall, the emergence of an institution such as the Drupal Association can be understood as part of an ongoing general dynamic of formalisation experienced by the Drupal community. This was one example of the vast emergence of institutions, with various degrees of formalisation, jurisdiction and scope, that were created by Drupalistas as the community grew, and which will also be prominent sources of tension in the community." (https://davidrozas.cc/sites/default/files/publications/files/phd_thesis_drupal_cbpp_pre_viva.pdf)
Do-ocracy as a model of governance ?
"When asked about the model of governance of the Drupal project, Drupalistas commonly defined it as a “do-ocracy”. “Do-ocracy” is a notion that encourages open participation. It is based on the self-allocation of tasks, and it allows those who carry out these tasks to be recognised and become more influential in order to make decisions when “rough consensus” (Russell, 2006) is necessary to be reached.
The following excerpt from Dries (Bacon, 2012, p. 514), the original creator of Drupal, illustrates how these main characteristics of “doocracy” shape the day-to-day life of the Drupal community:
- “[...] The Drupal community uses a “do-ocracy” model, meaning people work on what they want to work on, instead of being told what to work on. Decisions are usually made through consensus building and based on technical merit, trust and respect.”
Not surprisingly, the notion of “do-ocracy” presents characteristics that resemble those of the hacker culture discussed in section 1.1.2. For example, in relying on meritocratic values — such as the “technical merit” mentioned in the quote above — and encouraging the focus to be placed on contribution activities and quality, rather than on the personal characteristics of those who carry them out — “Hackers should be judged by their hacking, not criteria such as degrees, age, race, sex, or position” (Levy, 2010, p. 35). Another example is the mistrust of formal authority, as part of a more general anti-bureaucratic attitude of hackers. A “do-ocracy” operates on the idea that those who mobilise more resources towards a certain task and demonstrate their merit to the community have the legitimacy to make decisions that relate to that task, rather than legitimacy being based on arbitrary rules that consolidate power representing a threat for their creative impulses (Levy, 2010, p. 25).
The notion of “do-ocracy” is commonly found to describe the governance of organisational processes of CBPP communities (e.g. Mateos-Garc´ıa & Steinmueller, 2008; Fuster-Morell, 2010; Zacchiroli, 2011; Kostakis, Niaros & Giotitsas, 2015).
For example, Fuster-Morell (2010, p. 282) incorporated this notion in the context of the study of the governance of online creation communities and defined it as follows:
- “[...] Doocracy refers to the idea that there is no external body or hierarchy that decides how actions should be carried out. In other words, in a doocracy authority over an action is held directly by those developing it. Furthermore, participants gain influence and authority in the process according to their merits and the resources for ‘doing’ that they mobilize (such as time or attention).”
In addition, these “do-ocratic” characteristics incorporate numerous similarities with those presented in the literature review of governance of CBPP communities in section 1.4.1, such as the attributes defined by Benkler and Nissenbaum (2006). The previous quote by Dries depicts, for example, the self-assignation of tasks, whose outcomes’ quality is scrutinised through peerreviewing processes carried out by the community.
Nevertheless, these “do-ocratic” characteristics also imply an inherently blurred and informal nature, which can become a source of inner contradictions and tensions as communities adapt their self-organisational processes over time. For instance, the willingness to decentralise the governance of the community may produce tensions with respect to the rejection of bureaucratisation, since formal rules may be interpreted as arbitrary with the aim of consolidating power in the hackers’ eyes.
In the case of the Drupal community similar tensions and inner contradictions emerged, for example, when the community grew and discussed the necessity to formalise the self-organisational processes to scale up.
Hence, when applied to the model of governance of large and global CBPP communities, the notion of “do-ocracy” lacks relevant aspects, such as the emergence of more formal organisational forms depicted, for example, by the numerous institutions created over time by the Drupal community. For this reason, this study incorporates the notion of “do-ocracy” not as a model of governance, but as part of a strong culture within the Drupal community (Melanc¸on & Sarahe, 2011), whose values are interrelated and influenced by the values of the hacker culture discussed in section 1.1.2. To this end, the model of governance is a subject matter of this study in itself, in which the influence of the “do-ocratic” culture is considered as relevant in the shaping of the organisational processes of peer production over time, but assuming that, as shown in the literature review in chapter 1, there remains a necessity to improve our understanding of how large and global CBPP communities, such as Drupal, organise themselves and scale up while remaining viable over time.
Furthermore, this research conceptualised tensions, as those discussed between the anti-bureaucratic attitude and the formalisation of processes to decentralise the governance, as “windows of opportunity” to follow and collect data during the study. Hence, these tensions will help to improve our understanding of the emergence of the processes and structures which the Drupal community has created over time. For example, to improve our understanding of how decentralisation, a key notion to be explored in CBPP as argued in chapter 1, occurred or whether it did. This study develops from the notion of decentralisation in the context of CBPP of Benkler (2006, p. 62) as the “conditions under which the actions of many agents cohere and are effective despite the fact that they do not rely on reducing the number of people whose will counts to direct effective action”, applying it to question whether decentralisation occurred in the peer production activities of the community and how it did. This was materialised, for example, by exploring how legitimacy emerged and changed over time in the community in order to decentralise decision-making to perform changes in the digital commons, or to organise events; or to analyse whether practices regarding decision-making related to quality assurance were decentralised and how this occurred.
Another example of opportunity for further study, which arose from the aforementioned tension, is to be found in the need to explore the changes experienced in the organisational processes over time and the organisational dynamics. As stated by Benkler (2006, p. 61): “the salient characteristic of commons, as opposed to property, is that no single person has exclusive control over the use and disposition of any particular resource in the commons. Instead, resources governed by commons may be used or disposed of by anyone among some (more ore less well-defined) number of persons, under rules that may range from ‘anything goes’ to quite crisply articulated formal rules that are effectively enforced”. As discussed in chapter 1, there is a lack, however, of an in-depth understanding of how these “doocraticly-shaped” rules emerge, operate, are enforced and change over time in large communities, with the few exceptions of largely studied communities such as Wikipedia (Viegas et al., 2007; Forte et ´ al., 2009)." (https://davidrozas.cc/sites/default/files/publications/files/phd_thesis_drupal_cbpp_pre_viva.pdf)
See also: Drupal - Governance
Drupal's continued development is underwritten as a labor of love with a bit of a tendency for benevolent world domination. By his own account the project founder was simply to help a group of college students communicate. As developers and collaborators joined in to aid Dries the project grew by leaps and bounds, fits and starts, until the community of users and developers was large enough to begin having regular conferences. A Foundation was created to steward some aspects of the future of the project, responsibilities like insuring that the project hosting was sufficiently well managed, as well as raising funds for the development of specific functionality (and that only when necessary).
2.2 Key moments in the history of Drupal and its community
Origin of Drupal and launching of Drupal.org
"The history of the Drupal project began in 1998 at the University of Antwerp (Dolin, 2011, p. 822). Dries Buytaert and Hans Snijder, two undergraduate students, decided to set up a wireless bridge to share Hans’ ADSL27 connection between them and other students (Drupal.org, n.d.-e). Dries started the development of a messaging board system accessible through the Local Area Network28 to exchange messages and news between dorm-mates (Dolin, 2011, p. 822). Dries designed this system as a small content management framework, which would be the origin of Drupal.
After graduating in Computer Science, Dries decided to launch the site online in order to continue using the system after leaving university. A small community had already gathered around the site, and he decided to look for a domain which captured the essence of this community spirit. He thought of the domain “dorp.org”, an abbreviation of the Dutch word “dorpje” for village that also has communitarian connotations. Nevertheless, he mistyped it and wrote “drop.org”. Realising that the domain was available, Dries decided to reserve this domain instead and use it for the site that was launched online in April 2000.
On the 15th January 2001 Dries released the source code that powered “drop.org” under a GNU General Public License (Drupal.org, 2011g). This was the first FLOSS version: Drupal 1.0. The name was chosen as a back-translation of the word “drop” into Dutch: “druppel”. The word “druppel” is pronounced phonetically as “droo-puhl”, and he then spelt it in English as “drupal” (Dolin, 2011; Drupal.org, n.d.-e). These origins of Drupal are to be contextualised within a period in which large and complex websites still tended to rely on proprietary CMSs (Stephens, 2008; CMSReview.com, n.d.), such as Vignette (CMSMatrix.org, n.d.), and when FLOSS CMSs, such as PHP-Nuke (Paterson, 2005) and TYPO3 (Typo3.com, n.d.), began to be technically mature and more widely used.
Although the original purpose of “drop.org” was to act as a web board and news site for general discussions, the technology powering the platform in itself, Drupal, became one of the most popular topics on the site after being released as FLOSS. Two months later, Dries launched a new version of Drupal, 2.0, and decided to create a specific site for the discussions around it due to the increasing interest in the software: “drupal.org”.
This site was the initial point for users to gather and extend the Drupal community globally, becoming and remaining the main collaboration platform for the project. The site would be extended and modified over time to include various tools to facilitate collaboration in the community, such as groups, forums, issues lists for projects or wikis to write documentation. The growth experienced by the community over the following years would be reflected in the growth of activity on the site. What started as a basic site for discussion , now (11/02/2017) has nearly 1.3 million users registered, of which more than 105,000 are considered active contributors30, and more than 6.5 million comments and issues (Drupal.org, n.d.-d), providing but a few indicators of the growth of activity on the platform." (https://davidrozas.cc/sites/default/files/publications/files/phd_thesis_drupal_cbpp_pre_viva.pdf)
P2P and Drupal
Drupal itself is only a piece of software. It's like a shovel in the sense that it can be used for a number of purposes, and it lends itself really well to one particular purpose. The Drupal community is a teeming frothy pool of interaction and peer support, and the bulk of the traffic on the website is related to finding bugs, fixing them, asking for help about how to fix them, or planning new features for future development. The Drupal Groups site is where collections of users converse about sets of features and plan events together. For a fun insight you can take a look at the events page at http://groups.drupal.org/events. You can see that there are between 1-10 events planned almost every day for the next couple of months. It's an active community, and all of those events are produced by Drupal users looking to reach out to other Drupal users. They need no permission to offer an event.
The active community has fostered the development of a number of resources for new users, creating an "on ramp" allowing new users to gear up to Drupal and achieve competence quickly.