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 and

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.

9 thoughts on “Working Upstream.

  1. May I ask how many developers open-slx employs? Are you the only one or are there more? And if there are more, what are they working on?
    I barely know anything about open-slx and its website isn’t the most informative either.

    1. We’re working on our public presentation, as open-slx is still a young company. We’ll be more outgoing in the future, but for now, that’s the information you’ll have to do it with. :-)

  2. 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.

    That is exactly what I dont like or neither understand that how Ubuntu can really believe that they are the centrum of the universe?

  3. 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.

    Aren’t KDE Plasma, KDE PIM and openSUSE upstream of open-slx?

  4. “open-slx happens to sell and supports Linux deskop operating systems”

    And this would be the difference between open-six, other similar companies & Ubuntu/Canonical. Your efforts upstream contribute directly to the product you sell & you get point-of-sale revenue. Ubuntu is free.

    Someday Canonical might actually make some money from their investment in Ubuntu & other projects related to Ubuntu through commercial support & other agreements. Maybe we can be critical of them then.

    1. It’s actually exactly the same, we’re talking about Canonical’s contributions to GNOME (which is part of the product it’s selling), and I’m giving my experience of open-slx’s contributions to KDE (which is part of the product we’re are selling). Really, it’s *exactly* the same, no amount of denying changes that.

      What I am writing about is the philosophy behind contributions of companies that are selling a commercial product on top of Free Software components. That’s what is called “working upstream”, and I’m giving my definition and understanding of that, which is in line with the understanding of the concept “upstream” in the wider Free software community. Redefining such concepts just so it suits your public perception is just plain wrong. Coincidentally, I happen to have some first hand expertise and experience in this exact field, so me weighing in on this issue hopefully produces a more balanced understanding of how companies and Free software communities can collaborate so both win in the end.

      Furthermore, “complain when Canonical is profitable” I think doesn’t really hold. If you want to play part of a Free software ecosystem, you have to work with it in a way that its economics are kept in place, not cannibalise on it. If you don’t do that, people will complain — and that’s what we’ve been seeing over the past months, and from different communities, the Linux kernel and the GNOME teams to name two examples.

      When Canonical becomes a profitable enterprise or not is entirely Canonical’s matter and has nothing to do with this topic.

Comments are closed.