Simplified, Narrative, and Transient Attribution

I’ve been thinking through attribution models for many years. Mainly for books, but it is also interesting to consider how credit is attributed in open source projects. For both open source and books, I believe narrative attribution is a great model which escapes many of the problems of simplified attribution, but there are some interesting gotchas… so, let’s take a look at it….

A copyright holder is different to those people we attribute credit to for producing a work. Michael Jackson, for example, held the copyright for the Beatles songs for a long time, however we attribute the credit for those songs to Ringo, George, Paul and John.

I like to think of this ‘naming’ of contributors to be a type of simplified attribution. It is a handy tool to be able to hang credit on a couple of names. Nice and clean, not complicated, and easy to remember. It is also the way copyright works. Copyright requires some names to be cited as the copyright holder and many times we, out of habit, co-relate the named copyright holders with the credit for producing the work. It’s just how our brains work.

However, there are a couple of things we need to tease out here. First, named credit is not synonymous with the named copyright holder and we should be a little more careful with this and avoid conflating the two. Michael Jackson, for example, clearly did not write the Beatles songs, so we should be careful to avoid conflating credit and copyright.

Secondly, simplifed attribution doesn’t actually tell us much. It is not rich information. It’s a couple of names and we tend to attribute far too much credit to those names. We have a romantic notion of creation and we tend to want to think there is a ‘solitary genius’ behind things. If not a solitary genius, then a couple of identifiable people that we can attribute genius to collectively. But this is really fantasy. Great things come from many people, not one. One person by themselves isn’t capable of much. How individuals work together is the real story and these stories are far more complicated than the vehicle of simplified attribution can convey.

Those who know the story of the Beatles, for example, know there is far more complexity to how the songs were written and by who. Each Beatles song has its own history and unique way of coming into existence. The Song Michelle, for example, was mainly written by Paul McCartney, with a small portion a collaboration between McCartney and Lennon. Even more interesting, is that other characters came into play. According to Wikipedia:

McCartney asked Jan Vaughan, a French teacher and the wife of his old friend Ivan Vaughan, to come up with a French name and a phrase that rhymed with it. "It was because I'd always thought that the song sounded French that I stuck with it. I can't speak French properly so that's why I needed help in sorting out the actual words", McCartney said.

Vaughan came up with "Michelle, ma belle", and a few days later McCartney asked for a translation of "these are words that go together well" — sont des mots qui vont très bien ensemble. When McCartney played the song for Lennon, Lennon suggested the "I love you" bridge. Lennon was inspired by a song he heard the previous evening, Nina Simone's version of "I Put a Spell on You", which used the same phrase but with the emphasis on the last word, "I love you".

The actual story of how the song was written reveals a much more interesting story than the typical way we assign credit for these songs. I find the story of how something was made, and by whom, way more interesting and informative than a list of a couple of names. I also think it’s a better way to attribute credit as it values the contribution of each individual and brings forward the interesting ways in which they made the contribution. I think this kind of narrative attribution is a far more important way to credit people. It honours both the people and the process a lot better than the more simplified naming of names.

I want to say something about transient attribution in a bit, but before moving on I’d like to give another example of why I think narrative attribution is necessary as we move increasingly into a collaborative future. At FLOSS Manuals, an org I founded 10 years ago to collaboratively produce free software manuals, we automated simplified attribution. If you made an edit, your name was automatically added to the credits page. That worked ok for the naming of names. But how useful is this?

Well, if one person claimed to write the book, this might be useful. But below is an example which illustrates the problem…this is a screenshot of the credits page of a freely licensed book that was updated and rewritten every year by a different team of people for 4 or 5 years. So, the simplified attribution looks like this :


Well…you get the picture! It is pretty meaningless information, or at least, there is not much utility from this kind of attribution. It is, in short, too much information and too little information at the same time. A list of names like this is nothing more than a long list. It doesn’t highlight the many interesting ways individuals contributed, and no one here actually gets much credit at all from such as list because no one will read it. It is pretty much useless.

So…what can we do? Well, I believe we need to get away from simplified attribution at all times. We need to migrate to narrative attribution. We need to learn how to tell stories about how people make things and who was involved. It is for this reason that at FLOSS Manuals we started writing “How this book was written” chapters. Here is an example from the book Collaborative Futures which is now stored in the Wayback Machine. A brief snippet:

This book was first written over 5 days (18-22 Jan 2010) during a Book Sprint in Berlin. 7 people (5 writers, 1 programmer and 1 facilitator) gathered to collaborate and produce a book in 5 days with no prior preparation and with the only guiding light being the title ‘Collaborative Futures’.

These collaborators were: Mushon Zer-Aviv, Michael Mandiberg, Mike Linksvayer, Marta Peirano, Alan Toner, Aleksandar Erkalovic (programmer) and Adam Hyde (facilitator).

It is a short story but it goes some way to bring out a little of the nuance of how the book was made. We could have gone further but it gets the point across. We also made sure that this way of attributing credit was included as a chapter in the book. So wherever the book went, the story of how it was made travelled with it.

I think we could do the same with software. Let’s not conflate copyright with credit, for a start. Next, let’s proceed to a more interesting way of attributing credit. Not a naming of names, but telling a story of who was involved and how. Finally, let’s make sure this story is part of the software and travels with it ie. put the story in the source code repository.

But there is an obvious flaw to this approach. What happens when many people are involved over a long time. If you had been paying attention, for example, to that 29,000 pixel tall monstrosity I included as a screenshot above, you would have already deduced that narrative attribution is not going to do a better job of attributing credit than simplified attribution.

Just how long would the story be for that same book? It would be pretty long! So, how do we deal with this? Surely no one would read that story either? Good point! This is where I believe transient attribution comes into play.

Transient attribution is the recognition that large complicated works take a long time to make. In the case of software, the job pretty much never ends. A software must be updated to add features, or it may need to be refactored, updates needed for security fixes, or to meet the needs of new versions of operating system…it just doesn’t stop. That could mean that we just keep adding to the story, making it longer and longer as we go. But I would like to suggest another approach. I think it is more interesting if we were to tell only the story of the last phase leading up to the current version of the book / movie / software etc…there is really no need to tell the whole story all in one go…break it up into smaller parts. Learn to tell the story as it evolves. The software world already, kind of, does this in Release Notes. We commonly include Release Notes that document the differences between the previous and latest versions of the software. It is, in a way, the story of the software, but it is not the story of the people. Why not adopt this model for attribution too? Focus on the latest part of the story and call people out and celebrate their contributions for this most recent phase.

My recommendation is this:

  1. use narrative attribution to credit people for their work
  2. tell a story that says something about what they did
  3. use transient attribution to tell the story in smaller, more timely, pieces
  4. ensure the story travels with the software (ie. stored in the repo)

It doesn’t feel like such a stretch. It’s not that difficult to do either. The point is, software takes a long time to make, happens in stages, and different people with a diversity of skills come into play at different times. Let’s celebrate all the people that made it happen, and celebrate this as closely as possible to the moment they did the work. Further, the story of how a software is made is far more valuable to everyone than a simple naming of names. If we could take this short step (and it is not far) I think we would have richer attribution, happier communities, and a richer understanding about how software is actually made. And that, if you ask me, is a good thing.

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.”

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.

The Anti-Collaboration Alliance

Three factors have colluded to extinguish the value of collaboration in text production:

  • copyright
  • romanticism
  • marketing

These factors work towards preserving the idea of an ‘author’ as a solitary, elite constructor of literature.

There are a bunch of people that have written about the myth of the solitary author-genius. Most notable are Jack Stillinger (Multiple Authorship and the Myth of Solitary Genius) and Martha Woodmansee and Peter Jaszi (The Construction of Authorship). The second work is an edited anthology and much more readable than the first, however both are worth checking out.

Reading these texts, it is easy to picture the perfect alliance of forces designed to promote a simplified attribution and at the same time diminish the idea of collaborative production with all its sticky complexities and apparent contradictions.

The creation of copyright was not only a significant moment of establishing the results of intellectual endeavours as property, it was also a moment of penning into statutes the notion of the single Author.

So dominant is the belief in solitary authorship, there is little chance anyone will listen to a deconstruction of the myth. Any protests against notions of authorship will be shouted down or met with lots of arm crossing and ankle locking. Personally, that kind of response energises me – it suggests there is something very valuable to explore.

And that is the real shame of all this arm crossing – not that the myth of authorship is somehow ‘evil’ in any sense of the word. I don’t agree with IP as it has been constructed, sure, I also don’t believe in solitary author-genius, but nothing about that myth is inherently ‘bad’…in fact, it is quite enticing to believe in these super-human genius authors, here to shed light on our otherwise murky human experience. What is a shame, however, is that this myth has obscured and denigrated the value of collaboration. That is the real loss. We are immature collaborators – we do not possess a vocabulary for about talking the thing we do every day – collaborate. We do not have nuanced understandings of the value of different forms of collaboration around a text. We also do not understand why certain forms of collaboration work in one context and fail in another. We blunder through collaborations, missing huge opportunities to put collaboration under the lens and scrutinize it.

That is what this perfect storm of copyright, romanticism and marketing has done to us. We cannot harness effective collaboration because we are blind to it – we literally do not see it where it occurs and without seeing it we cannot understand it or leverage it.