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.

20170510_100223_1024

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.

Ponderings

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.