Please subscribe to RSS Feed! :)

Never mind do no evil – this is doing some serious good.

Several organizations, including parts of the US government, have successfully screwed things up, or promised to screw things up, this week:

Last year around this time everyone was getting ready for the Desktop Summit. I couldn’t make it and I could still kick myself for it tbh. Watching it remotely was rather painful as the information flow wasn’t as good as it could have been. So I promised myself two things for this year’s Akademy: 1) I’m soooooo going to be there. 2) I’m going to help make it easier on the people who can not go for whatever reason.
So here is the run-up of resources you will need to keep up-to-date on all things Akademy while it is happening in 2 weeks:
Most of them have RSS feeds you can subscribe to – use them
If there is anything else that would be helpful please leave a note in the comments.
Now if you are going to be in Tampere and going to make the world rock more, spread the coolness:
And you might have guessed it already…

(Special thanks to my employer ontoprise and the KDE e.V. for paying travel and accommodation. It would not be possible without you. *hint* individual supporting membership *hint*)
Hmmm and while I’m at it I might as well create some buzz for my talks, right? So I’ll be doing 3 talks it seems:
Be there! You know you want to
I’ll also be doing 3 BoF’s on git, community and wikis for those interested. Oh and I’m writing on a paper on mentoring to accompany my community talk. I’ll post it here when it’s published.
CU in Tampere!


This article is part of a series of articles about why I feel Launchpad is a great home for your Open Source project. I am writing these articles not as an employee of Canonical, but instead as a happy Launchpad user who gets agitated that not enough people know how cool Launchpad is.
Open Source is fundamentally driven by gifts. People contribute translations, documentation, artwork, code and more. Many of these gifts are made available in the form of patches; fragments of content that can be applied to other chunks of content to apply new features, resolve issues or add value in other ways. Patches are wonderful contributions. their authors take the time to care about a problem and invest their expertise and time in producing a solution that everyone can share and benefit from. As such, we should treat these patches with the due care and attention that they deserve.
Something we found in Ubuntu was that we were getting so many patches submitted that many were being lost in the mix and were not getting reviewed and applied if appropriate. This goes against the grain of a gift – we should always review these gifts with a strong sense of care and timeliness. The situation was not driven by carelessness or malice, but instead a lack of visibility on these available patches for a given project.
As such, we worked to build a new feature into Launchpad to provide a simple way of looking at all submitted patches. It looks like this:

Accessing this is simple; just add +patches to the end of a Launchpad project address. As an example for Zope
https://edge.launchpad.net/zope/+patches
This also applies to source packages in Ubuntu. As an example for the Gwibber source package:
https://edge.launchpad.net/ubuntu/+source/gwibber/+patches
With each of these patch views you can order the patches by patch age, see the current status of the patch, and see it’s importance. This all provides a better way for these important contributions to be reviewed for the benefit of everyone.
See a list of all of these Why Launchpad Rocks articles here.


This article is part of a series of articles about why I feel Launchpad is a great home for your Open Source project. I am writing these articles not as an employee of Canonical, but instead as a happy Launchpad user who gets agitated that not enough people know how cool Launchpad is.
One of the things I love about Launchpad is that getting, hacking, sharing, merging in code is dead simple. Much of this is because of it’s tight integration with the Bazaar version control system. Together it provides a kid-in-candy-shop level of awesome if you like to run and hack on code.
One of the things I love about Bazaar is that it is focused on simplicity, and having used CVS and Subversion in the past, and a little bit of git recently, I find Bazaar by far the most naturally connected with my workflow. The reason for this is that I don’t want to care about version control. I am not interested in it, I don’t want to learn it, I don’t plan on sending it a Christmas card; I merely want to learn enough to get code from somewhere, upload it somewhere and rock with it. Bazaar is well suited to my needs because it’s simplicity means that it doesn’t feel like a pain to use.

Getting code is simple. I can click on the Code part of a Launchpad project and Launchpad tells me what command I need to run to grab a branch. As an example, if I want to download code from the Lernid project, I just run:
bzr branch lp:lernid
This gets me a branch easily, and I am ready to hack on it. when I have my feature or fix ready, I can then push it really easily with:
bzr push bzr:~jonobacon/lernid/my-new-feature
…changing my-new-feature for whatever branch name I want to call it. At this point my branch will appear with the other branches in the Lernid project, so the other developers can download and try it. If I would like to ask the Lernid developers to merge it into their main trunk branch, I can Propose It For Merging in Launchpad which provides a user interface for the developers to review the branch, ask me comments, request changes and otherwise have a conversation about the proposed merge.
This all makes grabbing code, hacking on it, sharing it with others, and asking for it to be merged dead simple.
Not only this, but if you are interesting in contributing to Ubuntu, all source packages are held in Bazaar which means that the same tools and commands for working with code apply to working on one of the most popular Linux distributions too. You can read more about this here.
See a list of all of these Why Launchpad Rocks articles here.


This article is part of a series of articles about why I feel Launchpad is a great home for your Open Source project. I am writing these articles not as an employee of Canonical, but instead as a happy Launchpad user who gets agitated that not enough people know how cool Launchpad is.
Everyone has an opinion about bug trackers. I suspect my dad may even have an opinion, and I am pretty sure he has no idea what a bug tracker even is. The general consensus seems to be that everyone thinks that all bug trackers suck. A strong view, but one not entirely without merit given the fact that a vast majority of bug trackers do indeed suck. In the past I have mainly used Trac, SourceForge, Mantis and Bugzilla, and I have to say that I find Launchpad best suited to my needs and more importantly, most usable by my users who I expect to file a bug when something goes belly up.
I just want to zip through some of the reasons why I find bug tracking in Launchpad a breeze and well suited to all of my applications.
Of course, simplicity is a relative term, but I genuinely find that Launchpad provides the easiest interface for reporting bugs from the perspective of an end-user, and provides the easiest method of triaging and managing bugs. In terms of reporting bugs, the process is as simple as entering a subject and body content of the bug report. There are the usual additional options, but these are buried away a little so as not to confuse end-users. Launchpad also includes an excellent dupe-search to help end-users find existing bugs, yet still mark that it affects them without them having to engage in the irritating “me too” comment.
Ubuntu has been an excellent project for stress testing the triage and management of bugs, with literally thousands of bugs flowing through the system. The Launchpad team have reacted well to this feedback and now Launchpad feels like a nimble and efficient system for triage and management. The interface is simple and uncluttered and provides easy access to the different attributes of a bug report. Not only that but it is simple to query different classes of bug to make it simple to provide targeted work-lists for developers.

One of the coolest features in Launchpad bug tracking is bug linking. Imagine the scenario that you work on a piece of upstream software that is shipped in three different distributions. The same bug could conceivably be filed against the main upstream project in Launchpad, as well as against the source packages for the project in each distributors bug tracker. This now means you have four different bugs that actually reflect the same bug, each with their own comment histories and possible patches.
The Launchpad team have produced a feature where you can link a bug in Launchpad with other bugs in Launchpad against different projects, and even link against bugs outside of Launchpad in Trac and Bugzilla. Launchpad can then pull the status and from these other bugs and reflect them in the main bug in Launchpad. This provides a way of consolidating these different bugs in one place which saves time and duplication of effort. The Launchpad team have produced a series of bug tracker plugins for Bugzilla and Trac which can share the comment history for the same bug tracked both in Launchpad and an external tracker. What’s more, to help find low-hanging fruit, there’s a “Bugs fixed elsewhere” report that shows which of your bugs are marked fixed in other communities.

Ultimately a bug conversation ideally leads to a fix. Launchpad has made it simple to bring bugs and fixes together. You can easily see any patches attached to a bug report and you can also jump straight to a list of all the bug reports, associated with your project, that have patches. This is ideal when new developers join your project; you can direct them at the list of outstanding unreviewed patches as a place to start.
For fixes that require more than a simple patch, you can link directly to the Bazaar branch (including imports from Git, Subversion and CVS) you’re working in, allowing everyone interested in the bug to watch your solution evolve or even download your branch, make their own changes and then upload them back to Launchpad for everyone to see. A single URL points to the latest version of the fix and a single command merges it into the project’s trunk branch.

Anyone who has been in the software business for a while will know that no matter how much you try to pre-empt the needs of developers, developers will always end up writing their own tools and workflow that suits them best. In other words, give the developer the tools to write their own tools and they will do incredible things. I think providing this kind of extensibility really demonstrates maturity in the creators of a software product. It shows that the tools provider is keen to help the developer get the very best solution, instead of being overly protective about building every possible solution in to their interface.
The Launchpad team have produced an API called launchpadlib that provides a RESTful Python API that lets you manipulate data in Launchpad just like any other Python object. In terms of bugs specifically, launchpadlib lets you report, access, and manage bugs, and also provides the ability to authenticate your apps to Launchpad. This means you can write tools to interface with your bugs that meet your specific needs, be it easier ways to triage, generate reports, or even embedding a modified bug submission form into your project’s website. A good example of this kind of third-party work is Bughugger; a desktop front-end to Launchpad bugs and Apport, a tool for reporting bugs in Ubuntu that automatically gathers debugging information.
See a list of all of these Why Launchpad Rocks articles here.

I’ve got plenty to tell about my experiences of our two month trip to Silicon Valley, but I’ll start with telling about the conferences and events I’ve attended. I’ll start the story with the most important and the biggest one, Linux Foundation’s Collaboration Summit which was held in April in San Francisco, at the Hotel Kabuki.
Unfortunately I had a flu at the same time so some of my memories of the sessions are a bit hazy, but not to worry! Before the summit we attended WhereCamp, an unconference about geoinformation, maps and everything related to that. (I’m not too much into location information, but my partner is, and I tagged along.) The organizers gave out five Flip UltraHD camcorders, and we got one! So I naturally used mine to record the sessions, which turned out to be a good thing, since the MeeGo Workshop on Thursday was not recorded by anyone else. I’m still in process of editing the video files into uploadable format – my laptop and Linux applications for video editing seem to be incompatible combination – but I promise I’ll upload the stuff soon! (Keep tuned to this channel!)
The Linux Foundation Collaboration Summit was held in San Francisco on the 14th to 16th of April, 2010. Because of the flu I attended only the two first days, but that was plenty of action! Our hotel is down south at Sunnyvale so I had to find a way to travel to downtown San Francisco. I don’t have a car or drivers licence, so Caltrain was the only viable option, and that was plenty of adventure! I did plan to use the public transport in San Francisco, but it was too much for my hazy brain and I ended up using the taxi from the train station to Hotel Kabuki, where the conference was held. Being afraid of heights traveling on Caltrain was an experience, as the carriages were double-decker (see picture).
We visited Japantown on the Sunday previous to the conference so I’d know a bit about my surroundings, and it was a good decision. The hotel the conference was held is very pretty, and it’s next to a shopping centre full of Japanese shops and restaurants. It helped a lot with my navigation later!
Arriving to the venue on Wednesday we got breakfast and while eating my croissant and drinking my coffee, Elizabeth introduced me to couple of people, including Landon Jurgens from GE. I also had a little touch with fame as Bradley M. Kuhn joined our group and we talked, among other things, about Star Wars memorabilia. Geek, me?
First keynote was held by Jim Zemlin, Executive Director at The Linux Foundation, justifiably. He welcomed us, and talked about the State of the Linux Union. He told us about the reasons why Linux is so successful, but reminded us about the challenges the ecosystem faces too. As a funny sideline he showed us a video comparison of Steve Jobs describing the iPad: “wonderful, amazing, magical, easy” and beloved RMS describing GNU/Linux: free, freedom, freedoms, be a good neighbour…
I think one of the biggest reasons Linux is becoming more and more successful is the omnipresence of electrical and information technology related equipment. Even if personal computers might be running Windows or OS X or other non-Linux operating systems, there’s plenty of appliances, mobile phones, networking hardware, cars and DVR’s around.
The biggest problem with the heterogeneity of the open source community and projects – especially those who are responsible to the paradigm shift of computing infrastructure from locally owned and operated hardware/software combinations to computing as a service industry – is that there has to be extra vigilance to fit and finish what has been started and not lull into complacency with releases of half-baked services. This problem can be addressed with proper management of the project, setting targets, tasks, having testing at the heart of things and making quality assurance a top priority. [video]
Following Jim’s presentation, Daniel Frye with his IBM keynote discussed the lessons the company has learned through their decades of commitment to Linux and open source development. I found this presentation probably the most interesting of the morning sessions and enjoyed the view to the history of the IBM participation. One of the most important points that can be seen in retrospect are that it’s a lot easier to join an existing community than to create a totally new one, and that code drops are a difficult and dangerous way of participation; incremental edits for delivering change is usually better! [video]
The last presentation before lunch break was a panel about cloud computing. To my great disappointment Mark Shuttleworth wasn’t at the conference and didn’t take part in the discussion (although there were plenty of Canonical employees, including Pete Graner). I’m not a great connoisseur of cloud computing, but there were couple of points I managed to catch up: There’s vendor lock-in with the different cloud providers! I hadn’t really thought of that before, and it surprised me a bit. This makes it a bit risky business to trust your stuff to cloud services, but an idea of smaller vendors to create a standard by sharing code and infrastructure sounds mighty good to me. I’ll definitely need to add cloud computing to one of the subjects I need to read more about! [video]
After lunch Ari walked on the podium wearing a Maemo shirt to give his keynote about MeeGo, the free and standard Linux for the mobile industry. As we know, MeeGo is the result of the recent co-operation incentive of Nokia’s Maemo and Intel’s Moblin. There’s great hopes for this one, but I have been more or less out of touch of the real ideas behind MeeGo since I happened to be very, very sick on the week the new project was announced.
Having been watching the Maemo development from close range for quite some many years, the fact that MeeGo is aimed at not only smartphones but also TVs, tablets, car systems (and trains, planes etc) and netbooks requires some mental adjustment. MeeGo will be using Qt, Telepathy, WebKit, Fennec, RPM and GNOME, so there are some changes to Maemo. I’ve looked at the community response and the change to RPM has been the hardest to digest so far by the people.
Linux Foundation hosts the some work under MeeGo workgroup and there’s already considerable amount of collaboration going on with the platform, as Acer, Asus, BMW, Cisco, Careland, CS2C, Ericsson, DeviceVM, Gameloft, EA, Kingsoft, Linpus, Mandriva, Metasys, MontaSys, Neusoft, Novell, PixArt, Red Flag and others have already joined the MeeGo community. In the meantime first release of MeeGo has already been done in form of a code dump. It’s not really usable yet as it doesn’t have a GUI yet. N900 is the first reference device for MeeGo though, so there’s some hopes for the “older” devices :-P [slides, video]
The kernel panel was mainly uneventful. The new kernel will have better SSD support and some other new features such as a Linux equivalent of DTrace. Even if there are new features in kernel, the kernel developers keep getting older and there might not be as many new contributors to it as there has been in the past. Part of the problem is that the it’s not regarded as cool to be a kernel developer as it used to be. The code the old developers are writing into the kernel is so specialized and done by long time experts that it might be hard to understand and get used to by newer contributors. Long time contributors are well motivated and dedicated to their work on the kernel though – partly because most of them are employed to develop the kernel – so perhaps all isn’t lost after all. [video]
Imad Sousou of Intel and MeeGo technical steering group spoke after the kernel panel. He started off by mentioning his wish that since Ari had talked earlier and covered most of the topics he had in his presentation, perhaps he wouldn’t be asked the hard questions since Ari had already answered them. (This wish the audience later broke, by asking hard questions about proprietary blobs Maemo has had in the past. Ari answered them as diplomatically as possible, telling that while the project itself aims to be 100% open source, there might be proprietary components, such as device drivers, Skype etc. distributed by the vendors of the devices. Nokia will be one of the vendors, so, there will be proprietary components in the devices Nokia ships. This didn’t come as a surprise to me.)
What Imad stressed in his talk is that MeeGo plans to work very closely to the upstream.
If you want a kernel patch into MeeGo, send it to kernel upstream instead of MeeGo. If you want a Qt patch into MeeGo, send it to Qt.
MeeGo will also have a six month release cycle. First one is going to be released really soon (hopefully) as the schedule is aiming to release every May and November. [slides, video]
Why Your Life Might Depend on Your Code from the DFS Deutsche Flugsicherung (that’s the German Air Traffic Control) was mind-boggling. I’ve not watched the video yet, but I know it includes the video they showed us, and instead of yapping about too much about what the presentation was about, I suggest that you watch the video of the presentation. I can’t make justice to it by trying to condensate the points. [slides, video]
The presentation about how to prevent communities and co-operation was hilarious. Josh Berkus engaged the audience with his Over The Wall presentation. He had condensed how to stop global warming in a few easy steps that make sure you’ve built a wall between your developers and the community and stop contributions. The first premise you need to apply to the rest is that your developers do not take part in the community and all the releases are done in code drops, as thrown over the wall.
Ingredients include: difficult tools, preferably proprietary, homegrown, outdated or non-gui stuff, going all the way from CVS to CMS, via buildsystems and bugtrackers. The team needs to be overworked, and you need to make sure it’s kept that way: otherwise they’ll be babbling with the community! To make sure no communication happens, meetings need to be closed too – teleconferences make things hard, but make stuff impossible by having closed meetings. If you have a means of communication, obscure it as much as you can, and feed the trolls to make the community work against itself. Leave everything to be managed by one person, one person for webpages, mailing lists, etc. Use legalese everywhere where possible, but if you really want to tick people off, just be silent. [slides, video]
Chris diBona used Josh’s slides backwards to tell how Google does Open Source. Basically everything is in reverse! But in the end, Chris started using his own slides. Mootpoint was, that Google has released so far 915 projects as open source, and that more than 200 Google employees are patching and contributing to upstream projects. The message that also was included was that looking for enemies within the Linux and open source community isn’t beneficial. For Android to succeed MeeGo doesn’t have to fail, and indeed, in Android there’s plenty of stuff that has been originally contributed by Nokia employees. At the end of his presentation Chris won over the hearts and souls of the audience by giving every attendee a free Nexus One! [slides, video]
The first day of the event was brilliant, and we moved to a Japanese restaurant to an afterparty. I was getting tired after waking up at five o’clock and left the party around eight o’clock, to recuperate from the day to be ready for the next day. That’s up in my next blog post, coming up soon on this same bat channel! If you want to read a more accurate description of both the first and second day of Linux Collaboration Summit 2010, I highly recommend reading this Qaiku thread, written by Henri Bergius.

I’ve got plenty to tell about my experiences of our two month trip to Silicon Valley, but I’ll start with telling about the conferences and events I’ve attended. I’ll start the story with the most important and the biggest one, Linux Foundation’s Collaboration Summit which was held in April in San Francisco, at the Hotel Kabuki.
Unfortunately I had a flu at the same time so some of my memories of the sessions are a bit hazy, but not to worry! Before the summit we attended WhereCamp, an unconference about geoinformation, maps and everything related to that. (I’m not too much into location information, but my partner is, and I tagged along.) The organizers gave out five Flip UltraHD camcorders, and we got one! So I naturally used mine to record the sessions, which turned out to be a good thing, since the MeeGo Workshop on Thursday was not recorded by anyone else. I’m still in process of editing the video files into uploadable format – my laptop and Linux applications for video editing seem to be incompatible combination – but I promise I’ll upload the stuff soon! (Keep tuned to this channel!)
The Linux Foundation Collaboration Summit was held in San Francisco on the 14th to 16th of April, 2010. Because of the flu I attended only the two first days, but that was plenty of action! Our hotel is down south at Sunnyvale so I had to find a way to travel to downtown San Francisco. I don’t have a car or drivers licence, so Caltrain was the only viable option, and that was plenty of adventure! I did plan to use the public transport in San Francisco, but it was too much for my hazy brain and I ended up using the taxi from the train station to Hotel Kabuki, where the conference was held. Being afraid of heights traveling on Caltrain was an experience, as the carriages were double-decker (see picture).
We visited Japantown on the Sunday previous to the conference so I’d know a bit about my surroundings, and it was a good decision. The hotel the conference was held is very pretty, and it’s next to a shopping centre full of Japanese shops and restaurants. It helped a lot with my navigation later!
Arriving to the venue on Wednesday we got breakfast and while eating my croissant and drinking my coffee, Elizabeth introduced me to couple of people, including Landon Jurgens from GE. I also had a little touch with fame as Bradley M. Kuhn joined our group and we talked, among other things, about Star Wars memorabilia. Geek, me?
First keynote was held by Jim Zemlin, Executive Director at The Linux Foundation, justifiably. He welcomed us, and talked about the State of the Linux Union. He told us about the reasons why Linux is so successful, but reminded us about the challenges the ecosystem faces too. As a funny sideline he showed us a video comparison of Steve Jobs describing the iPad: “wonderful, amazing, magical, easy” and beloved RMS describing GNU/Linux: free, freedom, freedoms, be a good neighbour…
I think one of the biggest reasons Linux is becoming more and more successful is the omnipresence of electrical and information technology related equipment. Even if personal computers might be running Windows or OS X or other non-Linux operating systems, there’s plenty of appliances, mobile phones, networking hardware, cars and DVR’s around.
The biggest problem with the heterogeneity of the open source community and projects – especially those who are responsible to the paradigm shift of computing infrastructure from locally owned and operated hardware/software combinations to computing as a service industry – is that there has to be extra vigilance to fit and finish what has been started and not lull into complacency with releases of half-baked services. This problem can be addressed with proper management of the project, setting targets, tasks, having testing at the heart of things and making quality assurance a top priority. [video]
Following Jim’s presentation, Daniel Frye with his IBM keynote discussed the lessons the company has learned through their decades of commitment to Linux and open source development. I found this presentation probably the most interesting of the morning sessions and enjoyed the view to the history of the IBM participation. One of the most important points that can be seen in retrospect are that it’s a lot easier to join an existing community than to create a totally new one, and that code drops are a difficult and dangerous way of participation; incremental edits for delivering change is usually better! [video]
The last presentation before lunch break was a panel about cloud computing. To my great disappointment Mark Shuttleworth wasn’t at the conference and didn’t take part in the discussion (although there were plenty of Canonical employees, including Pete Graner). I’m not a great connoisseur of cloud computing, but there were couple of points I managed to catch up: There’s vendor lock-in with the different cloud providers! I hadn’t really thought of that before, and it surprised me a bit. This makes it a bit risky business to trust your stuff to cloud services, but an idea of smaller vendors to create a standard by sharing code and infrastructure sounds mighty good to me. I’ll definitely need to add cloud computing to one of the subjects I need to read more about! [video]
After lunch Ari walked on the podium wearing a Maemo shirt to give his keynote about MeeGo, the free and standard Linux for the mobile industry. As we know, MeeGo is the result of the recent co-operation incentive of Nokia’s Maemo and Intel’s Moblin. There’s great hopes for this one, but I have been more or less out of touch of the real ideas behind MeeGo since I happened to be very, very sick on the week the new project was announced.
Having been watching the Maemo development from close range for quite some many years, the fact that MeeGo is aimed at not only smartphones but also TVs, tablets, car systems (and trains, planes etc) and netbooks requires some mental adjustment. MeeGo will be using Qt, Telepathy, WebKit, Fennec, RPM and GNOME, so there are some changes to Maemo. I’ve looked at the community response and the change to RPM has been the hardest to digest so far by the people.
Linux Foundation hosts the some work under MeeGo workgroup and there’s already considerable amount of collaboration going on with the platform, as Acer, Asus, BMW, Cisco, Careland, CS2C, Ericsson, DeviceVM, Gameloft, EA, Kingsoft, Linpus, Mandriva, Metasys, MontaSys, Neusoft, Novell, PixArt, Red Flag and others have already joined the MeeGo community. In the meantime first release of MeeGo has already been done in form of a code dump. It’s not really usable yet as it doesn’t have a GUI yet. N900 is the first reference device for MeeGo though, so there’s some hopes for the “older” devices :-P [slides, video]
The kernel panel was mainly uneventful. The new kernel will have better SSD support and some other new features such as a Linux equivalent of DTrace. Even if there are new features in kernel, the kernel developers keep getting older and there might not be as many new contributors to it as there has been in the past. Part of the problem is that the it’s not regarded as cool to be a kernel developer as it used to be. The code the old developers are writing into the kernel is so specialized and done by long time experts that it might be hard to understand and get used to by newer contributors. Long time contributors are well motivated and dedicated to their work on the kernel though – partly because most of them are employed to develop the kernel – so perhaps all isn’t lost after all. [video]
Imad Sousou of Intel and MeeGo technical steering group spoke after the kernel panel. He started off by mentioning his wish that since Ari had talked earlier and covered most of the topics he had in his presentation, perhaps he wouldn’t be asked the hard questions since Ari had already answered them. (This wish the audience later broke, by asking hard questions about proprietary blobs Maemo has had in the past. Ari answered them as diplomatically as possible, telling that while the project itself aims to be 100% open source, there might be proprietary components, such as device drivers, Skype etc. distributed by the vendors of the devices. Nokia will be one of the vendors, so, there will be proprietary components in the devices Nokia ships. This didn’t come as a surprise to me.)
What Imad stressed in his talk is that MeeGo plans to work very closely to the upstream.
If you want a kernel patch into MeeGo, send it to kernel upstream instead of MeeGo. If you want a Qt patch into MeeGo, send it to Qt.
MeeGo will also have a six month release cycle. First one is going to be released really soon (hopefully) as the schedule is aiming to release every May and November. [slides, video]
Why Your Life Might Depend on Your Code from the DFS Deutsche Flugsicherung (that’s the German Air Traffic Control) was mind-boggling. I’ve not watched the video yet, but I know it includes the video they showed us, and instead of yapping about too much about what the presentation was about, I suggest that you watch the video of the presentation. I can’t make justice to it by trying to condensate the points. [slides, video]
The presentation about how to prevent communities and co-operation was hilarious. Josh Berkus engaged the audience with his Over The Wall presentation. He had condensed how to stop global warming in a few easy steps that make sure you’ve built a wall between your developers and the community and stop contributions. The first premise you need to apply to the rest is that your developers do not take part in the community and all the releases are done in code drops, as thrown over the wall.
Ingredients include: difficult tools, preferably proprietary, homegrown, outdated or non-gui stuff, going all the way from CVS to CMS, via buildsystems and bugtrackers. The team needs to be overworked, and you need to make sure it’s kept that way: otherwise they’ll be babbling with the community! To make sure no communication happens, meetings need to be closed too – teleconferences make things hard, but make stuff impossible by having closed meetings. If you have a means of communication, obscure it as much as you can, and feed the trolls to make the community work against itself. Leave everything to be managed by one person, one person for webpages, mailing lists, etc. Use legalese everywhere where possible, but if you really want to tick people off, just be silent. [slides, video]
Chris diBona used Josh’s slides backwards to tell how Google does Open Source. Basically everything is in reverse! But in the end, Chris started using his own slides. Mootpoint was, that Google has released so far 915 projects as open source, and that more than 200 Google employees are patching and contributing to upstream projects. The message that also was included was that looking for enemies within the Linux and open source community isn’t beneficial. For Android to succeed MeeGo doesn’t have to fail, and indeed, in Android there’s plenty of stuff that has been originally contributed by Nokia employees. At the end of his presentation Chris won over the hearts and souls of the audience by giving every attendee a free Nexus One! [slides, video]
The first day of the event was brilliant, and we moved to a Japanese restaurant to an afterparty. I was getting tired after waking up at five o’clock and left the party around eight o’clock, to recuperate from the day to be ready for the next day. That’s up in my next blog post, coming up soon on this same bat channel! If you want to read a more accurate description of both the first and second day of Linux Collaboration Summit 2010, I highly recommend reading this Qaiku thread, written by Henri Bergius.

Tuesday morning we were up bright and early for breakfast and the beginning of day 2 of UDS! As usual, the day for me started out over at the Community Roundtable.

- Community Roundtable -
In addition to being a general overview of the upcoming day, this roundtable really focused on the perception the community in general has of Canonical. In this last cycle the Canonical Design team really came under fire for making design decisions without keeping the community up to speed on the moving of window control buttons, and the now infamous bug report related to it. The rationale for this eventually came out in Mark’s blog and is generally supported by the community but it was felt that much of the community uproar could have been prevented by having some of the design team’s work be more accessible to the community. In response to this the Design Team over at Canonical have launched a really great blog over at design.canonical.com to work harder to engage the community and keep them up to speed with their ideas and projects. The design team was not the only team focused on in this discussion, it also expanded to other roles within Canonical, including those of developers. It turns out that it’s not well-know that for a Canonical employee to become an Ubuntu developer (or even an Ubuntu member) they need to go through the same process as anyone in the community seeking to fill the same roles, and indeed, there have been times when Canonical employees were asked to reapply for positions within the community when the governing membership boards felt they didn’t have enough solid involvement. The result of this session? Communication has to improve on all fronts to keep the relationship between the Ubuntu community and Canonical a healthy one.
- Ubuntu NGO Team plans for Maverick -
This was probably the most productive session of the day for me. The NGO Team has some really great folks involved who are really inspired to reach out to more non-profits and get them the help they need with documents, software packages and general tips for using Ubuntu and other open source applications within their organization. The result of this was several tasks defined for this next cycle, including some for me regarding php pear packages required for some of the webapps that the NGOs are keen to use.

- Ubuntu Support and Learning Center -
In this session Benjamin Humphrey introduced ideas for a Support and Learning Center website. The rationale behind this is outlined in the introductory paragraph of their wiki page:
The Ubuntu Support and Learning Center (USLC) will be an awesome, quality, dynamic website that acts as an online learning and support center for Ubuntu users to both solve their problems or work through tasks, and also to learn more about Ubuntu and how to contribute to it. The final site would involve material from the manual project, docs team, learning project and third party articles, split into well organized, topic based help using cutting edge web technologies like HTML5. The website would also collect information and feedback from the users on the usefulness of articles or individual paragraphs, so that we can constantly improve our material to make it the best quality we can.
It is primarily a portal for content that is easily accessible to users. Much of the discussion on this centered around making sure the team was going to work with the existing teams to develop content, and the hope is that initially this really would be a portal to existing content instead of a lot of content developed by the team itself. However, the grand vision was that of a moderated wiki where contributors would have an interface for quick edits to content that could be submitted via the web interface into the bug tracking system, as well as a full translations system that would be easy to use. As with many documentation initiatives lately the focus is really on working toward high quality documentation while maintaining a low barrier to entry and making translations as easy as possible. Just like the manual project I really hope to see some of the tools used in this project used throughout the community.

- Development Workflow Overview -
This was the second such session of the week (I didn’t attend the first), and focused mostly on how upstream developers and others could most effectively submit patches, including starting from a base of “how would a developer know where to begin?” and discussing whether attaching patches to bugs really is the most effective strategy. There are currently over a thousand bug reports in launchpad against Ubuntu projects which have patches haven’t been thoroughly reviewed and applied, so while the review team is now working hard to get through this backlog (and doing an amazing job!) the session was seeking to make this job easier by defining a set of simple steps that could be completed in bzr itself so that a patch and merge request could be made directly, hopefully moving the patch that much further along in the development workflow. The patch discussion will continue in some patch-focused sessions later this week.
- Open Week and Developer Week -
I really enjoyed this session a lot. Focused on Classroom events (Open Week, Developer Week, Opportunistic Developer Week, User Days), and general sessions), this session covered some of the strengths and weaknesses and best practices for all these. We also discussed timing of these events and how we can do a better job at promotion, as it was agreed that we could have done better for this latest Open Week and at getting our news out to non-techies in general. Out of this session I’ll also be modifying the Classroom docs somewhat to make it clear that anyone with a project within the community is welcome to use the channel, get their events added to the calendar and take advantage of the features of ClassBot.
- Create a localized help.ubuntu.com -
I don’t know a lot about translations (easy when you only speak one language, and that language is English!) but I do understand their vital importance to a project like Ubuntu, and see the value they present when proprietary and closed source software alternatives lack the international support that open source can provide. The translations of official help docs is an ongoing project that allows for documentation with each release to be shipped with installs, but the help on actual help.ubuntu.com is only published in English. Currently it’s the job of loco teams to maintain their own (like help.ubuntu-it.org) and Matthew East brings up some interesting points about the challenges of maintaining translations sites in his email to the docs list on Sunday. It was an interesting discussion, diving in to the resources the locos have and whether they should really be responsible for handling publishing localized documentation. Since I’m not involved with translations I don’t see myself being involved in this discussion after UDS, but I am certainly going to follow it as it develops.
- Live IRC Support In Apps -
This session covered a proposal (and live implementation with an app written in Python) for a “live help” client for the desktop which has an IRC back end. The initial stab at implementation is clever but probably won’t end up being workable because of the constraints of the IRC medium, since it creates a whole new channel for each support request, an idea which probably won’t scale (and might upset freenode). I was also somewhat concerned about handling quality of support, citing that when people use an app from their desktop itself they tend to think the person on the other end is a professional, but my doubts were mostly laid to rest when the discussion went in the direction of making it clear that it was free, community support, and perhaps they’d even add a link to paid support options. A very interesting session in all, it’s always exciting to see how people are innovating to improve the user experience.
Once sessions wrapped up several of us decided to take one of the evening buses in to Waterloo for dinner. It was raining so not the most beautiful night in town, but we were able to find a charming little restaurant, Restaurant L’Amusoir. Only a couple folks really knew French, so we were dependent upon them (this is steak with frites, right?) but it actually wasn’t too difficult, and the waiter helpfully knew enough english so that we were able to get by. So we ordered a round of beers and some amazing steaks.

First up was the Waterloo Triple 7 Blond, which was really nicely balanced, if a bit strong for a first beer of the evening. Then it was on to the Mort Subite, a lambic made by Alken-Maes Brewery. I ended up with a Kriek (in spite of the photo above being of a bottle of Framboise, the glass itself has Kriek!), which was quite sweet. Dinner itself was a generous portion of steak with creamy mushroom sauce, salad and frites, and was nothing short of spectacular, if a bit filling!

Around 10PM we caught the bus back to the hotel and settled down in the hotel bar where I picked up a Delirium Tremens. Now, Delirium Tremens is one of my favorite beers in the world, and it isn’t particularly hard to find in the US, but all of the beers server here at the hotel are familiar so I figured I might as well go with a favorite since new wasn’t an option. I ended up having some great chats about beer with Jan Claeys, continuing the dozens we’d had online previously, it was really a pleasure to be able to finally enjoy some beers and talk in person. I headed to bed shortly after midnight.
Now off to start day 3! Tonight Ubuntu Women is having a team dinner down at Drug Opera Restaurant, if you’re at UDS and reading this and would like to join us (no, you don’t have to be a woman, just be supportive), check out the signup section on the LocalParticipation page so we can get an accurate count for our reservations. Afterwards we’ll be heading over to the famous Delirium Cafe.

So according to Naked Law, the technology blog for the law firm I used to work for, Centrica contracted Accenture to write some software, and that software turned out not to work like they wanted. The court found Accenture liable for around u00a329 million. The lawyer response?
[This] demonstrates how widely the Courts are willing to interpret 'direct loss'. This will comfort the customer, but IT suppliers may want to consider strengthening their liability clauses.
Or, y'know, writing software that doesn't suck.
This is why I no longer work for lawyers.