How the 'itch-to-scratch model' can solve our UX woes

"Every good work of software starts by scratching a developer's personal itch."
481 readers like this.
Rocks stacked

Tony Smith via Flickr (CC BY 2.0)

Open source is a developer-centric solutions model, which, in a nutshell, could be described as building communities of developers to solve problems.

In its most simplistic form, the model has two stages. First, a developer has a problem, which they can fix with some new code, and they make a start on it. Second, if they then make their solution available to other developers it can develop into a full blown thriving open source community. When it works it is a fantastic process to behold and it this simple model that has changed the history of computing.

But outside of developers solving developer problems, open source hasn't done so well. This is pretty well discussed in open source circles, often framed in questions like: "Why are the user interfaces so sucky?" Framing the issue in terms of bad UI is common but it is perhaps a shallow treatment of the issue. 'User facing' open source projects don't just fail at UI, they fail to meet user needs at a much deeper level.

When looking around at the available open source solutions that are primarily aimed at users, have you ever asked yourself why open source seems to perform so poorly?It's not just the UX of your favorite desktop app that feels clunky, but why isn't open source winning in the desktop space in general?

Where is that open source desktop app everyone wants? What about web space for that matter?

Where are the open source equivalents that kill the proprietary opposition? Why isn’t open source wiping out the competition in every user sector from text editors to CRM, from webmail to social media?

There are few examples.

I would argue Unity desktop outstrips the competition, and that Mattermost and GitLab are better than Slack and GitHub, but I'm not in the majority on that.

Outside of a small handful of examples, I can’t see any open source products killing the proprietary competition when it comes to fulfilling user needs. Why has open source done so well in producing developer-facing solutions and web and internet infrastructure, but has done so poorly in the user-facing world?

I think open source can be dominant in social networks, text editors, CRMs, webmail, and more. In fact, I think the open source model has some essential characteristics that lend itself to beating the proprietary competition right across the board. But not without first understanding why it is currently not doing this.

To understand the problem, as a first step towards solving it, we must look deep inside the way we create solutions in open source communities. We need to do this critically and be prepared to ask ourselves some difficult questions.

The itch-to-scratch model

"Every good work of software starts by scratching a developer's personal itch." -- Eric Raymond

Eric Raymond suggested that open source and free software has a particular kind of solutions model he called the itch-to-scratch model. Basically, the idea is that open source projects start because someone, somewhere, sees a problem (the itch) and they start programming their way to a solution (the scratch).

That makes perfect sense and it is a very succinct way to describe what actually happens. Eric Raymond wrote more about it in The Cathedral and the Bazaar, which is considered a foundational work when it comes to understanding open source. As Eric Raymond states:

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

The itch-to-scratch model has two very important characteristics which have played extremely well for open source:

  1. The fact that it is your itch is essential for developing a good solution. If you have a problem and you know it very well then you are very well paced to start solving that problem. You are much better placed as an 'insider' to solve the problem than an 'outsider' that has a shallow grasp of the issue. Because it is your itch you are both motivated to solve it and, more importantly, you will have unique insights into how to solve that problem.

  2. Others with a similar problem are essential for building community. If your itch is a common itch, and you know others that need your partial or complete solution, then you are likely to see a growth in contributions and/or adoption. That's basically the secret sauce to the growth of open source projects. There is more to successful open source communities of course, like governance, volunteer management, understanding intrinsic and extrinsic motivations, and so on, but the heart of the matter is that if you know others with the same itch, open source is, if nothing else, an excellent model for magnifying the scratch effect. It is also not without precedent, as anyone that reads the works of John Abele or Everett Rogers knows. In the outside world, this process is known as 'diffusion'.

So, the itch-to-scratch model, as a model for open source communities, really succeeds because you know your itch, and, secondly, you know others that share the same problem and, consequently, want to share, or participate in creating your solution. So far it sounds thoroughly unhygienic!

In real life

In the real world, we see this in action. Perhaps the cultural genesis of this is Linux. Linus Torvalds has a problem, he wants a free operating system (the itch). He makes a go of it (the scratch) and posts an email to the world asking if anyone else is interested in solving this problem with him. And, we know the rest of the story: one big community-driven scratch that has changed the history of computing forever. This is the itch-to-scratch model in action in a prototypical manner.

That is pretty much how every successful open source project from day one has evolved. Developers solving technical problems and gradually attracting other developers to work with them to solve or adopt it. At the heart of this model are the developers. The people with both the problem and the solution. I call this model the developer-centric solutions model. It is, pretty much, the model for every open source project that exists.

So, we know that this model is powerful. We have seen what it can do. But how many times have we stopped to ask ourselves what it can't do or what it doesn't do well? How often have we asked ourselves where it is failing and why? I don't think we have this conversation enough.

Let's start to consider these questions by first being clear about where the developer-centric model works. Well, it works well when solving problems developers have, which are almost by definition exclusively or at least primarily, technical problems. This is why the internet is basically run on top of an open source layer from BIND to OpenSSH, and why you can't get far in the web hosting or container world without open source. In fact, you can't really develop software of any kind without using open source libraries of one sort or another. The developer-centric model wins, hands down when solving these kinds of problems.

However, while the developer-centric model has proven to be amazingly good at solving technical problems, history has demonstrated that it hasn't proven to be very good at solving user-facing problems. If it were good at doing this we would expect to see open source crushing proprietary applications in the user space. But we don't see this very often.

Could it be that this model is not good at solving these kinds of problems?

Here is where I believe the problem lies. The developer-centric model works for solving technical problems because, as Eric Raymond pointed out, the people with the problem are at the heart of creating the solution. The developers know their itch.

When developers are solving technical problems, problems that they have, understand well and want to fix, it works extremely well. And when developers are solving user problems, problems that are not their own, where they do not understand the issue intimately and the required solution is not primarily a technical issue, it does not work very well at all.

This is because in these cases we have broken the first requirement of the itch-to-scratch model: know your problem. The developers do not 'know' the problem intimately the way the users do because it is after all, not their problem. They are trying to solve the famous SEP, Someone Else's Problem. Consequently, they do not have the same in-depth experiential knowledge and understanding of the quirks and nuances of the problem that the users do. It is a qualitative, experiential, difference but it is an important one.

Consequently, we get software solutions that reflect the developers understanding of the problem and reflects a developer's approach to the solution; one that typically does not match the users understanding of the problem or their needs.

In open source today, developers are the dominant solutions providers. When they build solutions for themselves it is an almost perfect model. But when it comes to building solutions for a user base whose needs the developer doesn't intimately understand (because they are not the user), then the model fails.

How do we solve this?

I think the answer is clear. We stick to the itch-to-scratch model.

It is a good method for solving problems. It is the model that has enabled open source to squash the proprietary competition in the technical world. We should stick to it, but we need to be consistent in how we apply it. We need to keep the people with the problem, those with the itch, the people that understand the problem intimately, at the heart of the problem-solving effort.

It is not enough to add 'UX people' or 'user forums' to an otherwise developer-centric project culture to solve user needs. That approach is an interim patch and is only going to go so far. We need to go back to core principles of the itch-to-scratch model and bring the people with the problem (the users) into the heart of the solutions model.

To do that we need to begin asking ourselves what a user-centric solutions model might look like for open source.

What does it look like to you?

User profile image.
Adam is a Shuttleworth Fellow and coFounder of the Collaborative Knowledge Foundation. Previously founder of FLOSS Manuals, Booktype, and Book Sprints. https://www.adamhyde.net https://coko.foundation  

4 Comments

I get the argument here, but it misses the real question. Given that proprietary end-user software out-competes FLO offerings, how is it possible that proprietary software succeeds at this?

If proprietary developers of end-user software don't know the problems themselves (are fixing other people's problems), then obviously it's possible to successfully develop software that isn't scratching one's own itch. If proprietary developers are also scratching their own itches (certainly often the case), then the whole premise fails to describe why FLO end-user software does worse.

There are lots of complex issues (primarily economic but many other factors too). We won't successfully identify them by asking merely, "what is different between back-end/upstream/dev-centric FLO and end-user-focused FLO?", we need to ask "what does proprietary end-user software have that FLO end-user software lacks?" The most obvious answer is: an economic model to pay full-time teams to work on the software.

If you look dollar-for-dollar going into the development of end-user software, the advantage of proprietary software disappears. Given the same funding, proprietary software doesn't produce better end-user results. Does back-end FLO software do better with *less* funding than proprietary? In some cases, yes. But as an overall trend, funding is a decisive factor in back-end software too. The strongest FLO software is well-funded, even when we're talking about dev-centric software that started as itch-scratching.

Sure, the participation of non-programmers would make a huge difference, but the main issue is economic.

hey Aaron, Good points (and thanks for reading the article so closely). So...my point is that there is a large cultural difference between how open source is produced and how proprietary software is produced. Most modern software production processes that I have seen or read about in the proprietary world spend an awful lot of time (one way or the other) with target users and stay with them right through the process from design to going live (and after). Open source culture *can* use some of the methods proprietary projects use but I would argue that it has to be done in a different way - a way that is more appropriate to open source culture.

So, the question for me is - how can open source evolve to develop fantastic user facing software in a way that feels like it is 'the open source way'. Here I think we are leaving a lot of value on the table because open source projects that have users don't know what to do with them. Sometimes they get asked to file bugs, or do documentation, or marketing etc...but aren't we missing something here? If users are wanting to be involved why not involve them in a far deeper level? They are, for example, the best use case specialists you will ever have. So how about bringing them in as core team to co-design the software? Then you couple the people with the itch (the users) with a team that can help evolve the solution.

As for the economics of it. I think people like working in teams to solve problems together. I also think people love to volunteer to do these things. That is pretty much what community is, and open source (IMHO) needs to start working out how to include a broader skill base (use case specialists, UX specialists etc) at the core of the project (not tapped on the outside as an afterthought). Its not that difficult an issue to think through and start tackling, and I think open source at large, and any given project, would benefit greatly from this.

Also, I'll be writing some more on this topic in future articles here (if opensource.com approves!).

In reply to by wolftune

Great article. You captured the problem so well. I kept going yes, yes! I was so excited to find how you were going to solve this huge problem.

Then I reached the last section and the balloon deflated. The answer to the problem of why the itch-to-scatch model works so well for developers and not for regular humans is: the itch-to-scratch model! What? I went back trying to find if I missed the buried insight. And I still don't get it.

My organization develops/has developed open source solutions for people with disabilities, teachers, human rights activists, impoverished women and environmentalists. We do it relatively traditionally in terms of how proprietary software does it: we do user centered design, prototyping and using UX experts. It works reasonably well. Except, our open source community is really sparse, because there are few of our users who are developers who want to jump in and scratch an itch.

In your vision, what would we be doing differently? Assuming our target users are some of the people in society most in need of help.

hi Jim, Thanks for the comments! My point is that the itch-to-scratch model should be for everyone, not just for developers. So you need to look for people of all types (devs included) that are sympathetic to your goals and try and convince them to get involved. Since self-interest is really the driver here I'd ask yourself if what you have to offer is really appealing to the diverse roles that you wish to see involved. In essence, consciously designing your community processes to bring in the kinds of people you are looking for. Its hard work but not impossible.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.