The beauty of small teams


I have been involved in setting up a team for the Collaborative Knowledge Foundation (Coko). We are about 12 all up now and spread around the globe. At our core we have :

Jure – Lead PubSweet Developer Slovenia
Richard – PubSweet Developer Kenya
Yannis – PubSweet Frontend Developer Athens
Christos – PubSweet Frontend Developer Athens
Charlie – INK Lead Developer New Zealand
Wendell – XSL-pro East Coast USA
Julien – UX-pro France
Henrik – Designer Netherlands
Juan – Sys Admin Nicaragua

and then we have myself, Kristen Ratan (co-Founder), and Alex (process manager) in San Francisco.

So… just looking at how development works… in the dev side of things we are pretty well distributed over the world and across a large variety of time zones, in fact, NZ, EU, USA is about as bad as it can get when setting up meetings at reasonable hours for all affected… so how do we manage to make this work?

Well, firstly we obviously rely on some remote tools. We all coalesce around Mattermost – an open source version of Slack (By the way, don’t use Slack – This is a good avenue for remote chatting. We use it for both chit chat, y’know, hanging out and taking bullshit, and also work. Work mostly gets done on side channels, I wrote something about it here. that’s Mattermost. It’s a good tool but if we were just a bunch of people scattered around the world with a chat channel then it probably wouldn’t work as effectively.

So, I wanted to say something about creating space for people to operate and how remoteness can actually play into that rather nicely.

First of all, we are an organisation that likes people to like what they do. So we like to trust them and give them a bit of room to move. All people are creative and I believe all folks need challenges where they can exercise that creativity. Nothing new here – if you want to read more about this, with special reference to development teams, then read Peopleware (terrible title, great book – very old school… you can stop reading when they talk about optimum cubicle layouts, but the rest is awesome).

What I have found over the years is that responsible people work responsibly. So, I am assuming you work with some people like this 🙂 Otherwise return to zero and start again…. the thing about responsible people is that they like to get their head down into a flow and get on with it. They love hard problems and they love the trust given to them to solve these problems. But sure sure, this can happen in real space in a shared office…but…can it? I think there is an argument to made here that remote teams enable a more optimal working environment for this kind of team.

In our case, for example, we actually only have two people in the same place (not counting San Francisco). They are Yannis and Christos. Very nice chaps if you ever happen to be fortunate enough to meet them. Yannis and Christos work on developing the front-end components for the PubSweet publishing framework that Richard and Jure are building. We have an advantage here that we have carefully chosen to create a technical architecture that supports the autonomous development of front-end components which is separate to the backend that they rely on (the backend is known as PubSweet or sometimes we refer it to PubSweet core or ‘the backend’). Anyways… note to self, how you build what you build is a determining factor on how your team is structured and where they are… but… back to remoteness…

When we develop front-end components for clients, I go with Alex and/or Kristen to the client’s locale and then work through their design in a Collaborative Design Session. We then write this up and meet with Julien, Yannis and Christos remotely with a online whiteboard tool (BigBlueButton). And we have another collaborative session where we nut out the details. This is all a little by-the-by but just to say that we can segment our work quite nicely and the communication that does take place remotely is either:

  1. bullshit and fun
  2. high value and short

These whiteboard sessions are type 2 from the above. We set 2 hours to have the complete design sorted. When that meeting is done, everyone knows what they need to do. After that, we leave Yannis and Christos to get on with it and let us know when they are done. Any miscellaneous stuff gets sorted out bit-by-bit between the people involved. If, for example, some more UX mocks are needed, or some CSS detail, then Yannis or Christos will ping Julien on Mattermost and sort it out. No project management, no scheduled meetings. Short and sweet as per type (2).

At the same time, Jure and Richard are sorting out the backend. They communicate amongst themselves and solve the complex problems that such an abstracted system requires. All over Mattermost, too. Of course, there are various breakouts to real-time calls when required but it’s a minimum. Watching Jure and Richard tumble through difficult problems in Mattermost is a sight to behold. Both firing off each other and throwing ideas back and forth.

My job is largely to give each of these folks room to move.

So what about when each team needs something from the other? Being right up on the coal face of the client needs, I can see what things we need to address a little ahead of time and I call out to those affected and work out how we can sync the various threads. For example, we need to integrate PubSweet with INK (more about this below) for importing Word docs into PubSweet as HTML. So, seeing this, I talk to Jure mostly, and think through the issues. Jure interprets my partial developer-/partial user-speak and thinks about it. He then discusses it with all those necessary and they work out the best approach. Then we work out when it all needs to happen by and the order of play. Everyone then orientates around that timeline and away we go…in otherwords…the parallel teams ‘touch’ only when necessary – when they need something from each other. That’s not to say we try and stop people from talking to each other 🙂 Quite the opposite, we don’t gate any communication at all and leave people to sort it out. What we don’t do is build things before we need them or layer on complex management overhead. These are smart responsible people, let them work it out 🙂


the above image drawn with the fabulous MyPaint (open source) on a touchscreen Thinkpad running Ubuntu.

We are also achieving the same process with INK. Charlie is down in the Southern hemisphere tinkering away. She’s like a deep sea diver in Ruby and coming up to explain to us surface dwellers what’s going on down there. You saw whaat? …an uncontrolled multi-threaded waaaaaat!?oh good, you killed it Just-in-Time???…phew….. Charlie is building a system for managing file conversion pipelines but it is very abstracted. Essentially it is a job-agnostic queue manager. You can throw anything at it and it will do it. We are first using it for MS Word to HTML conversion. Wendell and Alex are working together to get the conversion process into shape. Wendell is writing the code and Alex is testing. Then we are making this into what we call a ‘step’ – essentially a plugin to INK. So Charlie can build the architecture for INK and then we need to make a light INK wrapper for the conversion scripts Wendell is making and then Alex can (not happening yet but soon) actually use INK to test the whole sheeeeebang. Cool. So, they can all operate pretty well remotely to each other building the same machine.

The cool thing about all this is that, sure sometimes details are hard to transmit, but mostly what happens is that people have most of the day, every day, to work on what they need to work on. I think this is helped by being remote. We have to be efficient. We don’t get in each other’s way. We have to get clear understandings fast. Remote comms aren’t nice for long conversations. We need them short, sweet, and efficient. Then everyone can just get on with what they want to do most…solve interesting problems.

I’m not going to say we are perfect. I’m also not going to say this process is perfect. We see the issues. We plan to have at least one full in-person team meet every 0.8 years so everyone can hang out and fill up the camaraderie tank (important)…the last one was in Athens and it was a blast



…and I make sure I go and see everyone every few months to make sure we are all on the same page and feeling connected. This setup needs these additional things. But it works, and when I travel around to see everyone, I see it working well and I see people performing exceedingly well doing things they want to do.

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