The Chair

Shuttleworth Gatherings are always fun. Fun, intensively thought-provoking and tiring. At each event, we get the opportunity to tap the minds of the fellow Fellows on a topic or issue we are working on. What follows is an hour or so of amazing insights from all sorts of smart people with very deep, diverse, insights into the issue. I have been to 4 Gatherings now and these sessions have deeply affected how I approach things and what I do.

At the most recent Gathering in Vancouver (early May) I pitched the following idea to about 14 sharp minds.


Aim: How to build community around Open Source Software Products

And I loaded it with the following assumption…

Assumption: The developers and users are not the same people.

My question to the group was set up with some background to my thinking about open source culture on which I have written a lot recently on this blog. The main idea being that open source has been great at developing infrastructure and developer tools but not user-facing products. The problem, as I see it, is that the ‘user’ (use-case specialist) is not central to the culture in these cases, rather the projects are developer led. So, if the use-case specialist was central to the culture, how would this work?

My two questions to the group were:

  1. why would people want to be involved?
  2. what would that interaction look like?

The chair pictured is one of the ‘artifacts’ that came out of the session. I took a photo because the session was super-helpful for me and led directly to a conversation a few days later in Athens with the Coko PubSweet team.


I haven’t had time to fully distil and unpack the Shuttleworth session, but there are a number of phrases and thoughts that are hanging around in my head that feel like pieces to a puzzle which I have yet to solve…. Some of the pieces as they exist in my head now:

  • attract/motivate people to be part of the project, not just part of the product
  • be community-centric (as opposed to dev or product-centric)
  • in a diverse collaborative group we must learn to speak each other’s domain language
  • work from a shared passion, not a shared need
  • such communities aren’t for everyone and we should be ok with this
  • success must be a shared metric
  • make it fun
  • make it something that is a shared journey/adventure/exploration
  • the journey must be social
  • contributions have equal but different weights
  • developers need to understand the user commitment
  • equality in difference
  • facilitation is hugely important
  • get away from the idea of someone making something for someone else
  • help people understand the value other roles can bring to the process
  • recognize different power dynamics
  • celebrate people for engaging with each other
  • reduce barriers to entry across the board
  • instinctive not explicit
  • community is core for figuring out solutions
  • there is magic in doing something new or in a new way
  • remove the community and all processes from the world of tech
  • keep the conversation really big
  • shared itch, not the same itch

These all link to more coherent and substantive thoughts but they are nice fragments for me to preserve. When I have pondered the matter some more I will draw these themes out in more depth.

What does it mean for me now?

Despite having to process this a little, I have already moved forward on some of these ideas. In Athens, we just finished a meeting with the Coko PubSweet crew. In this meeting, I proposed we discuss how we can get ‘users’ (use-case specialists) and ‘devs’ (code specialists) to work together in close collaboration. This would not answer the question as to how to make a community around open source products but it might give us some learnings and some clues. The idea we came up with is to form small work groups of 2 devs, 2 users, a UX person, and a facilitator – to work together on a trial basis. This would most likely have to be done remotely, which is challenging but the only possible way to make this happen at this moment since we are working with a very distributed team. That’s ok because that is a realistic reflection of the distribution of open source projects anyway.

So we will try this out with the Journal platform we are building. I think we will try it out with one team and reflect on it. See how it goes. From this experience, we will learn some things and take that forward in another iteration…

I was really happy with the discussion at the PubSweet meeting and it reflects the awesome bunch of folks we have at Coko. Really cool people.

Anyway …if the above makes sense to you in its partial, scratch out, form then please reach out to me with your thoughts.

I’d like to thank all the Shuttleworth Fellows that were at the session including Sean BonnerAnasuya SenguptaTarek LoubaniAlasdair DaviesUgo VallauriSeamus KraftPeter Cunliffe-JonesMadeleine BallLuka MustafaAaron MakarukGavin WealeKathi FletcherJesse von Doom and Helen Turvey. An amazing bunch of people.

First Global PubSweet Conference

I just finished a 3 day meet in Athens with the PubSweet team.

No event is complete without a t-shirt!

It was a fantastic meeting and we covered a huge amount of interesting ground. Most importantly we discussed:

  • the remaining features for a PubSweet 1.0 (due end of June)
  • some future ideas for PubSweet 2.0 (possible GraphQL Apollo integration)
  • a demo and discussion around the latest Editoria (looks amazing!)
  • a workshop on how to think through Journal workflows with our decoupled approach
  • and a great discussion on how we could start growing a community model around Cabbage Tree Method principles (moving towards Cabbage Tree 2.0!)

We also looked at the new Athens office, and meet with Vasilis who is managing the production servers for the forthcoming UCP Editoria tests…

Now off to New Zealand! It was a really fantastic week!

Coko and Communities

Kristen Ratan (co-Founder of Coko) and I have been pondering ‘the next phase’ of Coko. We have an organisation in place, with great people, and we have developed products (Editoria, and more coming soon) and frameworks (INK and PubSweet). Also, of course, we have developed the Cabbage Tree Method for facilitating ‘users’ (use-case specialists) to design their own products.

So…next up… community. It seems to me it is an interesting next phase which will require a lot of thinking about. The complexity comes from the fact that we have multiple primary stakeholders at play. A rough breakdown (note, each category is a complex ecosystem of diverse roles – all of which we still have to think through):

  1. PubSweet backend – this is a ‘headless CMS’ built for publishing workflows… however, it is a technical software whose primary community would be developers that commit to its continued development. Additionally, I would argue, its use-case is a whole lot broader than capital P Publishing… any organisation that wants to develop workflows for producing content (which is pretty much every organisation that exists) could benefit from this software. Publishers are just a tiny subset.
  2. INK – the web service for (primarily) managing file conversion pipelines. This is also a technical ‘backend’ whose primary community would be developers. INK’s use-case is also broader than ‘just’ publishers.
  3. INK Steps – INK processes files through steps which are small plugins. These can do anything from file conversion, to validation, content parsing etc…. the primary community for this is possibly more tightly connected to publishing requirements, but the builders of steps are more likely to be those involved on the production side of the workflow ie. file conversion experts, content miners etc
  4. XSweet – a very specific content conversion pipeline for producing HTML from docx. Primary community would be file conversion experts.
  5. Editoria – the monograph production platform. Primary community – Publishers but also interesting to any org that produces books.
  6. Journals – we are on our way to producing a Journal platform. The primary community for this is also publishing organisations…
  7. Ecosystem – we are building out an ecosystem of projects. So as much as possible we need to consider how we interact with and build community/collaboration with other open source/open access (etc) projects.

It is a complex stack..our job is to work out all parts of this stack, understand what they look like, and think through why they would want to be involved in a community, and how…

What I’m Pondering Now

I am slowly working out a pretty clear picture for the argument that open source needs to start developing its ‘own way’ to develop products. The issue is complex and interesting. While, for example, the Cabbage Tree Method solved some of these issues, it also opened up many more questions. How, for example, do we build flourishing open source product development communities… this is the next level of problems I’m pondering and I’m developing a narrative for it to help think through the issues as well as engage others in the discussion.

On this path, there are some issues that I need to get better at breaking down and explaining and I may have to evolve the language I use quite a bit to hit the right spot. For example, ‘product’ is hard to define. I started by saying ‘user-facing products’ etc but I have received some push back on this. Mainly the argument is that ‘developers and users are often the same’. I agree with that, but my point is very specifically that I’m interested in cases where this is not the case; I’m interested in cases, which I consider to be very typical product development scenarios, where the developers and the users are not the same people. This is exactly the area I’m targeting.

So, I’d like to define a product as any software where there are people involved in creating the solution that are not the primary stakeholders with the problem. This distinguishes the situation from the typical ‘itch to scratch’ model where the people creating the solution are the same as the people with the problem, in fact, you could say that I’m interested in developing models which mean that, to some understandable degree, we are ‘scratching someone else’s itch’.

Now…this might not be a suitable framing either. This is because I believe that ‘scratching someone else’s itch’ is a good way to describe how current open source culture attempts to solve this very tricky product development problem ie. developers creating solutions for ‘users’. However, if we are to develop a healthy open source product development culture, we actually all have to have a stake in the problem. Otherwise, why would we be interested in being involved? This is, in fact, at the very heart of the issue. If we are to “scratch someone else’s itch” we actually have to reframe what we do. We have to reframe the open source project mission at a higher level to attract people of all kinds to participate in solving a higher value problem.

For example, we need to reframe the mission from something like ‘building a browser’ to ‘building the open web’ (to borrow from a contemporary example). In my world, it is a reframing of ‘building better publishing platforms’ to ‘improving the sharing of scholarly research’. If we can reformulate what we are trying to achieve then we can attract a broader range of stakeholders and place the user (as a use-case specialist) at the core of the culture alongside others that have a stake in this mission (including developers, UX people, system architects, marketing people etc). We are, in effect, reformulating Eric Raymonds ‘itch to scratch’ model from

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

to something like

Every good open source product starts by scratching a shared itch.

I think this is super interesting because it retains the essential feature of open source culture that has made it so valuable and effective – that those participating in creating the solution are ‘internal’ to the problem. That is not often true of typical proprietary solutions models where ‘the user’ is, in essence, treated as a ‘research object’. But at the same time, this statement up-ends the current discussion and directs open source away from a developer-centric solutions model towards a culture that must embrace collaboration by a diversity of stakeholders to succeed.

Historical Progression

I am also slowly structuring the historical narrative. This comes from my discussions with Tony Wasserman. In essence, the argument can be made that open source has indeed solved many problems. The initial set of problems addressed were infrastructural –  this can be clearly linked to the development of the Linux kernel where Linus Torvalds wanted a free and open OS (the itch) and started the development (the scratch). He then reached out to others that were interested to communally scratch this shared itch. It’s a good framing story, well known and understood and not likely to be too controversial. The interesting point of the story, is that this foundational moment was in the pursuit of building infrastructure (an OS) which is primarily a technical endeavor.

To take the narrative further, I think it can be said that the ‘next set of problems’ (an important framing too), was developer tools ie. tools developers needed to do what they need to do. This would include things like basic email clients (eg pine/mutt etc), command line tools, IDEs, and reusable libraries. This may need to be refined a little when describing what this literally refers to, so as to avoid push back. The general arc of the narrative, however, is a story of progression. This aids in setting the scene for the ‘next set of problems’ ie. solving the problem of producing products.

I like this progression story because it also illustrates that open source culture has always been evolutionary. What we need to do now is take the culture forward to solve the next big problems it faces. It is a positive framing of a march forwards and a march towards solving the perplexing problem of open source product development.

The Open Source Way

In addition, I think I am getting some clarity on what I’m asking. We know how to develop products, that’s been going on for years. You can look at any number of amazing products and look at how they were developed. The big issue here, is how we do this ‘the open source way’.

I would frame this as largely a question about the bazaar vs cathedral, to borrow from Eric Raymond’s famous framing. We can, in open source projects, borrow methodologies like ‘Agile’ to build products (I have problems with notions of Agile as a method which mostly are inherited from this presentation by Pragmatic Dave, but will refer to Agile as a methodology here for efficiency’s sake). But these methods are pretty strongly managed and break two important foundational principles of the bazaar:

  1. they are formal processes – which puts their whole modus operandi in question as to its appropriateness in the informal bazaar. This makes community a casualty and community is, IMHO, what we are after.
  2. they assume the solution provider is external to the problem – ie Agile (etc) is a typical “scratch someone else’s itch” model. In the way that the cathedral is not with the people like a bazaar is, but for the people, Agile processes are cathedral-like. They lose all the power of ‘being of people’ which is central to the open source community model – the essential value being, in my opinion, derived by placing the ‘people with the problem’ at the center of the solutions culture.

So, how do we do this ‘the open source way’? Well, I think we need to rethink our community models. We need to develop communities that solve these problems in a cross-disciplinary way where use-case specialists, developers, UX people marketeers etc all work together such that all ‘roles’ are playing on an egalitarian playing field. This is the heart of the matter. How do we scratch this ‘higher level’ itch together?

In addition, we need to keep software development being a fun, productive, conversation. Voluntary working environments are opt-in processes. So, if they are to work, they need to hold to a notion of informality and they have to be fun. In my mind, this means that conversation is key. Productive conversation is both the driver and a key metric for a flourishing community.

When we know how to develop crossdisciplinary conversations where all parties are valued equally, we will be well on our way to forming communities that produce amazing open source products.

Just How Radical is This?

I guess this is the big challenge. When I think about an open source project culture that performs like this I think the fundamental principles of open source remain the same – we retain, celebrate and build community as a primary activity, we hold collaboration high in the culture, we celebrate individual contributions towards a collective effort, we continue to work in ways that are antithetical to intuitive proprietary-commercial culture by working out modes for collaborating with competitors (etc), we develop processes that appeal to both intrinsic and extrinsic motivations, and continue to carefully cultivate notions and practices of stewardship and governance, while at the same time upholding the full spectrum values of openness and freedom so deeply embedded in open source culture.

However, operationally, things would look quite different. In a community where there are a diverse set of equally valued roles at play to produce open source solutions, we would expect language, tools, working processes, and value metrics, as well as a whole swag of culture practices, to evolve in directions that, over time, would mark a clear departure from how things are done now.

That is the interesting part to all of this. The principles of open source remain the same, but the practice will look quite different.

Even though I am still working all this out ‘out in the open’ in an incremental and evolutionary way, I am convinced we need to do this. The big questions that are starting to surface to me revolve around how we do this. How do we evolve communities to experiment with these ideas and work out the path ahead. It is going to require a lot of empathy, bravery, trial and error to discover ways forward that can improve upon what we are doing now. Which is why I’m spending quite a bit of time talking to people, evolving the narrative, and thinking through strategies with others that can help us move forward.

OSCAL 17 Presentation on Itch to Scratch

Tomorrow I travel to Albania to present at the OSCAL 17 conference. OSCAL is the Albanian Open Source conference and I’ll be presenting for an hour or so on how the itch to scratch principles of open source could be used to create open source products (as opposed to infrastructure and dev tools)

I haven’t made the slides yet but they will be close to the presentation I did on the same topic in Detroit last week at Penguicon. Those slides can be found here (I use because they maintain the reveal.js open source presentation project).

On the plane tomorrow I will update this post with my new slides.

Open Source Product Development Culture

The more I think about Coko and the problems we have to solve, the more I have come to understand why and when open source works best. This should be a good thing, but strangely it raises more questions than answers. Up til now, open source has never been a product development culture. It has primarily been a technical solutions culture; the difference between those two cultures is vast.

I’m feeling a little like a stunned mullet. Like the most obvious thing in the world was sitting right in front of me but I never saw it. And we simply don’t have good examples of open source product development cultures that we can copy or learn lessons from. That fact is kind of shocking to me, and I am doubly shocked that it has taken me so long to clearly understand the ramifications.

It means that there is a difficulty, or we should exercise wariness, when translating lessons learned from existing open source models to those focused on producing products. The primary stakeholders change from developers to ‘users’ and that means that business models, metrics, language, tooling, intrinsic and extrinsic motivations, processes for inter-organisational collaboration, workflows etc all change. Everything changes. We have to examine and re-imagine everything.