Tag Archives: open-source

Pointing out my Dissertation

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.

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

Advertisements

Attention, Attention! This is the First Post

In a first post, I thought that I should properly introduce myself, my background and all the reasons that I have to do what I do as a sociologist studying technology development. But maybe next time. It seems the best way to explain myself is to jump directly into what is going on with me as a sociologist in the wild (pun intended).

I spent most of this week in Vienna on a conference called European Meetings on Cybernetics and Systems Research. There, I had the pleasure of being a co-chair of the Symposium on Sustainability, Ethics and the Cyberspace. It is not surprising that one of the focal points common to many contributions to the symposium was the issue of privacy and surveillance. Judith Simon, one of the authors participating in this symposium gave an interesting TED talk on the agency of things in today’s world and on the practice of epistemic hacking as a form resistence to surveillance. Definitely worth checking out.

In my talk, I focused on how open-source software development can be seen as a practice of knowledge production and on what distinguishes it from science, another form of knowledge production that has been claimed to be similar in certain ways to open-source. On top of that, I utilized some of the observations I made when writing documentation for the Pitivi video editor. Given the transparent environment of an open-source project, it seems that attention and its allocation plays vital role in what will result from the development process.

In the acedemic world, this isn’t exactly something new. Already in 1997, Michael Goldhaber came with the idea of attention economy, an economy in which attention is considered the single most important resource. As is the case with most of the manifestos proposing a completely new outlook on the world around us, Goldhaber went as far as to insist that the new attention economy will soon replace the old one based on money. This can be seen as an over-exaggeration, but today, one can see that what is taking place on the internet is a case in point.

And how does this apply to open-source software development? I guess that to the people having experience with this form of work, the importance of attention (and the decisions where to spend it) also isn’t something new. But things get interesting when we take a step back and ask the following questions: Are there shared ways to allocate attention in open-source projects? Are there established norms and common practices for that? Can tools and platforms used in the projects be considered as standards of channeling attention?

Based on these questions we can try to make comparisons of attention allocation e.g. between small and big projects, successful and discontinued, community and sponsored, you name it. But that is getting ahead of ourselves. What is important is not simply pronouncing that attention is somewhat important in open-source software development and be done with it, but to show how exactly this is happening and where are the differences among particular cases that could have the potential to explain their variability. This is the problem that I want to tackle with my dissertation thesis.