Plasma Active 3 Sprint Ongoing

These days, the Plasma Active team (and a few people new to it) is meeting in Darmstadt, kindly hosted by basysKom to work on Plasma Active. Our topics range from closer integration of social networks and instant messaging to more hardcore topics such as our developer story (Plasma SDK, OBS workflows) and getting to run the thing on more devices, especially working on the system integration for the Spark tablet, that will become available to users in May. The meeting room is still buzzing with people fixing bugs, sharing knowledge, packaging, testing and (in my case, writing a blog).

Two topics that have been pretty important have been integration of social networks into the Plasma Active user experience, our plan here is to use Akonadi for collecting and caching stream from various social network sources, for example Facebook, Twitter, Google+ and others, and using Nepomuk for connecting this data from different sources to people we know. The problem of “Metacontact” (people you actually know, interact with in contrast to addressbook entries / email or IM addresses) seems to be “mostly solved” and in the process of implementation on various sides — KDE PIM, Telepathy, so we can use that as departure point to create a more natural view on your social surroundings. Now, a cunning plan that is well aligned with other components such as PIM (via Kontact Touch) exists, and we can move to the fun part: implementing it. This part will be spearheaded by Martin Klapetek, who has spent a lot of thinking on this topic.

Another important topic is our “Developer Story”. We identified three levels of target “users” for this: App developers of “simple” apps (meaning apps that can be done in pure QML / Plasma Quick and which don’t need C++ parts (we’re extending the possibilities here all the time), more complex apps that use C++ (Kontact Touch, Calligra Active, but also other apps that are being ported to Active UI guidelines and being made touch-friendly). This group will be served by a well-defined process involving ready-made cross-compilation environments in the form of virtual machine images. A third group (and likely the smallest) is the group of system developers. This topic needs a bit of work still, so in the areas where the tools provided by the fantastic Mer project do not suffice, we rely on passing on our knowledge in the traditional way: i.e. catch us on the mailing list or IRC, and we’ll try to help.

A special guest who arrived today is Mer’s Martin Brook, who has been very active in the Active team in the past months already, and who brought Plasma Active to a whole array of devices. It’s wonderful to welcome new people to the community, and it really rocks to see how effortlessly people who never met each other in person, and who come from quite different angle sit down and do great things together.

KDAB Signs FLA en masse

At KDE, we take licensing of our software very seriously. In order to make licensing code more straight-forward for developers, and easier to evaluate for third parties, we’ve created the licensing policy which can be found on Techbase. With this tool, we provide guidelines for developers which licenses to choose for their code, so that it matches pieces of software that it is shipped alongside with. It also provides insight for those who would like to distribute KDE software to get an idea how our software is structured, license-wise.

There’s another, not too widely known tool we created a few years ago: The Fiduciary License Agreement, or in short FLA. The FLA is a tool that reduces the headache and work for us in case in the future a license used by us need a change. The FLA is a tool to make this process easier, especially in cases where it would otherwise be impossible (imagine the death of a developer, as an example).

The FLA is simply a mechanism that allows the KDE e.V., as steward of the KDE community, to relicense a piece of code in case the original developer cannot do that anymore. Within this process, the KDE e.V. is bound by strict rules. First of all, it has to act within its mission, which is (paraphrased) to do good for KDE and Free software. If you’re interested in a more complete explanation of this, I’d suggest to read Carlo Piana’s article about it.

Signing the FLA is not mandatory for contributing to KDE, but it does make it easier to deal with unforeseen problems, and thus it can save someone in the future a lot of headaches. (Hopefully, for different reasons, we’ll never run into this case, but you never know.) Even if it’s not mandatory, it’s is, as I explained still a very good idea to sign the FLA. If you care about KDE’s future, please consider doing this. You can download the FLA document on ev.kde.org, and send it to our office in Berlin (address is one the same website). You might recall that I’ve written about this topic earlier — so if those guys sign it, you should, too! :-)

Two weeks ago, we had an exciting parcel arrive in the KDE e.V. office, originating from KDAB. KDAB is a software consultancy, which employs many talented KDE hackers, who still contribute to KDE, either in their Free time, or in time alotted by KDAB. The parcel contained FLAs from many KDE contributors who work for KDAB, and KDAB has organised a batch-signing of those FLAs. Obviously, we’re very happy to see this happen, as it future-proofs KDE’s licensing significantly.