Category Archives: Thesis Fieldwork

Thesis fieldwork

Sprinting the development

Late yesterday evening I arrived in Wiesbaden near Frankfurt am Main for the Ubuntu Developers’ Sprint. The sprint started this morning, and it is the big halfway point of the Edgy Eft release cycle. All of the Canonical-employed Ubuntu developers are gathered to recalibrate their efforts and coordinate the specifications that were approved in Paris.

The feature freeze deadline – the date when development work on new features stops in order to leave time to fix the bugs that necessarily appear – is September 7th, and is thus fast approaching. And as Canonical Chief Technical Officer, Matt Zimmerman, puts it, this is “The Reckoning. It’s time to make a decision on goals which are behind on progress, and drop goals which aren’t going to make the feature freeze deadline.”

Even though people are hard at work, the atmosphere is still rather relaxed. “Sprint” is the key word here as it is all about getting people together to have them energized and synergized for run-in of the release cycle. Getting people together for quality face time and fast-paced work is an essential part of how Ubuntu is developed.

After the sprint, I’ll be going around Germany, visiting Ubuntu developers to interview them and get a better idea of how they work in a more everyday setting. To that end, I have invested in a 3-week interrail ticket so that I can go around visiting people without having to worry too much about travel expenses. It’ll be fun!

Non-technical contributors in F/OSS projects

As a not-too-technical person, my experience with the Ubuntu community has been somewhat rocky. The few non-technical projects – Documentation, Marketing, Translation – do not get very much attention compared to the technical tasks, and those involved are nowhere as well organized as the technical teams. As fellow non-technical Ubuntu contributor Matthew Revell noted:

When trying to find a project to which I could contribute documentation, I found that I was welcome but:

a. no one really knew how to use my skills
b. the onus was on me to navigate my way round the project to find where I’d fit in
c. I was thrown in at the deep end.

Mitchell Baker, “Chief Lizard Wrangler” of the Mozilla project, has had to deal with this as well, coming to Open Source with a lawyer background. And as more non-technical people join the Mozilla Foundation, she has had to consider how these people can get to work well with the development community. The main issue is that there is no established path to meritocracy for non-technical roles:

Open source has been around for decades, and there is a significant group of engineers who participate as volunteers, and a significant group whose work involves open source projects. We know what the set of activities are that lead to acceptance and leadership. That’s no so clearly the case for the set of other activities.

She argues that the crux of the matter is trust:

Integrating non-engineering contributors takes a lot of trust and feeling our way gently. Those people joining us in non-engineering roles must trust that the technical contributors will give them a fair chance to participate, add value, become respected and gain influence and leadership. The engineering community must trust that these people who may be new to the Mozilla community and don’t have deep technical expertise are worth listening to and giving a fair shake.

She concludes:

people are effective when they are known and respected. This is the basis of shared values, community cohesiveness and continuity. It’s one of the tenets of open source software development that I believe must permeate everything we do. Our challenge is to use this approach in places where engineering “chops” aren’t a sufficient and may not be a particularly necessary criteria.

GNOME Board member Dave Neary has raised this issue in the GNOME community, and reaches much the same conclusion:

When Mitchell says that we need trust on both sides, it’s because when someone who isn’t technical asks a techie to do something for them, often the reaction is either “who do they think they are?” or “I know better”, or “show me the code”.

We need to have some way to get the first non-technical contributors heavily involved in things like release co-ordination and marketing to get that meritocracy bootstrapped. We need to trust that new people coming into those roles are capable, and trust them, until they prove otherwise 😉

He also points to the proposed Code of Conduct, inspired by Ubuntu, as a way to ensure an friendly environment that will encourage new contributors to join the community. But another challenge is to simply make non-technical people aware that they can contribute

In Ubuntu, Ubuntu Membership Process does not require technical contributions, thus stating that any contribution to Ubuntu will be valued equally. And hopefully extending the necessary trust to help developers and non-developers to work together.

But once that membership is granted, it becomes difficult to further meritocratize within non-technical contributors, whereas technical contributors can go on to apply to become an Ubuntu developer with appropriate upload rights as well as the somewhat arbitrarily administered Karma points.

As it is, upload rights and karma points are no way to distinguish between good and bad marketing or community support contributors, and it is debatable when it comes to translation and documentation contributors. And as more non-technical roles within the community appear, the situation will not improve.

The fact is that social trust in Open Source communities is earned through merit and participation, and as Ubuntu grows, this trust may be strained. I think Dave Neary’s suggestion of further integrating the non-technical contributors in the main technical processes such as specification and release planning will be essential to this. And that will require these processes to be both transparent and open, as well as considering the various non-technical teams’ relation to these main processes.

At the moment I’m drafting a document that is to be shipped with the system documentation as part of the next Ubuntu release. The goal is to make a reference guide for new or would-be community members on how to get involved in the Ubuntu community. But it is also meant to be an introduction to the tools and communication channels within the community, I hope that it will help new contributors to get an easy overview of the community structure and of how the various teams – technical and non-technical both – interact.

At the same time, I’m learning loads of stuff on community procedures, which is great for my fieldwork as well!

No man is an island

While I was pondering the Ubuntu philosophy below, I remembered the following quote which also sums up the that philosophy, but from a different angle:

No man is an island, entire of itself; every man is a piece of the continent, a part of the main. If a clod be washed away by the sea, Europe is the less, as well as if promontory were, as well as if a manor of thy friend’s or of thine own were. Any man’s death diminishes me, because I am involved in mankind; and therefore never send to know for whom the bell tolls; it tolls for thee.

– John Donne – Meditation XVII (1623)

The Ubuntu Philosophy

One of the special elements of Ubuntu which seems to work to especially attract people who are coming to Linux for the first time, is the name and the implicit South African philosophy of shared humanity and common roots. The About Ubuntu page in the Ubuntu system menu says:

A rough translation of the principle of Ubuntu is “humanity towards others”. Another translation could be: “the belief in a universal bond of sharing that connects all humanity”.

“A person with ubuntu is open and available to others, affirming of others, does not feel threatened that others are able and good, for he or she has a proper self-assurance that comes from knowing that he or she belongs in a greater whole and is diminished when others are humiliated or diminished, when others are tortured or oppressed.”
– Archbishop Desmond Tutu

As a platform based on GNU/Linux, the Ubuntu operating system brings the spirit of ubuntu to the software world.

Not only do they quote Desmond Tutu, but they also include a video of Nelson Mandela explaining the term on the Ubuntu install CD!

Both Ubuntu developers and the marketing team agree that the term ubuntu communicates what they want to achieve with Ubuntu very well: To make Linux for human beings.

But what is interesting is the way that they adopt ubuntu to fit with the F/OSS philosophy that they already share. It doesn’t appear that often, since there is nobody who are being directly “humiliated or diminished” or “tortured or oppressed” in the Ubuntu community. In fact, it is quite often almost eerily quiet in this regard. This is in part because of the Code of Conduct which is the amalgamation of the ubuntu philosophy and F/OSS philosophy – though, I guess, ubuntu is mostly indirectly represented.

Building on years of social interactions in F/OSS development, the Code of Conduct seeks to promote the positive energies in F/OSS and minimize the negative energies which often result in flamewars, trolling and the like. Time and again, the tone of an email discussion or IRC chat will go towards the personal and aggressive. But when this happens, most often people will simply refer to the CoC and the discussion fizzles.

The passion is there, but it is being kept on a leash. As Benjamin Mako Hill, the Ubuntu developer who drafted the Code of Conduct, puts it:

I think that’s it’s clear that as a community with a goal and a message (that of spreading freedom through free/open source software), it’s to our strategic advantage to not be nasty because that just makes us easier to dismiss. […]

The CoC is not a stick to be wielded — although it sometimes gets used that way. Don’t let the misuse of an otherwise very good document deter from the real point.

The CoC is a voluntary code and set of guidelines that, through explicit agreement, sets the tone for the community. If you’ve read it and think it’s a good idea, go ahead and sign it.

Whether CoC kills potentially productive discussions or merely the ones that already have gone wrong is difficult to say. Other F/OSS communities prefer the un-mediated, un-regulated atmosphere where people can shout their heads off if they want too, and some even make fun of the need for a Code of Conduct.

But it does make it easier for people who aren’t used to the often intensely passionate discussions in F/OSS communities to find their feet and get involved. Even though the Ubuntu community is growing explosively, there are very few incidents that require intervention from the governing bodies of the community.

UPDATE: The GNOME community are having serious discussions about the need for a Code of Conduct in their community. One such has been proposed, and some community members are basically asking:

“Do you really think that writing down “Be nice” makes us nicer and makes us look nicer to the outsiders?”

To which the replies so far has been:

Reply one: “That’s the funny thing – YES! Strange analogy, but even while a lot of people have lost confidence in the USA in recent times, I don’t think anyone’s forgotten about the ideas the country was built on, and that hopefully it will return to. Their dead while males wrote them down for great justice. ;-)”

Reply two: “Just reminding people nicely can make a big difference. The reminder can make people think, and a considerable fraction, after thinking, will consciously decide to follow the reminder.”

Oh, and as Jeff Waugh, one of GNOME members behind the drive towards a Code of Conduct notes about the spirit of the proposed code:

“be firm, but lighthearted – I didn’t suggest “Be Excellent To Each Other” as a joke!”

Geeky humour strikes again!

Karma in Launchpad

For some time, I have been curious about the karma system in Launchpad – the massive infrastructure being erected not only for Ubuntu, but for the F/OSS community in general.

The karma system gives “karma points” for actions which the system appreciates, like bug reporting, specification writing, bug fixing and so on. But so far, it does little with this information apart from showing who the top 5 contributors in all of Launchpad are (lower left hand corner), and show how the karma is divided up between various tasks.

Now, with so much else around Ubuntu and Launchpad, it didn’t appear out of nowhere. The karma system is obviously inspired by systems in other F/OSS communities. And I thought it would be interesting to examine how these compare to Launchpad. The two that I’ve noted (though there are undoubtedly more) is Slashdot and the GNOME Bugzilla.

In both Slashdot and GNOME, karma or bugzilla points play an important social function. It is a value of trust.

Slashdot
Slashdot karma is gained by writing insightful or relevant comments or posting interesting new stories which are moderated as such by the other readers. In turn, you can use (expend) this karma to moderate other posts as insightful or not, thus strengthening the system. If you’ve been modded insightful with +5 modifier, chances are that you will also apply that good judgement when moderating other posts, so the system gives you 5 points to mod posts where you see fit. Thus the system trusts you the more you contribute. On Slashdot, karma doesn’t have an easily accessible point value but rather vague textual identifiers such as “Terrible”, “Neutral” and “Excellent” – this is to avoid some people gathering huge amounts of karma and thus setting themselves above moderation. The Slashdot FAQ has this gentle reminder on the topic:

Karma is used to remove risky users from the moderator pool, and to assign a bonus point to users who have contributed positively to Slashdot in the past. It is not your IQ, dick length/cup size, value as a human being, or a score in a video game. It does not determine your worth as a Slashdot reader. It does not cure cancer or grant you a seat on the secret spaceship that will be traveling to Mars when the Krulls return to destroy the planet in 2012. Karma fluctuates dramatically as users post, moderate, and meta-moderate. Don’t let it bother you. It’s just a number in the database.

The GNOME Bugzilla
The GNOME Bugzilla on other hand, works somewhat differently. The stated goal of the point system is to make make each contributor’s level of experience with Bugzilla and GNOME clear in an easily accessible manner. On a typical bug report, you will see the reporter’s point score prominently displayed, and when people comment, their point score will be displayed as well.

At the GUADEC, I talked to Olav, the GNOME bugmaster and maintainer of the GNOME Bugzilla, about how the system works and what they use it for. I asked whether the point system wouldn’t encourage long-time contributors to ignore bug reports from newbies, but he explained, that quite to the contrary, these long-time contributors could spend more time on newbie bugs, because they could rely on the bug information from other people with high point-scores and thus didn’t have to triage these as thorughly. It also helps new users to see which comments are from experienced people whose advice they would do well to heed.

The Bugzilla point score is calculated from the following formula:

log_10(1 + #comments) + log_2(1 + #bugs_closed) + log_2(1 + #bugs_reported)

The point scale is logarithmic with different bases for comments (log10) and bugs closed and bugs reported (log2). That means that you need to make 10 comments to get a point, but only close 2 bugs to get another. But for the next point after that, you’ll need to reach 100 comments, or close 4 bugs. Then 8, 16, 32 and so on. This means that it gets progressively harder to gain more points as you go along.

This means that going from 0 to 1 is very easy, but already at 5 points you can be considered a proficient bug hunter. Reaching the mid-20s range like some of the core developers will require a much greater effort. So far, only one bug hunter has reached 27 points. A list of how the points are distributed among the registered Bugzilla users is quite telling.

This logarithmic increase in points almost entirely cancels out the “computer game” tendency addressed on Slashdot, but the points themselves do not easily indicate a level of expertise to newbies. 27 points doesn’t sound like much compared to Launchpad’s several hundreds of thousands of points, but when you look at the statistics behind it, it is somewhat more impressive:

Since all bug management actions are counted towards the same score, you can access the bug management information, and can thus directly see what you have done to make you point score increase by looking at the list of bugs reported/closed/commented on the contributor page.

The GNOME Bugzilla aptly uses these statistics to generate weekly reports which give an idea of the amount of work being done within the last week. There are also annual statistics list which is announced and examined with much interest among the GNOME bugsquad.

So in this way, there a two distinct set of “point values”. There’s an overall contribution to GNOME value, and there is a contribution within a set period of time (last 7 days, last calendar year). This makes it possible to represent and acknowledge the experience and contributions from each individual both in total and over a shorter period of time.

In order to solve the problem of the point score giving a level of trust that is not easily interpretable for new users, the GNOME developers have introduced that developers can register the packages they maintain so that this information will also appear on the bug report, like this:

There has also been a discussion about turning the point values into some easy-to-understand text alternative. I would imagine that they could well end up with something silly and similar to the titles of the individual class levels in Dungeons & Dragons (“congratulations, you have reached level 23 – you are now a Grandmaster of Flowers!”). One GNOME developer has even compared developing GNOME to playing online role playing games!


Launchpad

Since Launchpad is much more than just a news forum or a bug tracker, it’s Karma system needs to span over several different elements that are not easily alignable. Launchpad consists of:

Malone – the bugtracker
Soyuz – the distribution management software
Blueprint – the Specification Tracker
Rosetta – the translation software
Bazaar – the version control system
– the so-far unnamed support tracker

Each of these distinctive parts have different uses and thus offer different ways of gaining karma. Different actions add different points to your karma total. For instance, reporting a new bug gives you 10 points, while providing an (unaccepted answer) on a support request gives you 1 point.

The developers admit that they’re just guessing when it comes to what right point values for each action should be:

The score associated with each action type is currently just a best guess. We have yet to do any serious analysis on the real data to determine which actions should be rewarded more and which actions rewarded less.

The way the system is built makes it possible to award karma points for actions which aren’t related to any of the above parts of Launchpad, such as registering an email address or a GPG key. This may further dilute the relevant data from the different parts of Launchpad.

All of a user’s karma points from all over Launchpad are then calculated with a degradation algorithm, where contributions today are worth 100%, contributions 182 days ago are worth 50% and contributions made 365 are worth 0% – which means that if you don’t contribute for a year, you karma will drop to zero. The developers provide the following rationale:

We feel it important that Karma is reduced by time, as otherwise new users may feel that they have no hope of catching up with a long time user, even if that long time user is no longer active.

This means that the Launchpad karma cannot be used to measure longtime experience or social trust within Launchpad, as trust or ability does not degrade like this. Instead, Launchpad karma is solely a measure of activity which is recalculated on a daily basis. This means that the karma values can fluctuate wildly from day to day – especially depending on how certain tasks are rated. For a long period of time, the Rosetta developers had way too much karma compared to their work because Rosetta gave out karma points more easily than eg. Malone.

The use of karma in Launchpad has been discussed on the Launchpad-users mailing-list, and some bug reports have been filed on it to base the karma on logarithmic factors like the GNOME Bugzilla and displaying the karma next to the contributor’s name on a bug report. Also, there has been bug reports asking for an easy way to use the list of karma gained as a log through which you can access the comments and bug reports that you wrote to get the karma in the first place.

And yet another bug report has been filed in the hope that more statistics on karma distribution will be available than the current top 5.

Being part of a immensely complicated (and unfinished) system, the Launchpad karma system has a lot unresolved issues. First of all, it doesn’t even seem like the Karma system has a solid purpose yet. From the specs it seems like it was mostly to log user activity. But since the user can’t use the log to backtrack to the actions they performed, it is not that helpful in that regard. In the Malone, there is talk of using Karma as an incentive for people do good work. But if they have trouble figuring out how the karma is counted, and if the karma drops back to zero after a year, then that is not a very good incentive.

The central focus of the Karma system should not simply be activity, but trust. Launchpad will used by a lot of people, and their interactions are based on very few factors. Having social guide line such as Karma can help a lot. Both Slashdot and the GNOME Bugzilla provide examples of how that can be done successfully.

I’m afraid that the Launchpad developers have been too caught up in the technicalities to think of the actual use cases of the Karma system. I hope this will help a bit (I have also sent a link to this text to the Launchpad-users mailing-list).

Mail, Mail and more Mail

Since I came from Læsø [note the Wikipedia entry name in the address bar – not easy to recognize] late Tuesday evening, I have been catching up on my mail. And lots of it.

Doing fieldwork in an on-line community means that you’re reading lots and lots and lots of mail. From the various Ubuntu mailing-lists I get an easy 200 emails a day, So when I got back, after a holiday trip plus 2 weeks of intensive fieldwork, I had a couple of thousands of mails to go through for exciting ethnographic content.

Sorting my mail, I find there are the following main categories:

Bug mail – updates on various bugs that I subscribe or have been subscribed to, through the Malone bugtracking system.

Spec mail – updates on the various specs that I subscribe to through the Blueprint Specification tracking system.

Change mail – Every time a new version of software package is uploaded in the new Edgy Eft version of Ubuntu, a mail is sent to this list. A typical change mail.(I hope to examine this further as I find this to be a prime example of communication directly through technological production rather than actual conventional social interaction).

Ubuntu Mailing lists – This is the bulk of the mail I get. These are divided into Ubuntu-Devel for Ubuntu development discussion, Ubuntu-desktop for Desktop and Usability discussions (very little happens there…), Ubuntu-Doc for Documentation discussions, the Sounder (apparently named after a pack warthogs, because the first Ubuntu mailing-list was called Warthogs) for random community chit-chat and lots of other, specialized ones that I pay less attention to.

Obviously, I find the Sounder most readable, but it often degenerates into long, awkward discussions about very little. It seems that discussions are either specifically on the technical issues or it can explode in any other direction at any whim. As Biella Coleman observed somewhere, geeks often self-reflexively comment upon this, as in this email signature:

Arguing with an engineer is like wrestling with a pig in mud.
After a while, you realise the pig is enjoying it.

On top of all that, there’s my usual mail, and then there are the Blogs. Following GUADEC, I’ve begun to read not only the Planet Ubuntu feed (which I’ve been reading for a long time now) but also the the Planet GNOME and Planet Debian feeds in order to get an idea of what the upstream is up to. I did this when I found out how central the Planet GNOME is to that community’s communication.

Basically it is just one big blog combining blog posts from all the different individuals who have had their blog signed up, but it gives a much better feeling of community than the mailing-lists. Maybe it’s because of the little heads next to each blog post. These are called Hackergotchis by the way.

So, I find myself spending a good part of my day reading and writing notes just like if I was doing a literature project. The difference is that here I can ping the authors on IRC at ask them what they mean, exactly.

And the Survey Results are in..

For three weeks through May and June I ran a Web Survey directed at the active members of the Ubuntu community. I got more than 290 valid responses, and I’ve set up a page to share the results with the Ubuntu community.

Not having done any major statistical surveys before, this was quite a change of pace for me – and I’ve certainly learned a lot about the finer points of quantitative analysis. Among other things, how to phrase your questions to get the kind of answers you’re looking for.

I started out with lots of comment boxes, soft interpretation of questions and giving the respondees the opportunity to write in the margin, make small comments and generally give feedback at every step. It was a good way to find out what worked in the survey, but it also made it very difficult to process the bits that didn’t work as well. As the quote goes:

??There are three kinds of lies: lies, damned lies, and statistics?

And once you start “massaging” data to get nice pie diagrams and meaningful percentages, it is very easy to just modify the data as well. Naturally, I didn’t do so, I just noted how easy it is to do – even unknowingly. Quantitative data seems to be just as liable to suffer from over- interpretation as qualitative data.

Now it’s out there, and hopefully it’ll be of some use. In any case I’ll be able to use for my thesis.

Now I’m off to Læsø for a few days, and will be completely off the grid until Sunday – something that has become increasingly difficult to do as I get more involved in this brave new on-line world.

Back from the field

I arrived back in Copenhagen late last night on delayed flight from Barcelona and the 2006 version of the GUADEC conference. Actually, the conference took place in Vilanova i la Geltrú, 45 km south of Barcelona.

The GUADEC (GNOME Users and Developers European Conference) and GNOME, for the uninitiated is the acronym for “GNU Network Object Model Environment” the full name of which people rarely use anymore. Actually, GNOME is a Free Software Desktop Environment – which means that it is a wide collection of different elements that seek to make the user experience of the computer as smooth as possible. Just like the Linux kernel or the X-Window system, GNOME is an central part of many Linux distributions such as Red Hat, SuSe and, of course, Ubuntu.

It is worth noting that GNOME is not the only Linux desktop environment available. There is also KDE (for the K Desktop Environment – very creative name, yes?) along with many others. For KDE users, there is a now a separate version of Ubuntu awkwardly named Kubuntu which is based on KDE rather than GNOME.

Anyway! Before this all but drowns in strange geeky acronymics (and to be sure, there’s a lot of that going on), I’ll tell you about the actual conference. I went there to get an impression of how one of the older Free Software projects (the GNOME project was begun in 1997) works socially and organizationally compared to Ubuntu.

The conference was a very different event compared to the Ubuntu Developers’ Summit. It is much more of a community-driven event, organized by volunteers and dedicated members of the GNOME community. Sure, there are lots of corporate sponsors and keynotes and workshop discussions, but everything seemed much more relaxed and unhurried. There were no results that had to be reached. No specifications that had to be written. It was just a good, social occasion for people to meet and have fun. It had a unmistakable feel of geek summercamp about it, with people going to the beach, sitting and hacking in good humour, hanging out. There was even a football tournament (“the FreeFA World Cup”), sponsored parties and live music with the GNOME band!

But a more typical image from the conference would be this:

I didn’t actually get to take any pictures at the GUADEC, but luckily almost everybody else did. It seems that almost every geek present had a digital camera, and quite a few had really big expensive ones as well. It seems that photography is popular hobby among geeks. At the time of writing, more than 1700 pictures on Flickr has been tagged GUADEC2006, and just by flicking through a few of them, you’ll get a good idea of the smiley, relaxed atmosphere there.
(also, the two pictures presented here are linked from Flickr).

At the same time, there was an intense amount of posting on the aggregated Planet GNOME blog feed that collects blog posts from lots and lots of GNOME developers. It is definitely another good way to get a feel of the atmosphere at the conference.

Compare to the Ubuntu Summit was called, arranged and sponsored solely by Canonical, the company employing the Ubuntu core developers, with an intense working schedule with workshops from 9 am to 6 pm every day and having to sneak in the social time after that and cut down on sleep instead. Actually, at GUADEC people also cut down on sleep, in a way that left most people absolutely exhausted at the end of the full week of conference.

Oh, and photos from the Ubuntu Summit has been gathered here. Including a very nice group photo. I unintentionally managed to end straight in the middle of the photo. A key to who the rest of the participants are can be found here.

Also, compare the playful banter of the planet GNOME with the more sober tone among the posters at the Planet Ubuntu blog feed. Also, note the small overlap of posts. I especially recommend the Ubuntu Quality Assurance guy (“bug hunter”) Simon Law’s blog posts which does well to capture the duality of the conference: Trying to both do hacking stuff and have time for social interactions and adventures in Paris.

At the Ubuntu Summit

Since Sunday afternoon, I’ve been at the Ubuntu Developers’ Summit at SAS Radisson hotel near the Charles De Gaulle airport outside of Paris.

Actually, the hotel is located in the small village Mesnil-Amelot which is even outside of the airport so that you have to take a shuttle bus to the airport, and then a train from the airport train station in order to get into Paris. Effectively, this discourages most of the assembled assorted geeks from running off to Paris all the time.

The summit is focused on discussing, drafting and approving the specifications that will be implemented in the next Ubuntu release, codenamed the Edgy Eft. As it is, as much of the planning of the release will be done within these 5 days as possible. You can check out the draft of the release cycle here.

There are a goodly mix of people from the community here. First of all, there’s all of the Ubuntu core developers with backgrounds in F/OSS projects such as Debian and GNOME, and fair few of the developers of the associated Launchpad project which is a platform for Open Source development that is still in active development. The connection between Launchpad and Ubuntu is really interesting, as it allows for a continuing exchange between the development of the distribution and the framework and structure through which it is being developed. The Launchpad framework makes certain assumptions about how Open Source projects are developed, and how the different sections of the whole wide Open Source community should coordinate their work. I’ll definitely be looking more into that.

Then there’s also the community volunteers, a fair few of which have been sponsored by Canonical, the company behind Ubuntu and Launchpad, there are people here from the KDE community to help with Kubuntu development, there are people from the Linux Terminal Server Project to help with Edubuntu development, there are XCFE volunteers to help out with Xubuntu – all three of which are subprojects based on the Ubuntu distribution. There are Intel people to ensure hardware compatibility, there are MOTU‘s – the volunteer package maintainers that prepare the software sync’ed from Debian for use in Ubuntu. Lots of activity and lots of different associations and motivations.

Many of the people I’ve talked to are very impressed that so many different projects are represented here. And that so many of the Open Source celebrities are here, hacking on Ubuntu together. People like Jeff Waugh and James Troup (note: Troup doesn’t seem to have his own webpage, so I’ve linked to a rant complaining about his central position in Debian. Mind the bile) work for Canonical and have quite a reputation among the volunteers here.

The format of the days are that everything is divided into discussions of single specifications. These sessions are called BOFs (for Birds Of a Feather, and scheduled based on the specifications in Launchpad through an automated process. Here’s the schedule for Monday. And here’s a picture of a typical BOF in session:

You’ll notice the ubiquitous laptops. Developers tend to bring them along wherever they go. Many have these tiny laptops that really couldn’t possibly be any smaller without it being too small to use properly.

People here are passionate about what they do, and friendly and quite willing to discuss their work. I’m really enjoying myself doing this fieldwork.

Off to Paris

Well, I’m finally heading out into the field. The real field, not the virtual one but out to meet real flesh-and-blood informants. I’m very excited, if you couldn’t tell.

The plan is like this: First I’m off to Paris for the Ubuntu Developers’ Summit where all of the core Ubuntu developers will gather to spend a week planning and discussing the next Ubuntu release, deftly codenamed the Edgy Eft.

I’ll be participating in the discussions, and I will be presenting the results of the Census Survey of the Ubuntu community which I have been conducting. I’ve received nearly 300 hundred valid responses and the questionnaire is still open for the curious – though any late responses won’t make it into my analysis.

After what I hope will be a great time in Paris (I’ll also have time to visit some old friends from Manchester), I’ll fly to Barcelona for the GUADEC conference. That is the “GNOME User And Developer European Conference” which is a rather snappy acronym. GNOME is the desktop environment that Ubuntu uses, and several of the Ubuntu developers are also GNOME developers and have strong ties to this project.

The GUADEC is another week of conference but in a somewhat different climate: Where the Ubuntu Developers’ Summit will be an intense work session, the GUADEC looks to be a bit more relaxed and easy-going. There will even be a GNOME football championships during the week. The differences will be interesting to note, too.

Also, very appropriately I stumbled across a song just yesterday by Swedish ragga outfit Helt Off. It’s called “Det brinner i Paris” [.mp3 file from Helt Off’s record label] and it’s about the riots in Paris last autumn where groups of young unemployed suburbanites lit cars on fire in the night. You can find the (Swedish) lyrics here.

Did I mention that it is damn funky?