In NZ for a week to renew my passport. Winter is here but it’s sunny and warm. Manuka is out in bloom.
In NZ for a week to renew my passport. Winter is here but it’s sunny and warm. Manuka is out in bloom.
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:
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:
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.
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 Bonner, Anasuya Sengupta, Tarek Loubani, Alasdair Davies, Ugo Vallauri, Seamus Kraft, Peter Cunliffe-Jones, Madeleine Ball, Luka Mustafa, Aaron Makaruk, Gavin Weale, Kathi Fletcher, Jesse von Doom and Helen Turvey. An amazing bunch of people.
I just finished a 3 day meet in Athens with the PubSweet team.
It was a fantastic meeting and we covered a huge amount of interesting ground. Most importantly we discussed:
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!
I’m currently in Athens for a PubSweet meeting. As it happens the Coko Athens team (now 3) also got the keys for the new Coko Athens office! 1 day to go, the last 2 days have been great.
From back in the day when I was a sound artist. Tracks made using sounds from space recorded with radio telescopes.
I just presented at the very cool Open Source Albania.
Now off to the first global PubSweet meeting in Athens!
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):
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…
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.
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.
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:
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.
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.
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 slides.com because they maintain the reveal.js open source presentation project).
On the plane tomorrow I will update this post with my new slides.