Here is a little Emacs Lisp snippet that I've started using. It makes Emacs pop up a desktop-wide notification when a compilation finishes, i.e. after "M-x compile" is done. Let's see if that keeps me from wasting time in the web when I launch a compilation.

(setq compilation-finish-functions
      (append compilation-finish-functions
          '(fmq-compilation-finish)))

(defun fmq-compilation-finish (buffer status)
  (call-process "notify-send" nil nil nil
        "-t" "0"
        "-i" "emacs"
        "Compilation finished in Emacs"
        status))

Today the OpenStack Summit started in Sydney with the keynotes. This time the keynotes are only on the first day, which is really nice since it's only a 3 days event - more time for the presentations.

• Multicloud requirements and implementations: from users, developer, service providers (Panel, Mon 6 , 2:20pm-3:00pm, step in for Kurt Garloff from T-Systems)
• Email Storage with Ceph (Lightning Talk,  Tue 7 , 9:15am-9:25am)
• Vanilla vs OpenStack Distributions - Update on Distinctions, Status, and Statistics (Presentation, Wed 8 , 9:00am-9:40am)

In the past weeks, we have noticed an increased interest in Plasma Mobile from different sides. Slowly, but surely, hardware vendors have discovered that Plasma Mobile is an entirely different software platform to build products on top of. For people or companies who want to work or invest into Plasma Mobile, it’s always useful to know where upstream is heading, so let me give an overview of what our plans are, what areas of work we’re planning to tackle in the coming months and years, where our focus will be and how it will shift. Let’s talk about Plasma Mobile’s roadmap.

Our development strategy is to build a basic system and platform around our core values first and then extend this. Having a stable base of essentials allows us to focus on an achievable subset first and then extend functionality for more and more possible target groups. It avoids pie-in-the-sky system engineering something that will never be useful and designed for a unicorn market that never existed. Get the basics right first, then take it to the next levels. These levels are:

1. Prototype (already finished)
2. Feature Phone
3. Basic Smartphone
4. Featured Smartphone

Prototype and Product Vision

The first public release of Plasma Mobile was this prototype. It showed a very basic and incomplete-for-daily-use system on actual, modern smartphone hardware. You could make phone calls, start and manage apps, and manipulate some basic system functionality. It showed a smartphone system based on Plasma could be done, and more importantly, it taught us a lot about where we want to take things on a technical level.
Along with the prototype, we developed a product vision for Plasma Mobile, a direction where we want to take it (emphasis added by yours truly):

“Plasma Mobile aims to become a complete software system for mobile devices. It is designed to give privacy-aware users back the full-control over their information and communication. Plasma Mobile takes a pragmatic approach and is inclusive to 3rd party software, allowing the user to choose which applications and services to use. It provides a seamless experience across multiple devices. Plasma Mobile implements open standards and it is developed in a transparent process that is open for the community to participate in.”

Feature Phone

The feature phone milestone is what we’re working on right now. This involves taking the prototype and fixing all the basic things to turn it into something usable. Usable doesn’t mean “usable for everyone”, but it should at least be workable for a subset of people that only rely on basic features — “simple” things.
Core features should work flawlessly once this milestone is achieved. With core features, we’re thinking along the lines of making phone calls, using the address book, manage hardware functions such as network connectivity, volume, screen, time, language, etc.. Aside from these very core things for a phone, we want to provide decent integration with a webbrowser (or provide our own), app store integration likely using store.kde.org, so you can get apps on and off the device, taking photos, recording videos and watching these media. Finally, we want to settle for an SDK which allows third party developers to build apps to run on Plasma Mobile devices.
Getting this to work is no small feat, but it allows us to receive real-world feedback and provide a stable base for third-party products. It makes Plasma Mobile a viable target for future product development.

Basic Smartphone

The basic smartphone extends the feature set of Plasma Mobile to a wider group of target users. The plan is to add personal information management features, such as reading and sending emails, calendaring and reminders. We also want to add file management capabilities in this milestone, because we think that the user should be able to deal with the data in her phone in the most transparant way, and file management is something that allows users to look into the fabric of their data, and that of the phone itself. Another big topic for the Basic Smartphone milestone is extending the app ecosystem through third-party and original applications to allow the user to do more things with the device.

Featured Smartphone

For the featured smartphone, we want to add more system-level integration features such as deeply integrated private cloud storage and have grown our own ecosystem with more apps and of course games. An often requested feature is support for Android apps. Supporting Android apps could give Plasma Mobile a huge boost in terms of possible target groups, since it allows users to switch away from Android more easily, even when they are requiring a few apps and can’t really live without these. Being able to run Android apps on a Plasma Mobile device can ease the transition considerably and it allows us to capture potential target user groups that rely on proprietary services which Plasma Mobile, at first, cannot serve simply because as a smaller player, it’s not an attractive enough platform to have the likes of WhatsApp develop native clients for.

When it’s ready!?

On purpose, we did not add a specific timeline to this roadmap for two reasons: First, Plasma Mobile is a participative project, if you want to see something done, get involved. We’re not running the show all by ourselves. We want to create an open eco system where people who do the work decide on its direction. This means if you get involved, you can help us shape the future of mobile computing instead of being just a code monkey that does what someone else has decided. Secondly, we don’t want to deliver half-assed software just because we set a timeline. We want to create quality software to build products upon. If you or your company want to ship on a specific date, work with us and we’ll plan together. We won’t make promises when something is ready beforehand, but as an upstream project, we want to ship “when it’s ready”. This “when” depends on all our input and hard work. So don’t sit in your armchairs and wait for someone else to do the heavy lifting, but let’s get cracking!

Last semester I founded the AG Open Source at our university. We are organizing workshops and hackathons in cooperation with open source projects/ companies. Our students should learn more about open source development and how to contribute. The difference to the Friedrich-Alexander-University and their professorship in open source development is that we want to learn the real practice by professionals.

After 3 months we had a reputation. The AG Open Source should be open for other faculties, too. EFI (electronic – fine mechanics – information technology) has been interested for our events. So students in Computer Science and Electronics are receiving basic courses in Linux and using git. In addition, we create a program which is different every semester. Last semester we had topics like security and the ownCloud hackathon. This semester our focus is on monitoring and docker.

I am the Lead of the AG Open Source. I am educating other students in the student council for different positions in the AG. We need an additional lead. So I have one student as a Junior Lead who is being taught in organization, email writing and publishing by me. Two other students want to become Linux Trainers. They  have to know all about the cooperation with other  AGs in the student council and their processes, too.

Last semester I was the Linux Trainer in all Linux workshops. One (advanced) student supported me with running through the lines and looking for different students. Other students in my semester are interested for this job this semester, too. Last week we received the request for a Linux course for advanced Linux users parallel to the Linux course for beginners. So I am teaching one student to pick up my course for beginners. Next semester we’ll use 2 rooms for this event. I’m planning the course for Advanced Linux Users.

Since this week we are responsible for a new task at our university: Linux

support for students

A EFI student stood in the door of our student council for Computer Science and said: „I’m not from this faculty, but I need Linux support by the AG Open Source. Nobody else can help me. I was in the data center. They want to support only Windows. I can’t find anybody at our faculty, too.“

The data center has reconfigured eduroam. That’s the Wifi for students and professors. We need additional entries for Linux systems and a new certificate now. I configured his Wifi and I know: I have to educate Linux Supporters for our AG. On our internal homepage openSUSE and Android are listed as supported operating systems (Linux) by the data center, but our Sysadmins don’t know what to do there. All students are coming to the student council for Computer Science now, because they are receiving Linux workshops by us.

Our AG Open Source is growing, but our responsibilities are growing, too!