Last year, something pretty awesome happened. One of the world’s most widely used operating systems got released under a Free license. Nokia and her partners worked very hard, and were even able to get through the legal jungle that’s always involved in such high-profile projects very quickly. The result was that the source code for Symbian became available much quicker than initially thought it would. How’s that for a project finishing early, instead of late?

Some months ago I was contacted by the Symbian foundation, who were in the process of setting up the Symbian DevCo, a non-profit organisation registered in the US which will relay between the Symbian foundation and individual developers who wish to take part in developing and directing the future of the Symbian operating system. Coming from the mobile phone industry, which hasn’t been known to be very open in the past, the governance model of the Symbian ecosystem is very much aligned to what works for large corporations. That means that if you want to take part in decision-making, or in maintaining packages in the official Symbian upstream, you have to be a company. Now most players in this ecosystem are, but requiring to be a company can also pose potential barriers to those many who can bring a lot to the Symbian ecosystem. Being able to toy around and develop using a certain technology without any restrictions is at the heart of any open eco-system, and this is where the Symbian Developers Cooperative (or simply devco) comes in. The Symbian DevCo gives a voice to individuals involved in Symbian.

Taking part as an associate in the Symbian Developer Cooperative means that individuals now have

• The ability to become a Symbian package owner
• The ability to be nominated for a seat on the Symbian technology Councils
• The ability to be nominated for a seat on the Symbian Board of Directors.

Those are three important privileges which have previously not been available for individual developers, and I think they’re absolutely critical to opening up the ecosystem, in tandem with Symbian’s source code. In order to low the barrier for participation even more, becoming an associate is free of charge.

My Role – President

That’s what it’s called officially. I’d personally much rather think of it as sanity checker and get-things-go’er. During our first board meeting, which happened last Tuesday, we talked a bit about the roles within the board. My prerogative was, from the beginning "Do not come back with a treasurer’s hat", as that would not be good for anybody involved. (I’m good at spending money, not good at keeping tabs, and even worse at that pesky thing called "acting responsibly". ;-) My idea of this role is to learn, to listen and to get people involved that really care about an independent governing process of the Symbian platform.

While I have to admit I’m rather green when it comes to Symbian, and its ecosystem, there are measures that should alleviate this. First of all, I’m an eager learner, and secondly, much more important, there’s the advisory board which does exactly this: Advise the board, bringing in expertise from the industry and the Symbian community. And if someone comes along who fits the shoe better, I’m all for passing it on. For now though, it’s important to get the thing running, and my experience in running the KDE e.V. together with my awesome fellow board members there comes as an advantage.

This position is voluntary, meaning I do it deliberately, and that I don’t get paid to do it. Well, technically, my awesome boss allows me to spend some of my work-time on this, but it’s all up to me how much that will be. After all I have this time-consuming hobby called KDE already (which also is part of my job). (This is just so I can say that I’m spending 60 hours or more a week on work-work, while in fact large part of work-work is fun-fun. Confusing, but awesome if you ask me.

Isn’t Symbian on the Demise?

It surely seems so. On the other hand, that doesn’t happen within a day or two, and according to analysts, we’re looking at at least another 5 years of Symbian being very relevant in the mobile space. A lot can happen in 5 years, so I think my time is definitely spent well. As of today, Symbian sales are still staggering: 260.000 Symbian-powered devices are sold each day, that’s slightly more than 3 per second (figures are based on the 1st quarter of 2010).

In the end, what matters to me is Software Freedom. Which technical implementation is leading us there is only secondary. If Software Freedom comes a bit closer today, and I think that’s what happened with the release of the Symbian operating system and the opening up of the ecosystem, I’m a happy person and glad to play my part. Taking this responsibility to lead in an area that’s traditionally (and understandable) a weak aspect of the Symbian (and in extension) mobile ecosystem is how I contribute to a world where Free Software is the norm, rather than the exception.

What about KDE?

Does this mean I will leave KDE? Surely not, my role in the Symbian DevCo is only part-time and voluntary. I’m as much motivated and committed to moving KDE forward as I have ever before. My involvement with Symbian will mainly have positive effects on my participation in KDE: my expertise and angle of view will expand, and like the Symbian DevCo benefits from my expertise in running a community-driven Free Software organisation, KDE and the KDE e.V. will benefit from the new insights and expertise I’m collecting as part of my involvement with the Symbian DevCo. Simply Symbiantik, isn’t it? (Ok, I just had to finish this boring blog entry with something really cheesy. Mmmhhhhmmm cheese…)

To make this blog entry slightly more useful, I’ve found the Android WordPress application pretty handy. In order to prevent spam, I’ve enabled moderation for the first comment of a person. This way I can more easily keep moderation times down and make that necessity a bit less annoying by quickly approving non-spam comments on my blog. The Akismet spam filter is already pretty good with 99.8% accuracy, the overall ratio spam vs. comments being roughly 50/50. Comment spam that slips through Akismet is caught in moderation, that way I can make sure that no spam shows up at all. WordPress on Android makes the approval process rather handy. It would be nice if the app could automatically check for comments and notify of new ones that need moderation though. If you don’t like web browsers to manage your wordpress blog, I find Blogilo as a desktop client and wordpress on Android app a very nice combo.

This year’s Akademy is significant to me for a number of reasons:

• I’m running for a second term on the Board of Directors of the KDE e.V., the foundation backing KDE. I’ve taken this opportunity to re-focus on my activities there. I will be working towards improving the organisation’s transparency a bit more. Transparency of the of our activities sometimes falls behind a little, since we’re very much focused on getting things done, and there’s always something important to push a little further, at the same time, status information gets outdated rather quickly. With the launch of our Supporting Membership Programme, it’s even more important to get the word out what the KDE e.V. is doing, so that’ll be what I’m working on on that front.
• Last year, Richard Moore and I started Project Silk, which has been silently tagging along. Silently doesn’t mean that we didn’t make progress, just that we didn’t talk about it as much as we could. We felt that we wanted to show results before talking a lot about it, so we sat down and wrote code, worked out concepts, talked to people in order to verify and improve on our ideas. I think we’re at a point now where we got some really compelling stuff to show, and to prove that what we have in mind is not only very viable, but also very important to move on. This year’s Akademy will in part be used to spread those ideas within the KDE team, and to get more people to think Silky. If you think that’s all too vague, attend my talk during Akademy. For the few of you, my dear readers who won’t make it, I’ll prepare some online resources over the next days, so you can catch up as well, and join the Silk bandwagon.
• Meeting my fellow hackers from the KDE Plasma team. After our last meeting in February in Nuremberg, we’re getting together at Akademy next week to plan, hack, gather ideas talk and have fun. What I really enjoy about getting us together is the sparkling you can see above the table we’re working on after only shortly being together. I guess it’s the motivation, the friendliness, the shared love for beautiful, intuitive Free software but also the mutual respect that creates this atmosphere where we’re getting into hyper-creative mode. It puts us in the position to think about solutions for the really hard problems out there, which none of us could solve individually, and it has more than once been the start of exciting new features and sub-projects.

[break] So I just got home, into our hot top-floor appartment in Nijmegen, The Netherlands. Everything’s been taken care of by our terrific friends, the cat is better now after a bladder infection we had to leave it at home with last week. While I do like summery weather, temperatures beyond 30 degrees centigrade without a really cold room are a bit too much for me, and tend to have a bad effect on my productivity. Band-aid: Work at night as much as possible, keep the sleeping room as cool for as long as it lasts and stay in bed as long as I can to get the needed sleep. The laptop is already compiling an updated trunk, while I’m enjoying Brazil playing Chile (Robinho scores the 3:0 as we speak, so I guess my special friend Artur will be happy).

As users’ needs vary, we decided to make the Akonadi port of KMail opt-in for the 11.3 cycle. openSUSE 11.3 is based on KDE SC 4.4, and as such will install the "mostly traditional" PIM suite. Users will not automatically be upgraded to KDE SC 4.5 (which is due in August), but in all likelihood it will be easily installable. As there are many people who follow KDE releases closely, many will install SC 4.5.0 and followups from the Factory repositories, so when 4.5.1 is released, these users’ email would get migrated to Akonadi automatically. That might come as a surprise, as it’s unconventional to make such a big technological leap in what looks like a bugfix update. So in openSUSE, we will keep shipping 4.5.0′s KDE PIM even in Factory, but also make available packages that replace KMail1 with KMail2. Users will be able to opt-in to the Akonadi migration, so they can do this upgrade when it fits for them. From a discussion with the PIMsters, it also looks a lot like you can try the Akonadi-based KMail, and if it’s not ready for you yet, you can switch back to KMail1 without losing your config. That’s a great achievement by the PIM team, and shows that they’re developing with end-users in mind.

For the user, this means that for the innocent nothing will change automatically in the upcoming cycle (other than bugs getting fixed). The effect is that there will be a roughly 6 months long window in which users have the choice whether they just want their KMail to not change, or to jump on the Akonadi bandwagon into the future.

This upgrade also gives us (upstream KDE and downstream openSUSE) the opportunity to make the migration and workings even smoother, and deliver some icing on the Akonadi-cake with the openSUSE 12.0, which show why Akonadi is a darn useful thing to have. I know many people (and I am one of them) who are looking forward to make full use of Akonadi, not only in the applications you’d expect it to be, but also integrate all the interesting information from Akonadi also in other apps. I’m sure some very interesting features will crop up after Akonadi is fully upon us.

I’m now running openSUSE on my desktop, which has an AMD RadeonHD 4350 card. That card is fast enough for my graphics needs (compositing window management, a dated game once in a while) and still passively cooled and providing two DVI outputs for my dualhead setup. I’ve been using an NVidia VGA before, but switched to AMD/ATi when I last upgraded my desktop workstation (to an Intel Quad core, meaning new mobo, graphics as well). I picked a RadeonHD card instead of an NVidia chip because of AMD’s open dealing with specs, something which I deeply despise in NVidia. So, NVidia, there you go: You lost me as customer because you’re too closed a company.

Now bitching about NVidia is not the (primary ;)) goal of this post. The goal of this post is, that with openSUSE 11.3′s graphics stack, I’ve been able to run a composited desktop with the Free radeon driver finally. While there were some hickups in the installation procedure (normal for a beta release), it now all fell into place, and I’m enjoying fast, beautiful graphics with a completely Free software stack. That is a lot of work from the Xorg people that has finally come to fruition: There’s the new DRI framework in the Linux kernel, along with drivers supporting compositing for many of the "newer" RadeonHD models, the compositing support for newer chips that has landed in the latest Xorg, all on top of the EXA acceleration infrastructure. If you’re interested what you can expect from your upgrade to 11.3, check the feature matrix compiled by the Xorg devs.

I’ve tried the setup on Ubuntu Lucid Lynx in the first place, since that’s what was installed on the workstation before, but didn’t have much luck. The kernel shipped with Lucid is just one version too old it seems, so lacks the functionality necessary to accelerate graphics suitable for compositing. For that reason, I’ve upgraded the kernel to 2.6.34, but only to find out that my Xorg is not good enough. Tried installing newer packages from the xorg-edgers repo, but that just resulted in my system hanging solidly during boot. (That’s to be expected if you’re using bleeding edge Xorg, and upgrade your own kernel, but still a shame it didn’t just work ;-)). I assume that new upcoming Ubuntu will provide this nice out of the box experience as well, but I didn’t try it.

For many users, the most interesting thing is probably that the Free radeon driver (and to some degree the Intel graphics driver as well) provide the best user experience for running a KDE Plasma desktop. Using the NVidia driver, the desktop always feels sluggish. That’s supposedly due to NVidia not accelerating some calls that are made while switching windows, so a couple of milliseconds are added there and the whole thing feels less responsive. It’s not as bad as it was, about 2 years ago, but there’s still a notable difference in snappiness when using a low-end (non-poulsbo ;)) Intel chip compared to anything using the nvidia.ko binary driver — and that’s just pathetic given the NVidia hardware is supposedly much more powerful. The same, even if to a lesser degree, is true for ATi’s binary driver, the (in)famous fglrx.ko. This one, while it works OK-ish, also suffers slightly from this lagginess. Switching to the free driver makes the whole thing just very snappy. I could well imagine that those who are complaining about a perceived slow system are suffering from just this problem — bad graphics drivers. If you’ve recently compared the binary and free drivers for RadeonHD cards, please leave a comment so we can see if this — rather vague — theory of mine (binary drivers suck, Free ones feel faster) is true for more people.

So, what’s the epic moment? Well, the epic moment for me was seeing KDE Plasma start up with the Free driver, enable compositing automatically and by that delivering a much more beautiful and functional desktop to me, out of the box. I’m happy that with the new graphics stack in openSUSE 11.3, the same will be the case for many users out there.

The next couple of hours we spent hanging out with the parachuters from Paracentrum Ameland, learnt a bit about safety, how you’d not break your legs, and what happens if you lose your contacts in mid-air. Then we boarded the small plane, one after the other, and climbed up to 3000m above the island, giving a fantastic view over all Dutch Wadden Sea islands. Then I was secured to my tandem master more tightly, put on the safety glasses, and open went the door. At that point, I just stepped out of the airplane onto the small step outside the airplane, stood there for two or three seconds, and jumped. We fell freely for a good 30 seconds until the parachute opened (probably wouldn’t be writing this if it hadn’t ;-)) at ~200km/h, and then spent another 5 to 6 minutes slowly decending onto the airfield again. Landing went smooth, as you can see on the photo.

I must say, that was an awesome experience, it’s a really weird moment when that door opens, but the view, the experience (and certainly the rush of adrenaline) make it absolutely worth it. I wonder if I’ve left behind my slight acrophobia on that flight. As to Chris, I think he still likes me. His face, in terms of Big Smile looked about the same as mine right after the jump.

If you’ve got friends that have you thrown out of a plane in mid-air, you don’t need enemies.

Left to Right: Cornelius Schumacher (President), Frank Karlitschek Celeste Lyn Paul, Sebastian Kügler, Adriaan de Groot

Claudia Rauch, KDE e.V.’s business manager took the photo. Normally, I’m not the overdressed one (but I do wear my KDE 4.0 Release Event t-shirt underneath. On the photo, it’s not very well visible, but Celeste does have part of her hair blue.

• Maintainance – KDE 3 is a large codebase. You need a good amount of people with domain knowledge of many different areas to effectively maintain a project like KDE. I see some of the first roadmap tasks for Trinity are updating the build system to deal with all the updated developer tools (e.g. newer autotools versions).
• Upstream Support – Official support for Qt3 ended on July, 1st 2007. nearly three years ago. Now this is not necessarily a problem (as Qt, too is Free Software), but it puts additional stress on the maintainance team — you have to provide support for Qt as well, not only KDE. This is also true for many other upstream components
• Community Support – KDE has many applications, and their developers take conscious decisions wether or not to support a specific version. Moreover, developers take great pride in their creations. Patches made to those components (even if it’s just maintainance) should be reviewed by their developers (who also happen to know the codebase best, have domain knowledge, and so on). Now the resources of these subprojects are also limited, and many decided to effectively end of life the support for their KDE 3 versions and fully concentrate on the KDE 4 version.
• Interoperability – In KDE 4, we introduced a couple of new technologies, D-Bus as our inter-process-communication mechanism, and the FreeDesktop icon naming scheme for Oxygen, KDE4′s artwork pillar. This was (and is) not possible with KDE3, and is actually only the tip of the iceberg of many improvements that have gone into KDE4, and which cannot be taken advantage of by programs based on KDE 3.
• Testing & QA – While the whole KDE project switched to KDE 4, we realised that releasing KDE 3 would be a lot harder in the future, since we heavily rely on the community testing the code before releases. This assures that the code is of sufficient quality and actually works. This process is not quite trivial, it needs testing, but also reviewing of changes that go into the codebase. For reviewing code you need familiarity with the APIs used by it, the actual codebase that’s being changed, and on top of that domain knowledge of the area your program is used in (for example if you’re writing a mail client, you should know mail protocols, and so on.) Again, you need a larger team to assure sufficient quality of the code you release.

For the above reasons, the KDE community has decided to not do releases of KDE 3 anymore. Technologically, it’s a dead end since many architectural, structural and environmental aspects of KDE 3 couldn’t be solved in KDE 3. If we just kept releasing KDE 3, we wouldn’t be able to assure sufficient quality and enough support so people wouldn’t be left out in the rain. Or put in other words, it would give KDE a bad name. The KDE3 branch in our SVN source code repository remains frozen for new features, bugfix patches are allowed but make very little sense, since there’s no plan to release new versions of KDE 3.x. That’s why the Trinity developers are using a work branch.

Those are challenges the Trinity team is facing now. Some of them can be solved by pouring enough manpower, tender love and care into it. Others aren’t easily solvable (think IPC) within KDE 3. Whether or not the Trinity team will succeed in maintaining and developing KDE 3 remains to be seen, but it’s certainly not an easy task. Then again, easy tasks are boring, and the Trinity team is validating the Free Software development and licensing model. In any event, the KDE community supports the efforts (for example by offering infrastructure in the form of source code repositories), and would like to see Trinity as another blooming subproject inside the KDE community.