More research

Looking into the dynamics of Open Source communities and questioning if there is indeed such a thing as devcentricity. Looking for evidence for or against. Looking for anything that can describe relationships and workflow between a diverse group of stakeholders with differing skills.

Major OSS projects are highly hierarchical and meritocratic communities (Gacek and Arief, 2004; Mahendran, 2002). Five different statuses are generally distinguished in these projects, according to the distinctive rights and power of the participants. Some participants can modify the source code and participate directly in the design process and in decisions regarding the software:
– the project leader (generally the creator of the project such as Guido Van Rossum for Python, or Linus Torvalds for Linux);
– the core team or administrators, who have to maintain the code base, the documentation;
-the developers or contributors who participate in the evolution of the OSS and maintain some of its parts.
Others participants are called users. In an OSS context, users may be highly skilled in computer science, and thus far from the classical notion of “end-users”.
– They are called active users if they participate in mailing-list discussions as informants for newcomers, by reporting or correcting bugs with patches, and by proposing new modules. These active users in a particular OSS project may be developers in another project
– Other users are called passive users as they only use the software or lurk on the discussion and documentation spaces of the project (Preece et al., 2004).
It is possible to evolve between these statuses by acquiring and proving one’s technical skills and ability to engage and maintain online discussions: that is to say that roles emerge and are actively constructed within the community
(Ducheneaut, 2005; Mahendran, 2002).


The literature on OSS clearly identifies that active users take part in the evaluation phase of design (bug reporting and patching, e.g. Ripoche and Sansonnet, 2006) and that the project leader, administrators and developers participate in the design process itself, i.e. generating and evaluating solutions and taking decisions (Barcellini et al., 2005).


Open issues are still to characterize the role of users regarding the design process itself and the role of all the active participants (project leader, administrators, developers and active users) during the elicitation of the needs and requirements phase. Despite the idealistic picture that users may intervene freely in the process, we will question whether users who are neither administrators nor developers in the core Python community can really have an impact on the design choices and decisions.


The coding of activities is inspired by previous studies on collaborative software design activities (d’Astous et al., 2004; Détienne et al., 2004; Olson et al., 1992; Stempfle and Badke-Schaub, 2002) and by the coding scheme developed in our previous paper (Barcellini et al., 2005), which we have extended.


We found that users mostly tend to participate in the user-oriented list, python-list. Here, they provide references mostly on usage and personal experience, computer science, and code and examples. They also tend to provide more personal experience and end-user references than others in python-list. Even if the users’ contribution seems important in order to specify usage needs, their participation remains local to the user-oriented community and does not guarantee that these needs will be taken into account in the actual design.


We found that cross-participants perform an emerging role of boundary spanners, which guarantees that usage is linked to design and that the boundary between the user community and the developer community is crossed.


According to our results, OSS design does not seem to be participatory in the strict sense of the definition, i.e. user involvement in “design” activities. Even if users of OSS may potentially be involved in all the phases of the OSS design process (elicitation of needs and requirements, design and implementation), we found that their participation remains mostly local to the user community in the PEP process we analysed. We found that the design-use mediation is supported rather by a number of key participants who act as boundary spanners and who are not necessarily users themselves: two of them were users but the three others were administrators and developers

Dev Centricity

More partial thoughts. I have been pondering the whole dev-centric nature of Open Source.

Open Source projects that put the dev at the centre of the culture see all problems as technical. Which means that if a problem is presented then a dev-centric approach will see the entire problem and, consequently, the entire solution, as technical. That routes around seeing the problem for what it really is.

I think this leads to:

  1. misunderstanding the real problem at hand
  2. producing solutions that don’t fix the problem

So we need to address this, however, the way that Open Source projects avoid seeing that they claim the users don’t know what they want.

We are kind of left with the scenario that all problems are technical and only the developers can fix them. Doesn’t that feel like a little broken?

This is the result of putting faith in technical meritocracy. A developer-centric sector that mostly judges your value by your ability to program. The signifiers are all there – naming a sector after code (‘Open Source’) signifies this, as does dismissively labelling those that don’t program as ‘non-coders’.

That’s not to say developers are bad people! Some of my best friends are developers! 😉 But it is to say that we need to see, discuss, and rework this legacy power imbalance as it really doesn’t help in making good solutions. We need diversity of all kinds – gender, ethnicity and roles in Open Source – bringing all voices in at the appropriate moments, and with even power dynamics brought about through skilled facilitation. Only this will lead to unleashing the real power of collaboration and sharing and make OS beat all those brain-dead VC funded techno-meritocratic proprietary ‘solutions’.

Some notes on CPD

At its heart, CPD is three things:

  1. Political critique
  2. A problem-solving methodology
  3. A diffusion strategy

Political critique

I like this part of Collaborative Product Design most of all. Open Source is a developer-centric solution model. Essentially we have created a clear distinction between people with problems and people with solutions. The later are called Developers, the former, Users.

The idea is that “Users don’t know what they want”. Which might also be remapped to “Developers don’t know what Users want” given that so many of these developers have created ‘solutions’ that fail. Somewhere in this model, something is broken.

I believe placing the developer at the centre of the solution design process is the problem. We need to put the right people in the right place. Users should be at the centre of designing solutions for user-facing problem spaces: developers should be at the centre of designing solutions for developer-facing problem spaces.

This means we need to do the following:

  1. first, change the language. We don’t have Users and Developers. We have People with Problems that need solving. Some have workflow problems that need solving, some have technical problems that need solving.
  2. People with workflow problems design solutions for these problems
  3. People with technical problems design solutions for those problems
  4. don’t mix up 2 & 3

Mixing up 2 & 3 is generally the default ‘Open Source’ model and is cast as:

  1. Developers solve workflow problems for Users
  2. Developers solve problems for Developers

Number 2 is fine, number 1 is what gets Open Source in trouble.

Where did this cultural default come from? Well…Open Source is famous for a horrible book known as the Cathedral and the Bazaar which the self-appointed bishop of open source anthropology, Eric Raymond, states as cannon

Every good work of software starts by scratching a developer’s personal itch.

He also states as cannon:

The next best thing to having good ideas is recognising good ideas from your users. Sometimes the latter is better.

This is just wrong. Good software comes from collaboration across specialist domains. If someone has an itch, we talk to them, possibly call in people with similar itches, some specialist medical experts, maybe some researchers if it is a new kind of itch, and whoever else is affected (infected? hoho)… and we learn from each other and collaboratively solve the problem. Raymond’s text, which has had a huge influence on Open Source culture, places the ‘user’ as someone who might have some ideas worth considering but really it’s up to the developer to make that decision. The developer is still, even in the most liberal interpretation of these statements, the arbiter of the design.

We need to get everyone to work together, talk to each other, and work out who is best at solving each part of the problem.

By the way, I am not saying that ‘developers’ have no value when creating solutions for user-facing problems. They do have value in this process. However, it is their ability to empathise and join in a collaboration that is of value in this moment, not an ability to code.

…and…if you wish to explore further gems from the genius of Eric Raymond’ please put aside a quiet weekend to dive into Sex Tips For Geeks….

this is a scratch pad…more to come…

Notes on Collaborative Product Development

So, during the Shuttleworth Gathering this week I facilitated a session about CPD and asked for feedback. I got some great information, most of which is targeted at what people would need to know in order to understand the process better. I am currently writing a ‘book’ about the methodology so this feedback will help shape that. Starting with:

  • challenges on the name and if there is something better
  • timescales need to be illustrated and discussed
  • implementation phase needs to be unpacked and described
  • testing cycles
  • bring out the fact that the product must be adaptable
  • explain how this will change ‘your’ organisation
  • importance of institutional buy-in
  • case studies and stories
  • maybe a hardware case study?
  • with this method some change is cultural
  • how would you measure cultural change?
  • how do you better ensure cultural change?
  • case studies would be very useful
  • simple illustrations of why this method is better
  • front load the political critique of Open Source
  • with the front loading highlight that most ‘client centered’ solutions are actually developer-centric solutions hidden behind a paywall

Also an interesting idea to make a current workflow image into a poster ‘this is what we are trying to avoid’

Arthur Attwell came up with this lovely way to describe the advantages of collaborative design:

footpath-oraSolution designed by the city council

footpath2-oraActual traffic

Here  you can see the dissonance pretty clearly.

I think I will structure the book something like this:

  • what is Collaborative Product Design
  • What does a hosting organisation need to think about
  • the basics
  • the setup
  • the design session
  • facilitation
  • the build
  • implementation