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

Where am I? How did I get here?

I recently did a presentation at the Open Fields conference in Latvia. It was about how art shaped how I think about publishing. It was a very personal pondering. I’m not sure how interesting it was to the audience but it gave me some moments to contemplate this for myself and, as a result, I produced these two mappings. The first shows my journey from art to publishing:

The next is the same journey but with the themes of Tech, Community, and Process threading through the mix.


I was trying to articulate how I am still the same person now, working in publishing, as I was when I was an artist. I think what I do hasn’t changed (it has, a little, utility has its own laws after all, but for the most part is the same) but the operational context has changed. I live (literally) in/on the publishing world, whereas previously it was the art world. In between was an interesting half-way house for my artist self – FLOSS Manuals which I founded when I ‘gave up’ the art world after I came back from Antarctica. This half-way house gave me the skills to transition from the art world to the ‘real’ world. In that period I developed the basics of the Book Sprint method, learned how to build community, and started building publishing tools.

Interestingly I never thought I was ‘entering the real-world’ (my apologies for the use of the term ‘real-world,’ it’s not to imply an invalidation of the art world, but it feels like a better term than ‘non-art world’ or any other term I tried to use instead). When I started FLOSS Manuals I thought I was doing what I did as an artist – making the interestingly ridiculous possible. I sought to establish the largest community in the world producing free manuals about free software. It didn’t have much reality attached to it and I never really thought through the sustainability options for this path. I just did it and trusted I’d work it out (a skill artists need all the time). So FLOSS Manuals is, in retrospect, a handy transitional moment and very important to all I do now, but at the time I just did it purely as a challenge and I didn’t want to get “a real job.” 😉

It’s important to me to drill down into this a little because I think art, like philosophy, enables you to choose ways of thinking. I think I’m still an artist, and its important to me to identify as that. I don’t go around saying “I’m an artist,” because the world reads artist with a capital A. Artist. Most would laugh if I said I was an Artist because in this world that sounds self-aggrandising. “Oh. he thinks he’s an artist of systems design”… sounds a little ridiculous. Like I’m claiming the mantle of Steve Jobs. But.. .a good friend of mine (Jaromil) once invited me to join an Italian hacker collective ( I was flattered but I said I wasn’t a hacker (or Italian) and his reply was ‘hacking is an attitude’ (I think being Italian might be an attitude too. 😉 I appreciated that and I think the same is true for artists. It’s a way of thinking, an approach. For me, it means being critical of what you do and not listening to the legacy ways. Of dreaming and allowing ideas to bubble through from of a cacophony of interesting ponders and hooks. Of allowing you to invest in the ridiculous as part of the journey to the succinct. At least that’s some of it.

Open Fields was an interesting event, perhaps more from a personal point of view too as this community was once my world (the art world). It was great to see some old buddies… particularly Tim and Tina from TimesUp. Still doing great work:latvia_3And of course…Marko Peljhan…never there even when he is there. haha 🙂


Collaborative Product Design v0.9 Ch5 The Build Process

The build is when the code and UI specialists start building. It is good to have this period immediately after a design session.

You can choose your own build methodology. Some organisations are set up to follow what they call ‘agile’ methods: [(I use inverted commas here for good reason – please see the following critique of the Agile Manifesto by one of the developers, Pragmatic Dave here or ], or some follow a requirements up-front process… whatever you choose that’s fine. I list the following proposed process as we have designed it and used it. It has some advantages. First, it gives the opportunity for the UI and code specialists to have creative input, second – this process is extremely fast and efficient, third – it delivers great results, and lastly – it actually works.

This build process, I’ll call it the Collaborative Build Process, for now, revolves around the creation of a single source of truth – the design brief. This document must be maintained with accurate and up-to-date information on the build teams approach to the solution.

From the design session, an initial version of a high-level brief should emerge that day or the next and then is sent to the UI and code people. This brief doesn’t need to be more than one page, 2 pages max and it should articulate a clear goal, breakdown of terminology (if necessary) to avoid confusion, and outline the design goal and parameters. The goal will be carried over as close to verbatim as possible from the design phase of the design session. The document should also state what the ‘space’ is for a second design session with the build team and what design choices have already been made. This document should be easy-to-read and contain no mocks. It is largely a narrative document, not a requirements document.

The build team then reads the doc and should be given a few days to consider approaches. Then the team meets (remotely works well if you can work out a good online whiteboarding system – we use Bigbluebutton). In this period the team go through a shorter collaborative design session. The goal is to make the simplest realisation of the previous sessions solution proposition. This sometimes means there is a lot to design, sometimes less so.


The build workflow of the Collaborative Knowledge Foundation (Coko)

The team can mock up roughly on a whiteboard and make UI and code decisions. The most important thing here is that everyone is in agreement at every step with the selected approach. When all parts of the design are discussed and decisions have been made,  then the team works out an order for these issues to be addressed. Once these decisions are made then four things must occur:

  1. Update Brief
    The design brief circulated must be updated with the decisions made in this session. This brief is the ‘single source of truth’.
  2. Code
    Code specialists can begin work.
  3. UX
    The UI specialists develop mocks. The code people can usually already begin on other tasks while waiting for the mocks.
  4. Update the Brief
    The brief must be updated with the finished mocks.

The build team then continues until done! It is good for the code specialists to check in with the UI people whenever necessary to get specs etc. Once completed then other Collaborative Design Sessions must occur for review and designing the next part of the solution.

Collaborative Product Design v0.9 Ch4 Facilitation

Facilitation is a key ingredient for Collaborative Design Sessions. No group should attempt this process without a facilitator. Some important things to get right going into the event include:

The facilitator is not a Benevolent Dictator
The facilitator here is not the Benevolent Dictator For Life, cat herder, or Community Manager (or other models) commonly found in open source, rather the model is closer to an unconference-style facilitator. Don’t confuse these very different approaches!

Organisational neutrality
The facilitator should not be part of the organisation that is in need of the solution. This frees the facilitator from internal politics and dynamics and enables them to read the group clearly and interact freely.

Domain Knowledge is not necessary but useful
A facilitator may be entirely neutral or, in the case where an organisation is working already with an open source product in mind, be part of the open source product development team or community. The facilitator of these sessions may or may not have domain or product knowledge. If there is no domain knowledge it is recommended product and domain experts be present. This helps a great deal to keep the process anchored to ‘product reality’.

However…there are some gotchas. If the facilitator is part of the org with ‘the solution’ (eg an open source product) then make sure someone else from your team is present. Facilitation is about trust and you can’t be both a facilitator and a product advocate. You need someone else present to advocate for the product. The second gotcha is that it is generally better for the facilitator to be neutral to all parties, however, in this case, I believe there is value in the facilitator knowing the proposed product-solution intimately (with some knowledge of how it could apply to the use case being confronted), but you will need to work extra hard to maintain your trusted neutrality (you might have to work out in advance how to manage your feelings if the group starts advocating that they don’t use your product, for example).

You may wish to have tools such as post-its etc, but generally, a large whiteboard and markers (or large pieces of paper) will take care of it. Most shared objects are documentation but it may be necessary at times to use other facilitation tools and tricks to move a group process along.


Facilitation Tips
Here are some things to remember when facilitating Collaborative Design Sessions:
Build trust before products

As a facilitator, your job is to build trust in you, the process, the group, and the outcomes. Each time you make a move that diminishes trust you are taking away from the process and reducing the likelihood of success. For this reason, you must put building trust, working with what people say and towards what people want, ahead of building ‘your’ product. Trust that the product and a commitment to it, will emerge from this process, and it will be better for it.

Change is cultural, not technical
Too often technology is proposed as the mechanism for change. Technology does not create change. People create change, with the assistance of technology. Make sure the group is not seeing technology as the magic wand. Change is not magically ‘embedded’ in the technology. Improvement, optimisation, or radical reworking of workflows requires people to do things differently. The group must be committed to changing what they do. The ‘what they do’ should not be posited as a function of technology, it is their behaviour that will always need to change regardless of whether there is a technology change. Behavioural and cultural change is a necessity, not something that ‘might happen’. The group needs to recognise this and be committed to changing how they work.

Focus on problems and solutions not technology
As mentioned above, cultural change is necessary and many behavioural changes can occur that will produce positive results without the need for a technology change. It is important that you and the group can identify these issues and bring them into a focused discussion. For this reason, it is very important that the initial sessions focus on what the problems are, irrespective of whether they are born of technology or workplace process. If you can accomplish this then the group may very well propose changes that have nothing to do with technology. This is a very good outcome, as the end goal is to improve how things are done. If technology change is not always (or ever) part of the solution that is also success for the process.


Even the best solutions have problems
Own that even the best solutions, including the one you are representing, will have problems. There is no perfect solution, and if there is then time will inevitably make it imperfect.

Leave your know-it-all at the door
If you are part of a product team then you may be expected to be somewhat of a domain and / or product expert. Leaving that at the door is not possible of course, but you should be careful that you do not use this knowledge as heavy handed doctrine. Instead, it should manifest itself in signposts, salient points, and inspiring examples at the right moments. These points should add to the conversation not override it. Don’t overplay your product knowledge and vision, you will lose people if you do.

Give up your solution before you enter the room
If you are part of a product team it is a mistake to enter into a Collaborative Design Session and advocate or direct the group towards your solution. If the group chooses a technology or path you do not have a stakeholding in, then that is fine. The point is, however, that the likelihood is that they will choose ‘your’ technology, otherwise, you would not be asked to be in the same room with them. However, if you facilitate the process and drive them to your solution you will be reading the group wrong and they will feel coerced. You must free yourself from this constraint and be prepared to propose, advocate, or accept a solution that is not ‘yours’ or you did not have in mind when you entered the room. This will not only free you up to drive people to the solution they want, but it will earn you trust. When they do they choose your solution, and chances are they will, then they will trust it because they trust you and trust the process. If they don’t choose it, they will trust you and come back another time when they are ready for what you have to offer and, additionally, they will advocate your skills to others.

Involve a broad set of stakeholders
The sessions should involve as diverse a range of stakeholders as possible. This will not only improve the product but increase stakeholder ownership of the solution and that in turn will help the organisation implement it. If people feel they own the solution, they will work towards seeing it implemented. Stakeholders in this context can apply to the organisation you are working with (to solve their problem) or other projects that might play a part in solving the problem. Inviting the later to the events will greatly enhance the final product and produce valuable collaborations.

Move one step at a time
Move through each step slowly. The time it takes to move through a step is the time it takes to move through a step. There is no sense in hurrying the process, this will not lead to better results or faster agreements. It will in all likelihood move towards shallow agreements that don’t stick and ill-thought out solutions that don’t properly address the problem. The time it takes to move through a step will also give you a good indication of the time needed for the steps yet to come. Be prepared to re-scale your timelines at any time and to return to earlier unresolved issues if need be.

Ask many questions, get clarifying answers, ask dumb questions, the dumber the better
Ask many many questions. Try not to make them leading (note: sometimes leading questions are necessary for points of clarification or illustrating an issue). Keep asking questions until you get clear simple answers. Breakdown compound answers where necessary into fragments and drill down until you have the clarity you need. Dumb questions are often the most valuable. Asking a dumb question often unpacks important issues or reveals hidden and unchallenged assumptions. It is very surprising how fundamental some of these assumptions can be, so be brave on this point. If necessary feign humbleness and stupidity for asking an obvious question.


Own stupid problems, laugh about them!
Every workplace culture knows they do some stupid things. When you find these, call them out, and, if possible, laugh about them. Providing a context where people can bring forward and own ‘stupid’ processes in an easy way is going to help identify the problems and move towards solving them. It also sometimes gives people an opportunity to question things that they never felt made sense and this may, in turn, help others question the ways things are done – this is very valuable and is not always possible in the everyday workplace environment. Bringing these issues out can be very revealing, it gets people on the same page, and is often cathartic.

Reduce, reduce, reduce
The strongest point is a simple one.

Get agreements as you go
Double check that everyone is on the same page as you go. Get explicit agreement even on seemingly obvious agreements. Total consensus is not always necessary but general agreement is.

Document it all
Get it down in simple terms on whiteboards or whatever you have available. At the end of sessions commit this to digital, shareable, media.

Summarise your journey and where you are now
At the end of a session, it is always necessary to summarise in clear terms the journey you have taken and where you have arrived. Get consensus on this. It is also useful at various points throughout the session to do this as a way of illustrating you are all on the same journey and reminding people what this is all about. When doing this it is very useful to make points in this summary that illustrate that you understand them – bring out points that may have taken a while to get clarity on or that you may have initially misunderstood (there will be many of them if you are doing your job well!) so the group knows that you are embedded with them and not merely massaging them towards your own pre-designed end game.

State your willingness to discard your own product
Nothing builds trust more than statements to show that you are invested in helping them achieve what they need over what you want. Your investment in this, as with all your actions and statements, must be genuine. For this reason, too, you should accept conclusions that propose cultural solutions over technical, and other people’s products over yours. This also implies you need some fair understanding of products competitive in your space and you should not make denigrating comments about them, but instead recognise when they have value. The assumption is however that since they invited you here, and if you are doing a good job, people will choose your product anyway – but you must let them make that choice. It’s OK to highlight this dilemma and probably helps things if you do and do so in a light-hearted way.

All solutions must be implemented incrementally
Do not design and then build the final solution all at once. Solutions must be deployed incrementally and learnings folded back into the proposed solution. Build to a minimum proposition, try it, learn, redesign, repeat.

Bring in the competition
During CDS it is sometimes a good idea to have complementary or competing technology providers at the session. You will probably find that his leads to great collaborations, each contributing what they excel at.

Use their semantics
Use terminology to describe the problem and solution that come from the group. Don’t impose your own semantics.

Facilitation is an art of invention
While this section has not been about how to facilitate it is important to make a note about invention before the next section in the hope that no one just reads the below as an instruction manual. There are processes and methods that you can use ‘off the shelf’ as a facilitator but none of them will translate from paper to reality in a one-to-one mapping. People are too weird and contexts too variable to ever allow facilitators the luxury to do it by numbers. At the very least facilitation is an act of translating known patterns into a new context and tweaking it to fit. But the reality is that much of the what a facilitator does is to make things up. Instinct and the fear of failure force on-the-fly invention of methods, but each time a good facilitator makes it appear that the method has existed for a hundred years and never been known to fail. When it does fail, a really good facilitator will ensure no one notices and that the outcomes were the typical, expected, ones you were after.