Monday 8 December 2014

The Pillars of KDE 'Now'

Who here remembers the "Pillars of KDE 4"?

As you can see, I asked the Internet (and got little response). I was attending MeetingC++ as I wrote that tweet and spoke to some KDE folk who were attending. Between us (and online) we could remember:

Oxygen, Sonnet (remember that?), Solid, Plasma, Akonadi and Decibel... This list in one way or another might be wrong. Not so cool. But you know what is cool? People remembered the Pillars of KDE 4 existed and the effect they had.

What Were Those Pillars All About?

For me, the Pillars of KDE 4 were a battlecry: "KDE 4 is coming and these are its foundations! Look out!". Or something like that. When I first got involved with the KDE community KDE 4 development was in full swing and the first release was about 8 months away and these "pillars" were everywhere. We used them internally as points of coordination and we used them externally as points of marketing.

In my recent conversation I heard the pillars referred to as "just a piece of marketing". Humph. No, this was only oneof their functions and, for me, by far the least important.

The Pillars of KDE 4 were talismans. The community's good luck charms that we rallied around. The "things" that helped us to identify what was crucial to KDE 4. For me the keyword was "experience". All of these talismans were keys features of the KDE 4 experience; key technologies that were going to ensure our users (old and new) enjoyed "experiencing freedom".

I love "Experience Freedom" as KDE's tagline: what more prominent experience do computer users have, then their desktop?

Step Back In Time With Paul Adams

Once upon a time I was a teenager. It was back then that I discovered Free Software and first become involved. I was using Red Hat Linux or SunOS at school. GNOME was not to my taste (although not bad) and CDE was an affront. I build a preview of KDE 3 from a magazine cover CD and never looked back.

Why?

KDE has always been an extremely well-integrated experience. Sure, there are always things to be "polished" but, in general, everything worked and, more importantly, everything worked together. KDE was the one Free desktop where everything felt nicely integrated. It felt like a thoughtful product.

But KDE is no-longer a desktop. Remember? Wikipedia tells us:

KDE (/ˌkdˈ/) is an international free software community producing an integrated set of cross-platform applications designed to run on LinuxFreeBSDSolarisMicrosoft Windows, and OS X systems. It is known for its Plasma Desktop, a desktop environment provided as the default working environment on many Linux distributions, such as openSUSEMageia and Kubuntu and is default desktop environment on PC-BSD, a BSD operating system.

So What Is KDE?

The official party line (as supported by the Wikipedia entry) is that KDE is the community. KDE is a community of skilled individuals who all pull together to produce various ingegrated technologies, one of which happens to be a desktop (for various platforms). Many of the other projects directly relate to that desktop.

Hmmm... But wait a second. We have a separate definition, in the form of the KDE Manifesto:

We are a community of technologists, designers, writers and advocates who work to ensure freedom for all people through our software.

OK, so this is certainly compatible with the previous definition. Although perhaps a little less specific. Again, the clear point here is that KDE is a community. And this is something I feel increasingly dissatisfied with. What was wrong with KDE being a desktop with a well-integrated collection of awesome applications (which were also able to be run independently of that desktop on all major platforms)?

No really, what?

The Great KDE Disintegration

I first got involved with KDE because I was studying the management of Free Software communities for my PhD. In particular I was concerned about how communities remain productive. At the time I regularly made one specific warning: moving from centralised VCS to distributed will have enormous social implications way beyond the technical ramifications if the process is not monitored and managed properly.

Why? Because the VCS is a tool we communicate through. It is the most crucial tool we communicate through and it dictates how we can build our product(s). The way in which we design our software structure is constrained by how we communicate. Fundamentally change your communication structure and you will be forced to fundamentally change how your structure your code. This is called Conway's Law; I've mentioned it before in this blog and elsewhere. I dare you (nay, double dare you) to try and tell me that somehow it does not apply to Free Software or, more specifically, KDE. Go on. Give it a try.

With SVN KDE had a massive and unwieldy, but integrated codebase (heck, it was all in the same repo!). The community was also massive and unwieldy. But it was well-integrated and this was reflected in the product. KDE 3 was a phenomenon and so was KDE 4 early on.

Then we switched to GIT.

KDE became a collection of projects because each component of the community got its own repo. And we stopped working together as much. Our development became silo'd. There was even some weird behaviour within these silos. (My personal favourite... Adriaan de Groot being told to create his own repo for FreeBSD integration work for a particular application. Apparently creating a branch to work on in the existing repo was a bit too much to ask.)

Then it happened.

We became so disintegrated as a community that this became our branding. We, explicitly, stopped being a desktop project and became a collection of projects, one of which happened to be a desktop.

Let me be clear:

The VCS changed, this forced changes in the community structure and how we communicated, which encouraged us to rebrand in order to closer match our new communication patterns and how we view ourselves.

And, thanks to Melvin Conway, KDE became a less-integrated experience.

The Pillars of KDE "Now"

KDE 4 had its pillars. As the community disintegrated they fell to the wayside.

The KDE community continues to produce excellent technology. In particular, Plasma 5 is shaping up very nicely (although it is still not quite "there" enough for me to use it as my main desktop yet). But, inevitably, the fractured nature of the community will reflect in the user experience and, at that point, one of our killer features (being "the integrated experience") will be gone.

So I'm left wondering, what are the pillars of KDE now? What are the "things" we, as a community, can all get behind and say "these are the things that underpin the KDE experience".

Akonadi? Baloo? KF5? Plasma? Telepathy? KTeaTime? Heck... I'm gonna throw Akademy into the mix.

In Conclusion

Switching to GIT has brought many benefits to KDE (none of which are discussed here). But it has caused us social problems which will inevitably reflect in our products. It already reflects in our messaging, so it is really just a matter of (not much) time.

I think it is about time we took action to socially reintegrate before becoming a totally disperate collection of technologies. My 2c: KDE was strongest when we were all marching towards KDE 4, when the "pillars" were our talismans and we were one in community and vision.

So, tell me, what are the pillars of KDE "Now"?