Apr 14, 2023 6 min read

The Itch to Scratch Model: The Foundation of Open Source Success, and Failure

Embracing a new open source model that empowers non-developer founders is crucial for fostering innovation and inclusivity in user-facing software.

Robots Cooking

In the realm of software development, open source has become an essential and powerful force. At the heart of this movement is the "itch to scratch" model, as identified by Eric S. Raymond, an influential advocate for open source.

The Itch to Scratch Model

The itch to scratch model is a concept that explains the motivation behind open source projects. It suggests that developers create software to "scratch their own itch" – to solve a problem they themselves are facing. This self-serving motivation drives them to create a solution, and they share it with the community in the hope that others will find it useful and contribute to its improvement.

This model is particularly effective when the person who encounters a problem is also the one with the skills and means to solve it. The developer can directly address the issue and create a solution tailored to their needs. By open-sourcing the solution, they enable others with similar problems to benefit from their work, fostering a spirit of collaboration and shared innovation.

However, the itch to scratch model has a limitation: if you don't have the necessary skills to solve the problem, you can't "scratch the itch." In the context of open source, this means that only those with the technical ability to create and improve code can meaningfully contribute to a project. As a result, the open source community primarily values developers, who possess the skills to make these kinds of problems disappear.

Thriving in Code-as-Infrastructure

The itch-to-scratch model is especially successful when applied to code-as-infrastructure projects. These are upstream code libraries that solve specific problems for other developers, making their lives easier and more efficient. As developers use and benefit from these libraries, they become invested in their improvement, leading to further adoption and contributions.

This cycle of solving a problem, sharing the solution, and receiving input from the community ensures that the open source model thrives in this scenario. It creates a self-sustaining ecosystem of innovation and collaboration, driving the development of solutions for a wide range of code-as-infrastructure challenges.

This model is largely what we know as, and celebrate as, open source.

Where it fails

However this model fails when those facing a problem don't have the means or skills to solve it. This becomes particularly evident in cases involving user-facing ('non-technical') problems.

In situations where the person experiencing the issue is a non-developer[sic] or primarily a 'user', they often lack the technical expertise required to start an open source project. These individuals may have valuable insights and a strong desire to address significant challenges, but their inability to code has been thought of as a barrier to entry, especially when it comes to founding projects.

As a non-programmer, I have faced this predicament. I wanted to tackle publishing problems using software, but my lack of programming skills was generally seen by others as a hindrance. This experience is not unique to me; many non-developers have encountered resistance when attempting to participate in the open source community.

I have even come across established open source figures who have told me directly that non-coders should not start open source projects. This mindset creates a barrier for those who could potentially contribute valuable ideas and perspectives to the open source landscape.

The risk is, that if we don't find ways to empower non-developers to contribute to, and start, open source projects, we risk perpetuating a software landscape dominated by user-facing proprietary applications. This is precisely what has happened in recent years, as many user-friendly solutions have remained locked behind proprietary licenses and open source solutions have failed to materialize or compete.

Solving problems in the open source world as a non-developer can be a daunting task. However, two crucial ingredients can help you overcome these challenges: stubbornness and persistence. It's essential not to let the naysayers deter you and, instead, find your own path forward.

My Journey: Stubbornness and Persistence in Action

You might be wondering if it is possible at all to start an open source project if you cannot create code. I am here to say that it is. I have done it many times and I will post more about what I learned along the way on this site.

In brief, starting open source projects as a non-developer has involved first convincing people to contribute, and then, later, finding resources to employ people who could build the open source software I wanted to see in the world. Securing funding for these projects wasn't easy; initially, the money came in sporadically, although the situation has improved over time.

However by far the more critical challenge to address is the culture you create within your project. The itch to scratch model has positioned developers as solution providers – which they indeed are, but they are not 'all domain' solution providers. Developers are, specifically, technical solution providers. Often, developers (and others) perceive themselves as capable of solving any problem, regardless of the domain (I'll also discuss why I think this has come to be in later posts). This mindset can be a recipe for failure.

For open source projects in the user space to succeed, it is crucial that each stakeholder tackles the problems they are best equipped to handle. In my opinion, users should design the solution, while developers should focus on solving the technical problems (a topic that will also be explored further in upcoming posts on participatory design).

Navigating Empowerment and Dis-empowerment

In implementing this approach, I have observed that first-time participants tend to experience a shift in dynamics. Users often feel empowered, as they have a say in designing the solution. On the other hand, developers may initially feel dis-empowered. However, it is crucial for developers to understand that they are not the jack-of-all-solution-providers. In-fact all stakeholders need to embrace this reality as it is a critical aspect of collaboration in user space open source projects.

Developers who recognize and accept their role as technical solution providers are truly invaluable. They bring forth outstanding technical solutions and do meaningful work. Over time, they also gain valuable domain knowledge and insights into the solution-approach, becoming even more effective contributors.

On the other hand, developers who struggle to accept this role and insist on imposing their ideas on users' problems can become disruptive and sometimes even toxic. While their technical skills are valuable, they may be better suited for projects that are more developer-centric.

To help this all work it's essential to maintain clear boundaries between users and developers. It might seem difficult or even confrontational to tell developers upfront that they will not be involved in solving users' issues directly. However, this conversation is crucial in helping them understand their role in the project and setting expectations for their contributions.

If you avoid discussing roles and boundaries with developers, they may inadvertently overstep their responsibilities, leading to stress and friction within the team. This can result in a breakdown of collaboration and a negative impact on the project's progress. Therefore, it is far more responsible to address the issue upfront, ensuring that everyone is on the same page from the beginning.

It is also crucial to support users so they don't automatically defer to developers. This effort requires considerable energy but is equally important. Users who defer to developers may undermine their own contributions, ultimately harming the project.

Elevating A New Model to the Core of Open Source Culture

To foster a more effective, inclusive and diverse open source ecosystem, we need a new model – one that encourages non-developers to initiate and manage open source projects. This model should promote a collaborative environment where developers recognize that they are not the sole solution providers, and instead, contribute as part of a larger team with diverse skill sets.

To make this new model an integral part of the open source culture, we need to create a framework and discourse that goes beyond the status of just 'a few side projects.' This new model should be a fundamental component of open source values, and its promotion should be at the heart of the community's efforts.

We need to foster the skills required by non-developer project founders so they can found projects, generate resources, build partnerships, and lead projects effectively.

Without embracing this new model, the open source community will continue to struggle in the realm of user-facing software. The current dominance of developer-centric projects limits the potential impact of open source, leaving many user-oriented challenges unaddressed, or poorly addressed.

Conclusion

In conclusion, we need to adopt a new model of open source collaboration that elevates non-developers-as-founders and encourages a more diverse and inclusive approach to problem-solving. By doing so, we can create a thriving open source ecosystem that is better equipped to address a wide range of challenges, including those in the user-facing software domain. This shift in mindset and culture will not only benefit the open source community but also contribute to a more innovative and accessible digital landscape for everyone.