The Luminosity of Free Software, Episode 13

Lucky number 13? Maybe! Tomorrow "Luminosity" will get its thirteenth installment.

• Why we work together, and why we sometimes don't: In Free software, forking used to be seen as a really bad thing reserved for unfixable situations. These days it happens all the time. Duplication of  effort was usually met with "Why?" rather than "Why not?", and typically reserved for the "beginner's application topic" (Was text editors, then irc (or mud!) clients, then media players, ..) Have we forgotten culturally the benefits of working together? Have new priorities shifted the playing field? When does it make sense to I'll try to make the case for less diversity than we have now, or at least a more responsible investment of effort.
• Open Build Service: We'll be looking at one of the coolest tools out there for people building software, images and operating system distributions: Open Build Service. We'll look at how it works, how it can be extended and at some self-hosting options.
• Q&A: If you have a burning question to ask, do so in the comments here or on G+ and I'll do my best to get to it in the show. Or you can ask live on irc ...

You can join live tomorrow on G+ or Youtube at 18:00 UTC, with live chat on irc.freenode.net in #luminosity, or catch the show later on my Youtube channel. See you there!

Plasma Workspaces 4.11: A long term release

We are nearing the soft feature freeze for the 4.11 release, and that seemed like a good time to share some news. Plasma Workspaces 4.11 is going to significant for two reasons:

1. It will be the last feature release in the 4.x series of Plasma Workspaces. Feature development will switch fully to the Qt5 and KDE Frameworks 5 based Plasma Workspaces 2.
2. We will be providing stabilization releases (bug fixes, translation improvements, etc.) for two years for the 4.11 release of KDE Plasma Workspaces.

Before going into more details, let me offer a preemptive clarification:

This does not effect, in any way, anything other than the code currently in the kde-workspace repository. Applications are not affected, kdelibs and kderuntime will continue on as they currently are (with kdelibs in a feature freeze of its own already). I fully expect there to be a 4.12 and likely a 4.13 release of the applications, and how long that goes on will be up to the application developers and release team.

With that out of the way, some details!

Long Term Release

One of the most exciting things about this direction is that our distribution and packaging partners will be able to have a version that will see releases which focus exclusively on stabilization for at least two years. There will be no new features added after 4.11.0 to Plasma Desktop and Netbook, though the code will be adjusted as needed to maintain and improve existing functionality. This should make Plasma Desktop 4.11 an excellent candidate for inclusion in distributions that have a longer shelf-life.

This is a great opportunity to get changes in that polish things up as they will be available for a long while. Often between releases whole components are revamped and sometimes this results in some polish being lost temporarily. With a long lifespan, these improvements will be allowed to naturally accumulate to the benefit of those using it.

We expect that these ongoing releases to overlap with, and indeed continue after, the initial release of Plasma Workspaces 2.

This was one of the secrets behind the success of KDE 3.5 (back when we called the whole thing "KDE" .. more on that later, though): it had releases for a very long time that focused nearly exclusively on stabilization and polishing. We were working towards the 4.0 release at the time, but it showed that having such a release supported for a longer time can be quite a good thing. We actually did two releases for 3.5.x after 4.0; we even announced our intention to do this when we released 4.0. Unfortunately, the world basically ignored that and one reason might have been because it got buried beneath the excitement around the new major release.

Hopefully by announcing it early and getting the long term release version out well in advance of Plasma Workspaces 2 it will work better and distributions will be able to build plans around it effectively.

Decoupling the Software Compilation (Somewhat)

As KDE's software projects have grown in scope and number, one thing that became increasingly clear is that a single development and release cycle no longer fits all of the projects equally well. Large mature libraries benefit from longer and more conservative cycles while smaller and newer components benefit from rapid iteration. Releasing twice a year may be enough for a desktop shell, but for many applications six months is a larger window than is comfortable. When we add in dependencies between the libraries and the applications, having to time everything just right to take advantage of additions to the libraries becomes increasingly difficult.

This was one of the concerns we took into consideration when repositioning the KDE brand a few years back. We reappropriated the term "KDE" for the community of participants and gave names to each set of software. With KDE Frameworks 5 (the next major release of KDE's core libraries) and Plasma Workspaces 2 both being developed in tandem, we are now free to set each on a release and development schedule that works for them. We won't have to compromise in either direction just to find a single release date that works for both. This also means that application developers won't be hung up waiting for Plasma Workspaces 2, either. They'll have a great 4.11.x workspace to use and develop in and will be able to move to Frameworks 5 independent of where Plasma Workspaces 2 is in its development and release cycle.

I fully expect that we will continue to have coordinated release days for KDE software, and I actually hope that more software will release on those days as we move beyond the strict nature of the "software compilation". However, development cycles will not be the same and some projects will release more often than those couple of times per year. There is a lot of discussion and planning to be done before this is fully implemented and working. This is simply a first small step from the Plasma team towards this.

It's taken a few years to get to this point due to having to wait for the right moments to engage certain aspects of these plans, but it feels very good to approaching the place we envisioned.

Shortening the Wait for Plasma Workspaces 2

Due to all of the above, we will be able to focus our feature development efforts squarely on Plasma Workspaces 2. We will also be able to do releases when it is ready, independent of Frameworks 5. It is not outside the realm of possibility, for instance, to see an initial Plasma Workspaces 2 release on top of a technical preview of Frameworks 5.

By focusing our attention and creating sensible schedules for each component, we will be able to get to Plasma Workspaces 2 as quickly as possible (though no quicker). It also is allowing us to broaden the scope of Plasma Workspaces to bring in a number of "orphaned" modules, such as networkmanager or bluedevil. These components are currently developed in their own repositories and outside the KDE software compilation development cycles. This makes lots of sense for these projects as they can iterate faster and release when necessary more easily. Unfortunately, it makes coordination and integration harder.

With Plasma Workspaces 2 approaching and following it's own rhythm we will be looking to pull more of these projects together. The networking plasmoid, for instance, should not be an add-on developed outside the main workspace efforts, but a properly integrated feature with the ability to participate in the direction setting. So instead of producing a core shell and then waiting for all the pieces to eventually catch up, as we have done in the past, we're working to ensure a complete experience sooner.

How We Arrived At This Decision

We first discussed these ideas among developers who work on Plasma Desktop. We broadened the discussion to the general Plasma developer community, and finally looked for the consensus within those discussions while at the recent Tokamak 6 meeting. We communicated this back to the wider KDE community, first by approaching the release team and ensuring the idea was feasible from their point of view. We then posted an announcement to the kde-core-devel and packagers mailing list with further details. Those discussions have run their course, and so now I'm taking some time to share it with you. :)

The plan has been formulated by consensus (which is not the same an unanimity) and it took quite a while to arrive at as a result. However, it got a lot of great feedback and realistic concerns which has improved the resulting plan in many ways. It's still plastic, however, and we can and will adapt it as necessary as we move forward with its implementation.

Visual harmony in Plasma Workspaces 2

One of the big things we've accomplished on the road to Plasma Workspaces 2 is making all the desktop "chrome" use Qt Quick (nee QML). The log out dialog, the lock screen, the splash screen, the log in screen, the activity manager and widgets explorer .. everything.

(Well, with the exception of KRunner, which I actually have rendering with QML in a branch in kde-workspace, though it is not quite complete yet. You can do searches, results come back, etc. but a few things like configuration are missing.)

We recently defined a new package type, the Look and Feel package, that will hold all of the QML used to render these various components. The idea is simple: by having everything in one package, you will only need to select your preferred look in one place and the entire desktop will conform. This is a natural extension of the ideas behind the SVG theming, bringing consistency to the user interface itself.

I'm very excited about this as it will allow us to put some of the professional, elegant touches that are currently missing. I've probably mentioned it in my blog before, but the fact that the log out dialog is a dialog at all (with a moon!) bugs me every time I see it. Understanding why it is a dialog (with a moon!) helps explain how we got to this point in general.

Each of these user interface components were originally designed way back in either the KDE1 or KDE2 eras. Windows and widgets fit the design sensibilities of the time, so when you go to log out you just got a little window that sat in the middle of your screen asking for confirmation. There were no desktop effects (so no nice fading of the screen) and certainly no ability to do anything very pretty other than traditional widgets like push buttons as seen in every other application; but we could do images. So someone put a picture on the left side of the dialog. Pretty! Shiny! .. and it was. For the time.

Since then we've iteratively improved everything around and under these components, but these bits of the UI themselves were translated faithfully from one version to the next. So even though there is no reason to do it this way now, the log out dialog still has things that look like little push buttons and it still has inexplicable picture on the left, despite now being written in QML and having all the power that implies.

Plasma Workspaces 2 is our opportunity to improve these parts by harmonizing and modernizing them. The log out interface ought to look like it belongs with the lock screen; the log in screen ought to mesh with the splash screen; the activity manager should echo these components visually; etc..

We have a couple people who can do this kind of work, but they have lots on their plate already. This is a great opportunity for someone with a flair for design to get involved and help draw all these pieces together to help create an improved KDE Plasma Desktop.

If you are that person, or know someone who could be, get in touch with us and let's talk. (aseigo at kde.org works for email.)

The Luminosity of Free Software, Episode 12

Here it comes: episode #12 of The Luminosity of Free Software. Tomorrow we will do the usual three-topics-and-questions dance on a Google+ hangout. The topics will include:

• Emergence of the Linux Design Philosophy: The UNIX philosophy of "do one thing, do it well" and "everything is a file" are both being increasingly marginalized by new design concepts in Linux which put more emphasis on consistency, completeness and service architecture. As the effort and attention that UNIX enjoyed in past decades has shifted significantly onto Linux, this is an important development and I'll look at some examples of the new philosophy in action and share my thoughts on the upsides (and potential pitfalls).
• haproxy: I had the pleasure of finally getting to know this interesting bit of software and was impressed by its power and flexibility. It bills itself as the "reliable, high-performance TCP/HTTP load balancer" but what I was really impressed with was the number of things you can do with it.
• VTK: The visualization toolkit, by the same folk who bring us CMake, is an amazing visualization library and recently hooked a $2.4 million research grant. What makes VTK special, and is public funding a viable model for technology creation?
• Q&A: If you have a burning question to ask, do so in the comments here or on G+ and I'll do my best to get to it in the show. Or you can ask live on irc ...

You can join live tomorrow on G+ or Youtube at 18:00 UTC, with live chat on irc.freenode.net in #luminosity, or catch the show later on my Youtube channel. See you there!

Recently Muktware started covering KDE related news in a section they call KDE Sutra. The writers and editors are people who believe strongly in Free software and it shows through in their efforts in my opinion. In any case, they recently invited me to write a little bit about KDE. I ended writing a bit more than a little, and you can read the article here: "A Community Made of Momentum".

While writing it, I rolled around a lot of old and familiar thoughts in my head. Free software is focused on technology; however, there is a strong social and ethical aspect to it, whether one cares to pay attention to that or not. This is because there are people at the center of it all creating that technology. Whenever groups of people get together to make things, there are social and ethical profiles that emerge from these activities. Often the social aspects don't receive much attention: they just are.

Free software is a special (though not remotely unique) construction in that there are people who care deeply about those social constructs and the ethical implications and who spend time thinking about them, documenting them and shaping them. The GPL was perhaps the first step in this, but it has certainly not been the last.

Many Free software projects don't spend much, if any, time considering the shape of their community constructs. They rely on the emergent properties of humans coming together to do the right thing. This often works, and it also often doesn't. Many of the worst dramas in Free software in past years could have been ameliorated, and possibly avoided outright, had it been left a little less to chance and self-emergence and purposeful thought applied to this side of things.

I'm not suggesting that the hackers should put away their IDEs, the artists their digital paintbrushes, the documentation and translation teams their editors. There ought to be a few people in each Free software community that is bigger than small who spend some time ensuring that the non-technical structures of their community are kept in working order and progressing forward.

A goal of such efforts is to bring it full circle and have these efforts expressed by improvements in the technology that is created and in the reach into the world around us that it has.

The balancing practice in such efforts is to ensure that these efforts do not retard the pace of technological advancement or otherwise hijack the technical efforts.

No system of people is perfect, but they can progress and they can be healthy and sustainable. They can be rewarding and enjoyable and productive. KDE is one such system, and the technology we've created over the last decade-and-a-half are the record of that.

This is what I was trying to capture in the article written for Muktware, and hopefully it comes through when you read it.

Cheers, hugs and happy hacking ...

Luminosity of Free Software, Episode 11

After a week away at an intense dev sprint in Germany, I'm back in the home office and that means another Luminosity of Free Software episode!  This week on the menu are:

• Riak: a distributed data store that strives for eventual consistency rather than ACID. Inspired by the CAP theorem, this key value store is aimed at big data but is really fascinating for anyone with even a passing interesting in computer science.
• Little boxes: We all know how fun the Raspberry PI is and the utility one can get out of an Arduino. What would be possible with higher-spec devices with more useful base configurations that were still affordable and completely driven by Free software? That's the question I found myself asking the other day.
• KLyDE: This is an attempt to package KDE's Plasma Desktop in a more conservative way with a goal of trading out features for resources. We'll look at what they are actually dong, how it works with the Plasma Workspaces as they are now and what sort of impact this kind of effort could bring in future releases.
• Q&A: Where we explore the meaning of the universe, or at least the questions you lob at me. Leave questions ahead of time in the comments below or during the show in the irc channel.

I look forward to your questions, comments and feedback. You can leave questions for the show in the comments below or drop them live during the show in #luminosity on irc.freenode.net.

Due to daylight savings changes here in Europe, the time in UTC is being pushed back by an hour. We'll go live at 19:00 UTC this Thursday, the 25th of April. See you then!

Tokamak 6: A Plasma Workspaces 2 Milestone

Members from the Plasma team assemble a couple times each year to get some face time with each other. This is good both for team building and for making large strides forward in the technology we maintain and work on. When we get together on our own, rather than as part of a bigger event, we call the events "Tokamaks". We held the sixth such meeting last week in Nürnberg, Germany where we were hosted by SUSE with additional support coming from KDE e.V.

Tokamak 6 Kaban starting line

We always set a theme for these meetings so we go in with a goal. We usually spend the first day catching up with the state of the project and each other as well as defining in detail the topics we will cover in the coming days. After the first day's presentations by attendees, we ended up with a wall full of sticky notes arranged in tracks and ready to be marched down towards the finish line.

We organized things into four tracks: the shell, kwin and Wayland, session services and startup and a catch-all miscelaneous track. Unlike some of the past Tokamaks, particularly some of the earlier ones, where we had a very clear and obvious design with implementation gaps that needed filling with code, at this Tokamak the sticky notes on the wall were dominated by design topics.

This really reflects where we are in the development lifecycle of Plasma Workspaces. Currently we have a stable desktop environment with some minor annoyances left to be addressed; bug fixes and user interface cleanups are the norm for development these days when it comes to the desktop shell. This is great for our downstream partners and users as they have a reliable environment to build upon and use.

Simultaneously, over the last year we have also been working on a few very important developments: realizing our device spectrum vision and moving to Qt5 with KDE Frameworks 5.

Single Shell Theory

Many readers of this blog are familiar with Plasma Active which is a Plasma Workspace template for mobile devices; our reference device there has been tablets, but it certainly is not limited to that in any way. This effort which started in 2011, with the first release coming in October of that year, was the next logical step in the plan to build a user interface that spans devices from phones to tablets to media centers to desktops to things we aren't even looking at right now but you might be.

In the process of creating Plasma Active (and three subsequent major updates to it) we learned a lot about the power of the Plasma framework and QML. We also learned how it could be better. Sometimes it was simply confirming what we knew needed more work and sometimes it was revelatory. It all came to a head at Tokamak 6 where we took the opportunity to put firm blueprints down on our sketches.

Perhaps the most critical development is the creation of the unified shell. Right now all of the Plasma Workspace share most of their code, but they each carry a separate binary that essentially launches the desktop layer. Bringing together the efforts from desktop, netbook, active and elsewhere, we have developed a single binary that can load any of these shells and which will be able to switch between them at runtime.

The power of this idea was aptly summed up by Marco Martin who wrote, "One interface does not fit any device, but one technology does, especially when it can give you an user interface always optimized for the device you are using in a particular moment." This is an ultimate form of doing more with less and the culmination of some 6 years of effort.

This causes an interesting series of knock-on requirements. First, we need a package that can describe what a given workspace means. What makes up a desktop, what makes a tablet, what makes a netbook? We now have a package definition that includes all custom QML for the shell, the initial setup (done with Javascript, just like it currently is), default settings, processes to ensure are started (and later stopped), window manager tweaks, etc. We are still researching some aspects of this, but a working definition was put down.

This also implies that KWin needs to be able to adjust at runtime. Much of the underpinnings are already there, so this will ultimately be a short hop for KWin. A new KDE daemon plugin (kded module) has been written that tracks what the current shell is along with its runtime attributes (e.g. does it have a mouse, or does it rely purely on touch?) to coordinate this between the different processes.

With a single shell, this also means that all the "helper" interfaces need to follow suit. Things like the lock screen, the logout interface, user switching, the login manager, etc. We've worked hard over the last few releases to make sure that all of these things can now be done in QML. In Plasma Workspaces 2 we will be introducing a new Look and Feel package that can contain QML for all of these components. This means that you can switch, customize and share themes using a single package in a single location on disk. (That's a bit of a simplification as there is a transparent fall-back mechanism, but this is already getting long enough. :)

Qt5, Frameworks 5 and Wayland

Complimenting the single shell approach is the move to Qt5 and KDE Frameworks 5. These are the new releases of the libraries we currently use from the Qt Project and KDE. Thankfully, most of the API has not changed much or at all in these version bumps. Unfortunately, Plasma Workspaces uses two things that have changed a lot: interaction with the windowing system and the QML engine internals. So we've had to pick up our socks and do a lot of work on the internals of the libraries and some of the core apps. 

We've actually been able to do quite a lot of this in the Qt4 based versions, so many of you have already seen some of the benefits of this work probably without even being aware of it. After the 4.11 release this summer, however, we plan to shift our focus to pushing out the Qt5 based release.

When will that release happen? We have not discussed it with the KDE release team, nor do we have a firm fix on some aspects of Frameworks 5 so it's too early to commit just yet. We did something equally important, however: we defined what would make this release qualify as being "done" for release.

The principles we agreed to are simple:

• Do not break current workflows; what works now, must work as well or better in the new release
• Stability; it needs to be usable for daily use
• Harmonize all the interface pieces that are now on a common technology footing (QML) but do not reflect that due to disharmony in the visual and interface design

You may notice that this is completely different from our goals for the 4.0 release. This release is about rebasing a working technology on a new version of the libraries rather than making a large leap forward in technology design. We are also able to decouple the workspace development pace from library and application development as we no longer release under a monolithic and confusing "KDE" title. This means there is no pressure to release the desktop before it is ready for fear of holding up the libraries and therefore the applications.

Also part of this move is completing on another multi-year goal we've been working on: being able to support Wayland for the graphics stack and windowing system. We are relying on features in Qt5 for this and KWin has also needed much work to make the transition cleanly, but now it is all coming together. While some seem to be viewing the move away from X11 and x.org as a sprint, we have viewed it as a marathon: a long distance run that you have to plan careful and resolve to finish in the best time you can.

Miscellaneous?

There will also be a number of other small improvements here and there under the hood. For instance, I presented a proof-of-concept rewrite of RunnerManager which is used by KRunner, Plasma Netbook, Kickoff, Home Run and others. The goal is to simplify its threading and thread the things which aren't currently threaded for a zero-interface-thread-blocking design that is also a bit more flexible and which should also be kinder on memory.

Improvements in network management, power management and session startup are also on the table and being worked on.

I highly recommend reading some of the blogs by others who attended this or the parallel Solid sprint to get a further feel for things. That would include Marco's, Martin's, Sebastian's and Lukas' entries.

The Luminosity of Free Software, episode 10

Last week went without a LofS show, sadly, due to me laying about in bed being ill after what had been a very enjoyable and blissfully peaceful Easter weekend get away. That'll teach me for having fun, right? ;) Well, I'm back and that means another episode this week. Due to my schedule this week, it will once again be on Friday but I will be returning to the "full length" format. So what will we be exploring this week?

• Plasma Workspaces 2: Next week there is an extremely important meeting taking place in Nürnberg, Germany to devise answers to some of the remaining open questions, draft a roadmap to the first Plasma Workspaces 2 release and hack until dawn. With this event coming up, I'll take some time to explain the main changes that are coming with Plasma Workspaces 2 and how it will make your usage experience a bit better.
• What is QML? After an interesting set of discussions recently with people about just what is QML, I thought a segment on this topic from someone who has actually been there from pretty much the start, who has actually read through things like the parser code and worked extensively with it (namely: me ;) could be interesting. In a nutshell: we'll look at how QML gets process from text files into pixels on your screen.
• Vivaldi's open hardware: I'll share some photos of the silicon we've developed for the upcoming Vivaldi that is just now coming out of the factories along with some descriptions of the technologies we've decided to use, including how we've created what will probably be the first upgradable tablet to hit the market.
• Q&A: The usual game of "throw a question at Aaron", this time sparkles and rainbows! Well, maybe sparkles and rainbows. Definitely answers, though.

So, yes, this episode is a little more self-indulgent than past episodes in that I'll be talking about things that I'm involved with in some fashion or another .. but perhaps that's a fun way to celebrate hitting episode #10.

I look forward to your questions, comments and feedback. You can leave questions for the show in the comments below or drop them live during the show in #luminosity on irc.freenode.net.

We'll go live at 20:00 UTC this Friday, the 12th of April. See you then!

Luminosity of Free Software, Episode 9

Today I will be recording the 9th episode of "Luminosity" and it will be a short episode, in part because of time constraints I'm facing today but also because I'd like to experiment with the setup of the show to see if it can fit into a 30 minute form and how the viewing audience finds that.

So .. there will be only one topic this week plus the usual Q&A session:

• Mer: A (not so) new (mobile Linux) hope. The project and the community, a history and an update. We will look at what the Mer project provides and who uses it, visit the community structure and introduce the brand new build service that rolled out to replace the MeeGo build service that is being closed down.
• Q&A: Ask me anything, and I might answer it .. history shows the likelihood of that is actually pretty high.

See you there on Google+ Hangouts at 20:00 UTC. Chat and questions can be found on irc.freenode.net in #luminosity.