openSUSE conference 2010

These October days, I’m spending in Nürnberg in Southern Germany to attend the openSUSE conference. My role here is three-fold, first and foremost I am here as a representative of open-slx, my employer who sells products and services based on top of openSUSE. Then, I’m a KDE ambassador. Finally, I’m also getting more and more involved with the openSUSE team, getting to know many people and learning about challenges and opportunities this community faces.

That last one is actually really interesting, as the openSUSE community is in the process of re-finding itself. There’s the discussion about strategy going on, which is I think mainly formalizing the biggest problem openSUSE has: It’s lacking a common direction. This is a symptom of good and bad things, it reflects the diversity in the openSUSE community, which I think is of great value. On the other hand, it makes it hard to deliver one coherent product as there are nearly as many goals and opinions how to reach these goals as there are people in openSUSE.

Another part of this process is the de-coupling of the openSUSE community from Novell. This independence is very important for the Free software community since it means taking your own decisions — for instance about the direction of the product. Now my impression is that Novell doesn’t want to abandon openSUSE, but it’s trying to make it stronger by giving it more independence, it’s some sort of growing up of openSUSE.

Yesterday, I attended a session about setting up a foundation for openSUSE that can manage funding, governmental aspects and other more organisational tasks. Interestingly, the openSUSE board has (after looking at many comparable organisations in the Free software space) taken a direction very similar to how KDE with the KDE e.V. backing it up is set up. This is good to hear, since on one hand it validates the work we’re doing in the KDE e.V., and it’s yet another way of sharing in the Free software ecosystem. (Actually, we get requests for organisational assistance from Free software or Free culture projects on a somewhat regular basis.)

I’ve just attended a talk by Cornelius and Vincent (KDE resp. GNOME) who were talking about freedom in the cloud, giving a nice overview how the values of Free software apply to application used from the cloud. The rest of the day is packed with technical sessions, which I’m really looking forward to, and towards the end of today, I’ll talk about user experience in openSUSE. Actually, I’ve decided to talk about user experience and interaction design in general, explaining typical design processes and tools. I aimed for a talk teaching and explaining techniques this time around, since I think that this applies best to a community from kernel hackers to UI designers. My hope is that people will take away some ideas of how to improve the user experience of their work.

Working Upstream.

On the website of an Austrian (no kangaroos!) newspaper, I read an interview with Canonical’s Jono Bacon. In this interview, Jono talks about the process of developing central components of the desktop inside Canonical. The process is basically that Canonical’s design department, Ayatana develops components. When they are finished, they’re offered for inclusion into GNOME, which was not a successful in all cases yet. According to Jono this is "working upstream", explaining that in this context Ayatana is the upstream. GNOME is seen as a provider of components, building blocks for Ubuntu’s user experience.

The definition Jono handles of upstream development is quite different from how it works for me. I can speak of personal and professional experience in this context, as I have been working quite a lot on central components of the Plasma Desktop (and Netbook as well). I have done this work both, as a voluntary contributor in my Free time (pun intended), and continue to do so in my working hours for open-slx. open-slx happens to sell and support Linux deskop operating systems.

Nowadays, many of my contributions to Plasma and KDE in general are paid for by my employer, open-slx. As part of my job, I am allowed and intended to work inside KDE during working hours, this includes "hacking on Plasma stuff" as well as taking on some organizational load, such as working in the release team and the KDE e.V. Board. open-slx’ philosophy behind this is that it is essential to play nicely in the community as a company, and that selling a product which heavily relies on its user experience is made easier, not harder by working directly in the context and infrastructure of the project we intend to merge our creations into. In my case that’s KDE, and especially the Plasma team. This means that I commit my work directly to KDE’s source code repository, that design and technical decisions are being taken in the approriate upstream communities. This can happen for example during sessions at Akademy, at sprints, on IRC and most importantly on mailing lists such as plasma-devel@kde.org and kde-pim@kde.org.

The latter two are a nice example for a project I’m currently working on, the Akonadi-based email notification system. During Akademy, I sat together with a bunch of the KDE PIM developers, to design the new email notification system that will likely come along with Plasma and KDE PIM 4.6.0 next January. Over the past weeks, I’ve spent quite some hours on working out the plans. I’ve committed my changes to the code right away to KDE’s SVN to share them with others. Once the code is "good enough", it’ll be submitted for review and inclusion into Plasma or PIM, whatever makes more sense from a packaging point of view. It will be released together with Plasma 4.6 next year and through openSUSE 11.4 will be part of open-slx’s next product, the boxed version of openSUSE. This way, these contributions, the working hours my employer pays for trickle back into our product via downstream projects such as KDE Plasma and PIM teams, and openSUSE. The initial design of the new Plasma email notifications has actually been born during Camp KDE 2009 on Jamaica, but that’s a different story altogether. If you now are interested how that actually looks like, that will be the topic of another entry on this blog.

Let me get this straight, though. It makes sense to provide modifications to the user interface as add-ons that other companies with a similar product don’t ship. Also products based on Free Software need unique selling points in order to make their whole enterprise commercially interesting and viable, and thus make money flow into the development of Free Software.

On the licensing side, this is expressed in making it possible to write proprietary components, for example by using the LGPL license for libraries — Qt, kdelibs and libplasma are all licensed under the LGPL for exactly that reason. Technically, systems such as Plasma’s widgets which can replace any part of the whole Plasma Shell, be it the display of notifications (which Aurelien has actually proven by writing a Plasmoid that displays notifications according to Ayatana style guides), the taskbar, or all kinds of online services. From a branding point of view, the simplest case is probably slapping your branded wallpaper onto the default install. More advanced usages would be a customized Plasma theme, or maybe even "fingerprint animations", that make using your desktop feel a bit more special. For open-slx, Plasma turns out to be an excellent choice of toolkit to build an improved user experience upon, and that is true: we can virtually turn Plasma into any kind of product we like functionally, we can make it behave and look like exactly as we like, and we can maintain a clear separation between aspects we think are the unique selling point of our product, and the contributions we make directly upstream as part of being a good citizen in the KDE community.

The point here is that in order to sustain a Free Software eco-system such as KDE, or maybe GNOME (like in Canonical’s case) you need a healthy balance in your contributions to the upstream community, and your work to differentiate yourself commercially. It’s good practise to make a clear separation between the things you choose to be your USP and your Free Software contributions. Communicating clearly what your contributions are and where you are "commercially sensitive" is both essential: You want to create goodwill among developers that don’t get a paycheque from you (so-called "community support") when you need their help in a context that’s commercially sensitive to you, and which you want to keep separate for licensing and marketing reasons. Moreover, this clear distinction between your proprietary add-ons and your upstream contributions make it clear to customers why to buy your product, and not the competitor’s one.

KMail’s Akonadi migration in openSUSE

In openSUSE’s KDE team, we’ve recently planned the migration to Akonadi, the groupware caching solution that will be the base of upcoming KDE PIM versions, notably KDE’s address book, email client and calendar app. With the release of KDE SC 4.4, we’ve seen the first component being ported to Akonadi, KAddressbook, spearheaded by its fearless maintainer Tobias König. In the KDE SC 4.5 cycle, we’re seeing more components in their first Akonadi-incarnation. As this means a big step for these applications, some attention needs to be paid to users who will, over the coming months, migrate to the Akonadi-based PIM components. The PIM team has decided to go with a stepped approach, and not introduce all applications in their Akonadi version at once. This is a sensible decision, as it allows you to learn from problems in the migration path, and fix these in the next wave of ports. PIM in SC 4.4 brought the address book migration, which wasn’t completely smooth from a user’s point of view. While in most cases, the fix was as easy as "point Akonadi to your contacts (or .vcf) file", we can (and will) do better with the migration of KMail. KMail2 (which is akonadi-based) will not arrive with 4.5.0, though, but is planned become part of the next monthly SC update, 4.5.1. This decision has been made by KDE’s PIM team in order to get a little more time to stabilise and test the release. This is also our first line of defense :-)

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.