To KDE With Love

At the Ubuntu Developer Summit in Budapest we had some great discussions outside scheduled sessions. Amongst the topics was also how Kubuntu works with the upstream KDE community.

For quite some years the Kubuntu team has made it their personal goal to do as much of their programming effort as part of KDE as possible, rather than making generally great software that is of no use to anyone but Kubuntu.
This went to such an extent that it has sometimes become difficult to decide whether a Kubuntu member is contributing enough to Kubuntu in order to become Kubuntu Member, because they were doing most of their work from within the KDE community. As much as this makes it difficult for the Kubuntu council to decide whether someone deserves to become Kubuntu member, I believe it is a truly great thing. Not only does it mean that we are doing a great job in achieving our “as much upstream as possible” target, but it also proves that one can be an integrated part of both the KDE and the Ubuntu Community; essentially this is what Kubuntu is about, bringing two amazing communities and their equally amazing products together and achieve a whole new level of awesome.

Building up on this great history we are renewing our commitment to KDE technology. Despite strong competitors Kubuntu will continue shipping Rekonq as the default browser of choice and invest more time in improving the user experience.

Romain Perier, one of our newer contributors, has taken it upon himself to bring userconfig, our user management tool, back to the mother ship that is the KDE software collection and by that give every KDE user the possibility to use this excellent piece of software.

Rodrigo Belem, from Kubuntu Mobile fame, is bringing much improved file sharing experience to the KDE workspace. He completely reworked the whole file sharing dialog in Dolphin along with the underlying technology. As this currently only implements SAMBA, there is WebDav and perhaps even Netatalk (for Mac interoperability) support planned for the not so distant future.

Those are but three examples, but there are many more, certainly also more subtle things.

The entire team is dedicated to this mission and so we are going to continue doing work upstream and forming it into a coherent distribution downstream.

Kubuntu sends contributions to KDE with love, because Kubuntu loves KDE :*


14 thoughts on “To KDE With Love

  1. Very nice to hear this, good job! And thanks to all the brilliant kubuntu KDE developers!

  2. that is a really great spirit and perspective on upstream/downstream collaboration and efforts. really cool to see it both here on your blog as well as in action in the source repositories 🙂

  3. I’ve always wondered why people complained so much about Kubuntu being so close to ‘Vanilla’ (s.i.c) KDE. I like KDE as it stands, without customization and frankly I like to customise it myself 🙂 This is why I’ve been behind Kubuntu since KDE 4.0!

  4. For quite some years the Kubuntu team has made it their personal goal to do as much of their programming effort as part of KDE as possible, rather than making generally great software that is of no use to anyone but Kubuntu.

    Then why the focus on the apt-only Muon at the expense of the cross-distro KPackageKit/Apper?

    • Because Kpackagekit has one of the most atrocious UI’s in existance. It’s not possible to describe my level of hate for kpackagekit.

    • We gave Kpackagekit a fair shot. It was our default package manager for several releases and Dantii worked very hard (much appreciated) to mature it and make it work better on Debian and derived distros.

      In the end, packagekit (and by extension Kpackagekit) suffers from it’s RPM heritage. It just doesn’t integrate well with Debian based package management.

      I think it was reasonable to give it a try, but I don’t think packagekit solves the cross-distro package manager problem. At least we shipped it, in Debian, the KDE configuration shipped with no GUI package manager at all for Squeeze because they didn’t think Kpackagekit was suitable.

  5. Kevin: Because Muon has more features and is more powerful.
    The Kubuntu community has just decided to choose Muon as the default package manager, as it’s a Qt apt frontend, it does make sense. KPackagekit won’t be remove from kubuntu.

  6. I did not realize that Kubuntu was so focused on passing everything upstream (the way, in my opinion, Linux should be). This is great news, and lifts my perception and appreciation of Kubuntu!

    This places it in the running for putting on my system if/when I get a system capable of running Ubuntu post-12.04 (the PAE kernel on a non-PAE system.. no fault of anybody just a bad “roll of the dice”)

Comments are closed.