In the process of preparing the presentation, I returned to thesis and delved into the material in a way that I haven’t done since I wrote it. It was interesting to see how my own ideas have developed in the light of what I have learned and worked with since finishing two years ago. So I’ve continued working on the presentation even after the conference, annotating and adding to it, and making a more visual, more updated and – hopefully – more easily approachable version of my thesis than just the raw PDF of the whole thing that I’ve showed so far:

Oh, and if you read it – please let me know what you think can be improved. One big part is probably killing some more darlings, so tell me which parts didn’t work for you.

As Kelty argues, we’ve been drowning in explanations of why Free Software has come about, while starving for explanations of how it works. Thus, Kelty’s focus is on the actual practices of Free Software and the cultural significance of these practices in relation to other aspects of our lives.

Kelty’s main argument is that Free Software communities are a recursive public. He defines a recursive public as a public “whose existence (which consists solely in address through discourse) is possible only through discursive and technical reference to the means of creating this public.”

It is recursive in that it contains not only a discourse about technology, but that this discourse is made possible through and with the technology discussed. And that this technology consists of many recursively dependent layers of technical infrastructure: The entire free software stack, operating systems, Internet protocols. As Kelty concludes:

The depth of recursion is determined by the openness necessary for the project itself.

This is a brilliant observation, and I agree that the notion of a recursive public goes far to explain how the everyday practices and dogmatic concern for software freedom is so closely intertwined in this public.

The book is divided into three parts, each part using a different methodological perspective to examine the cultural significance of Free Software.

The first part is based on Kelty’s ethnographic fieldwork among geeks and their shared interest in the Internet. I found this to be the weakest part of the book. His ethnography does not cover the actual practices of Free Software hackers, but rather on the common traits among Internet geeks, which certainly supports his argument (that they’re all part of a shared recursive public), but doesn’t give a lot of depth to understanding their motives.

The second part is based on archive research of the many available sources within the various open source communities. In my opinion, this is the best part of the book with both deep and thorough analyses of the actual practices within free software communities, as well as vivid telling of the pivotal stories of “figuring out” the practices of Free Software.

The final part is based on Kelty’s own participation (anthropologist as collaborator) in two modulations of the practices of Free Software in other fields, the Duke University Connexions project, and the Creative Commons. These are stories of his own work “figuring out” how to adapt Free Software practices in other realms. These practices are still in the process of being developed, experimented with, and re-shaped – like all Free Software practices. And this part gives a good idea of what it feels like to be in the middle of such a process, though it offers few answers.

Being a completely biased reviewer, I’ll stop pretending to do a proper review now, and instead focus on how Kelty’s analysis fits with my own study on the Ubuntu Linux community. Kelty argues that there are five core practices, which define the recursive public of Free Software. Kelty traces the histories of “figuring out” these practices very well, and I’ll go through each in turn:

Fomenting Movements
This is the most fuzzy on Kelty’s list of five core practices. I understand it as placing the software developed within a greater narrative that offers a sense of purpose and direction within the community – “fomenting a movement” as it were. Kelty has this delicious notion of
“usable pasts” – the narratives that hackers build to make sense of these acts of “figuring out” after the fact.

In my research, I found it very difficult to separate these usable pasts from the actual history within the Free Software movement, and my thesis chapter on the cultural history of Ubuntu bears witness to that. So I am very happy to see that Chris Kelty has gone through the momentous task of examining these stories in detail. I find that this detective work in the archives is among the most important findings in the book.

Sharing Source Code
A basic premise of collaboration is shared and open access to the work done – the source code itself. The crux of the matter being giving access to the software that actually works. Kelty tells the story of Netscape’s failure following its going open source with a telling quote from project lead Jamie Zawinski:

We never distributed the source code to a working web browser, more importantly, to the web browser that people were actually using.

People could contribute, but they couldn’t see the immediate result of their contribution in the browswer that they used. The closer the shared source code is tied to the everyday computing practices of the developers, the better. As Ken Thompson describes in his reflections on UNIX development at AT&T:

The first thing to realize is that the outside world ran on releases of UNIX (V4, V5, V6, V7) but we did not. Our view was a continuum. V5 was simply what we had at some point in time and was probably put out of date simply by the activity required to put it in shape to export.

They were continually developing the system for their own use, trying out new programs on the system as they went along. Back then, they distributed their work through diff tapes. Now, the Internet allows for that continuum to be shared by all developers involved with the diffs being easily downloaded and installed from online repositories.

As I point out in my thesis, this is exactly the case with the development of the Ubuntu system, which can be described as a sort of stigmergy where each change to the system is also a way of communicating activity and interest to the other developers.

Conceptualizing Open Systems
Another basic premise of Free Software is having open standards for implementation, such as TCP/IP, ODF, and the world wide web standards developed by the W3C – all of which allows for reimplementation and reconfiguring as needed. This is a central aspect of building a recursive public, and one I encountered in the Ubuntu community through the discussions and inherent scepticism regarding the proprietary Launchpad infrastructure developed by Canonical, the company financing the core parts of the development of both the Ubuntu system and community.

Writing Licenses
Kelty argues that the way in which a given software license is written and framed shapes the contributions, collaboration and the structure of distribution of that software, and is thus a core practice of Free Software. Kelty illustrates this by telling the intriguing story of the initial “figuring out” of the GPL, and how Richard Stallman slowly codified his attitude towards sharing source code. This “figuring out” is not some platonic reflection of ethics. Rather, it is the codifying of everyday practice:

The hacker ethic does not descend from the heights of philosophy like the categorical imperative – hackers have no Kant, nor do they want one. Rather, as Manuel Delanda has suggested, the philosophy of Free Software is the fact of Free Software itself, its practices and its things. If there is a hacker ethic, it is Free Software itself, it is the recursive public itself, which is much more than list of norms.

Again, almost too smartly, the hackers’ work of “figuring out” their practices refers back to the core of their practices – the software itself. But the main point that the licenses shape the collaboration is very salient, still. As I witnessed in the Ubuntu community, when hackers chose a license for their own projects, it invariably reflected their own practices and preferred form of collaboration.

Coordinating Collaborations
The final core practice within Free Software is collaboration – the tying together of the open code directly with the software that people are actually using. Kelty writes:

Coordination in Free Software privileges adaptability over planning. This involves more than simply allowing any kind of modification; the structure of Free Software coordination actually gives precedence to a generalized openness to change, rather than to the following of shared plans, goals, or ideals dictated or controlled by a hierarchy of individuals.

I love this notion of “adaptability over planning”. It describes quite precisely something that I’ve been trying to describe in my work on Ubuntu. I used Levi-Strauss’ rather worn duality between the engineer and the bricoleur to describe part of this, but I find Kelty’s terms to better describe the practice of collaboration on a higher level:

Linux and Apache should be understood as the results of this kind of coordination: experiments with adaptability that have worked, to the surprise of many who have insisted that complexity requires planning and hierarchy. Goals and planning are the province of governance – the practice of goal-setting, orientation, and definition of control – but adaptability is the province of critique, and this is why Free Software is a recursive public: It stands outside power and offers a powerful criticism in the form of working alternatives.

As Kelty points out, the initial goal of these experiments wasn’t to offer up powerful criticism. Rather, the initial goal is just to learn and adapt software to their own needs:

What drove his [Torvalds'] progress was a commitment to fun and a largely in articulate notion of what interested him and others, defined at the outset almost entirely against Minix.

What Linus Torvalds and his fellow hacker sought to do was not to produce “a powerful criticism” – those almost always come after the fact in the form of usable pasts to rally around – rather, their goal was to build something that would work for their needs, and allowed them to have fun doing so.

I find that this corresponds very well to the conclusion of my thesis: that the driving goal of the Ubuntu hackers continues to be to build “a system that works for me” – a system that matches their personal practices with the computer. A system that is continually and cumulatively improved through the shared effort of the Ubuntu hackers, each adapting the default system to his or her own needs, extending and developing it as needed along the way. As Kelty writes in his conclusion:

The ability to see development of software as a spectrum implies more than just continuous work on a product; it means seeing the product itself as something fluid, built out of previous ideas and products and transforming, differentiating into new ones. Debugging, in this perspective is not separate from design. Both are part of a spectrum of changes and improvements whose goals and direction are governed by the users and the developers themselves, and the patterns of coordination they adopt. It is in the space between debugging and design that Free Software finds its niche.
(…)
Free software is an experimental system, a practice that changes with the results of new experiments. The privileging of adaptability makes it a peculiar kind of experiment, however, one not directed by goals, plans, or hierarchical control, but more like what John Dewey suggested throughout his work: the experimental praxis of science extended to the social organization of governance in the service of improving the conditions of freedom.

In this way, Free Software is a continuing praxis of “figuring out” – giving up an understanding of finality in order to continually adapt and redesign the system. It is this practice of figuring out that is the core of cultural significance of Free Software, as we continue to figure out how to apply these learnings to other aspects of life. Kelty does well to describe his own efforts “figuring out” in relation to non-software projects inspired by Free Software practices in the final part of the book. Though these reflections do not come across as entirely figured out yet.

All in all, it is a brilliant book. But given its Creative Commons license, it poses an interesting challenge to me: Remixing – or modulating, as Kelty calls it – the book with my own work (and that of others – like Biella) to create a new hybrid, less tied up in the academic prestige game.

(Maybe then I can change the title, because that continues to annoy me: Why is it called Two Bits? Apart from the obvious reference to computing in general, it doesn’t seem to have any other relevance particular to Free Software?)

Since I joining Socialsquare, I’ve been working with all sorts of aspects relating to communities online, and it’s been great to return to that the my work on the Ubuntu Community and see new ways to extend my old analyses and apply them in new contexts. But most of all, I’ve come back and found just what a good framing the Community of Practice is for understanding online communities, and I hope to learn a lot more on how to apply it from the CP Square community.

Parties that are successful bring the right number of people together. Those people end up having a good time and having fun. They will hopefully come for whatever their purpose is and achieve that sort of goal (having fun, learning, meeting people, etc.). When people achieve their particular goals and have fun, they leave feeling happy.

Good parties almost always have good hosts. It is their job to keep the size of the space appropriate for the number of guests, plan the party, get people involved, and keep things rolling. The host not only needs to be the organizer of many things, but sometimes the life of the party and cheerleader. Sometimes this is is necessary, but not always.

One or two bad guests can ruin a party and make it miserable for almost everyone. A space that is too large or too small for the number of guests can make for a bad party. A party with a terrible host will likely be bad. Sometimes parties are really great or really bad for no apparent reason.

Now replace every use of the word party with community, every use of the word guest with member, and host with community leader.

Lee LeFever, who probably first made up the metaphor, lists all the ingredients which a good party and an active online community have in common. Unsuprisingly, his conclusion is simple:

In the end, if you’re truly interested in online communities, the most important ingredient is you. Without people who care about the community and are willing and excited about making it work, it will not succeed.

This sounds misleadingly obvious, but in my experience, it’s true. The open source projects that I’ve taken part in all work hard to maintain a solid focus on what they have in common and how to have fun doing it. Ubuntu uses a Code of Conduct to ensure the good intentions of its participants, while two Subversion developers have made a very successful talk on “How Open Source Projects Survive Poisonous People (And You Can Too).”

Concerns which are very similar to those of discotheque managers and bouncers. And I suppose the tools of kicking and banning aren’t really that dissimilar…

You can download the abstract, or the full 2.9 MB PDF file.

I’ve released it under a Creative Commons license so that everybody is most welcome to redistribute it and add their comments.

EDIT: My webhost removed the file due to excessive load. But it is now back on-line.

The thesis is now also mirrored at AsianLinux.org thanks to kind help from Anand Vaidya.

And at Software Libre Rudd-o thanks to Manuel Amador. So please use one of those mirrors in case of any further issues with my webhost.

“Free Software and Open Source are the same. What difference there used to be between the two is now deprecated. When we first began working on the term ‘Open Source’, Eric Raymond was afraid that IT companies couldn’t deal with Richard Stallman, and thus it would be necessary to distance ‘Open Source’ from Richard and Free Software. But it turned out that the companies have no trouble relating to Richard. They do indeed take him seriously, which became quite apparent during the drafting of the GPL version 3 where several big companies took part in the process. So there is no longer any need to differentiate between the two.”

Bruce Perens has launched into his talk at the Danish Unix User Group, and he immediately touches upon the issue for which he is best known: the definition of Open Source, and his role as a mediator between two of the other big men within the free software community, Richard Stallman and Eric Raymond whose eccentricities and disagreements have become the stuff of legend.

As he notes, Stallman often refuses to give talks where people are using proprietary software, instead offering to “defenestrate the computer” – that is: remove Windows from it (and, presumably, install a suitable free replacement).

Compared to those two, Perens appears as one of the more sensible, pragmatic free software advocates. Usually, he does not attract as much attention as the others, and no more than 30 people have showed up this Monday night to hear the Copenhagen stop in his whirlwind tour of talks around Europe.

Most of these talks are given to various government institutions and policy makers who are considering their stance on free software, software patents, or with open standards, or with the GPL version 3.

Perens obviously gets a lot of practice doing public speaking and he sprinkles the relevant technical and legal expositions with some interesting anecdotes while remaining patient and interested in the questions that appear along the way. He comes across as a sage passing on the growing tradition of free software activism, telling us how to learn from past mistakes and seeking to amend previous wrongs – such as the divide between open source and free software.

His talk is called “Innovation goes public” and it is basically Perens’ interpretation of how the free software advocates should go about introducing the core ideas of free software to policy makers, corporations and other non-technical parties:

“You know how newscasters used to report from a crime scene, saying “The police suspect it is the work of a lone isolated nut”? Well, with the Internet, there are no more isolated nuts! The nuts can easily go on-line and find 50 people who share the same obscure interest. That’s basically how Open Source development came about!”

Perens compares this with the way that old people have embraced the Wikipedia. He has found that there many retired professionals with plenty of time on their hands and no one to receive their no-longer active knowledge, so they begin adding that knowledge to the Wikipedia, finding new communities of shared interest in that way.

But the main point of his talk is how free software compares favourably to proprietary software in that it makes economic sense. He argues that companies should examine their use of software and find out which software they use is the differentiating factor setting them apart from their competitors. For the Amazon bookstore, that factor is the recommendation system which boosts their sales remarkably.

Perens notes that, generally, a company’s differentiating software is less than 5 % of all the software they use. Thus it will make sense to them to keep that 5 % percent proprietary and develop that as they have so far, but to use Open Source for everything else, since those 95% of their software is infrastructure such as web server and operating system software which isn’t giving them any vital advantage over the competition, and thus, it can be developed in an free software fashion, giving all of the companies greater rewards compared to the amount of development they invest.

Thus, Perens explains, the Amazon bookstore uses free software such as the Apache web server, the PHP scripting language and the MySQL database which cost them nothing, and enables them to get custom made development done in-house or by others as they may need it. Thus allowing them to reduce cost and focus on what they actually sell. That is: books.

I quite enjoyed the talk, which lasted almost 3 hours as Perens expanded his scope to touch upon more and more topics. I wonder how he fares with a less geeky crowd, but he certainly was hit here. Make sure to go see him if talks at a LUG near you.

Since I began writing my thesis, I’ve had this as my background screen on my computer:

‘Going Native‘ is losing your reflexive anthropological distance by becoming to closely involved with the field. It is taking on some of the cultural traits of the people you study, eventually reaching the point where you can’t even tell yourself apart from your informants.

Naturally, this is a bad point of departure for writing serious anthropological analysis, and I needed that daily reminder not to jump back in to the digital conversation flow on IRC and mailing lists and continue my direct involvement with Ubuntu, which would make writing this thesis so much harder (and most likely make the end result even worse that it has turned out..)

So I left the Ubuntu community for a while, longer than anticipated, actually, as it seems that Parkinson’s Law (stating that “work expands so as to fill the time available for its completion”) remains in effect.

Thus, I won’t be able to defend my thesis until late August because the University of Copenhagen summer break in July. And similarly, I won’t have time to make my thesis available on-line until then, partly because the people I quote in the thesis need to have a chance to read and approve of the data I make public, partly because I will be on summer holidays almost continuously until the 27th of July, and partly because my computer died recently, leaving me with little means of working on the go.

But as a little (tiny) appetizer, here’s the front page:

Later on, I hope to sum up some of my experiences writing this thesis. I haven’t really been very good at posting updates on how my writing has progressed, but I suppose that is in part due to the thesis tunnel vision that sort of blocks out everything else.

Until then, enjoy the summer!

I think Debian is a tremendously interesting case when it comes to understand human cooperation. Because, not unlike what Eric Raymond pointed out long ago, there is the “Bazaar” of Debian, the heterogeneity of the network. And there is the “Cathedral” of it: The ability to structure the large amount of work to the degree that you can slip a Debian DVD into a Windows-computer, and turn it into a Debian computer in less than an hour. How far can you take this mix of “cathedral” and “bazaar”? How much bazaar can you have before it forks, and how much central control can or must you enforce upon the network? How can you build a system that enables the “beauty of (hacking) mankind” to simply do good, and/or how much must you invoke something like the (partly fantasy figures) of the Ubuntu-Launchpad and the Debian-Cabal?

This much-discussed question of centralization connects well with the stated goal of World Domination that many Free Software communities state again and again in a typical “ha-ha, only serious” fashion.

Global domination is a centralistic quest to compete with the cathedrals of Windows and Mac OS, and to do this while maintaining the freedom of learning and technical exploration that is the essence of Free Software will inevitably be a balance act. It is one that all Linux distributions are performing with various degrees of success.

One way is, as Canonical proposes, to let companies define the supported Free Software that the end user might need, and guarantee that it is available and that it “just works”. Thus creating small pools of centralization – the specific traits of Ubuntu – merging with the larger decentralized pool of shared knowledge within the bazaar – Debian Unstable every six months.

Mark Shuttleworth describes this relationship as Debian as “the Tibetan Plateau of the free software landscape” upon which Ubuntu is built:

By contrast with Debian’s Plateau, Ubuntu is a cluster of peaks. By narrowing the focus and allowing the KDE, Gnome and server communities to leverage the base of Debian without treading on one another’s toes, we can create a K2, and a Kangchenjunga and a Lhotse. Ubuntu’s peaks depend on the plateau for their initial start, and their strong base. Ubuntu needs to be humble about its achievements, because much of its elevation comes from Debian.
[...]
Many people have asked why I decided to build Ubuntu alongside, or on top of, Debian, rather than trying to get Debian to turn into a peak in its own right. The reason is simple – I believe that Debian’s breadth is too precious to compromise just because one person with resources cares a lot about a few specific use cases. We should not narrow the scope of Debian.

At last year’s DebConf, a talk compared Ubuntu’s use of Debian to shopping at a supermarket, a one-stop shopping for your free software needs. This innocent analogy sparked a lot of discussion, with many of the Debianistas arguing that this reduced Debian to a giant collection of un-integrated software – which wouldn’t be very interesting at all. As Debian Developer Joey Hess put it:

My main motive for contributing to Debian is to make Debian the best distro I can; I don’t mind if others use that work, especially if stuff gets contributed back. But it’s long been clear to me that the most important added value to Debian is not adding another package to the shelf, but finding new ways to integrate our software together. When you’re working mostly above the level of individual software packages, to have your work mostly appreciated on the basis of “component contained in Ubuntu” is not very motivating.

Integrating and creating a universal distribution is still a central motivation for many Debian developers, who may find that Ubuntu is not only stealing their thunder but also compromising their ideals, again with no small amount of distrust towards the dealings of the opaque corporate entity that is Canonical.

But as Shuttleworth also notes, that when you seek narrow goals, it will come at the cost of openness and democracy. The Debian community is obviously unwilling to make such a trade, and as such, must look elsewhere for inspiration on how to organize themselves towards their goal.

Taking a cue from an earlier comparison of the Free Software communities to the scientific communities, I think it would be worthwhile for Debian to leverage their solid technical infrastructure towards becoming commonly agreed upon open standards to allow the exchange of knowledge and code will be possible on equal terms. In that way, I think that Debian is quite well poised to become a sort of “research library of Free Software” – collecting the “monographs” and “articles” of code, cataloguing and organizing them for easy and open access.

Almost all Debian developers, and apparently 76 % of all Debian users,use Debian Unstable or Testing.

Debian Unstable, codenamed Sid, is the latest, most volatile version of Debian, where new packages are uploaded to, and changes to old packages are added on a daily basis. It contains all of the latest releases of the upstream communities, packaged and categorised. Debian Testing contains all of the packages that haven’t had a critical bug filed against them after spending 10 days in Unstable.

Only 24% of the Debian users use Debian Stable, since the releases are so rare as to only come out every 2 or 3 years – much too rarely to keep up with all the latest hardware and desktop applications, making Debian Stable relatively unattractive in the long term.

Since Debian Unstable (or Testing, for the less adventurous) fulfills the needs for both the users and the Debian developers, there is little incentive to make an Upstream Version Freeze and actually get a new release out, and since Debian is solely based on volunteer work (with suggestions to pay release managers meeting fierce opposition), bug fixing and release deadlines aren’t enforced that well, further slowing the actually release of the Debian Stable.

As Shuttleworth points out, Debian Unstable is “not subject to the same political tradeoffs that are inevitable when dealing with releases, architectures, dates, deliverables, translation, documentation and so on.” – it is the core strength of Debian.

As the developers I interviewed said again and again when asked what they get out of contributing to Free Software projects like Debian: “I get a system that works for me.” To some extent I think that is what Joey Hess’ means when he says that his main motivation for contributing is “to make Debian the best distro I can.”

Debian Unstable is not merely about keeping software up to date, but also about improving it, further integrating it within the Debian infrastructure. It is a research library in the way it is not only focused on gathering knowledge, but also on using it. It is also a laboratory where Free Software is shared and combined in new and interesting ways.

Maybe that would the most fitting analogy to what Debian really is: A research library containing all of the Free Software that lives up to set strict criteria. Offering all the development tools, libraries and applications up-to-date for new experimentation.

This would fit well with the Lars’ counter-argument:

Science is (also) extremely disunified (there are 22.000 different medical journals in the world. “Medicine” (in singular) is known by no-one). And “science” can live with this relative disunity. Can Debian? There is at least one difference: “Debian” as a whole must occasionally come together to produce a release. A release which is unified enough for a computer to work. Fuzziness is simulated by computers, because they work only by strictly separated ones and zeroes. The knowledge of Debian, packed together as a release is pretty much a unity. A unity of which a large degree of coherence is required. The knowledge of science may be unified in an encyclopaedia, but, metaphorically, the discrepancies and glitches of that body of knowledge is so enormous, so “buggy”, that it would make any computer halt very early in the boot.

Much like the knowledge of science only can gathered for release in an encyclopaedia that is outdated before it is even published, all of the software within Debian will also be outdated by the time it is released. Perhaps Debian should take inspiration from Wikipedia rather than other Linux distributions.

Wikipedia is a reservoir of such diverse knowledge that it would never be in a position where it could be published in paper form. It would require an insane amount of work, flamewars and unhappiness for all involved. It would require a centralization that simply is not present in the Wikipedia community.

But in spite of this, by far the biggest part of Wikipedia is eminently usable and accessible at any given time. As is Debian Unstable.

Perhaps the Debian community should take some comfort in this.

Risan raises some relevant issues that have received much discussion within the Free Software communities around Ubuntu, namely: What is Canonical’s intended purpose with Launchpad, and why isn’t it Free Software?

He finds that the main lines of argument revolves around the fact that Launchpad is Canonical’s flagship investment, and that the promises of freeing the Launchpad source code will only be kept once Canonical has secured the market for Open Source infrastructure, and that Canonical much like Google seeks to trade in free web services to profit from the unhindered access to the data – the translations, source code, bug reports, specifications and support tickets handled by the system.

While Mark Shuttleworth’s reply to these claims emphasizes that he has no problem if people prefer to use something like Pootle instead. And he concludes:

One thing I can say, though, is that a web service (or even a remote app service) can never create the same level of pain that a proprietary OS can do. Having watched what Microsoft has done, I’m largely motivated by a desire to ensure that countries like South Africa never have to pay a tax like that again.

And that’s fine. Like Google, Launchpad is intended to provide a service which you can choose to use or not. But as Risan points out, the service still isn’t very good. In his case study of how Rosetta works, he concludes:

At the moment, then, Rosetta seems not to be Adding Value ™. It is just adding mess. Neither is it evil. It is just bad.

As Risan does well to show in his paper, it is not a matter of whether Rosetta technically offers the necessary capabilities, but rather whether the infrastructure can work with the various upstreams – in Risan’s case the Norwegian translators of KDE – to make sure the latest translations are available in distributions like Ubuntu which depend on Launchpad for its translations.

The problem is that with Risan’s translations, Rosetta has simply supplanted the Norwegian KDE translators as the translation upstream, thus actually segregating the community rather than uniting it. And the reason for this may exactly be the Norwegian KDE translators’ hesitancy to drop Kbabel and other tools for Launchpad and Rosetta – a platform which many Free Software developers still do not entirely trust, nor will be willing to use until it becomes Free Software itself, or at least until it becomes so good that it would be too much work to build an alternative – like Google.

In this way, the adoption of Launchpad continues to be slow, not because of any bad intent from its architects or lack of interest from its potential users, but because it has been built without consideration for the social connections within and between Free Software projects.

Indeed, Launchpad is often described as seeking to “automate social connections between projects” so that patches and data can be exchanged as smoothly as possible with a minimum inter-community flame-wars (this fits quite well with Ubuntu’s relationship to Debian, where a number of developers continue – rightly or wrongly – to be unhappy with the patches that Ubuntu send back upstream).

When the project started, the Launchpad developers mapped out all the software repositories of the Free Software world and linked them together, but they did not map out the flow of information between these repositories or how its active inhabitants collaborate. Thus Launchpad does not reflect how the upstreams work, limiting their willingness to adopt it, and since they can’t customize it to fit their needs as they would otherwise do – the source code is still unavailable, after all – they simply stay away.

Unlike Google – whose services generally are so easy to use that they require little or no customization, Canonical’s Launchpad is a intricate behemoth of details. Even core Ubuntu developers who use it everyday do get lost in the system from time to time. It cannot be optimized for a single use case, since Free Software projects, though they appear much alike, have subtly and vastly different ways of collaborating – both due to community structures and dynamics, but mostly because of the many different tools they use.

Having the data is not enough. Understanding and incorporating the work flow of the upstreams is also necessary. And nobody will be able to do that better than the upstreams themselves.

This constant negotiation between the technical and the social is the main theme of my thesis, and though I can’t delve into the entirety of Launchpad, I do hope to elaborate further on some of these ideas about the role of technical infrastructure in Free Software projects.

“You’re just using their categories, the way that they talk about things. You don’t really write about the differences in what they say they do, and what they actually do!” he continued. And I sat there nodding, mumbling “’spose so”, not only feeling shamed for being accused of forgetting the basic tenets of anthropology, but even more so boiling with frustrated anger: What! I’ve worked hard at this! This report is the first concrete result of 7 months of fieldwork and 3 months of preparation before that! Don’t tell me what I know about this community!

But of course, he was right. He wasn’t doubting what I know or how I came about that knowledge. He was merely pointing out that it did not seem as if I had reflected very much on this myself. To him it seemed as if there had been a point in my fieldwork when I had begun to understand the inherent rules, ideals and social structures of the Ubuntu community so well that I had begun to take them for granted. That I had basically gone native to some extent, and that it would not be enough merely to take me out of the field, but also begin to take the field out of me.

I’ve only been out of the field for a few weeks, but even so, I still bring it with me on my computer. I’m still subscribed to lots of mailing lists, I still hang out on various IRC channels, read a lot of Planets, get bug mail and mails on wiki updates. I’m basically in touch with and exposed to the community all the time, even though I’m supposed to stop gathering data and start analyzing it. And as long as I keep these ties, I will inhibit my own reflective distance as an anthropologist.

As I’ve participated in this community, I have met so many passionate people with so much enthusiasm that it has been impossible not to be smitten by it. This passion is what has helped me to contribute and become so involved with the whole project, and naturally it is also what will make it so hard to leave the Ubuntu community, and the net of on-line communications which it consists of, behind for a while.

Yet that is what I’ll have to do in order to be able to reflect on all that I have learned, seen, and participated in over the last 10 months, I will need to leave the communication channels that the Ubuntu community consists of.

Today Ive unsubscribed from all the Ubuntu mailing-lists, logged off the IRC channels, stopped the wiki page-updates, unsubscribe the Planet RSS feeds, and step down from the Launchpad. I will divert my attention capital elsewhere, to my books, my fieldwork notes and my thesis, but it does not mean that I will stop using Ubuntu or encourage others to do so. I’d like to think that I can still share a bit of the work that happens in the community by using and sharing the system itself.

It’s been really great meeting all of you Ubunteros. You are some of the sweetest, most dedicated and geekiest people I’ve ever met. And I do feel honoured to have gotten to know all of you. I will keep my blog on the Planet Ubuntu, but only posts related directly to Ubuntu will appear here. I do plan to come back to the community once my thesis is done and my university obligations no longer conflict with my newly-found interest and passion for Free Software.

See you in 6 months’ time…