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.