having made our beds, we now lie in them

Oh my. Poor Dave Neary. He was just trying to offer some insight into how GNOME gets put together, and it ends up serving as an outlet valve for some pent-up frustration towards Canonical, in this case via a blog entry by Greg DeKoenigsberg.

Perhaps Dave's presentation could have been a bit "safer" if it had looked at just more recent times, or covered more than just commit rates, but presentation time is limited and, really, any information on how your community works and is put together is invaluable to its health and improvement. If I were part of the GNOME community, I'd be looking for ways to embrace Dave's hard worked for information in positive ways.

Dave's intentions were undoubtedly good and he put an obvious amount of time and effort into his presentation, but was repaid with a very public and unflattering flame war about something rather tangential to his goals with that presentation. Ouch.

Tribalism

Why does this happen? That's a great question, and I'm not sure we can ever have all the answers with perfect accuracy. Maybe we can summarize and approximate, though, and discover useful things as a result. Mark Shuttleworth offers that the problem is tribalism, and that tribalism in the form of fanboyism is Bad(tm). I think Mark hit the heart of the matter.

Here's an unfortunate part of the truth, though: while Mark rightfully comes out against tribalism, Canonical has, in my experience, been as much a part of fostering tribalism in F/OSS as anyone else. In fact, I'd say they are right there among the leaders in doing so: it's a side effect of their immense drive to build a rabidly loyal community around their brand and their propensity to try tell other communities how to do things (e.g. how to schedule their releases).

After all, it's pretty meaningless to be a self appointed dictator for life if you don't have a kingdom to dictate, right? (That's said with my tongue placed firmly in my cheek. :)

Those are rather tribalistic concepts, though, and it is reflected in choices such as Canonical's decision to use launchpad rather than upstream repositories that already exist or how we see Ubuntu LoCo's displacing more diverse Linux interest groups at the local level. It isn't zero-sum, though: Canonical has their reasons and there are benefits that come along with the challenges. I even believe that Canonical's motivations are not conspiratorial in nature, but are similar to those that drive rest of us: making F/OSS awesome. I also recognize that mistakes get made, in spite of those good intentions. Most importantly: Canonical isn't alone in this set of interactions. We are all part of this thing.

If you are an Ubuntu or Canonical fan (or Mark :) and you read that, it might sting a bit (or maybe even a lot) and the instinct might be to react quickly, negatively and loudly. After all, who the hell am I to say something like that, right? :) Instead, maybe we can step back for a moment, turn off the flamethrowers for a little while (there's lots of time and opportunity to use them later if we wish to ;) and really think about the root causes of our tribalism. Much of it is going to turn out to be innocent, but all of it will show where we have room for improvement.

On Being Able To Admit Failure

One thing I've learned in my travels as someone who dabbles from time to time in providing leadership is that in doing so your faults will be put on display for everyone to see. We are each imperfect, we all screw up from time to time and being front-and-center means our screw ups get put front-and-center, too. It is humbling. It can be important to recognize when it happens and (even if it takes a while) come back and go "yep, I screwed up, let's see how we can improve on that going forward..." At that point we all grow and become better people for it. If we do that within our Free software communities, our communities will also become better for it. Linus' ability to do that makes up for many other faults he may exhibit from time to time.

Someone asked me the other day on the kde-promo list how KDE people can expect to get the KDE branding terms "right" when even I don't always get it right! I responded with the most honest answer I had: I still, even now, make mistakes when it comes to the branding terms, in large part because I've been doing the "KDE thing" for so long that it's like an old dog with new tricks. I asked them to continue to point out when I get it wrong so I can improve. It's often hard to say things like that without hedging, especially for those of us with hard heads and big hearts.

I've also discovered that, sadly, I'm going to offend or let down those I love dearly from time to time even though I really don't mean to and don't want to. When that happens, it's often more important to just say I'm sorry without worrying about defending what I did, even if I think it was a misunderstanding or justifiable. I have been working for many years on being able to prioritize the well being of those I care about more than I do about being "right". Let me be honest: it doesn't come naturally to me, and I still fail at times. But ... I also do manage to say "I'm sorry", to look for root causes without looking for blame to attach to it, and most importantly to me: to try and work on improvements that address root issues. I keep trying to remind myself: "I am an imperfect man reaching for the unattainable goal of perfection; and I am inching closer to never getting there every day."

Ok, so what's my point, already? Well ...

When Mark wrote about tribalism, Máirín dredged up in the comments section an unfortunate and regrettable public gaffe on Mark's part from the past and asked him if he'd apologized for that yet. Maybe Mark should consider doing just that, even if he doesn't consider what happened to be wrong in his own mind. It could help drain away some of the poison out there that is used to fuel some of those tribal fires. It certainly can't hurt.

In fact, all of those who have pointed fingers or defended themselves loudly, including (but certainly not limited to) Greg, could maybe try to step aside from their own correctness and ask what are the shared root causes that lead to this state of affairs. Can we instead create discussions with ourselves and with each other that reach for understand but don't include statements of blame or accusation? It is possible to discover the mechanisms of failure in a relationship and come up with new possible solutions to try in blame-neutral ways.

That's just another way of saying that others may be responsible for (a large or small) part of the current dynamic, but we don't need to use that as an excuse to sidestep responsibility for the roles we play in it or as a way to avoid addressing the issues altogether. After all, what's more important: the moral high ground in our own little kingdoms of "Me, Myself and I" or forging a stronger and unstoppable thing together?

On Being Part Of The Problem Solution

The good news is that when we are one of the people caught up in a problem, intentionally or not, we can be part of the solution. Yes, being part of the problem is an opportunity. To illustrate: we may not have invented proprietary software ourselves, but we are/were caught in the midst of the consequences of a world that was dominated by proprietary software; by writing Free software, we are creating part of the solution to the negative effects of that situation.

In the questioning of Canonical's contribution, right now I see a lot of people trying to make the case that they aren't a part of the problem or that others are more a part of the problem than they are. Quite clearly they axiomatically are all shareholders in whatever failure is happening (the flamefest itself is a failure, imho). It is axiomatic because the problem is being driven by how communities are interacting, and the people pointing fingers and making defenses are part of those communities. Some are even responsible for leading the relationship components of those communities. They could be identifying what the challenges are and being part of the solution, regardless of who is contributing what to those challenges in the first place.

If each of the parties (GNOME, Canonical, Red Hat, whoever else) involved took internal stock of the situation they might identify all kinds of things they can each do to improve. How much better than writing witty blog posts that won't alter the status quo that would be! Leadership will be self-evident when people start describing and implementing such improvements, regardless of whether others do so first, later or never.

On Alignment

Starting with the alignment of priorities and agreeing on the context for the conversation would be a reasonable place to start, perhaps. To illustrate what I mean by that: Jono Bacon
used the term "upstream" in his response to the issue in a way that is very different from what the people leveling the complaints at Canonical are. Jono used upstream in terms of Canonical's own efforts: their software developers are upstream of their packagers. However, it seems evident to me that Greg and others are using the term in the context of the global F/OSS economy, where in this case GNOME is the upstream of Canonical. It's the difference between looking at the supply chain within one particular company's factory, and looking at the role of that factory in the greater economy in which it operates.

Due to this difference in context, people are engaged in a conversation about upstream contribution in which both are 'right' in terms of the context they have chosen to speak from. This also means, though, that neither party is really addressing the same issue together. As long as those kinds of context and priority differences are not addressed so that a common conversation can be had, it will be a very long, hard, painful and probably unfruitful conversation.

I've been caught in many such conversations in the past with others in F/OSS. It happens; it's also fixable.

Why Care?

I believe it to be important that we care about these things because they are doing large amounts of unintended damage to F/OSS. But as my step-father used to tell me, "When you point a finger at someone else, you are pointing three fingers back at your own self." (Try it: point at something with your index finger, arm extended. :)

So let me address those three-fingers-pointing-at-myself. To be honest: the relationship between KDE and Canonical has not always been fruitful or friendly, ditto for KDE and Red Hat or KDE and GNOME. Even within KDE we have our moments of discord. It's not easy, it's not simple and I do not want to come off like I'm pretending it is or that my or KDE's track record is perfect either. KDE has managed to improve many of these things, some of them immensely though certainly not to perfection, but you know what is really unfortunate and sad when I reflect up on that? The root causes, tribalism and selfish misalignment of priorities relative to each other, were / are the same as those at the heart of today's tempest in a teapot over Canonical's upstream contribution and/or lack thereof. F/OSS has yet to truly learn the lessons we need to. We keep repeating the same unhealthy behaviors, we keep enabling each other in doing so.

I have to say that it was really tempting to delve into an analysis of what, in my opinion, the specific behaviors are that led to this particular blog storm, but when I thought about it I realized that it's not really my place to do so. After all, I'm not a direct stakeholder in this particular scenario and have not been invited to enter into the middle of what amounts to other people's relationship. So instead, let me get a little philosophical about what it might take to step away from our feudalistic ways:

We ought to be looking for F/OSS communities who can lead in demonstrating positive and useful ways of dealing with these somewhat inevitable moments of conflict. We need to encourage those who aren't leading in this way to improve their game; we need to give each other the opportunity to improve our game by avoiding blame games. We need to support each other in our hard times and our moments of brilliant alignment. For those who insist on tribalism, the rest of us need to move past them and minimize their impact and importance in the F/OSS ecosystem, so as to limit the harm they perpetuate.

We need to learn how to accept that someone is going to be a fan of $DISTRO or $PROJECT without using that against them. We need to learn how to be a fan of $DISTRO or $PROJECT without looking for ways to push for its advantage at the expense of F/OSS in general. We need to learn to recognize each others strengths, as well as to stop claiming that we're strong where we aren't. We need to learn to disagree without sabotaging each other. We need to learn how to cooperate, even sometimes by making local compromises to achieve a higher level of global win. We should be looking at how to put together what we are each doing well into a larger whole, even when we are also competing elsewhere. We can both compete and cooperate without dragging each other down in the process.

The path beyond tribalism is, in my humble opinion, to realize that despite our love for KDE, GNOME, Ubuntu, Red Hat, Suse and/or fluffy bunnies we must each hold aloft a common goal that trumps all else: F/OSS must succeed. The world is depending on us to do that, because the world needs Freedom, and Free software is an important part of that.

That is the challenge we have before us. Sort of puts things into perspective, doesn't it?

But Before I go ..

Kids are smart. They will learn that when you do something bad you get attention even if it is negative. If they don't get the attention all children need in the course of growing up, they put this together in their head and start to look for ways to break "the rules" to get that attention. To be fair, some adults do that too. :) As an adult who plays a role in the child's life (a parent, especially), that pattern can be prevented by (among other things) paying attention to the things they do that are positive.

In that spirit, I'd like to end this blog post by giving a shout out to a few of the communities out there that are doing good things. Good work deserves attention and recognition, and you shouldn't have to be in the middle of a controversy to get it.

I'm thinking of OpenSuse, for instance: they make hard decisions and are pretty open about how difficult things can be internally at times, but they've consistently been a pleasure to work with, even through difficult times.

I'm thinking of Pardus, a small but hardworking group of people making an awesome distribution aimed primarily at their own region, but who are also doing all kinds of wonderful things technology wise both in their project and upstream.

I'm thinking of Red Flag who, despite other possible negatives, have also been contributing more and more upstream over time.

I'm thinking of Mandriva who, despite their financial bumps over time, have not only never caused grief for us as an upstream project but have contributed significantly.

I'm thinking of the numerous small and medium size businesses who aren't distributions but who are as important as many of the distros in making sure upstream keeps ticking. I'm also thinking about you, reading this blog entry because you care enough about these issues to do so with an open mind.


p.s. I'm concerned, having re-read it (and edited it several times), that this blog entry could come across as preachy. I really hope it doesn't, but I do recognize that my communication skills have limits to them and some may choose to read it that way. It feels rather unsafe to push the "Publish Post" button, and honestly I am hesitant to do so. It seems, however, that these are things that need to be said, and I can only hope that some of it is useful and gets through to those who will make things better than they are now. Deep breath time!

Love and with hope for all the best things in life, Aaron.

Read More

Plasma in KDE's Wikis

The Plasma team tries to care about documentation. We always fall short of our own high expectations, in part because they are high and in part because we don't have a technical writer in the project. What a difference just one technical writer as a Plasma team member would make!

Still, we have quite a bit of documentation around. This includes API docs, examples and Techbase tutorials. I'm quite proud of the comprehensive documentation we have for things like the desktop scripting, Javascript API and Theme contents (thanks to Marco for updating that one today!) as well as the growing number of examples we are adding.

We have, however, been committing two sins: we've been abusing Techbase as a project community wiki and we haven't been writing end user documentation. We're fixing that, but before I go into details I'd like to point you to Dominik's excellent reminder-by-blog regarding the mission of each of KDE's public wikis. To quote the summary from that blog entry of his:

• TechBase: The primary place for high quality technical information about KDE targeted at 3rd party developers, ISVs and system administrators.


• Community: The working area for the KDE community. It provides a place for sharing information within the community and coordinating community teams.


• UserBase: The home for KDE users and enthusiasts. It provides high quality information for end users on how to use KDE applications.

Community.KDE.org

So everything we have had under Projects/Plasma on Techbase really is supposed to be on community.kde.org. We started, and are very nearly complete, that transition. You can see the results on community.kde.org/Plasma. We've used this as an opportunity to freshen up and reorganize some of the content.

If you are involved in a project that has content under techbase.kde.org/Projects, please also consider moving it over sooner rather than later. I did a few pages a day (so that I didn't get bored by it ;), spending no more than 30 minutes or so at a time doing so. Marco also pitched in with the Theme Details, which has now moved to being a tutorial and out of our community coordination wiki space. So it's very doable, you just need to budget a little bit of time. Best part is that it taxes no brain cells, so makes a great end- or beginning-of-day task for when you'd like to do something KDE but can't bring yourself to do any heavier lifting. :)

All Hail KDE User Documentation Writers!

Next up is user documentation. While in Finland for Akademy 2010 I made a personal commitment to Anne Wilson, one of this year's Akademy Award rockstars, to write user documentation on Userbase for Plasma. It's not quite as selfless as that may sound at first. You see, there are those who would like to see Userbase become the new spawning ground for end user documentation.

This is due to the fact that there are, and have almost always been, just a small group of absolute heroes who have worked on KDE documentation through the years. They have done an awesome job with the resources they have to work with. In fact, one of the key players thus far in documenting apps based on the KDE Platform v4, Burkhard Lück, was also recognized with an Akademy Award this year. There is only so much a small group can do, however, and our software moves quickly. In addition, our users are more and more web-centric when it comes to looking for information.

Wouldn't it be great if we had a way for more people to participate easily in adding to KDE user documentation? How about providing our documentation in a more familiar web format as well? Enter Userbase, a mediawiki-driven site that may just be a key part of the answer. It has a passionate and committed project driver behind it as well in the form of Anne.

The goal is to therefore put more and more user documentation on Userbase where it can be groomed and improved into stunning user documentation. There may be some nay-sayers who think that user documentation is a work of art (and I agree to an extent) and requires skill to do well (again, I agree). The issue, however, is that it's too difficult for those with the skills and sense of the art to get involved. That difficulty is in part perceived ("how do I contribute?" is such a common question) and in part real (barriers not low enough). Remember that many people said the same thing regarding art and skill about encyclopedias and maps. Turns out this kind of content creation does work pretty damn well. Hello, Wikipedia. Hello, OpenStreetMap.

Realizing The Dream

For this dream to enter reality, though, several things were needed. Translation is a solved issue now from what I understand (kudos to those who got that going!), but still outstanding was the ability to generate offline versions of the contents of Userbase so that we don't require going online every time you want some documentation about a KDE application. There was the intent and the desire to work on this, and even a good start to it.

So I decided that out of respect for our users and for the work people were putting into Userbase that I should put some of my own skin into the game as well. So I told Anne that if they got the offline creation of the documentation working that I'd document on Userbase how Plasma Activities work from an end user perspective.

Well, guess what Anne and her co-conspirator Ingo Malchow have managed to do? Yep, they've got automatable offline document creation of Userbase content figured out. There's a remaining issue of whether to use an online service that exists outside of KDE for this, or to set up our own installation of the same (Free! :) software on one of our own servers. That's an implementation detail, though. The hard work has been accomplished in my opinion. Which triggers my commitment.

So I will soon be starting to work on Plasma documentation regarding Activities on Userbase in the Desktop area. I also plan on tidying up the organization of the content that is already there as I go. It will take me several weeks, I imagine, to complete this task. I also hope that by throwing some of my energy into it, that it will encourage others to follow suit. Particularly those amongst our users who are reasonable writers; and remember: if you are concerned about your English skills, it's a wiki .. we can help fix errors if/when they appear. We appreciate content added to the point that it wouldn't even cross our minds to think poorly about good content that happens to have a few English mistakes. We also will need the English content translated so that we can offer this much needed documentation to all of our users across this blue marble we live on together.

I'll keep you all updated regarding my progress and what I learn as I go through it. Anne and I also discussed the possibility of doing Documentation Days, similar to how we used to do Techbase Days (which would be nice to start up again as well) and the very successful Bug Days.

(Speaking of which, did you know that Bug Days are starting up again? Yep! Next one is the 1st of August, so be sure to mark it on your calendar and show up for some bugtastic fun. :)

Read More

today's 30 minute hacks

I ended up taking two "breaks" during the day today to do "30 minute hacks". This is where I do something in the codebase that may or may not end up being useful but which I find interesting to try out, keeping the exercise to a length of 30 minutes or less.

The first one was moving around some of the UI in ksnapshot (after chasing down an annoyance in kdelibs that would pop up a notification every time ksnapshot started if you had last saved a snapshot to a remote location). Here's the result of that "30 minute hack":

The default size is bigger (and it remembers the window size between restarts), the snapshot thumbnail has a bit of a shadow around it and the buttons have been re-arranged. Other than the window size saving, which I consider a bug fix, I'm not sure if the rest will make it into the next release or not. We'll see. I'm currently waiting for feedback from Rich Moore, my KSnapshot partner in crime. ;)

The second "30 minute hack" was inspired by finding a blog post I found linked to from Linux Today. One of the ideas behind making Plasma a flexible architecture is that people could not just talk but also do. When things are welded at the seams and full of internal assumptions, it can be hard to make changes. When things are loosely coupled and free of internal assumptions it is easy to make even radical changes. To prove this, I tasked myself with implementing this screenshot in half an hour:

Well, I "failed": it actually took me ~45 minutes to come up with this:

It has the arrows and dots, everything is clickable and works as described in the blog post and you get more or fewer dots when you add/remove virtual desktops. All of the elements are QGraphicsWidgets that belong to the Desktop containment and the arrows are drawn with an SVG from the standard Plasma Desktop Theme. Since they belong to the containment, they don't need to be set up, they aren't removable or movable, desktop widgets can freely overlap them and they show up on the widget dashboard (assuming dashboard-follows-desktop). I can imagine any number of nice improvements to it: some text saying which desktop you are on; on-hover animations for the circles; only reacting to clicks when they are on the circles, not just on the rects that bound the circles ...

You can find the diff against kdebase/workspace/plasma/desktop/containments/desktop here. Maybe someone will take that patch, fork the Desktop activity with it, spiffy it up a bit and release it with a new name on kde-apps.org. Personally, I'm not sure the idea of the arrows/dots on the desktop for virtual desktop switching is all that hot, but I wanted to show that not only are these kinds of things possible ... they are easy to do. That kind of flexibility doesn't happen by accident: we want people to experiment, try new things and re-shape Plasma apps in various ways. (An up-coming blog post about Plasma Classroom will touch on exactly this point.)

Now, if it took me 3/4ths of an hour to implement that, I can't imagine it taking someone with a little bit of Qt and/or KDE development experience more than a couple of hours to do the same thing. In fact, I bet many of you reading this could have achieved the same or better results in the same amount of time (maybe even less!) than it took me. So get hacking, people! :)

Read More

snippets

It's summer time and the living is ... hectic! I'm back from Akademy, which was amazing (more on that in the days to come), and my schedule is packed to the brim and then some. The list of KDE and Plasma related activities on my plate is a bit astounding, but it's all scheduled up now and feels manageable. I've even set aside 30 minutes a day for blogging again, so you can expect to see regular updates here again.

On top of that, P. and I have been enjoying the summer: yesterday we went biking down along the ocean stopping at various beaches between Kits and Jericho as we went. A pit stop for ice cream was also required, of course! Round trip was about ten kilometers, but it felt more like one as we sailed along the pathways and streets of Kitsilano next to white sand beaches under a beautiful summer afternoon sun. I'm finding that ten (which is how old P. is these days) is a great age: increasingly independent and able to keep up, but still wants to hang out with his dad. ;)

I've also been working in my evenings/weekends (because I don't have enough to do these days, right?) on a Super Sekrit Projekt(tm) with my good friend Zack and it's nearing fruition. Some who were at Akademy would have caught my hallway presentation of it, and we're gearing up for a release before 2010 is done.

I did the usual "step back and check out the upcoming SC release" the other day, using Plasma Desktop and various KDE Applications from the 4.5 branch next to P.'s laptop running version 4.4 of the KDE software compilation. A number of big and little annoyances jumped out at me in the 4.4 version as I started using both; the 4.5 release is going to be a big step up in terms of completeness and polish. Kudos to everyone who has been working on it!

A flurry of activity has already started for the 4.6 development cycle, with Google Summer of Code projects getting to mergeable states and trunk open again for feature commits now that SC 4.5 is into the release candidate phase. I have an upcoming blog (3, actually) about Plasma in SC 4.6 so I won't go into too much detail about it right now. I did manage to find a bit of time yesterday after lunch to sit down and do something that I wanted to have. It's a bit funny but these days I don't do many features "just for me", but it's nice to find time for that once in a while still. So what did I do?

Well, I use the Javascript-powered desktop scripting console quite a bit.

(You may notice that there's a mouse cursor in that snapshot! KSnapshot in SC 4.6 will support grabbing the mouse cursor, which is a feature that was submitted by one of our enthusiast users via bugs.kde.org. Huzzah!)

I find that the desktop console is a great way to tweak things in the desktop quickly and test configuration changes on the fly. In SC 4.5, it now autosaves/loads the last script you are working on which is quite handy. But I often want to switch between different scripts I have sitting around. You can indeed load scripts from disk by either supplying the path to krunner when opening the desktop scripting console or using the Open button in the console's toolbar. I wanted something better, though. I wanted snippets.

In SC 4.5 we already have the ability to create layout templates using Javascript. These templates are bundled up in little Plasma packages. The plasmapkg helper app understands the package type "layout-template" in support of this, meaning you can easily install, remove and update template packages. Do you see where I'm going with this yet? (I bet you do! :)

(As an aside, when I read Matt Zimmerman's blog entry on divide-and-conquer as an approach to packaging I found myself nodding and thinking, "Yeah, that's exactly what we're doing!" :)

So here's what I ended up with after ~15 minutes of hacking:

All installed Javascript layout packages appear in the Snippets menu in the toolbar. Select one and it is loaded into the console for you to tweak and try. To complete the effect, I'll be adding:

• export the current script as a layout template package


• save changes made in the console to the layout template that was loaded


• share templates with other users via kde-apps.org

Each of those items will take less than an hour of work, so should fit neatly into those little pockets of "I need to scratch an itch!" time that pop up every so often. This probably won't be a feature most of our users care about, or even ever see, but I know it's a feature that I'll be using on a regular basis. :)

Read More

akademy videos

Kenny Duffus is a hero. Not only does he help Akademy organizing teams year after year on the march towards success (and this year's Akademy has been a roaring success this far!), but he's worked to get videos up for the keynote presentations in a timely fashion. His poor little netbook churned all night long to encode four videos: the opening, the first keynote, my keynote and the Telepathy presentation. More videos are coming as they get encoded and you can find them on the conference program page, starting right now with the four aforementioned videos.

If you'd like to know why the word "elegance" is a key to KDE's present and future, check out the video of my talk.

Right now, I'm sitting in one of the Uni rooms which is slowly filling up with KDE e.V. members for the annual general assembly of the society. Our goal this year is to do the whole thing in under two hours. I remember how the second e.V. meeting I was at ran to something like 12 hours including breaks, with the first one not being all that much better. The refinement of process within KDE e.V. has been remarkable over the last few years.

I also saw the awesome tri-fold brochures for Join The Gamem KDE e.V.'s supporting member campaign. They look positively awesome and are sure to make a splash at all the events KDE shows up to this year!

This afternoon is a big Plasma team coordination meeting and then hack, hack, hack, HACK! (The planet? ;)

Read More

start your Akademy engines!

I arrived yesterday in Tampere, Finland for Akademy 2010. The travel went amazingly smoothly and I have even managed to my way around the town without much fuss. (I'm usually quite good at getting mildly lost in new cities, which I try and treat as an opportunity to discover things I wouldn't otherwise. :) Lots of KDE and F/OSS people are here already and the "day 0" hugs, visits, beer and food was excellent. My presentation slides are ready for tomorrow, though I want to go through my speaking notes one more time (and probably copy them over to fresh paper as they've become a bit of an edit-mess). So everything seems to be going very smoothly so far. I'm about to leave the hotel for the Uni where the first day of the conference proceedings will commend in ~90 minutes. The opening keynote talk is about MeeGo, and is being given by the Director of MeeGo Software in Nokia. I can't think of a better way to kick this whole thing off, and am really looking forward to the full day's worth of presentations and hallway meetings.

As the days go on, I expect there to a steady stream of news and updates to share. I'll try to augment the news that appears on The Dot with updates both here on my blog as well as as on my identi.ca stream where I'll hopefully be able to "live blog" the presentations.

Read More