Informality and Emergence

FLOSS software development has been perhaps most famously described by Eric Raymond in his essay from 1998, The Cathedral And The Bazaar. A great many FLOSS projects were up and and running at that point with well-described and reflective processes in place (for example the Debian project documented by Biella Coleman (Coleman 2013), but Raymond made an important intervention by writing a short, accessible article that, for the first time for many

people, explained the motivation and processes within Open Source. Based around a series of numbered assertions, Raymond's number one statement is: “Every good work of software starts by scratching a developer's personal itch” (Raymond 1998). It's implication is clearly that developers are creating software for themselves; in other words the developer is also the user - this is a major departure in the conventional view of the user and developer relationship.

This view of how FLOSS projects emerge and develop, in which users and developers merge is backed up through research including (Scacchi 2002, Nichols & Twidale 2003, Barcellini et al. 2014, Jullien & Roudaut 2012). For instance, Nicholas and Twidale applied conventional usability tests to some FLOSS projects. Their findings suggest that projects do not perform well against these criteria, but nevertheless, the authors admit that Open Source projects can be successful, even if not problem-free:

“This success is, at least partly, derived from the similarity of the experiences of the members of the developer community. When the user group is distinct from the developers these differences can easily generate usability problems: assumptions that work within one community don't cross over to the other”

(Nichols & Twidale 2003)

In conflating users and developers and foregrounding the pragmatic meeting of immediate needs, the conventional industry/academic view of a software development life cycle and structured processes for requirements that gather and identify stakeholders is immediately challenged. This is replaced by a much more informal and emergent process in which tools and practices shape each other. While this is taken as a negative in the work of Nicholas and Twidale, others have taken a positive approach that works backwards from the success of the projects and approaches these processes with curiosity.

Informality is the theme of Walt Scaatchi's deeply descriptive account in 2003 of how open source projects gather requirements. His paper shows that open source processes tend to be deeply at odds with the formal Requirements Engineering (RE) processes, or I might add, any defined UCD or PD methodology Nevertheless, FLOSS software can be fit for purpose, usable and widely adopted (2002). Scaatchi re-iterates this point, and refines the findings, in a more recent publication with Alspaugh Understanding Requirements For Developing Open Source Software Systems (2013)

In his first investigation, Scacchi shows how, in the Open Source projects he studied,

requirements are not formally described. Instead, they can be found implicitly embedded into narratives and social interactions and found peppered online in forums, email archives and bug tracking software. Scaachi found that requirements are in no sense 'elicited' and no data is gathered. Instead the project emerges from needs and desires, and features are often not even traceable to a single origin. Most interestingly however, he points out the absence of any kind of formal modelling (for instance using notations or logical languages) that in conventional RE

practice is seen as so necessary to bridge the 'real' world with the logical descriptions required by programmers. Instead he suggests the term 'software informalisms' to encompass the varied forms of descriptions found on a wide variety of forums (Scacchi 2002).

Scacchi suggests that there is no reason why a formal modelling process could not be instituted; it is simply not done because there is no need for it. He suggests that there is a replacement for this bridge between worlds. This bridge is the shared mental model that emerges among

developers from all the varied narratives, descriptions, diagrams and screenshots that circulate in these informal ways. However this mental model is also constituted from the prior

knowledge of the developers of their field, or added research that they take on once involved in a project. One of Scacchi's case studies is the development of software to process x-ray

astronomy and deep-space imaging data. In this case he describes the importance of the developers' prior knowledge of the astronomy aspects as essential in being able to create software from informal descriptions (Scacchi 2002).

The same research theme is refined by Scaachi and Alspaugh in 2013. In this study the basic findings of the earlier work is reinforced and expanded. Through a number of case studies they further investigate the same “conundrum” as the earlier study; that so may FLOSS projects are successful and widely accepted while still not conforming to any industry recognised

requirements gathering processes. In this study they refine the idea of “infomalisms” from the 2002 research, replacing it with the term “provisionments”. This new term is used to indicate an emphasis on descriptions or prototypes that demonstrate potential solutions. They point out that in this focus on “solution space”, they contrast with most RE methods that begin with a description of the problem. (Alspaugh & Scacchi 2013). Like the previous study, it is noted that these descriptions may appear in any number of online platforms that are used by developers to communicate and organise their work.

Why is this focus on the productivity of informal processes and shared identity between users and developers important for my argument and for understanding the Hublink example? The answer is threefold; these three points being key to the central argument of my thesis.

Firstly, the continual meeting of the needs expressed by FLOSS participants is a way to understand how and why FLOSS creates a shared resource in a community setting. If developers are working in similar contexts – for instance the not-for-profit sector – they will have at least some shared needs. These will be shaped by the values and constraints of those contexts. It then follows that tools will emerge that are of common applicability. This point is further developed in the next section on modularity and generativity.

Secondly; the findings provide another view on the theme of ‘design-in-use’ as a necessity to create effective software. Fischer and Giacciardi have argued that FLOSS software can as a whole be seen as a continuous meta-design project (2008). Scaatchi is more precise and describes the process of continual expansion and improvement as continuous ‘reinvention’

( 2005) . And, in an echo of our discussion on PD, mutual learning and infrastructuring, links emergence to both learning and community:

“Reinvention is a continually emerging source of improvement in F/OSS functionality and quality, as well as also a collective approach to organizational learning in F/OSS projects”

(Scacchi 2005 p.10)

Thirdly, and most importantly for this thesis, the PD process itself is a route towards producing the 'shared mental models' that Scaatchi claims is so important for making informal processes able to work (Scacchi 2002). This could be seen as another way of describing the 'mutual learning' that occurs in PD. The importance of prior experience and shared mental models also opens up some new and interesting questions about the role of developer in an environment where PD meets FLOSS and links to the idea of key roles for individuals with domain knowledge and technical skills.

All three of these points are illustrated by the Hublink project and its use of the Open Source package Drupal. On the first point, Drupal has a wide user community, many of which come from the not-for-profit sector, either from small organisations or much larger governmental ones. Via the modular architecture of Drupal that we explain in the next section, this has resulted in a large amount of very useful and often well-maintained resources.3

On the second point, the need for some kinds of design in use has been a key feature of this project, and is a highlighted feature of the project description Evidence shows that it was the collective learning that took place during that design process that allowed continuous

customisation, and that there was a feedback loop between learning about customisation and contributing ideas for further development.

On the third point, because of the constraints of the context we worked in while creating Hublink, we used many strategies that Scacchi has described as “informalisms”. These were useful for this project as not imposing new tools or conventions meant that there were fewer barriers to participation for our community partners. I would argue that these were effective forms of communication in our case because of the shared mental model we had built up through the PD processes. However, there are also problems with informalisms that we will return to later. In addition, while participation in the design phase for knowledge about the project can be empowering, our experience is that it also leads to fragility. This is illustrated in the project description by the changes that occurred when key staff who had been involved in design left the organisation.

In the next section we look at how the informal and distributed nature of FLOSS projects influences their structure and further facilitates ongoing change.

3 There are some other sectors that also use Drupal widely and are well served by community contributed modules, for instance publishing.