Drupal - Governance
Discussion 1: David Rozas
"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)
"Focus on the people, not the product. A team that enjoys working with one another will naturally be more productive. Take a "mental health" check of the people on your team. Is there animosity brewing between two or more groups that could be solved by them working more closely together? Is decision-making in the hands of a single individual, hampering the feeling of ownership by other, capable people? Resolving these kinds of issues should take precedence over anything else.
Eliminate barriers for those who want to make improvements. Where not absolutely necessary for security or legal reasons, fight red tape in all of its forms. Remember that a frustrated person is often best poised to lead revolutionizing changes for the better as they have the motivation. Get the road blocks out of their way and empower them to get to work.
Fight the stagnation of perfectionism by encouraging collaboration. Put processes in place that help prevent perfectionists from getting trapped in their own heads, and get them working with others instead. Not only does collaboration help achieve a more robust solution, it can be used as a mentoring tool to help raise the collective IQ of your entire organization."
"In the Drupal project, as in most open source projects, improvements to the software may be contributed by anyone, but they are only added to the core software after the changes are peer reviewed. Aside from the rather obvious benefits that this process has on the quality of the contributions, the effect this peer review requirement has on the community is three-fold:
1. It actively fosters an environment of mentorship. Experienced contributors are highly motivated to help newer contributors to understand more complex areas of the software because it directly benefits them to do so. As they gain experience, new users become better equipped to help in the review.
2. It helps keep the overall community's IQ level high, as members are constantly exposed to areas of the software they may not have seen before. This naturally occurs because often the easiest way for a contributor to get their changes reviewed is to review someone else's in exchange. It also actively works to prevent less desirable and community-damaging personality traits from manifesting themselves. After all, people won't get the peer reviews they require to accomplish their goals by being arrogant, insulting, and demeaning towards others.
3. It is extremely helpful to document in as many mediums as possible (text, audio, video, interactive classes, etc.) the options available to people who want to help, and what methods they can employ to be most effective. The sooner a frustrated user realizes that there is only a collective “we" where each contributes whatever they can to make the project better, the sooner the transformation into contributor can take place. Users then learn to channel their frustration into an effective force for change."
The Problem of Perfectionism
"The natural problem-solving methodology for perfectionists tends to be withdrawal from the community and working quietly in isolation until they believe they've achieved something that is immune to criticism. This brings with it a whole host of problems, including:
1. Perfectionists never truly believe that their work is immune to criticism, because they can always find something that can be improved. In practice, their work can get permanently trapped in "analysis paralysis" and never see the light of day.
2. In the rare cases where the perfectionist feels that the ultimate, “immune to criticism” state is achieved, they can develop a deep emotional attachment to their contribution. This can lead to the perfectionist growing irrationally defensive, and rejecting or dismissing useful critique from their peers.
3. Working in isolation eliminates transparency, and removes the ability for other contributors to help. In a worst-case scenario, the larger community has already developed a solution to a problem in parallel by the time the perfectionist is finished, leading the perfectionist to extreme frustration, particularly if coupled with a deep attachment to their own solution.
4. Working offline until perfection is achieved naturally leads to fewer interactions with the larger open source community. These interactions are absolutely key to a contributor establishing their own expertise and personality within the community, which in turn directly impacts how well they are received by others. These interactions are also key to helping others understand the proposed solution so that they may provide reviews in the future.
It is vital to establish a strong culture of “release early, release often” where people are encouraged to throw solutions against the wall and find out what sticks. This results in increased visibility for individual contributors and a lack of attachment to any one solution so that the best possible solution is found.
Fighting perfectionism does not equate to compromising in quality. Perfectionists can still contribute improvements that are up to their enormously high standards, and the project still benefits. The key difference that separates healthy perfectionist contributors from unhealthy ones is the participation in a collaborative problem-solving process, rather than an introverted one. The community's processes should reward those who do the former, while encouraging those who do the latter to change their approach." (http://www.osbr.ca/ojs/index.php/osbr/article/view/890/860)