Collabora vs ONLYOFFICE

Since the Nextcloud Hub release switched from ONLYOFFICE to Collabora Online as default, lots of people have asked why. Is one better than the other? Let's talk about this.

History

Let me first say - the decision wasn't pure technical. As always, relations and other reasons play a role. I'll try to cover both aspects, but there is always more. With that out of the way, let's first look at how ONLYOFFICE got into Nextcloud.

Frank, myself and others in the Nextcloud community have wanted to integrate office in our collaboration platform for most of the past decade. Previously, we* had invested quite a bit in getting a collaborative document editor into our private cloud. The Documents app was a from-the-ground-up developed ODF editor with a unique and very clever design, built by KO GmbH (now sadly defunct). We together put resources in integration and further development and we hoped other (open source) businesses would invest and contribute too, so the solution would grow in time. Also, we had hoped some customers would be willing to pay for it. Both of these did not really come true, and KO sadly didn't survive.

* Note that I use 'we' here loosely as I wasn't really involved back then, so think 'the core team', as a slowly-changing team of people, including Frank, Jan, Arthur and others.

Fast forward to our launch on June 2 2016 (happy birthday!), and a few months later we announced Collabora Online integration. We had worked with Collabora to make this available not just to enterprise customers, as before, but to all users thanks to the 'CODE' docker image. As you know, we care deeply about community/private home users and this was of course a great step forward.

But running docker, setting up a reverse proxy on a second domain with proper certificates - it isn't easy and does not work for everyone. So we had to keep maintaining the Documents app a little, as some users still could only use that.

ONLYOFFICE vs Collabora

Meanwhile, a new open source online office solution came around, ONLYOFFICE. Let's talk for a sec how they compare Collabora, as the two could not be more technically and non-technically different!

Technical: how they work

The way Collabora Online works is:
An embedded version of Libreoffice runs on the server. It reads the document, then 'streams' the rendered document as image tiles to the browser client, which shows it to the user. The browser client does some of the menu's and lots of smart things like showing the cursor, other users, text selection etc, but many other components like pop-up menu's and sidebars are also streamed from the back-end, giving relatively good feature parity with LibreOffice. This strategy is responsible for giving LibreOffice, for example, desktop-level table style editing, better than any other online office solution.

The way ONLYOFFICE works is:
The document is converted on the server to a JSON file which is streamed to the browser client. The browser client is the full office suite, editing the document. Once done, it sends back the JSON and the server merges and exports it back to a file. A fully html5 canvas based front-end means a relatively pretty user interface and any javascript dev can go hacking.

So what does this mean?

• LibreOffice is much heavier on the server and network connection, but uses a bit less client resources which tends to help mobile devices with battery life during editing
• You get the full Libreoffice file type support. Decades worth of obscure file formats, it is all there.
• ONLYOFFICE has a more modern UI, writing it all in Javascript so it is far easier to be mobile-friendly. You can imagine how useless those old LibreOffice paragraph settings dialogs are on a mobile phone screen!
• In theory ONLYOFFICE would be much easier to integrate in web apps in general. Most app frameworks can consume a javascript or json component, a simply streamed, tiled image is far less flexible...

Compatibility

On document support, three things.

First, with regard to the Microsoft file compatibility - this is ALWAYS hit and miss. I can't objectively claim either is better or worse, you will always find a file that works well in one but not the other. But you will also find lots of MS Office files that won't work in Office 365, or break the desktop version between Mac and Windows or even just from older versions, because Microsoft screwed up their own compatibility.

Second, one thing I can say: if you migrate from Collabora Online to ONLYOFFICE and most of your files are ODF files because that's what Collabora uses by default, you're in for a bad experience. The ODF support in ONLYOFFICE is quite basic. But with MS Office files they feel on-par to me and that's what probably matters for most people. (sadly, yes)

Third, if you need any other file types - Collabora can handle a LOT, due to its long legacy. Word Perfect anyone?

For other technical capabilities - I probably be best off simply pointing to the comparisons both made themselves:

• From Collabora
• From ONLYOFFICE

Social/historical differences

Let's talk about the second big difference between Collabora and ONLYOFFICE: their roots. Collabora builds on and is part of the LibreOffice community, a decades-old project, and consists of long time open source believers. Development is open and accessible and there are lots of individuals and companies that work on and can provide services for its code base. ONLYOFFICE on the other hand, is quite new to open source and only a bit over a dozen people have contributed to the code base. Their open core model if of course less than favorite in the open source world, though it is still miles better than proprietary - some people seem to lose sight of that sometimes, if you ask me. For an end user, the development model makes little difference, in either case.

let me emphasize two things.
First, it is awesome that we have TWO open source office suits. Building one is an amazing accomplishment - we have had others in the past but most are no longer really viable due to the massive amount of resources required to keep up.
Second, I think it is great that ONLYOFFICE decided to open source their product. I believe most people really under estimate what it takes to turn around your business model so radically. And if you're unhappy with decisions made, in either case - contribute, get involved. That is how you change things in open source.

Getting Office in Nextcloud

So, as I said in the History section, by 2017 we had three office solutions integrated in Nextcloud. One was easy to install but unmaintained and quickly deteriorating. The other two were harder to install but much more complete.

You know we're ambitious people, so indeed we have thought about and discussed this situation forever. And at some point, Robin started to really investigate what would be possible. After looking deeply at both, he finally managed to create a proof of concept with ONLYOFFICE. What he did was:

1. Separate the 'converter' part from ONLYOFFICE, the javascript front-end and the 'rest'
2. Made a separate binary of the converter, package the javascript and rewrite all the glue that lets them interact in PHP
3. Make this thing install-able as one big blob, acting as alternative 'server' with a proxy component that ties it all together

This was a LOT of work, but after polishing it, we had something we could show to the ONLYOFFICE people. They were initially not huge fans of what we did - no surprise, as it was an ugly solution. We discussed this for a fair bit and in the end, we agreed on an approach.

The result was what we made available last January with the first release of Nextcloud hub. We saw it as a first step towards deeper integration. Watch the video below to get an idea of what it looked like!

📺 view video on YouTube

And then...

After release, two things happened.
First, ONLYOFFICE has sadly been unable to focus much on the integration with Nextcloud. There was a long wish list we had - there is a lot you can do to make the experience nicer, from removing/disabling/hiding duplicated features like the build in chat and file handling to making file collaboration work in other apps like Talk, or adding certain features that connect even deeper like @mentioning users for example. Unfortunately, this didn't happen. No blame, there is a lot happening in the world right now!
Second, Collabora was inspired by the work and while we didn't think we could make it install-able with such ease, they obviously know their own technology better. And indeed, they did make it happen! Besides that, we worked with them to improve the already pretty good integration further, allowing you to edit documents while in a video call or chat in Talk.

As our focus continues to be on providing the best experience possible, we simply looked at that: what gives, right now, the best experience. And thus our latest video shows Collabora instead...

📺 view video on YouTube

Note that this doesn't mean we don't like ONLYOFFICE. 😍 This just changed the default you get on installation. Both solutions are very good and continue to be available for users! And perhaps things will change for the next release. Given the large differences at every level between the two, I consider it a benefit to have both approaches available for Nextcloud users!

So is Collabora better?

I will let Captain Marvel answer that.

Home Automation, AI and the Crownstone

Waiting for that future where you're dressed automatically? I'd rather do that myself and don't have a Roomba yet but as tech marches on, we'll get more automation in our homes.

With more and more 1984, Brave New World and Farenheit 451 being brought to this century by our esteemed leadership and our corporate overlords, I'm hoping that this tech will be ours, rather than theirs.

Enter a nice player in the "automate stuff" arena: Dobots. In their own words:

Our goal: Really smart buildings. Really smart robots. We're a startup in AiTech with applications in CleanTech and GreenTech.

What makes them nice is that they are real Open Source folks, putting what they code on github under a free license and working with and building on open tech.

They previously did industrial cleaning robots and other stuff. Currently, they are running a kickstarter for a smart power outlet as a first foray into home automation. EDIT: they've instead decided to, for the first run, only create EU plugs as there was little interest in the US. You can order them on the crownstone.rocks website.

Enter the Crownstone

How is AI relevant for power outlets? More than you'd think. One example is SLAM. SLAM (Simultaneous Localization And Mapping) tries to answer two key questions in Robotics:

• Robot Localization: “Where is the Robot?”
• Robot Mapping: “What does the world around the Robot look like?”

(read more about SLAM here)

Dobots has turned this around in the crownstone, using these algorithms to map your house and localize people in it. Yes, the Crownstones know where THEY are and where YOU are. While not exactly a localization tech, the Crownstone uses Bluetooth LE for this so it works with pretty much any device. And the best part: their localization code is, in Javascript, to be found on github!

This means you need no motion detectors or cameras to know where people are in the house, keeping things simpler and cheaper. But Bluetooth LE is used for managing the Crownstones, too. Rather than turning to WiFi or (expensive) central control hubs, Dobots lets the Crownstones automatically create a mesh network. Your smartphone acts as control hub (apps on github, of course) though you can also take a Raspberry Pi, plug in a bluetooth usb module and have it act as hub. That way, even when you're not at home, you can control devices or get notificationsthat, say, your television, computer or other devices are getting unplugged. It uses XMPP and WebRTC to get through your firewall and guess where you can find the Cordova based Raspberry Pi app...



But there's another innovation in there which helps avoid extra devices and complicated configuration: extremely fine grained power usage monitoring. Yeah, it can tell you how much power your fridge and TV use but more importantly: it can automatically detect which device you connect to it! So when you leave the house, it can kill power to your tv but not your fridge... I've been told they think they eventually will be able to figure out different makes and models of laptops based on their power signature. Now is that cool, or what?

The algorithms to do this are currently Matlab code but once finalized, they'll be on github, too.

Dobots regularly works with students who get to play with their tech and come up with new, innovative use cases. And this works wonders. Just some results from a recent hackathon:

• Team 1 developed ChildLock. Devices are only turned on when adults are in proximity.
• Team 3 developed Start VR. Virtual reality that allows you to picture your own furniture in an Ikea store.
• Team 4 introduced Never Lose. Lights indicate for elderly people where they have lost items with iBeacons.
• Team 5 used Crownstones to indicate the way to store employees.
• Team 6 worked on Tommy. An AI that analyzes patterns of daily life to combat loneliness.
• Team 7 developed Any Morning. Your phone using the Crownstones guides you to your morning routines to make you leave your home on time.
• Team 10 implemented Tipspromenad. Kids have to find objects in a place combined with solving puzzles for fun!
• Team 11 developed SpotOn. In emergency situations lights indicate how to flee a building

All together

The Crownstone has some nice advantages over the competition:

• Functional. Dimmer, iBeacon, a current measuring device, a standby killer and more in one.
• Cheap: you get 2 ready-made or 3 do-it-yourself for Eur 75 but there's no need for a hub, motion sensors or other stuff.
• Open. Using open protocols and code on github and I expect interesting applications to come from the community.

I did an interview with their COO - for more background, read it on LinuxVeda.

So I say - if you are looking to start with some basic home automation, go and get some Crownstones and get started!

What's Holding ownCloud Back?

In the recent article about the ownCloud event program, I pointed out that while ownCloud has 2.5 million users, it is a drop in the ocean looking at the number of Internet users (a little over 4 billion today). The announcement of the "Let's Encrypt" initiative from the Electronic Frontier Foundation, Mozilla and others prompted me to write this: it is one step in the direction of removing the limitations holding back wider ownCloud adoption. What does the future hold?

Easy ownCloud

As Frank pointed out in his blog on the future of PHP, ownCloud has ease of use as an explicit and very important goal. And while the technological choices made aren't always so exciting and bleeding edge, they do result in ownCloud being very easy to deploy on a very wide range of devices. Plenty of tutorials exist showing it running on everything from Rasberry Pi devices to big iron at organizations like CERN, where physicists looking for the origins of the universe are routing hundreds of terrabytes of data through their CernBOX build on ownCloud, sharing and collaborating on the data analysis.

Limitations

Unfortunately, there are limitations outside of what ownCloud can directly control.

In the database area, SQLite is default because it requires no manual setup whatsoever. But performance suffers when an installation has more than a trivial amount of data. When sharing with more than 15 users or indexing your mp3 connection, SQLite usage leads to frequent time-outs and other issues!

Another, more serious issue, is the architecture of the current internet. Most users are set up at home behind a firewall provided by their internet router. While this provides some additional security, it is mainly because the limited number of unique addresses available in the still widely-used 'IPv4' protocol. It simply is impossible to assign a unique address to each device connected to your internet at home. But this means your server will not be reachable when you're not home, unless you adjust some settings on your router. While we can configure some routers automatically, most we can't and as every router is different, an easy 'generic' how-to can't be provided either.

A third issue is that an ideal ownCloud platform would be small and cheap devices like the Raspberry Pi, but these are almost all based on 32bit CPU's. Due to technical limitations in the platform ownCloud builds on, this means you won't be able to have it handle files bigger than about 4 gigabyte! That is a big limitation if you'd like to store your virtual machine or Blue Ray collection on your ownCloud.

The fourth issue I see is security. While not the biggest problem of the three, setting up a server to be secure, including a decent SSL certificate, is not easy. I personally couldn't figure it out and while I'm new to server things, I am not a technology hater by any means. My parents wouldn't ever be able to figure it out and more importantly, they wouldn't want to!

Solutions

These four issues to wider ownCloud adoption aren't the only ones, but as far as I can tell, the biggest. So how do we deal with it?

There are several routes to an even easier ownCloud installation. Having a pre-setup operating system in the form of a container (Docker?) or a virtual machine can take care of much of the trouble around database setup and help a lot with the security issue. However, it can't run on light hardware like a Raspberry Pi and doesn't deal with the file size problem.

When it comes to the address limitations, the internet is slowly transitioning to IPv6 which will provide more unique addresses for each person than IPv4 offered in total (see here how Google explains IPv6). So, essentially, we just have to wait for this problem to be solved.

The hardware problem is also working on solving itself: the upcoming new swath of ARM CPU's (and Intel CPU's targeting the embedded market) are fully 64 capable so while current-gen Raspberry Pi devices (and other embedded devices like routers!) aren't perfect for ownCloud, a year from now many new devices will be perfectly capable of providing a great ownCloud experience.

The Electronic Frontier Foundation's "Let's Encrypt" initiative offers a (partial) solution for the security issue. Without it, a pre-configured ownCloud system will most likely be set up to use a self-signed certificate. While secure in principle, it always warns visitors of the self-signed state and thus isn't ideal. Let's Encrypt provides an automated and more importantly free (in terms of cost) solution for this.

And now

While I'd love for all these changes to be implemented yesterday, in reality we simply have to wait for the transitioning to IPv6 and 64bit CPU's. In the mean time, we can already start working on integrating Let's Encrypt into virtual machine and Docker images with a pre-configured MySQL (or MariaDB) and perhaps recommend people to run them on a 64bit capable system like a modern NAS or a NUC. The ownCloud-in-a-Box image on SUSE Studio is a great start!

Meanwhile, getting ownCloud ready to run on a wider range of devices and perform a wider range of 'cloudy' functions like running as backend of the Chromebook devices (see this page and ping me if you want to get involved) should be on the agenda as well. I personally look forward to more 'social' integration in ownCloud, like the ability to comment on images or other data and share these with the people you share files with. We're on it, tags sharing is integrated for ownCloud 8 and a generic metadata repo was created (empty still). Get involved if you can!

Obviously, telling people about ownCloud is still important - which is what the ownCloud event program is all about - and help is welcome. Go to owncloud.org/promote and share the love!

ownCloud 7 awesomeness

One of the things I love from the Free and Open Source software world is that doing things in the open simply leads to better solutions. Resources are often constrained, polish might be lacking, but frequently from the seemingly chaotic processes emerges brilliance.

The upcoming ownCloud 7 has one of those things: server to server sharing. You see, for a long time, I and others have been asking the ownCloud desktop client developers for a feature: support for syncing multiple ownCloud installations. That way, files from our corporate ownCloud installation (of course we dogfood here at ownCloud Inc.!) and my private ownCloud could both be synced to my desktop and laptop. Unfortunately, while it has been on the todo for a while, it just kept pushed down by more urgent feature work.

While you could get it to work already by running multiple clients and playing with the config file locations, it seemed a bit brittle to me and I just accepted this feature wasn't there yet.

Only today, during my bike ride to c-base, did I realize that ownCloud 7 actually introduces this feature. And I even wrote a sneak preview about it! It is the server to server sharing that solves this issue.

What is Server to Server sharing?

Let's step back. What is the major thing that 'private' clouds don't have which public clouds do? Other than the NSA snooping, that is...

Well, you're all alone, of course. If you want to share a file with another student from uni, you have to create an account or use a shared link. He/she will then have to visit your ownCloud to be able to work with you. It gets quickly messy with a lot of files.

This is where Server to Server sharing comes in. You can simply share a link and your collaboration partner can add this, either a folder or a single file, to his or her own ownCloud. They can put the file wherever they want in their folder structure (we've gotten rid of that rigid shared folder concept in ownCloud 7!) and work with you like the file was on their own instance.

That means they can also locally sync the file with their sync client by just putting it in a folder that is synced!

Boom. You don't have to create and manage multiple server accounts in your sync client, creating a folder on your system for each server you work with. No, you just add the share to your ownCloud and put the files wherever you want - in one folder, or grouped by subject - whatever works best.

Now tell me that isn't awesome ;-)

There's more

Of course, this is just a first step to bringing ownCloud servers closer to each other. Our goal is full 'federation' of data: transparent sharing between servers so they can act as one cloud, protecting privacy while giving you the convenience of sharing, collaborating and communicating with friends, family, collegues and more. Once you connected to another ownCloud, you should be able to share files with the users on that server seemlessly - and other data, like contacts or music! You should be notified when things are shared (a news feed!) and be able to comment and chat. This however still needs work. If you're interested in helping to make this happen, consider joining us at the ownCloud Contributor Conference from August 26-31 in Berlin, Germany!


* Note that you can have kind-of server-to-server sharing with ownCloud 6 by manually mounting folders from other servers via webdav. This of course comes with various limitations (you do have to give out webdav credentials, to name one) so the new server to server sharing is a massive improvement...

It all comes together: no more Software Compilation but more KDE!

KDE 4.0 demo in Dresden, 2007 (short hair time, yes)

With the KDE 4.0 release we had the issue that everything was one big blob: the libraries, the desktop and the applications, all inter-dependent.

Back then, at the end of 2007, the libraries and many of the applications were in a very good shape. Especially the KDE Edu applications I remember: they were stable, pretty and awesome for many months already before the release and their developers were itching to get their code to users. I had made a blog post with cool video's of KDE edu apps in October 2007. Here is Kalzium at that point:



Unfortunately, the desktop, having undergone a HUGE rewrite, was not at that same level of quality. As I wrote later that Month:

"When I show people the state of Plasma, they're like "hmm, that's not good". So I then proceed to show the Edu and Games, cheers them right up."

But the last release of KDE had been in 2005 (!!) and after more than two years, we really wanted the new and improved apps to get out to users. The desktop was basically workable so we decided to release. Code that is not in users hands rots away...

We all know how that went - distributions shipped it as default and the internet erupted with hate.

Doing better now

So, for the 5 series, we split it all up: Frameworks 5.0 (the new name of our modularized libraries) was released last week, the desktop came out yesterday and the Applications still mostly have to start moving to Qt5/Frameworks 5... We weren't forced to release half-baked stuff but everything came 'when done'.

KDE is now People. And dragons.

Better separation: rebranding

That was possible because we rebranded 'KDE' to mean community in November of 2009. This created (over time...) separate brands  for 'Plasma', 'Applications' and 'Platform' (now 'Frameworks') which could release on their own. Could being the operative term here, as we kept releasing it together.

That created quite some branding confusion, also because we had not thought through all the issues we would bump into. So when we finally decoupled releases at the release of Plasma 4.11 (the latest release in the 4.x series) and the KDE Platform at 4.9 (although that got some serious updates since then and has kept increasing version number for packaging convenience), it was largely ignored.

Which in turn created some confusion when Frameworks 5.0 came out - several people asked 'where can I get KDE 5', expecting to run the desktop and applications already. Well, I'm quite OK with users saying 'I use KDE' as long as they mean Plasma and realize there is more to KDE than the desktop. Because when I say I use Microsoft, I am not lying. I've always been a huge fan... of their keyboards. Not joking, their operating system wasn't great last time I used it but I love the 'comfort curve' series of keyboards. They should stick to hardware, clearly their strongest point.

In hindsight, we probably better would have waited until there was a real need for the rebranding - like today, or in 2013, when Plasma stopped releasing. Then again, we did expect that to come soon - there already had been talks about disconnecting the releases, it just didn't happen. Well, hindsight is always 20-20, they say...

And as the title points out - there is no more need for the 'Software Compilation' term, which was invented to solve the confusion of 'KDE releases three separate things but all at once'. We no longer release the Applications, Desktop and Libraries at once...

Better communication

Another thing we changed is our communication. In the KDE 4 times, what we did was PROMO: being as positive as one could be ;-)

Since then, we've learned a little actual marketing. Perception management and fancy stuff like that. Including properly explaining what something is and is not ready for! That's why I wrote a known issues section for the Beta of Plasma including:

"With a substantial new toolkit stack below come exciting new crashes and problems that need time to be shaken out."

With a clear section on where we stand in the final release announcement on the dot (See Suitability and Updates on the bottom of the article) we have made clear what the state is - and that we don't think distributions should ship Plasma 5.0 as default. And distributions have picked up on this - at least neither Kubuntu nor openSUSE will ship their upcoming release based on Plasma 5.0.

Forward

Now, the future. Plasma 5.0 is out, and on a 3-month release cycle. Frameworks comes with a new version every month, the Applications are still at 4.13 with a beta of 4.14 out last week. After 4.14 is out, the work on a Frameworks 5/Qt 5 port will commence full-steam but some applications will be ready before others. How will we deal with that conundrum? I don't know yet. There might be two KDE Application releases for a while, as some applications will take longer to get ported than others.

But we're better positioned than ever to bring innovations to the Linux Desktop. So let's see what the future brings!

(Ok, I do have SOME thoughts on where KDE, is going, see Part 1 and Part 2)

Frameworks 5.0 is out!

It took us a while but here it is. And I think we did quite a decent job communicating this to the outside world with articles like

• An extensive overview of and background on Frameworks 5
• Tech Preview release article with lots of info
• How KDE contributed to Qt 5.2 to ready it as base for Frameworks 5
• The mini series of 'where KDE is going' discussed Frameworks and its importance pt 1, pt 2
• Article for Linux.com about why Frameworks is a big deal for Free Software

For the final release (this one, I mean) we had far less time than I had hoped - I wrote most of the announcement last Saturday (though we started a few days earlier and had our already-prepared communication plan) and we didn't really rally as much of our 'friends' to help promote the release as I had planned initially. And yesterday my internet broke down so in the end, Mario and Jonathan R had to put most of it live, half a day behind plan. But despite these issues, it did turn out quite well I think.

Now the communication is done and it is up to the code to prove itself in real life!

As I blogged before, I think this is a huge deal for Free Software on desktops AND mobile devices - it goes far beyond the KDE community. Qt is by far the largest Free Software ecosystem doing native (non-web, I mean) end-user software, but much of that is proprietary. Which makes sense - Digia and the other companies in and around Qt have to make money and don't have 'spreading Free Software' as their prime goal. Frameworks introduces a genuine FOSS touch to that, hopefully bringing many of these developers in touch with the KDE community and the Open Source development processes.

Oh, and just a few more days to go to support Randa 2014, and support it really needs. Remember, this is where Frameworks started! Let's see what KDE comes up with this year at Randa ;-)

Where KDE is going...

In my blog about conf.kde.in, I promised I would blogify my talk about KDE's future but failed to publish it until now. I thought the content might be a good fit for on paper. It took a while, but the upcoming Linux Voice should feature an extended version of these blog posts about where KDE is going, with quotes from a variety of KDE folk providing some background.

Meanwhile, on the dot I have published an updated version of the first blog post about the technical side of things: KDE software. It is mostly aimed at people not intimately familiar with KDE but curious about what is coming. Users, for example...

If you find a bug, report it to me or the dot editors! And: spread the article around for users and interested people to read...

Building Converging UIs

I just blogged about my article on linux.com about the just-released KDE Frameworks 5 sneak preview.

Convergence in 2010: Plasma Netbook

Converging Form Factors

On the Frameworks, one can soon expect to see releases of KDE's Plasma Workspaces. A Technology Preview of Plasma 2 has already been released and this ambitious project has not lost any of its goals. Today, I noted that ZDNet's Steven J. Vaughan-Nichols wrote about what he expects from Ubuntu in 2014. There, he quotes Jono Bacon talking about formfactor convergence. And the intarwebs are full of people making jokes that Microsoft is copying Ubuntu with their single UI for multiple devices. But let's not forget where they got their ideas...

What is real ambition?

I would argue that neither Apple, Microsoft, GNOME, nor Ubuntu/Canonical are even half as ambitious as the KDE Community in the area of convergence. They are all merely catching up to the state of KDE technology in 2010. In that year, the KDE community released Plasma Netbook, a plasma-based shell optimized for another form factor: the netbook. With far more advanced convergence than anybody today has yet shown: Plasma Netbook and Plasma Desktop share well over 90% of their code, as opposed to not even sharing toolkit or display shell (Ubuntu) and having a completely separate desktop (Apple). On Plasma, widgets can dynamically adjust to the constraints of their environment, be it on a panel, free-form on the desktop, full-screen, in a window or in a tiled environment. And yes, the different form-factor optimized shells be switched on-the-fly. No separate login or account, no loss of functionality, no separate applications for each shell, nothing like that. It just works. See this blog from 2011 to get an idea how the tablet plans were doing.

Plasma on desktop/netbook/phone in 2011.

I understand what Microsoft is doing - trying to build a single user interface for vastly different devices. And I guess we've all seen how it does not work - Apple is smarter, in that regard. Underlying technology can of course be re-used but you simply can not make a UI which works equally well on a 75 DPI 24" screen with mouse & keyboard, on a 455 dpi touch phone, on a 300 DPI touch tablet and a 64" television with Kinect or something like that...

Instead, the Plasma team has build a technology which separates presentation from logic, allowing you to build UI's which adapt dynamically to the needs of the form factor.

Below is a video of Plasma's awareness of the container size in action, like it has functioned since it was released in 2008.


Now I don't deny that in terms of resources, MS and Apple are so far ahead they can make pigs fly. Our more advanced architecture and ideas can't really compete with what they do and as long as we have 0.5% market share on the desktop, Free Software will probably not get the resources it needs to polish things to the same degree. That's a bit frustrating but it doesn't mean we frequently do things far beyond what the big boys do: anybody who has seen the introduction of the upcoming release of Mac OS X and knew about KDE Connect knows we're way ahead of them when it comes to phone-desktop integration ;-)

Moving Forward

All this technology will be brought to a new level with the release of Plasma 5, where your workspace will be able to smoothly morph into a different form factor without even a hickup. So, when it comes to the convergence of formfactors, KDE is lightyears ahead of what the competition is even aiming for. And outside of that, we're doing awesome stuff, for sure.

Did I say something about the power of innovating in the open? That's what I'm talking about.

oSC13, Strategy and Stable

At the openSUSE conference there were discussions about the future of openSUSE. Last Wednesday I summarized some of the ideas around Factory. Today I blog about the openSUSE releases.

Note: This is a combination of stuff I heard (not just at oSC but also earlier - even from the first strategy discussion, 3 years ago) and ideas I have. I just attempt to put it into text so it is easier to shoot at, comment upon, think about.

Stable - big picture

On the Stable release future, things are much more in the air. In his keynote, Ralf hinted that SUSE has some ideas about how the future of openSUSE should look:

• Open Governance - SUSE wants openSUSE to be successful and independently strong. Ralf noted that SUSE does not expect or aim to make money on openSUSE directly; other parties however are very much welcome to build a business around openSUSE.
• Filling the gap - SUSE and openSUSE have a great win-win relationship. But SUSE notices a gap between openSUSE and SLE in the market: SLE is oriented to large enterprises and the current openSUSE has a too wide market to feed, from newbies to hard core developers to professionals.

This is, from the SUSE side, the big picture; SUSE wants to provide room in the openSUSE ecosystem for initiatives, both from volunteers and from the commercial side. And SUSE would like openSUSE to move up a little, offer solutions for people serious about computing in a professional capacity. But what does this mean exactly?

Concrete changes

Let's start again with what came out with the keynote. Ralf essentially summarized some of SUSE and openSUSE's history and talked about our current situation. openSUSE Stable, our final release coming out every 8 months, is a compromise between stability and being-up-to-date. But this compromise was made in a time when far less people used the many repositories on OBS offering more up-to-date software; and before Tumbleweed and Evergreen saw the light of day. It is 2013 now and Ralf hinted at a possible re-evaluation of the choices that were made back then: perhaps, we should limit our scope, improve quality and increase the life cycle of openSUSE?

Improve quality

Let's talk about quality first. This is difficult, harder than it seems. Factory has some automated testing and openQA got better thanks to some recent work, but nothing can replace human testing and there is not enough of it. There is room for improving our processes here, but there is also the fact that some people in our community care more about Stable and others more about moving forward with Factory. We need to find a way to service the needs of both. Having Factory more stable, hence more usable on a day-to-day base, would be a great first step here.

Limit the scope

If you want to do something well, you should focus on it. It's the Unix philosophy many of us share: do one thing, and do it well. openSUSE is well known for doing everything a bit - making everybody a little happy, but nobody REALLY happy. Part of why this model is still working reasonably well is thanks to OBS - which has grown in this role. Many, many users these days use the openSUSE release as simply a base for their favorite OBS repositories. If we want to improve quality and lengthen the life cycle, we can use this model.

For example, parts of openSUSE which can be and are maintained longer get in the stable releases; other parts with a shorter life cycle (Firefox for example) stay on OBS. This means that being part of Stable depends on commitment from both upstream and the openSUSE maintainers of the packages; as well as testing capacity and our quality standards.

Lengthen life cycle

A portion of the openSUSE users would like to have a longer release cycle - the interest in Evergreen and questions on our mailing lists and forums make that clear. SUSE has dedicated a set amount of resources for maintaining openSUSE releases; checking security and entering bug fixes. The maintenance process is now opened up and some teams in openSUSE are contributing to the maintenance, lowering the load on the SUSE maintenance team. A smaller scope (resulting in a smaller release) would do the same, as Ralf mentioned in his keynote. This will have to be a part of the solution we're looking for to increase our maintenance window.

In practice

To put it in perspective, three examples of how we could do this. Keep in mind that sticking to the openSUSE-has-all-and-comes-every-8-months model is of course also an option...

Rings, rings, and rolling!

Presume we will have rings in Factory (see blog from Wednesday)? Let's put them in the distro. There's the core with ring 0 and ring 1 ("everything up to X"). It is released every 2 years and maintained for 3. Then, there is ring 2, with the basic desktops and their devel frameworks. They are maintained 2 years after release (every year). Then, ring 3, the applications and development tools. They are updated from OBS, essentially rolling.
It would of course be possible to keep ring 3 also stable - for, say, 1 year. Update it when a new release comes out - you can keep the core and desktop from the previous version but have the new apps.

Split it up in components

As Robert proposed on the factory ML this week it would be possible to split openSUSE Factory not per-se in rings, but in smaller components, dictated by their dependencies. Some would be one package, others would be multiple. Each component is developed by a team in a factory-like model. Rob states: "Each component advances based on it's own release cycle and the component team decides which release of it's dependent components to build against. Some tooling will be needed to help sort out the combinatorial problem."

And "when a release approaches,the release team picks a version of the core component that will be the base for the next openSUSE release. This version is used to populate factory and may be the only component that is in factory for a little while." This scheme should make the job of the release team easier but would still allow us to release the same openSUSE. Perhaps faster, perhaps slower - or perhaps in pieces, giving users an unprecedented level of flexibility!

Core, selection + OBS

How about we take the core of openSUSE (ring 0 and 1 from Coolo?), add a few components which have a long-term commitment from their teams; and let OBS take care of the rest! So, we'd have, say, the Core, our default desktop with a base set of applications for it, LibreOffice and Firefox. That is the release. The rest you grab off of OBS. The core is maintained for a longer time (this very much depends on community input!) and much more tested than what we ship today.

To limit the impact of the change and for the convenience of our users, the installer would still be able to offer the same choices as it always has; but besides adding the packages, it also enables the repository they are found in!

Initially, the release would be a lot smaller than it is today - but in time, as people step up for long(er) term maintenance, it will grow again. The idea is similar to what was proposed on the factory ML this week, but might lead to less clashes between components as there are less of them (much is in the core, presumably).

The real discussion

The issue with all the above scenarios is that while we can technically do them (some are harder than others, of course) the choice doesn't just depend on what we can do but also on what we should do. That makes the discussion a lot more interesting. We have to fix some things in our process, adjust to reality, that is clear. But do we want to shift direction, too? What is our real goal?

Our previous strategy discussion hinted at the fact that most of our users are professionals, people used to computers. We decided not to focus on newbies and making things simple to the expense of flexibility of our distribution. Should we go further on that path, make harder choices to focus on people using computers for a living?

Conclusion

What I tried to illustrate with the 3 examples is that we can go in various directions. It will be up to some of our core developers as well as the dev teams to comment on what makes most sense, what is the least amount of work for the biggest benefit (to users). But there's also the question of who those users are!

oSC13, Strategy and Factory

The openSUSE conference had some chats about strategy. Ralf talked about suggestions from SUSE in his keynote and there were more suggestions discussed in person between various people. I'd like to summarize some of the things I heard. In this blog I will talk about the directions of Factory, what Ralf mentioned as SUSE's ideas from his keynote; later this week I will blog about the openSUSE releases.

This is a combination of stuff I heard (not just at oSC but also earlier - even from the first strategy discussion, 3 years ago) and ideas I have. I just attempt to put it into text so it is easier to shoot at, comment upon, think about.

Factory

Let's start with talking about Factory.

Who is it for

We need to think about who factory is for, how these people are supposed to be using it etcetera. Right now, we have a shared understanding - but it probably isn't always as shared as it seems and it can be good to write things down and talk about them (see my keynote at oSC). Some of these thoughts will come to the mailing lists, I am sure, over the coming months.

Where should it go

On the technical side, there are some things I've heard about and seen several times and which will most likely see some form of implementation:

• more automated testing - the openSUSE team did a openQA sprint but many agree that there is more room for improvement.
• getting more people involved - As Ralf said, SUSE will commit to more SLE engineers on openSUSE; and the community & the openSUSE team should work more on both growing our dev pool and training people. In a GSOC discussion about this at oSC, this point was made as well: it would be good to use GSOC also for bringing existing contributors to a higher level.
• Bringing Tumbleweed, Devel projects and Factory in alignment - As Ralf noted in his keynote, not all work on Devel projects and Tumbleweed benefits Factory and openSUSE ultimately - it would be great to unite forces and bring them all in one process!
• segmenting Factory in rings - which Coolo has been talking about for a while now. It would create a Ring 0 with the bootstrap- and compiler infrastructure, ring 1 with the base system and other rings on top of that. He has been experimenting with this, hinting at some results in this mail. I leave it up to a later post (perhaps by/with Coolo) to be more concrete about this whole thing once the core Factory team has talked to more people and expanded upon it...

That last point is by far the least concrete - it is an idea which is discussed and toyed with. How much and what exactly will happen - only the Geeko knows ;-)

Some discussion has started on the mailing list, by the way, with the idea of segmenting Factory in even more 'components' than just the rings. I had a chat with Coolo before this proposal came out and I suggested the same thing. He noted that it would lead to a huge mess of dependency issues, including many circular ones (he gave libpoppler as example). This is already brought into the discussion there, let's see where this goes!

Akademy for everybody

About six weeks from now the yearly KDE conference 'Akademy' will kick off in Bilbao, Spain! Looking forward to that. I had to ramble a bit on why I think it's worth going there. And a tip for if you still have to book!

Have not booked yet?

Aw, I was late, and I'm paying the price, in terms of money and convenience. There's work and family and in my case a dose of always-lateness with this stuff that got in the way. Probably not different for others. But keep in mind - I never met anybody who who was sorry they went through the trouble of going to Akademy! It's worth it...

Relevant

Akademy is relevant, useful and fun above and beyond just another Free Software event. Seriously. Even in a world of Android, KDE still builds major Free Desktop stuff. Think about Krita going places lately. Think about how KDE PIM still is arguably the only serious Free enterprise-ready mail-calendar-etc solution on the market. There is plenty more at the event: KParts might get a successor, we move forwards with new task-centered UI paradigms, we move to new devices and more.

Directions

Akademy is important for setting directions. We don't all agree on where KDE is going and that's why we meet. To SET goals and CHECK expectations. That is hard to do over mailing lists, blogs, social media and all that - so we need to talk in person. We're doing new things and it takes a while, often a long while, to get stuff together. We have to address misconceptions, improve common understanding, find out why we disagree. And this works, we're making progress! Nepomuk is now getting the love it needed and same for KDE PIM, the Plasma team can finally implement their ambitious plans without the technical limitations of old thanks to QMLv2 and openGL etc etc.

And I'm betting that those who think KDE is doing the wrong thing actually have arguments and reasons for that. Are these reasons so vague and unconvincing that nobody will listen? Or would the KDE folk be so stubborn they wouldn't listen to obvious facts? That is either under-estimating who-ever-disagrees or the 300-odd KDE contributors. And both, I think, are undeserving of that.

Family

Akademy is about more than listening to talks or giving them. Even if you haven't had time or motivation to contribute, if you didn't agree with one thing or another or got yelled at by (or did yell at) somebody, does that matter? KDE is family: family has plenty of disagreements and fights, yet in the end, you all hug and make it up to each other, yes? Being at Akademy is not just about learning new things and deciding on the future of what we do (and, to a large degree, where Free Software for end users is going) but it is also about meeting, having energizing and inspiring conversations, learning from each other, sharing great ideas. Something we all enjoy, don't we?

Booking

I'm sure there'll be a lot of people at Akademy but I think that should include you... Now, about the booking. It will be hard to get a hotel room, esp if you need space for two people, I'm afraid... I booked the first 3 days (Thursday-Friday-Saturday) for a painfully high price in the Holiday Inn Express Bilbao and the rest in RÍA DE BILBAO which is far cheaper.

And last but not least, if you're going to Akademy and want to make sure all relevant people are there, be sure to talk to those you'd like to have a chat with, convince them to go! And perhaps add the awesome going to Akademy badges to your blog or website!

On Innovation, Free Software, NIH, Geary, Trojita and KDE PIM

I argue that if Free Software wants to get anywhere, it needs a culture of 'collaboration first'. In most areas, we have that. In some, we don't - and that is hurting. The desktop is probably a prime example of that.

Rob Boudreau wrote an opinion piece about Personal Information Management (PIM) and the future. He concludes that 2013 has different requirements from PIM than 1995, and:

"KDE PIM seems to be the only FOSS project working on technology that will eventually go beyond just the PIM itself"

I think reality agrees with him. Mobile devices are cleverly integrating chat, email, social media and phone in one. Contacts have details on all of these and show the latest tweet or Facebook message of that person as status. Why doesn't the desktop do this? Well, it does, but only by putting your data on corporate servers, accessible though web browsers: Facebook, Google, Microsoft, ...

The Linux Desktop has a mission here: help keep user data out of the greedy hands of Google, Facebook and Microsofts! That can only be done by building on the shoulders of giants, not by re-inventing the wheel out of sheer arrogance. Let me explain what I mean.

Collaboration

10 years ago I often presented to people new to Free Software and how we work. I would explain the benefits of Open Source so:

"Imagine you thought of the best New Idea for word processing. From now on, documents will almost write themselves. But you first have to embark on the huge journey to write a full word processor. Three years later, your amazing application does not get anywhere as it can't open MS Word files."

"Imagine instead you added your amazing feature to an existing word processor. The discussion with the experienced word processor developers even resulted in a better result!"

Being able to stand on the shoulders of giants is an important benefit from collaboration in Free Software. We do have competing projects but note that most successful forks and rewrites were started due to a lack of collaboration! A recent example is LibreOffice. Often people from the 'original' project join or even start the fork or rewrite. Wayland is build by the Xorg team and the MySQL fork MariaDB is led by the founder of MySQL!

The Linux kernel is another great example. Google, for example, is putting in enormous resources in getting their technologies back into the kernel. After a period of forking for the benefit of speed and efficiency, they figured out that in the long run, it actually is more efficient to not fork and put in the extra effort in collaboration.

Collaboration-by-default is not a given. Aaron Seigo said about KDE:

"The open nature of the community has purged the “not invented here” syndrome from our ranks"

Yes, the KDE community has a strong tradition of re-using efforts and building on the shoulders of giants. And questioning those who don't! But such a culture took years to build as there is plenty reason to NOT collaborate.

Reasons for not collaborating

Failing forks or duplicating projects are often based on personal conflicts or a dislike for certain toolkits, languages or technical choices. And there is much starting from scratch because developers just focus on their own problem or want to learn something new.. While I would argue that you probably learn more working with experienced, competent people, and you might get more done, too, it is not hard to understand these reasons.

Then, there is psychology. Most people think they are smarter than average and programmers are no different (sometimes expressed as "what others do is easy")... Given the bell-curve followed by the distribution of intelligence, this clearly is one of the many fallacies our brain saddles us with. Even companies are affected. Google, working to get their features into the upstream kernel, discovered that not all the intelligent people in the world work for them and there is lots of room for improvements in what their team came up with.

More than one mail client

I argue that this last reason leads to more duplication of effort than healthy in the area of mail clients. Recently, Yorba pushed to get funding for Geary, another 'new approach to mail'. And there is Trojita, also providing a great IMAP client. Both projects were started in the last couple of years and seem to be re-inventing the wheel -- twice. As you probably saw many prominent developers giving a hard time to a company insisting upon writing another display server, I hope you understand how misguided I think this is. Yorba said they decided to write a new email client to keep things simple and fast and due to the complexity of other mail clients... I described the rationale and wrongness of this "let's write a new mail client" approach in a comment on LWN a while ago. In short, I'm betting that the reasons behind it boil down to the previously mentioned combination of over-estimating oneself and underestimating the problem. In the case of email probably a lack of ambition and forward-thinking as well. Just email doesn't cut it in 2013, certainly not 5 years from now.

Bringing conversation-view to email is an awesome idea - and can probably be done through a Google Summer of Code project within an existing client. Writing an entirely new email experience needs a bit more effort of course, but writing the entire underlying infrastructure too - that is just a sodding waste of time, pardon my French. Good to see Trojita at least has joined the KDE community and is working with KDE PIM! How about you, Geary?

More than one conference

I've always been a big proponent of the Desktop Summits and I do indeed think that it shows both arrogance and a lack of big-picture thinking that these don't happen anymore. I'm glad that the KDE board, including Agustin (who organized the first Desktop Summit) managed to kick off a "freedesktop summit" at the SUSE offices. I'm also glad that some people who DO see the benefit of collaboration participated there - even if their communities don't (yet) understand that it is worth the investment.

What we need

We need a culture where we are critical of people who don't try to work together or are unwilling to put in effort to collaborate. Free Software depends on collaboration and not working together is just counterproductive. So I'd like to ask all readers to support collaboration: talk about collaboration, share the tales of success. And if somebody decides to write an app from scratch, or is writing an application doing the same thing another does - question them, ask why they go it alone, why not collaborate. It is totally OK to be critical of forks and anti-collaborative behavior. You don't have to beat anyone up, but at least making them think about it is a good thing. And if you're a developer: integrate technologies, build re-usable libraries. And remember that the shoulders YOU are standing on can be made stronger for future generations of Libre developers! Just dumping disconnected code is NOT a contribution to Free Software, contrary to what some folks seem to think.

I'd also like to ask people to support KDE PIM: if we want to have a shot at keeping our data out of greedy corporate hands and if we want to ever get onto the corporate desktop, Akonadi is the only architecture that really has a shot. Instead of writing new wheels, let's improve this one together! Yes, KDE PIM needs UI work. Then why not do that? Writing a new mail client makes total sense - if you build it on a proper infrastructure. The KDE PIM team is greatly looking forward to help people who want to write new mail, RSS, Facebook or contact management applications. Skills required are mostly related to motivation and the willingness to ask questions and get help - otherwise, javascript coding skills will probably get you pretty far as it makes all the sense in the world to write these new UI's in QML.

Concluding

I'm happy to concede that things are not black and white. I'm sure nobody can fully judge neither Geary nor Trojita or all aspects of the Desktop Summit. Mea culpa for any wrongness. But please take the lesson to heart: there is great value in collaboration. And getting these benefits means putting in 'extra' efforts, yes, it can cost you something in the short run - that is the whole point of long-term vs short-term thinking. So, next time somebody argues that 'we can go faster if we do it alone', tell them that most smart people do NOT work for you and problems are always simple when they're not (yet) yours. Or just remind them that once upon a time, people thought volunteers could never write a encyclopedia. It is the 21st century and collaboration is what sets apart winners from losers.

Take care!

Why should you participate in GSOC as mentor?

When deciding about participation in the Google Summer of Code program you think about the opportunities of getting new people involved or code written versus the time they have to put into mentoring and evaluating. But there are other, often overlooked advantages to participating in GSOC and I'd like to point a few of those out.

GSOC
Google started the hugely successful Google Summer of Code project in 2005 to get students exposed to 'real developers' and open source. Since then, it has allowed projects to mentor thousands of students who were enabled to work on Free Software full-time thanks to the payments by Google. Conceived of by Sergey Brin and Larry Page, the project was also supposed to bring fun, excitement and innovation to the open source community. Each year, thousands of students send in proposals and Google allows the most promising of them to execute their ideas.

In practice
Projects put in a lot of effort mentoring these students, hoping they will stay around after the project or get some coding work done which otherwise might not have happened. This works out to varying degrees - not all students stay, not all code gets merged, and some mentors feel that they put in more effort than it is worth.

Serendipity
While I can not judge the cost-benefit ratio for each project, I'd like to point out that there is a factor you should include in your calculation: serendipity. If you're unfamiliar with the term: it means "happy accident". Simply put, it is the positive outcome of something you were doing for entirely different reasons.

GSOC has benefits beyond 'getting people involved' and 'getting code written'.  Here are a few of these:

• GSOC creates a lot of positive attention around all projects that are involved. The vast majority of this is positive, fun news about features, getting involved in the project and more.
• The students also create a flurry of activity. They ask questions, get answers, write proposals, push people to help them. Activity leads to engagement and for those already involved it is often nice to see interest in the project and stuff happening.
• You also create long-lasting fans with the mentoring of students. They are 18-25, a very formative time in the life of a person. Most will look back with good feelings to their time with your project, even after 'life' has taken them other places. The value of this 'social capital' is hard to judge. But I am sure you understand what it could mean if one of your students makes it to CTO of a big company and they have a chance to do something related to your project!
• Your project learns from the GSOC experience. People learn individually, but projects as a whole learn too. This is not as ephemeral as it might seem: the way your project works is build upon many lessons-learned. GSOC makes your community adapt to new requirements of coordination and organization - learning!
• Sitting down together, thinking about ideas and discussing them is useful. You find out what your fellow team members think about ideas, what you could work on in the future - and perhaps you come up with The Next Big Thing™ ;-)
• Last but not least, there are networking opportunities and collaboration with other organisations. Some of the mentors and students travel to the GSOC meetups around the world, having an opportunity to discuss mentoring and getting new people involved with other teams. This is of course especially true when you collaborate with several communities together, like +openSUSE does this year with +ownCloud, Hedgewars and Oyranos.

I started this blog because I wanted to remind our students that is time to start creating proposals for Google Summer of Code 2013. But I'm hoping the above is also inspiring for mentors - there is still time to get involved!

So what to do?
For students looking for a project, I integrated the openSUSE/Hedgewars/ownCloud/Oyranos ideas I understood (that's a subset...) in the article so readers would get a glimpse of what GSOC for openSUSE has in store. It is cool stuff: integrating maps in apps in ownCloud, fcitx in wayland, comment support in OBS and much more.

Meanwhile, of course, there are GSOC idea pages all over. I checked out the KDE ideas page too - being the largest GSOC project in the last few years, I did expect quite some nice stuff. Oh boy... From web applications and library work to Amarok, Digikam and Plasma, there is a huge number of really cool ideas.

openSUSE and KDE are just two of the many organizations involved in GSOC. If you're a student, think about applying. And if you're a current contributor, think about how you could help your project by helping a student!

Klyde coolness update

I've heard Will Stephenson, Klaas Freitag and Frank Karlitschek talk about a lighter and/or easier KDE based desktop forever. And while I shared the ambition, implementing it is always easier said than done.

So when Will asked me to join his Klyde Hackweek project, I thought - awesomeness, let's try and finally move something forward! And that happened, we had lots of fun and I learned some real packaging tricks. I'll bore you with epic details at a later time ;-)

We realize the idea of Klyde and what we aim to do is a tad vague so Will and I had a long chat yesterday and came up with some more details about our focus.

1. Modular for everybody

The first goal is to make everything more modular. The openSUSE KDE team did a huge effor here, simplifying dependencies so you can have a Plasma Desktop without most applets, Activities, Nepomuk or Akonadi. Of course, that means you give up on good and useful functionality but reality is that we don't always need everything. This way the functionality is optional and this will hopefully become the default packaging state for openSUSE. What you don't use will not add menu items, widgets and memory usage to your system.

By default, a 'Klyde' desktop comes with none of the above-mentioned things and only a minimum of applications and applets. But upon installation of Activities the widget will be added to your panel and Akonadi will fire up the first time you start up KMail or Akregator!

2. Low footprint if you want

We know that 'lightweight' is not easy to define and it is hard to do scientific measurements of memory usage and all that.

Currently, the Klyde settings have some obvious things (disabling animations, disabling some services etcetera) and lots of temporary choices (plastique as widget style for example). We WANT to make informed choices here and input from developers on what is faster (even if that means loosing some functionality or eyecandy) is very much welcome. And we realize work will be needed: we would greatly welcome help creating a fast and efficient widget style, for example.

3. Simple by default

systemsettings simplified.

Systemsettings exposes about 80 different modules to the user. Some of these you'll (almost) never use. And many which, from an user point of view, belong in one place (like theming) are split over several categories due to technical implementation details. It is noticeable that this was designed from the technology up, not from the user requirements down. I spend a big part of my hackweek figuring out how these categories are populated and the modules are shown, then creating an alternative tree with only about 35 modules. Will made a patch to allow systemsettings to either show the basic or the full set of KCM's.

This is an example of what we mean by simple, although we're not done yet. Ideally, these and other improvements will go upstream and we intend to put work into that.

Note that this simplification, in no way, can be scientific. Of course 30 KCM modules is more 'simple' than 80 but it is very much a matter of taste to decide which ones need to be there and which ones don't. That's why we want to put effort in having our cake and eating it too: creating a proper theming KCM might allow us to get rid of a whole raft of theming-related KCM's, for example. Yup, we're still KDE people... But in other places, we are willing to make hard choices based on common sense, research and simply our taste. Unless a designer can convince us he/she Is Right™ we reserve the right to make bad decisions.

Feedback?

We're open for feedback and would love to hear input. Please remember that we're trying to get stuff done so if you have input, put in the effort to make it useful. Have mockups, refer to what others do or scientific facts. Remember that we are not trying to create a desktop for experienced computer users and tinkerers: they can easily morph the normal Plasma Desktop into what they want. It's what I do myself, its what the vast majority of people who read this do.

Instead we aim for a wide cross-section of people who don't want to put in the cognitive effort to understand abstract stuff like virtual desktops or activities. If you understand and use these things to be more productive (which I do myself, by the way), you're not our target audience.

If you want to help out, join the #opensuse-kde channel on freenode and check out our trello board.

Enough talk

Enough talk? Wanna try it? Yeah, it ain't perfect yet, but I've created an initial Studio image and published it in the Gallery. It can be installed, if you insist, but this is a beginning of a work in progress: it will eat babies whenever it can.

Click to go to SUSE Studio for the testing appliance.

About packages and a repo, this isn't easy as you would either have to remove packages by hand or start with a very basic system with only X for this to work. We're looking for a solution there ;-)

EDIT: User and root password for the appliance are the SUSE Studio default 'linux'.

Have fun with it ;-)

Klyde in a VM.