Okay, no time to prepare an appropriate build up for writing about the main concluding points of my dissertation so I will just drop the heavy stuff now and then try to follow up with some of the smaller points later on. There are two main points I will write about today and I will try to make the result as clear and concise as possible, but taming that 200 page beast is not easy. So please bear with me.
1. In FOSS, ownership has been redefined and is closely related to knowledge.
Let’s start with a claim that is common among the FOSS movement: with proprietary software, the user is only licensed to use the software. He or she cannot see how it actually works, let alone alter it or redistribute it. As a result, users don’t actually own what they buy, ownership is reserved exclusively for companies that develop and provide the software. In opposition to that, free and open source software licenses supposedly let anyone own the software by denying the restrictions to source code availability, modification or redistribution. If you want something more than my sweeping description, you can hear it from Stephen Fry himself:
This is where it usually ends, but this is also where I actually start. How can we talk about ownership if the rights traditionally associated with it are purposefully reversed by the copyleft or liberal licenses? Don’t be afraid, I will not argue that FOSS is some kind of communism. Instead, I will argue that in FOSS, ownership is not defined by legal agreements or licenses (this is not to say they are not important! They need to be in place in order to constitute an environment in which they don’t matter — how nicely paradoxical), but by knowledge intensive practices.
We get into a situation, where reading, modifying and redistributing source code (the exercise of basic ownership rights) is not restricted by license or a legal agreement. Anyone can contribute, right? But on the other hand, we can see that only a narrow group of people actually participate long term on the practices associated with ownership rights. Are those people the new “owners” of the source code? And if so, what qualifies them to such position?
The new owners are the ones who have been able to overcome the so-called entry barrier and worked to establish their position among the development team. To overcome the barrier, they had to develop knowledge of everything that goes into the software development practice: tools (text editors, version control systems, build systems, etc.), environment (libraries or other dependencies, similar/competing software, etc.) and the codebase itself. This is nothing trivial, in fact, Chris Granger once wrote that enjoying programming with all its complexities is a kind of masochism. In any case, it represents a substantial investment of effort exerted over a long period of time, typically by solving piecemal tasks.
In this sense, ownership is earned by overcoming the barrier. Those who succeed in overcoming it continually practice the rights originally associated with ownership. But by following this line of argumentation, we redefine what ownership is. It is no longer exclusive, it can be performed by multiple actors at the same time, but due to the entry barrier, it is still differentiating. This is why some companies are able to make profit out of software that is, together with its source code, freely available — because they employ developers that hold knowledge allowing them to overcome the barrier and practice the rights of redefined ownership.
2. Knowledge does not immaterially operate upon itself.
After reading through the first point, it seems that knowledge is the single most important “thing” in software development. Sure, pointing out the importance of knowledge is hardly anything new — social scientists have been working with the claim that knowledge is the most important production resource since the late 1960s. More recently, this claim resurfaced as an assumption in the enthusiastic anticipations of what digital technologies can offer, spearheaded by the utopistic visions of planet-wide systems of collective intelligence. These visions are most often associated with the work of a French philosopher Pierre Lévy, but there are also others that relate the concept of collective intelligence with images of “harnessing crowds” or “creating a prosperous world at peace”. But what does this have to do with software development? Just consider this excerpt from Eric Raymond’s essay The Cathedral and the Bazaar:
That is, that while coding remains an essentially solitary activity, the really great hacks come from harnessing the attention and brainpower of entire communities.
In Raymond’s essay as in visions of collective intelligence, the good thing comes from “harnessing” many individual minds. But there does not seem to be much elaboration on how this “harnessing” takes place, we just glue minds together with some sort of technology. And it doesn’t matter much what technology it is because it’s changing all the time anyway. This tendency does not avoid even the most prominent sociologists, in fact, it seems to culminate in a peculiar claim made by Manuel Castells in his monumental, three volume work on the information age:
For the first time in history, the human mind is a direct productive force, not just a decisive element of the production system.
But what’s wrong with that? After all, isn’t mind where knowledge resides? Well, sort of. My argument is that with mind, you only get half of the equation. The second part are information (data existing outside of mind) with which the mind interacts to produce knowledge. In software development, information can take many shapes: source code of a developed program, interface of an existing one, logs, backtraces, bug reports, and the list goes on… Essentially, all of the things that add to the complexity of software development and constitute the barrier to entry I wrote about in the previous point.
It has been said that a good interface should be invisible, but that does not mean that it is not there and that someone did not design it to be functional with regard to cognitive processes. But what do we get when we place all of the emphasis on mind? An image of actors freely moving through space and swarming around problems they deem important — all of this in a very frictionless manner (what can be more frictionless than a mind directly producing something?). These images are present in social scientific concepts (self-organization, spontaneous order) and in FOSS culture (flock, anyone?) alike.
In FOSS, the image is further supported by the existence of the so-called drive-by patches, which are often highlighted more than the work of core developers (see, for example here or here). It seems that the work of the heavily involved contributors is taken for granted and is often made invisible, presumably because it does not fit in with the public image that FOSS has — the one of unlimited possibilities of frictionless movement. Because they invested so heavily into their knowledge of particular technologies, maintainers or core developers tend to stay with projects for long periods of time, spending their working hours on integrating all the drive-by patches into something useful. Should they try to switch to a different project, their movement would probably be anything but frictionless (even though with seasoned developers, a large part of learning tools and environment would probably fall off).
Here we are again with all the complexities constituting the entry barriers. If you consider knowledge to be the most important productive force and mind to be pretty much the only thing that determines it, then you end up with images of constantly reconfiguring fluid associations, which, however, are unable to grasp the solidity and stability that are also inherently present in FOSS development projects. On the other hand, by taking into consideration the environment with which the minds interact (tools, dependencies, libraries, source code, etc.), we can acknowledge also the limiting role of knowledge — that it constitutes a barrier which places individuals who overcome it on an advantageous position. And as a result, we are able to account better for the stability of FOSS projects’ cores.
And that’s it! If you have any thoughts or comments, if you think that I’m outrageously wrong or totally right, please let me know.