Adam Hyde

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.