looking east

“every time you want to know what a nonhuman does, simply imagine what other humans or other nonhumans would have to do were this character not present.”

Bruno Latour in Mixing Humans and NonHumans Together: The Sociology of a Door-Closer, p. 299.

Inspired by this paper by Basile Zimmermann, I would like to do a small thought experiment about open source development using Latour’s citation as a starting point. It’s almost impossible to imagine open source software without nonhumans. A nonhuman is a object which plays a specific role in a certain context. For example, the remote control allows the human TV watcher to control the TV from the couch without standing up to change the TV settings from the TV itself.

To start with, I would like to create a non-exhaustive list of human and nonhuman actors in open source development. Nonhuman actors include: the developer’s computer, the servers on which the project is hosted, the bug tracking system, the code repository, the IRC channel, the project website, the mailinglist, the code files themselves, binary packages, the software running on the developer’s computer, the software running on the server, etc. Human actors are: the developer, a “community” of developers around the world working on the project, the project maintainer, the server administrator, the people who have manufactured the developer’s computer. I think you can see where this is leading. The idea is to show that a single developer sitting in front of his computer is connected to a huge network of humans and nonhumans who “help” him complete the task. Some of them, like the computer manufacturers, have played a more important role in the past, but they continue to be a part of the developers’ current work.

Now, let’s try removing a nonhuman actor. I’ll choose the most obvious one, the developer’s computer. If the developer doesn’t have a computer, how can he contribute to the open source project? In this case, the answer is quite obvious: He will have to find another computer to replace it. However, a computer cannot simply be replaced by another one as the open source software he is working on might require a specific software setup. If the developer has access to a university lab, he could go there and start setting up a computer. He might first have to ask the university’s administration, if he is allowed to configure the computer and install software. And if not, he will need to follow a procedure to receive this permission. Once he has access to the computer and set up the operating system and the required software, he could start working on the project. However, the university lab might have specific opeingn hours, and our developer will again have to deal with the university administration to receive a key to access the lab whenever he wants.

What do we learn from that? A developer’s computer can only be replaced by another computer. To really replace the computer all together, it would be necessary to rebuild a computer from scratch with all the people and technologies involved in computer production. We also see that if our developer doesn’t own a computer, he will need to go through a more or less complicated set of steps to obtain access to one.

To conclude the thought experiment, let’s imagine the code repository is not present. That means, there is no way to access the source code online, to commit to a common code base, and to obtain the latest version of the trunk. In this case, the source code could be maintained by the project maintainer. That means, if our developer wants to contribute to the project, he will first need to obtain the latest version of the code. He would thus need to write an email to the project maintainer and ask for it. Once the developer has made a change, he would need to send the code back. If the project receives code from several developers, the maintainer would need to merge the code into the main version each time. Merging the code without software means that the maintainer would first need to find out which files have been changed and then open these files and compare them line by line to see what changes have been made. Additionally, after each merge, he will need to test if the software still works as required and if the features added really did what they promised to do. These are all tasks that are generally done by the community when a source repository is present.

So, what is this post about? It’s about to show how complex open source development is, how many actors, human and nonhuman play a crucial role in it’s existence, and what impediments can occur when one or several of the actors are missing.

This entry was posted on Saturday, May 3rd, 2008 at 11:20 am and is filed under academic, computing, thoughts, open source, community, sociology, thesis.