Tag: open source projects

New Intro

The following is an update of the opening chapter for a book about the Collaborative Product Design method I developed. It is meant to be ‘thought provoking’. Feedback is very much welcomed…

Open source is broken. Or, more precisely, it’s partially broken. It works for solving problems developers have, but it doesn’t generally work so well for fixing problems that (so-called) users have.

The part that works is where the famous ‘itch to scratch’ model comes into play. If you’re a developer and you have a problem which could be fixed with some new code, then you’re in a good position to solve it. This model has been thought to work because the developer has the coding skills to create software, so they are in a good position to solve software problems. But I’d like to suggest that while writing code is a necessary condition for creating software, it is not the critical reason this model works. The critical reason is that in these cases the developer is the user. Hence the developer understands the problem in depth since it’s their problem.

This is where open source excels. This is why we have such a proliferation of open source ‘under the hood’ libraries and tools for developers. In fact, it’s nearly impossible to be a developer these days and not use open source tools and libraries other developers have made. The itch to scratch model has worked for developers solving the problems they and, consequently, other developers, have.

But outside of developers solving their own problems, open source has largely failed. There are few convincing ‘user facing’ open source solutions that can beat out their proprietary rivals on approach, utility, and usability. This is because we have incorrectly concluded that the ability to develop software is the same as the ability to solve any problem that involves software. But understanding the problem, developing an approach to the solution, and developing software, are different skills. Open Source culture has not, by and large, recognised this and we have instead conflated these three conditions into one – the ability to develop software. To move on, we need to recognise the non sequiteur inherent in the logic of open source culture and develop models to address it.

The strength in open source is in people fixing their own problems (itching their own scratch). It works because these people bring insights into the problem that no one else has. Consequently, they come up with great solutions. The strength is not developers solving problems, but people solving their own problems. That is why developers do a great job fixing developer problems. The model fails when we extrapolate the developer solving developer problems model and assume that those who can create software can solve any problems where software may be required. We have conflated writing software with solving problems that require software and we miss the point, the fundamental strength, of open source. Open Source succeeds not because of code, but because of people solving their own problems.

This may sound counter intuitive. Open Source’s success is not because of code? But it’s not that difficult to understand. Simply put, software is a means to an end. We have focused too much on the means (developing software) and forgotten that it is not what we are doing. We are actually trying to solve a problem for someone, somewhere. Software, open or closed, is no good if it doesn’t solve that problem. It is completely useless. Open source’s primary goal is to solve problems, not create code, even though software is the dominant means to get there.

Not understanding this has lead Open Source down any number of non-productive wormholes and has lead to a technocentric culture that doesn’t understand its own strengths and limitations. We have been myopic in our approach to problems, seeing all problems as merely issues developers have not yet solved. It has led to terrible cultural issues for open source, including the over-reliance on ‘technical thinking’, the dominant power being held by white men who know how to code, the understanding that software freedom is merely a licensing issue, and a lack of understanding of wider issues of empowerment, the belief that developer tools (such as git) are good for any problem, if only we knew how to use them, the requirement in open source projects that all those involved should use the tool in the developer’s stack, the lack of role diversity in open source projects and the power imbalance that accompanies this, the use of the term ‘non-coders’ to name all skilled people that are not developers, the absence of patience for the ‘user,’ and the distillation of the user (the one with the problem) to the furthermost point from the center of the endeavor.

All of these issues have lead to a lack of cultural diversity, shortcomings on approaches to the many interesting problems the world has to offer open source, and, simply put, many bad open source solutions.

We need to address this issue and fast. Open source is fast losing out in ‘user space.’  We need to turn the corner and understand quickly that the real strength that open source represents is when people solve their own problems. When the user brings insights into the problem that no one else has. When they are deeply involved in scratching their own itch. This is when great solutions evolve,  as open source has already proven by the many amazing, innovative, world-beating solutions developers have created for themselves. But since we’ve mistakenly conflated ‘person with the problem’ with ‘developer’, we’ve missed the value of our own proposition.

What are we to do with this? The answer is simple: always have the people with the problem at the heart of the open source project. While the answer is simple, the implications are huge. They include the need to diversify participation on open source models, to push the developers out of the central roles they currently occupy in open source projects, to tear down technical meritocracy as the single determinant of value, and to experiment with new models of open source cultures.

This is why the Cabbage Tree Method exists. It’s a process designed to assist open source projects to develop world-beating, user-facing software. It’s also a process that changes the typical open source model substantially and advocates, by example, for a fresh approach to how open source projects are created, constituted, and operated.

Attributing All Contributors in Open Source

Attribution in technical projects is a fascinating topic. Fascinating, important and very occasionally controversial. Who should get credit for a work? That developers get attributed for the code they create is generally non-controversial. One, fairly typical, way to do this is to document these contributions in the copyright and contributions file of an open source project. You can also, of course, look at any given repository and see who has added what over the course of a project. It all seems pretty clear cut.

But what of the other people involved? Those that make wireframes for example? High level systems architects? Project or product managers? Ideas people? Founders? Designers? These people do not contribute code, so where do we place attribution for their work?

Generally speaking, the acknowledgement of these contributions occurs in places other than the code. How should we tell the story of the other people involved and what are the appropriate tools to do this?

These stories don’t often get told. When they do, they are in narrative form, on websites or blogs, telling the personal or organisational journey that saw a software from idea to reality. But unlike the contributions files and history records in code repositories, blogs and websites have a much shorter lifecycle and are bound, sooner or later, to be lost. Those stories tend to fade, leaving just the record of the code to tell the story.

It is a pity, because many of these contributions are critical in the life cycle of any software. Where would any successful desktop software be without the contributions of user testers? Many software solutions would not get a second look without a designer’s touch or feedback. Some projects would never have been born if it wasn’t for the inspiration of some energetic soul who managed to convince others of the value of an idea.

I’ll use my own work as an example but the phenomenon is bigger and there are far too many folk whose contributions go unacknowledged.

In a career, I’ve been fortunate to work on many successful and interesting technical projects over almost 2 decades. I have often been the ideas guy, not a developer, not a designer. I suck at QA, but I major in musing on the possibilities that technology can offer and I have become better and better at opening up people’s minds, from developers to clients, to funders, to what is possible. It is a process of inspiring and convincing others, of finding ways to gather momentum and resources to propel people down a promising path.

Sometimes I am fortunate to be credited for this work and I cherish those few moments where people have recognised this contribution and credit me. It doesn’t happen often, but it does happen in the occasional blog. Martin P Eve for example, a good friend and all round solid guy, called me out recently in a post about his JavaScript Typesetting Engine CaSSius:

“I can’t remember when Adam Hyde first suggested to me that CSS regions might be a viable way to produce PDFs for scholarly communications but it seemed like a good idea at that time and, I think, it still does. CaSSius is my implementation of that idea.”  https://www.pagedmedia.org/cassius-heavyweight-typesetting-with-lightweight-technology/

It was very generous of him to do so. Without this, there would be no other record of my affect on his thinking and practice. I was humbled by his generosity.

When these things happen, while rare, it motivates people like me. It puts some fuel in our engines to keep moving on and continuing to work the way we do.

Sometimes, however, it goes the other way. Occasionally, and once again (thankfully this time) it is rare, there are those that believe we should not be credited. Having managed many projects, I actually understand why some people do not see the value of this kind of contribution, as Lao Tzu is credited with saying:

“When the best leader’s work is done the people say, ‘We did it ourselves.'”

Management and leadership are strange arts, and often lead to strange paradoxes. I have often found myself invisible in credits while generously crediting others. Once or twice someone has been outraged when I casually mention my involvement in a project that I managed, initiated or inspired.

These moments are rare and curious, especially when they involve small projects that represent not much more than a line item in my career over several decades involving many innovative approaches to many interesting problems. I guess over time I have come to understand that for someone the line item is the source of great pride. This may be the only innovative project he or she has ever worked on. While I’ve begun to understand it, this kind of proprietariness doesn’t make a whole lot of sense in the open source world – it plays better in an all-rights-reserved world.

But even when things are this weird, I will continue to shine the light on their work and attribute them, despite the lack of reciprocity. Credit where credit is due, even if attribution is, unfortunately, a one-way street at times.

The good news is that many open source projects do attribute many types of work. Mozilla, for example, has a single global credits list where names are recorded of people that have made “a significant investment of time, with useful results, into Mozilla project-governed activities.” Audacity is a favorite project of mine that credits pretty widely, categorizing contributions to include code, documentation, translation, QA, administration etc. These are great examples of software projects recognising and honouring a variety of work. We should all follow these examples, Open Source can only benefit from the generosity of attribution illustrated by these projects.

As a coda, and on reflection, I think we need to think carefully about how work is valued and attributed in technical projects. Architects often proudly say “I built that house.” Did they actually lift the hammer and cut the wood? Probably not, but I think they have a right to proudly state their contribution as much as user testers, designers, developers, managers, QA folk, and ideas people have a right to state and be recognised for the contribution they made towards a software. Not only that, we should all celebrate and recognise the large variety of contributions that goes into making software and find effective, lasting, ways to tell those stories.