Sunday, December 13, 2009

Virtual easter eggs

Easter eggs are fun. A special kind of them are winter easter eggs (do you still call this easter egg?). In the spirit of this tradition we added some snow to SUSE Studio last week. Now when booting a virtual appliance in SUSE Studio's testdrive today, the openSUSE boot screen was all snow with some penguins wandering around. What a splendid coincidence. I guess you can call this a virtual easter egg. Fun :-)

Looking forward to real snow now.

By the way, did you notice that you can stop the snow in SUSE Studio?

Monday, December 7, 2009

Build openSUSE 11.2 appliances in SUSE Studio

We released support to build openSUSE 11.2 appliances in SUSE Studio today. It took a bit of time to sort out all issues and do proper QA, but now it should work fine. If you find remaining problems please let us know.

Many of you will want to migrate existing appliances using an older version of openSUSE to 11.2. In many cases it's probably not a lot of work to recreate the appliance from scratch with openSUSE 11.2 as a new base, but that's clearly not a good solution for all cases. So we are working on a way to automatically migrate appliances to a newer base system. We'll let you know when it's done.

And now for something completely different: It's snowing in SUSE Studio land.

Friday, November 27, 2009

Opportunity for intership at KDE e.V.

KDE e.V., the non-profit organization which represents, supports, and provides governance to KDE has grown significantly over the last couple of years. In 2008 we hired Claudia Rauch as part-time business manager taking care of event management, partner communication, and organizational support. Since beginning of 2009 she works full-time for us, and in August this year we opened a joint office with the Free Software Foundation Europe in Berlin, Germany's enthralling capital.

To continue this growth and being able to increase KDE e.V.'s support for the KDE community and free software, we are looking for an intern in the area of event management, business, and communication for the Berlin office. Read the full job description for details.

This internship is an exciting opportunity for passionate candidates to gain some experience with working in a high-performing non-profit organization on the topic of free software in general and KDE in particular. If you are interested in the position, please send your application to the board of KDE e.V.. If you know other people who might be interested, please point the to the job description as well.

Tuesday, November 17, 2009

openSUSE 11.2 and SUSE Studio

Last week we celebrated the release of openSUSE 11.2, the latest incarnation our fine green Linux distribution. It's a great release. People seem to like it. One quote: "OpenSuse stands out as a fine example of what a Linux desktop operating system can be."

Here at the SUSE Studio team we got quite some requests when openSUSE 11.2 will be available in SUSE Studio. Rest assured: We are working on it. There is some infrasructure to adapt, importing repositories, updating templates, upgrading Kiwi, and we are also planning to add a feature to migrate openSUSE 11.1 appliances to openSUSE 11.2, so you don't have to start from scratch, when you want to make use of the latest openSUSE for your existing appliances. It will need a little bit of time, but we'll add the support over the next few weeks.

So stay tuned, you'll soon be able to make use of all the openSUSE 11.2 goodness in SUSE Studio as well. I'm looking forward to what you will come up with.

Sunday, October 11, 2009

4,273,291 lines of code

4,273,291 lines of code, that's the size of the KDE core modules, which are released as the official KDE software distribution, as of today, the numbers generated using David A. Wheeler's SLOCCount. Of course we all know about the problems with counting lines of code, but I still find it interesting to run these statistics from time to time. I was doing so tonight, and thought, when I do so, I can just as well share the data with the world.

Please see this as an interesting but not too significant data point about what's going in KDE, and don't forget that removing code is one of the finest tasks of a developer.

Of course these four million lines of code are only a part of all the KDE code that is written. There are tons of applications which are not part of the standard KDE distribution, but are just as great. Would be interesting to do the complete statistics, but this is hard. How to get hold of all KDE source code which exists?

Concluding random data point: SLOCCount thinks that it costs $ 175,364,716 to develop the code of the KDE core modules.

Monday, September 14, 2009

KDE Showcase

This week there is the openSUSE Conference in Nuremberg. There is a lot of activity planned, and as there will be quite some people there from both the KDE and openSUSE communities, I thought it would be a good idea to use that opportunity to work on a project I always wanted to spend some time on: Creating a KDE Showcase.

The idea is to create a live system, which shows KDE as it's meant to be. Based on openSUSE, but with plain upstream KDE packages, augmented with some demo data and configuration, this system can be used to show KDE at trade shows, be given to users as a teaser, provide a reference for press people looking at KDE, and lot of other cases, where you want to show KDE in all its glory.

A couple of years ago I made a screenshot for a contest showing KDE 3.1.5 in action:

This screenshot was a success, and won me a price., Now, five years later, I would like to do it again with current technology. Not only doing a screenshot, but a whole live system, and of course with the latest KDE 4.3.1.

We'll have a small team at the conference, which will work on creating KDE Showcase. If you would like to join the fun, there is a session on Thursday afternoon as part of the unconference. Or just contact me directly. Ideas and other input are more than welcome. We'll collect what we are doing at the KDE Showcase wiki page.

Thursday, August 6, 2009

How to build a KDE 4.3 distro with SUSE Studio

Last week SUSE Studio was launched, and this week KDE 4.3 was released. They make a great combination. With SUSE Studio you can build a KDE 4.3 distro in just a few minutes. Here are the instructions how to do it.

SUSE Studio provides openSUSE 11.1 as a base template. By default it comes with KDE 4.1, but in the openSUSE Build Service, there are the latest KDE packages available. To build a distro using them, just follow these steps:
  • Go to your home page in SUSE Studio, click the "create new appliance" button, select the openSUSE KDE 4 template, choose a fancy name and click the "create appliance" button. You'll end up in the appliance editor.
  • Go to the software tab, click on "Add repositories", search for "KDE4", and then add the repository "KDE:KDE4:Factory:Desktop openSUSE_11.1".
  • Go back to the software selection, and remove the pattern "kde4", and the package "kde4-kdm-branding-openSUSE".
  • Search for "KDE 4.3", add add the pattern "KDE 4.3 Default Desktop".
  • If you prefer the original KDE branding over the openSUSE branding, replace the packages whose names end with "branding-openSUSE" by those ending in "branding-upstream".
  • Do whatever other modifications you would like to do (for example uploading a beautiful wallpaper, or select some of your favorite applications), go to the build tab, and click "Build".
  • Wait a couple of minutes (could be slightly longer, if the system is very loaded), and you are done. You can download or testdrive your new KDE 4.3 distro now.
As an example I've build a live CD with KDE 4.3 and the original KDE branding. You can download it from the Studio site.

Monday, August 3, 2009

KDE SDK status after hackweek IV

My goal for the fourth openSUSE Hack Week was to create a KDE SDK. When I started I thought this was mostly a technical challenge. I coded, packaged, built appliances. But while doing all this I found something much more interesting. In this post I will tell the story, and where it lead me.

I will start with the end, the technical end, the resulting product. Here is a screenshot of the KDE SDK appliance, running in SUSE Studio test drive. It shows my variant of Qt Creator, running the KDE SDK plugin.

This is only a technology prototype. It's a real appliance, containing real packages, built from real code. But neither the quality of the code, nor the quality of the UI, is anywhere close to what I want it to be, and there are large gaps in functionality. But that's ok. The really interesting results are what I learned while creating all this.

It started a week before hack week. I had a lot of ideas what to do, but I wasn't sure what would be relevant for users, so I asked in my blog. The feedback I got in comments on the blog or via direct mail was pretty clear, the idea of the KDE SDK resonated with lots of people. So I decided to give it a go.

At the start of hack week, I took a couple of design decisions to give the project a clear direction. It made it easier for me to start, and it again gave me quite some feedback. Some people advised to use a different programming language or a different IDE, and there were also some good hints on how to do details. I will revisit the design decision in the light of the experience I made during hack week and the feedback I got, in a later blog post. For hack week they gave me a good start. Knowing how to approach the project, and having feedback on the approach, that helped me.

The first thing I implemented was a skeleton plugin for Qt Creator, to give Creator some KDE spin, and to provide a base for all the things I wanted to put on top of it. I cloned Creator on and hacked away. After making some progress, getting the plugin running, and taking a first screenshot, I ran into some problems, where I couldn't easily find a solution. The core plugin with the welcome screen was structured a bit confusingly, and due to the lack of documentation it was a bit hard to find out how to get to the current project data or how to add additional window panes in the IDE. Of course I had the source code, which helped a lot. But even more helpful was to go to the #qt-creator channel on IRC, and talk to the Creator developers directly. They were very friendly, and I thought, wow, free software is great. You not only get the software and its source, free to use, distribute and modify, but you also get access to the people working on the software, can discuss the code, and receive help to get into the code yourself. We might perceive this as a given sometimes, but it's actually a priceless feature.

Once the plugin was in place, I went on with creating KDE application templates for getting users started. At first I had planned to write my own template generator, but then I remembered a hint annma gave me in response to my initial blog about the KDE SDK. She recommended to use KAppTemplate to generate KDE application templates. KAppTemplate actually does that very well, so I decided to use it. I needed some tweaks, because I wanted to preselect the name and the working directory of the application to be generated, so I cloned it on, added what I needed, and packaged it in the openSUSE build service, ready to be used in my KDE SDK appliance.

At this point I started to think. What makes developing KDE applications great? Sure, there is exciting technology, there are great libraries, there is lots of existing source code, there are lots of places to find help. But the most important feature is the KDE community. All the feedback, advise, help, code to use, pragmatic tips, which I got for the KDE SDK project, all this came from the community. This made the difference. Interacting with other people with the same interest, sharing goals and culture, this made me much more productive than all the technology.

Encouraged by this insight I continued with one of the ideas I wanted to implement for the KDE SDK, the integration of online services, for tasks like source code hosting, package building, or publishing applications. Connecting to the online services promised to also give some better connection to the community. I decided to go for three services for a start, for source code hosting, the openSUSE Build Service for package building, and for publishing application info. I invented a simple XML format collecting the meta information how to access these services for a given application, made Creator put this into the source code directory of the application under version control, and added support for it to the KDE SDK plugin in Creator.

But there was one technical problem. When Creator starts, it has no projects loaded, so I didn't have access to the meta information of an application. So what could I show to the user, until a project was loaded? As I had to test the implementation of the connection to anyway, I decided that I would just load the list of friends from and show it until the user had loaded a project.

When I saw the result, I realized that this was much more than just a test of loading some data from a web service. It actually was a useful feature. Some of the people on this list were the people I had to talk to in order to get my project done. I had to talk to Frank about the upload API for, and Klaas was working on a library to access the build service from Creator. So having these people present in my development environment added a real value. Of course just listing them was just a start, but all of a sudden a whole bunch of additional features came to my mind. What if I showed their latest commits, the status of the packages they were building, or a direct contact to them on IRC, or their latest mails to the relevant developer's mailing lists? This would have been exactly the information I needed, and which I still had to collect the hard way now, by using a dozen of different tools and manually combining the info I needed. So again the connection to the community appeared as the major feature.

I did some more work on the plugin, added details panes for the different online services, improved the attica lib for accessing kde-apps a bit, and fixed some bugs in my code generation framework for XML, Kode. This was needed to deal with some of the XML data involved in communication and storage within the KDE SDK framework. Technically the following screenshot pretty much represents the state of what I have now:

This hack week brought me the interesting insight that the best feature of a KDE SDK is not of technical nature, but is the KDE community. This closes the circle. During the last hack week I worked on the social desktop. While the idea is very promising, it's hard to connect it to useful functionality for the general use case. But when focusing on a concrete case, such as developing KDE applications, everything falls into place. There is so much use for social interaction and integration of the community when doing KDE application development, that it's very easy to come up with ideas how to make use of it in an KDE SDK. Relating commits to friends, connecting to IRC handles, integrating mailing lists, see what others are doing in terms of coding, packaging, communication. Exchanging source code, documentation, help, hints, advise, interacting with users on application directories, and much more.

So in the end, the KDE SDK becomes developer's social desktop. This is a great result.

Saturday, August 1, 2009

Will code for XML

When working on my hackweek project, the KDE SDK, I had to deal with some XML parsing for operating REST web services. To make this easier I made use of my old project to automatically generate XML parsing code from a
schema. Yesterday Tobias blogged about the new XML Schema features in Qt 4.6, and wrote about the need to generate code from schemas. Having this thought come up twice in only a few weeks can't be an accident. So I brushed up the Kode Home Page today, which has a solution for this problem.

Kode is a project to handle C++ code generation, especially in the context of XML parsing, with a special focus on web services. It's so important these days to be able to easily operate XML based web services, and handle all kind of other XML data conveniently, that we really need great support for this use case. In C++ this is usually relatively hard, mainly because of the static nature of the language, but with code generation this problem can be solved.

The tool which has developed over the last five years, admittedly with long periods of inactivity, is kxml_compiler. It can take an XML schema and generate C++ classes with a nice native Qt API which deal with representing the data and all the XML reading and writing stuff. This saves a lot of boring and annoying coding of trivial code.

When I started this project, I was convinced that an accurate and complete formal description was the key to this mechanism. Nowadays I'm not that convinced anymore. I found it much more practical to go for a 80% solution instead of striving for perfection. As result I implemented the support for using XML examples as a schema description. This makes it easy to just rip off examples from informal REST API documentations, or to use instances of an existing format, and let code be generated from that, which deals with this data. It works surprisingly well, and doesn't have a lot of overhead. Obviously it's lacking in some areas, and the implementation is still far from being production ready, but it is a useful tool and it solves the problem for quite some cases. It accommodates quite well for the needs of the rapidly changing world of Web 2.0 and its APIs.

The code lives in KDE playground. If you are interested in working on it let me know.

Tuesday, July 28, 2009

SUSE Studio Launch

Today we launched SUSE Studio as part of Novell's SUSE Appliance Program. This is an exciting event, as it marks a major milestone for the work we did in the Studio team for the last two years. With SUSE Studio you can build your own Linux, fast and easy. You only need a web browser. To achieve this, a lot of code was written, a lot of feedback from users was collected, and a lot of work was done to deliver a great user experience. At Linuxtag 2008 we presented Studio to the public for the first time, followed by an Alpha and a Beta period where we invited more and more users. We talked at FOSDEM and Linuxtag 2009 about Studio and presented the Studio Kiosk at various trade shows. All this comes together now in the launch of SUSE Studio as part of the SUSE appliance program. If you would like to give it a try yourself, sign up at, and we'll send you an invitation.

The major features of Studio, such as building appliances and testing them in the web browser, are pretty well known now, not least thanks to an amazing community, which has created walkthroughs, screencasts, reviews, and tutorials. But there are also some lesser known features, for example the API, testdrive networking, public download URLs, or the MySQL configuration. I'll try to find some time to write a bit more about these features later.

For my personal work Studio has become an important tool. I used it for example to create the Marble Live CD, or for my hackweek project, the KDE SDK. It's also a nice way to try out software or create an updated openSUSE version, for example with the latest KDE. But many other people are using Studio for interesting projects as well. Some of these are collected on the SUSE Studio appliances page in the openSUSE Wiki. If you have created something with Studio, please don't hesitate to add your project there.

One of the most interesting aspects of working on SUSE Studio is the technology side of things. It's a complex and demanding system, so it was an exciting challenge to actually build it. When we started as the SUSE incubation team, our mission was to explore new technology and foster innovation, and we learned a lot while applying this mission to the work on Studio. As a base we use Kiwi, the SUSE command line imaging tool, and we basically put it on Rails, with the web interface you can see on written in Ruby on Rails. Rails is a fantastic framework for doing web applications, and we use it not only for the UI itself, but also for internal HTTP APIs. SUSE Studio even made it to the list of amazing applications on the Rails web site. Another area where we learned a lot is deployment. It took us a while to find the right combination of procedures based on git, Webistrano, and system administration tools. But now we have a three-layered weekly release process, which works pretty well, and enables us to get fixes out to our users in a quick and reliable way.

All that said, from my personal point of view the best feature of SUSE Studio is the team which created it. It's an honor and a pleasure for me to work with people who bring together such an enormous amount of talent, experience, and passion. I really enjoyed the last two years, and I'm looking forward to a lot of other great stuff coming from this team. Guys, you rock.

Monday, July 20, 2009

Creating a KDE SDK

Last week I had written about my ideas for the fourth openSUSE Hackweek. I got quite some feedback and most people seem to think that the KDE SDK is the most useful idea. So I'm going to work on this for the hack week.

My goal is to create a software development kit for KDE, which makes it as easy as possible to write KDE applications. The main target audience are third party developers, who want to create desktop applications. The entry barrier should be as low as possible. There should no special knowledge about KDE, development processes on Linux, or familiarity with the community be required.

I thought a bit about how to best approach the creation of a KDE SDK. This lead me to the following design decisions:
  • The SDK will be delivered as a sofware appliance. I'll probably make a VMware image and a live CD for a start. This makes it easy to use it everywhere, independent of operating system or other system constraints. It also makes it easy to set up a very well-defined environment for the SDK, so that all components play well together and don't interfere with other parts of an existing system.
  • As a base for the appliance I'll use openSUSE, because this provides not only a great base system, but with the openSUSE Build Service and SUSE Studio it also provides excellent tools for creating and distributing appliances.
  • The UI of the KDE SDK will be based on Qt Creator. The main reasons for this choice are that it provides a pretty clean and simple UI, and that it's easy to hack, as the code is pretty straightforward and it's conveniently hosted in git on
  • Application programming language will be C++. Some of the script languages might be easier to grasp, especially for beginners, but for KDE and Qt C++ really is the native language. Documentation, examples, and most code is in C++, so it's most easy to get help how to do things. It also avoids the complication of having the extra level of a language binding.
  • Integrated documentation. There is lots of documentation floating around in various places. The SDK needs to integrate that in some way and provide pointers to what's relevant and helpful.
  • Integration of online services. There are lots of online resources and services, for example documentation in Wikis and other web sites, mailing lists, IRC channels, web sites like, or web services for development like gitorious, the openSUSE Build Service, or SUSE Studio. The SDK should integrate these as far as possible, so that the user gets the full benefit of all these community supported services. Maybe the SDK could even be basically stateless, so that all data is held online, and it doesn't matter with which instance of the SDK and from where you are using it.
  • Full software life cycle support. Developing applications is not only about writing the code. The code has also to be packaged and deployed to the user. There is a rich infrastructure to do all that, so the SDK should make use of it and support stuff like creating packages of the application, and publishing them at the places, where they can be found and used by end users.
  • Version control is essential. So the SDK will support git and out of the box. This should be done in an as transparent way as possible, which guides the user through a defined workflow, so the user gets the benefits of version control, but doesn't suffer from complexities of the underlying system.
I'm willing and plan to revisit every single of these decisions later, but to get started I will follow this path for now. For detailed progress updates about how the KDE SDK development goes see my hack week blog.

If you are interested in helping with creating a KDE SDK, let me know. I would be happy to team up with others to get this project done.

Tuesday, July 14, 2009

Hackweek IV

From July 20 to July 25 there is the fourth openSUSE Hackweek. Past hackweeks have been a blast. So many great projects have emerged from it. One of the latest example is the social desktop, which was one of the award-winning projects of Hackweek III. Ideas for hackweek projects are collected in openFATE. Browse for the Hackweek IV product to get an overview.

I'm pondering what to do for this hackweek. I have a couple of ideas:
  • GUI client for SUSE Studio. Studio is a fantastic web app, but sometimes it would still be more convenient to have a native client, for example when dealing with lots of overlay files, or to manage writing downloaded appliances to physical media or running and controlling them in a virtual machine. The Studio API makes it possible to write a native client.
  • Xing client lib. Xing is said to have some API to access the data about your social network. It would be great to have a client lib, which allows to get hold of this data for further usage on the desktop, e.g. putting it in your addressbook, or connecting it to the data of other social networks.
  • Grand Unified Social Network. Many sites let you manage your social network in its own way, Facebook, Xing, Linkedin, OpenDesktop. Even Twitter and sites like Gitorious provide some of these functionality. It would be great to put all this info together on the desktop and integrate it in some unified scheme, which merges and connects all your different social networks you have build on the web. This certainly would be a UI challenge, but it has quite some potential.
  • KDE SDK. Developing KDE application is not hard, but involves quite a bit of machinery. You have to get in place the development environment, tools, documentation for all involved components. Creating a KDE SDK appliance, which puts all this together in a pre-configured and easily accessible way, could make it even easier to get started with KDE development.
  • Krest. I have worked on some infrastructure for creating C++ bindings for REST services in the context of the Kode project. kxml_compiler already supports creating data model classes from XML examples. The missing piece is a tool to guide creation of these classes and associated transport bindings according to the needs of the developer. The goal would be to implement a guided binding creation by example in contrast to the usual approach of taking a full formal spec of transport and format.
  • Clubwagon. This is the dormant project to write a web tool for managing associations. In Germany there are hundreds of thousands of them (e.V.), and all have to manage members, budgets, meetings, etc. This would be straight-forward Rails programming, so in a week quite a bit could be accomplished.
  • Todoodle. This is my award winning notes taking application, which I use for my private needs, but which hasn't seen much development over the last time. It would be nice to give it some more polish and do a proper release for the public.
  • Package magician. I would love to have a UI for the build service for rapid package creation. Ideally this would cover RPMs and Debian packages for all supported distributions under an interface which is simple to use and hides all the nasty packaging details an upstream developer doesn't want to know about.
  • Plutimikation. My math learning application for children could need some love. It works, but it could have some more motivational features.
If you have input on the projects, would like to join, or just have a preference for one of them being done, let me know. You can also view the projects in openFATE and vote and comment there.

Thursday, July 9, 2009


After all the discussions and meetings we had about during the Gran Canaria Desktop Summit and on the xdg mailing list, I have now written down a more formal version of the process we talked about, so we can sort out all the details and decide on a final procedure how to document specifications and define what is an accepted specification. This hopefully will fix

To bootstrap the process I wrote it down as a specification for the Specification Process.

The next step is to get comments and incorporate them into the document. So if you have comments please let me know, respond to the thread on the xdg mailing list, or provide a patch to the document.

When comments are incorporated we can merge the specification back into the main specification repository and get acceptance by the desktop communities.

Wednesday, July 8, 2009

Signals from the Gran Canaria Desktop Summit

It's the sixth day of the Gran Canaria Desktop Summit. I finally have a little bit of time to collect some of the things which I found personally interesting.

It's an intriguing event, lots of stuff going on, lots of people, and the local team is doing a fantastic job with the organization. It's fascinating to see how Akademy and GUADEC happen in an intertwined way. There are many specific sessions dedicated to all the rocking technology our desktops are based on, but there is also lots of room for getting together and mix, so everybody can individually decide about how big the dose of collaboration and cross-desktop pollination is he is going to take.

View on the sea from the symphonic hall of the Alfredo Kraus Auditorium, where keynotes and lightning talks took place on Saturday

There was quite some talk about how to move KDE to git. The proposal which seems to be most attractive is to use to host the KDE repositories, which would give us a common space with Qt and some other projects. It was great that Johan and Marius, two of the guys behind Gitorious were at the Desktop Summit, so we could pepper them with questions about Gitorious and discuss how to best make the move. Today was a BoF session about KDE and git, which was so crazily crowded that I decided to look for a quieter place. While doing this I met Vincent, who had the same idea and we talked a bit about the GNOME migration to git. They have creates some good git help and documentation about the move itself. Later I heard that the BoF session was a good success, and that there is a team of people who will take care of what needs to be done. That's great. I'm really looking forward to the move and being able to use git for KDE development.

We also managed to get two sessions about together. There have been some problems with it because of administrational issues and a lack of transparency and criteria about what actually warrants a freedesktop,org acceptance. Aaron has proposed a solution, this could be a good base for an implementation. The sessions were attended by a wide range of people including developers from KDE, GNOME, and admins of There was a broad consensus that we need to fix the admin issues in some way, but that the real issue is one of governance, and we need a better and more transparent way how to express what specifications on have which state, which are generally adopted and which are just in an incubator state and not yet a real cross-desktop solution and so shouldn't have the label yet. In the end we came up with a solution. The basic idea is to only accept specifications on, if they are accepted by two major desktop projects GNOME and KDE represented by their release teams. Details certainly have to be fleshed out, and their also is a need for some more discussion, but in general this feels like the right direction.

An unexpected but very interesting encounter was to meet Jan Lehnhardt and learn something about CouchDB. This is a document-centered database based on JSON with built-in replication. There are all kind of interesting uses cases for it, and the Ubuntu guys seem to plan to rely on it pretty heavily. Worth looking into it. There already is an Akonadi agent for CouchDB. Unfortunately there don't seem to be any openSUSE packages yet.

Yesterday there was the annual membership meeting of KDE e.V.. One of the main topics of the meeting was the election of the board. We had five great candidates for three open positions. This is an encouraging sign that KDE e.V. is in a pretty healthy state and the work we do in supporting the community is accepted and bearing fruit. In the end we elected Frank and Celeste as replacements for Aaron and Klaas. Adriaan, Sebas and me stay in the board. We prepared this for some time to have a smooth succession providing some fresh blood to the board, but also having some continuity. This seems to work out pretty well.

Finally I came across a report by Glyn Moody about the summit. He held the first keynote of Akademy, and presented an interesting line of thoughts there, explaining how hackers will save the world by bringing their culture of sharing to the greater society.

One paragraph of his text Gran Canaria Desktop Summit: a Study in Contrasts stroke my special attention:

Although it was great to see the large numbers of hackers from the GNOME and KDE communities coming together at this joint conference, I think it's vitally important that they continue to go their separate ways, each convinced that their approach is best, but each ready to be stimulated by and learn from what their colleagues and rivals are up to.

I think that nicely summarizes the atmosphere of the event. There certainly is some competition, but in the end it's motivating and stimulating for both communities and leads to better solutions for all of us.

Thursday, July 2, 2009

Blog moved

I finally decided to move my blog. has served me well, but now I want some more features. Blogger provides some killer features, such as using my own domain, blogging by email, or the powerful comment system. So from now on you'll find my blog at See you there.

Tuesday, June 30, 2009

KDE Wiki Meeting Report

Two days of KDE Wiki Meeting are over. Danimo, Frank, Lydia, Dominik, Milian, Thorsten and me met in Berlin with the goal to get some more structure into the KDE Wikis and provide a plan for the future, where to put content. I'm happy to say that we accomplished this mission.

While we have TechBase for high quality technical documentation for a while, and the corresponding UserBase for end-user information since last year's Akademy, we were still missing a proper place for community content, especially for content which is mostly community internal, of more transient
nature, or just not finished yet. The idea to create a dedicated Wiki for this community content was floating around since a while, and now we created it at

To make it clear which content belongs where, we created a mission statement, which gives clear guidance about which Wiki serves which purpose. You'll find it at in a few days. The basic idea is that provides end-user information, contains high-quality technical content for third party developers, distributors, and system administrators, while acts as a collaboration space for the community.

Actually already existed. It contained the charter of the community working group. But to keep things short and to the point we decided against creating another base, but go with the logical and short domain. The charter of the CWG will find a new home on the KDE e.V. web site.

With the creation of we can also shut down at least two places where community content ended up due to lack of a proper home. We'll shut down the old Wiki, which was available under, but whose content wasn't that well maintained, and which didn't fit too well in KDE's infrastructure because of technical reasons. We'll also move all the pages which piled up under the Projects directory on techbase, but in almost all cases didn't really belong there and also didn't match the quality requirements of being polished content targeted at technical people who aren't necessarily familiar with the community. Most of these pages find a proper home on, though.

In addition to the general cleanup and structuring we also worked on some improvements of the existing Mediawiki installation. Danimo replaced the OpenID login UI by a much more usable version, Milian finally managed to get rid of the annoying horizontal scrollbars inside the page on code samples, and we also discussed some more improvements, like the intensified use of templates and the introduction of a way to rate and classify documents on the Wiki to indicate their quality and make it more obvious what needs more work.

As a side track, we had an interesting discussion with some Tiki developers. They have an amazingly powerful and feature rich system, which would
be able to solve some of the problems, we still have with our Wikis, such as translation infrastructure. For now we decided for the sake of consistency and simplicity to stay with the current Mediawiki installation, but maybe Tiki is an option in the future.

Working on the Wikis was fun and satisfying because we got some concrete results, which will simplify maintaining KDE web content in the future. But besides all the work we also didn't forget to relax with a great dinner at a Chinese restaurant at Berlin-Adlershof, enjoying a great buffet, including cheese cake for dessert.

Thanks go to the KDE e.V. and Qt Software for supporting the meeting.

Sunday, June 21, 2009

Three Events

The next three weeks will be pretty busy. I'm looking forward to three exciting events which will take place during this time, and I'm happy to be able to attend them.


First event is Linuxtag, from June 24th to June 27th in Berlin. I will be there and give a presentation about SUSE Studio as part of the openSUSE Day. We'll also present SUSE Studio at the openSUSE booth as well as other openSUSE goodness.

Linuxtag of course always has been a great place to meet the KDE community as well (I'm thinking for example of this and this, or that, and that). So I'm looking forward to the KDE related presentations as well, and will certainly also spend some time at the KDE booth.

As a special opportunity, if you want to sign the FLA with KDE e.V., find me and we'll get this done.

KDE Wiki Meeting

Directly after Linuxtag there will be a small KDE Wiki Meeting. We'll sit down and get some content, structure, and technology sorting done, to improve the Wiki presence on and I hope we'll also find some time to discuss the idea to create a third Wiki, for holding community content, which currently floats around without a proper home on various different KDE sites. This should be a place for collaboration and for content which is important to the community, but not really relevant for the general public.

Gran Canaria Desktop Summit

From July 3rd to July 11th there is the Gran Canaria Desktop Summit. This includes Akademy and GUADEC, and will be a fantastic meeting place for everybody working on or caring about free software on the desktop.

We have a great lineup of keynote speakers, a fantastic Akademy conference program, and much more. And of course there is plenty of opportunity to informally meet, discuss, and get some work done. It will be fun.

Saturday, May 9, 2009

Marble Live CD

Marble is one of my favorite applications. I especially like it in combination with OpenStreetmap. Free software and free maps, a brilliant combination. But I also love the historical map or the moon view.

Marble also is great as a demo application. It's easy to grasp and makes an attractive showcase. To make demoing Marble a bit easier I thought it would be nice to have a Marble live CD, and as I happen to have a great application for doing this at hand, I created some Marble live CDs. You can download them from my Marble live CD page.

I'm interested in feedback. So if you have questions, comments or want to help, contact me.

Built with SUSE Studio

Saturday, April 25, 2009

Akademy program, almost there

The Akademy program is almost done. Speaker notification deadline was yesterday, but we are still busy sorting out some last details and haven't sent notifications yet. Please bear with us and have a bit more patience. We have a lot of great proposals, more than we can fit into the schedule. So it's not easy to decide what we can take, and the co-hosting with GUADEC adds another dimension of complexity to this task. But we are on a good track, and we will have a fantastic program. Stay tuned...

Monday, April 6, 2009

5 days left to submit your Akademy talk

There are still five days left to submit a proposal for a presentation at Akademy 2009. The deadline is on Friday, April 10th. Akademy happens as part of the Gran Canaria Desktop Summit this year. See more details about what we are looking for in the call for presentations. Akademy is the prime occasion for meeting the community, and present and discuss your ideas. Lots of great initiatives were kick-started at Akademy. Don't miss out on this opportunity and submit your proposal now!

Personally I'm particularly interested three kinds of presentations:
  • First I would like to see presentations about the beauty of KDE. KDE 4 shines, and I would love to meet the people who make it shine at Akademy, and hear how they did it, and what we can expect in the future. That's not only limited to beautiful graphics. Elegant code, organic user interfaces, beautiful APIs, engines which enable a beautiful desktop, fluffy-bunny themed Chuck Norris, all this falls under this category.

  • Second I would like to hear about projects which go beyond KDE or which serve as a foundation for KDE. The state of X, cross-desktop infrastructure like Akonadi or other projects, general interesting desktop computing concepts, all this would make great presentations for Akademy and the Gran Canaria Desktop Summit in general.

  • Third, and that actually might be the most important category, I would really love to have lots of application developers at Akademy, especially the people who stand behind the thousands of "third-party" applications which create the richness of the KDE experience. You might think that your application is not important enough for a big conference like Akademy, but that's not true. All the little tools, which were created to scratch a special itch, they make up for an essential part of the KDE software universe, and they should be represented at Akademy. This also includes all the nice Qt applications, which only use a small or no part of the KDE libraries. They share the same base with every other KDE application, and are a natural fit for the KDE community. So, if you are the author of one of the great applications on, don't think twice, submit your abstract.
I'm looking forward to a special Akademy in a beautiful surrounding with lots of exciting content. Be part of it, submit a talk.

Monday, March 2, 2009

Blog on the move

I have moved my blog from
to I'm of course still a KDE developer, but as I also blog about openSUSE and other stuff, I felt a more neutral domain wouldn't hurt. There also are some technical reasons. The new blog is hosted on Blogger, which has a couple of killer features compared to, for example the option to use my own domain, blogging by email, and the powerful comment system. It also provides a pretty good editor. So for now I'm happy.