Motorcycle Adventures and Free Software
Henri Bergius
Biker, free software consultant, neogeographer

See also my JavaScript blog, The Universal Runtime

There is a total of 867 posts.

Weblog: category "kde"

Open Advice

Posted on 2012-03-19 10:51:12 UTC in 52° 29.400 N 13° 25.272 E Berlin, DE to . 0 comments.

Open Advice coverI seem to have not blogged about this, but Open Advice, our book on Free and Open Source Software: what we wish we had known when we started, was published last month.

The book was edited by Lydia Pintscher and includes essays from 42 authors, many of whom you'll recognize if you tend to go to FOSS conferences. The LWN book review concludes:

Open Advice is a book that will be helpful to those who are new to FOSS, but, because of the individual voices, styles, and tones, it doesn't read like a "how to". It could even be recommended to those who aren't necessarily interested in contributing, but are curious about what this "free software thing" is all about. It is, in short, a great book for a variety of audiences and the (mostly) two or three page essays make it easy to read, while the anecdotes and recollections personalize it. The authors, editor, and everyone else who helped should be very pleased with the result. Readers will be too.

I probably shouldn't give the ending away, but my essay on cross-project collaboration, a subject I've also blogged about, ends with:

Good luck with breaking down the project boundaries! In most cases it works if your ideas are good and presented with an open mind. But even if you do not find a common ground, as long as your implementation solves the use case for you it has not been in vain. After all, delivering software, and delivering great user experience is what counts.

The book is licensed under CC-BY-SA, and is available as free download in ePub, mobi and PDF formats, and as paperback from Lulu. The book sources are available on GitHub, patches welcome!

Sponsored links

save money using, phone card

Open Mobile Linux, this Saturday in FOSDEM

Posted on 2012-02-02 08:55:37 UTC in 60° 9.792 N 24° 55.662 E Helsinki, FI to . 0 comments.

As mentioned in the earlier call for presentations, we're running a track on Open Mobile Linux in FOSDEM this Saturday. Room AW1.120 at the ULB campus in Brussels. From the CfP:

Our primary goal is to facilitate meetups, collaboration and awareness between different projects and communities within Open Mobile Linux and provide a place to present directions, ideas and your projects themselves.

By Open Mobile Linux we mean any open source projects revolving around typical non-desktop/server Linux, such as handsets, tablets, netbooks or other creative uses. Examples of such projects could be Qt5, Mer, MeeGo, Android, webOS, Plasma Active, Tizen, Boot to Gecko, SHR and other related efforts.

There are several exciting things happening in this space, including the recently announced Spark tablet, open sourcing of webOS's Enyo framework and continuing interest in the Maemo platform. Saturday's program includes:

If there are any last-minute announcements or happenings that people want to discuss, we may be a ble to squeeze in a talk or two. Contact Carsten about this.

Also, if you want to chat other things (like PHPCR or CreateJS), I'll be around the whole weekend including the beer event. Drop me an SMS.

Looking forward to seeing as many of you there as possible!

Call for presentations: Open Mobile Linux at FOSDEM 2012

Posted on 2011-12-14 09:46:57 UTC in 47° 48.570 N 13° 3.300 E Salzburg, AT to . 0 comments.

At FOSDEM 2012 we will have a devroom related to Open Mobile Linux. Our primary goal is to facilitate meetups, collaboration and awareness between different projects and communities within Open Mobile Linux and provide a place to present directions, ideas and your projects themselves.

By Open Mobile Linux we mean any open source projects revolving around typical non-desktop/server Linux, such as handsets, tablets, netbooks or other creative uses. Examples of such projects could be Qt5, Mer, MeeGo, Android, webOS, Plasma Active, Tizen, Boot to Gecko, SHR and other related efforts.

We have the room AW1.120 with 74 seats, a video projector (VGA), wireless internet on Saturday 4th February for a total of 8 hours.

The format we will be utilizing is lightning talks of length 15 minutes with 10 minutes of questions, 5 minute changeover to next speaker. Our goal is about 15 talks during the day.

The motivation is that after each talk, you and your project will be visible to the rest of the Open Mobile Linux community and further deeper discussions into your topic with your peers can continue outside the devroom.

Please send a short biography and an abstract for your talk to carsten.munk@gmail.com by Dec 31st 2011, and we'll get back to you at latest January 7th.

We're also grateful for volunteers helping to run the devroom. Contact Carsten if you're interested.

Where is the future for openness in mobile?

Posted on 2011-10-03 17:53:42 UTC in 60° 0.000 N 24° 0.000 E 28km S of Lojo, FI to . 1 comments.

These are tough times for fans of open mobile environments. Android is less and less open, Symbian was closed again, HP stopped making webOS devices, and now Intel abandoned MeeGo to work with Samsung and operators instead. So, what is the community to do?

One option is to follow the lead of the big companies, hoping that Tizen works, or that Google again sees the benefit of working with others in the open.

The other is to take the matters in our own hands. There is precedent for this. Much of early Linux activity came from the efforts of the community, not on the initiative of corporate interests. And there have been OpenMoko and Mer, the latter an attempt to make a fully open version of Nokia's Maemo environment, suspended when MeeGo promised to bring the same benefits.

Well, now Mer is back.

mer-400.jpg

The goals for Mer align pretty well with what the community would need:

  • To be openly developed and openly governed as a meritocracy
  • That primary customers of the platform are device vendors - not end-users.
  • To provide a device manufacturer oriented structure, processes and tools: make life easy for them
  • To have a device oriented architecture
  • To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5)
  • To innovate in the mobile OS space

There have also been some other invitations to new potential homes for the community, ranging from openSUSE to Debian.

It will be interesting to see how this works out. But whatever we as a community do, we should ensure we look at more than just licensing.

Some notes from Desktop Summit 2011

Posted on 2011-08-11 16:18:35 UTC in 52° 0.000 N 13° 0.000 E 15km SW of Luckenwalde, DE to . 0 comments.

As usual, Desktop Summit 2011 has been a lot of fun. I've been to most of the GUADEC and aKademy free desktop events in the past few years, but this was the first time I didn't give a talk. Even that way, it was definitely worth spending a week in Berlin.

While much of the corporate involvement around the desktops has evaporated through some recent events, this seems to have given the developers lots more creative freedom. I've seen many very promising concepts from both communities.

Here are some things that happened during the week:

  • The roadmap for Midgard to become closer to the JCR specification solidified, including a reasonably good plan on backwards compatibility
  • We published the first version of GICR, generic Content Repository interfaces for GObject. Midgard will probably be the first project to implement them, but we hope others will follow. It'd be a great fit for GNOME Documents, among other things
  • The project to replace our own PHP frameworks with Symfony2 continued by implementing the MidCOM compatibility layer that will allow Midgard1 web applications to be run in the new environment
  • My work on the NoFlo flow-based programming tool got some positive attention and interest. Still lot of stuff to do
  • We at Nemein co-sponsored the GObject Introspection hackfest. GIR is important for bringing GNOME libraries to new environments like scripting languages and the web
  • Lots of ice cream got eaten. I think it will be fair if I stay out of next year's deathmatch and focus on coaching ;-)

Tomorrow back to Helsinki for a week, then onwards to FrOSCon and Salzburg...

Desktop Summit, and some thoughts on Flow-Based Programming

Posted on 2011-08-06 15:09:59 UTC in 60° 19.098 N 24° 58.002 E 12km S of Tuusula, FI to . 0 comments.

Like many, I'm currently in Berlin for Desktop Summit, the combined conference of the GNOME and KDE communities. It is a lot of fun to see all the familiar faces, and talk about the different projects going on!

DS2011banner.png

Now, one of the things I've talked about with people is NoFlo, my new tool that brings Flow-Based Programming to Node.js. What is that? Wikipedia explains:

Flow-based programming (FBP) is a programming paradigm that defines applications as networks of "black box" processes, which exchange data across predefined connections by message passing, where the connections are specified externally to the processes. These black box processes can be reconnected endlessly to form different applications without having to be changed internally. FBP is thus naturally component-oriented.

Basically the idea here is to simplify managing the control flow of software: what data goes where, what happens then, etc. with the goal of making software more understandable. With NoFlo you can go and peek under the hood of a running piece of software, see where data is going to, and even rewire some connections if you want to.

The project is still in reasonably early stages, but it is already used in at least one real-life deployment. Here are some sneak peeks:

noflo-shell-small.png:

noflo-gui-small.png

If you're interested, follow the progress on my GitHub repo, or subscribe to the Flow-Based Programming mailing list.

In the spirit of Desktop Summit, it would be interesting to talk how these workflows would fit into the concept of a free software desktop.

Understanding MeeGo

Posted on 2011-06-05 03:58:17 UTC in 42° 0.000 N 77° 0.000 W 19km SW of Elmira, US to . 0 comments.

Disclaimer: I'm a software developer with a background in Nokia's Maemo mobile Linux ecosystem. I've built both software and community services for it. As a Maemo enthusiast, I've also been following MeeGo with interest, and am helping to build some of the project infrastructure there as well. But I do not speak with the authority of the MeeGo project, and what is written below is my personal view into what MeeGo is.

After the recent San Francisco MeeGo Conference there has been surprisingly much negative reporting about MeeGo, mostly centered at Nokia's MeeGo story. While Nokia's strategy changes are unfortunate, much of the reporting around it appears to come from misunderstanding what MeeGo is about.

Many see MeeGo just as Android without Java, but it is much more, as I'll explain here.

Industrial Linux

MeeGo is much more than just handsets or tablets. It is an attempt at creating a standardized industrial Linux distribution that can be used anywhere from in-vehicle infotainment devices to TVs to, indeed, handsets.

It is a true open and collaborative environment, managed by Linux Foundation. The governance model is there to ensure that MeeGo stays a vendor-neutral platform that anybody can build their products on top.

Many device segments have very long development, and especially usage times. For this MeeGo has a predictable release schedule of a major release every six months, and a roadmap kept by the Technical Steering Group.

If MeeGo succeeds in this, you will be using it in your TV, in your car stereo, and at the back of an airline seat. But in most of these situations you won't be able to know that it is MeeGo. It is simply there to make building products faster and cheaper for the manufacturer.

Openness

As I argued in my earlier piece Open Source? Free Software? What we need is Open Projects, being an open platform is much more than just the licensing terms of the code. There needs to be transparency into the development process, a clear procedure on how to participate and much more. And of course licensing has to be such that the participants can actually use the results in whatever they're doing.

For this, most of MeeGo is licensed under permissive terms, like the GNU LGPL and BSD-style licenses.

But indeed, the other aspects of openness are more important. With MeeGo you can see every commit happening on Gitorious, and you can see the bugs and features being worked out in a public Bugzilla.

MeeGo as a project is still quite young, and many participants are still learning how to work in the open. This has lead to some issues in project transparency. But hopefully those are now getting resolved.

User Experience

MeeGo allows anyone to build their own user experience on top of the platform. Actually, this is expected of any serious manufacturer. Sure, there are some reference UXs available, including Tablet, Handset and Netbook, but none of these are quite product-ready, and are not necessarily even intended to be.

Because of this it is quite funny to see reviews of the reference UXs. They're not the ones most devices will run, though obviously some manufacturers or community members are going to use them anyway. A full MeeGo product will look and feel like something completely different.

This is not like Android manufacturers adding their own skins. With MeeGo anybody has the full freedom to build a complete user experience that suits their device, branding and other goals. The whole platform has been built to allow this sort of differentiation, without a risk of fragmenting the ecosystem. I'll explain the fragmentation question soon.

Actually, the freedom of defining your own user interface is big enough that both Android and WebOS could theoretically be rebased on top of MeeGo to be just different MeeGo UXs. Obviously they would need to allow running MeeGo-compliant Qt applications in addition to ones written for them directly, but that is minor detail. WebOS already ships Qt, so it isn't even that far from this. Similarly, KDE or GNOME could run as MeeGo UXs.

Compliance

At the core of MeeGo there is a set of compliance rules. Being Open Source, anybody can take MeeGo, modify it, and run it on their devices. But only if their implementation passes MeeGo compliance it can be called MeeGo.

Device Compliance is a set of rules that ensures any MeeGo-compliant software can run on a particular device. Application Compliance similarly ensures an app can be installed and run on any MeeGo-compliant device.

Both of these sets of compliance rules have automated tests that anybody can run. So, between non-compliant MeeGo-related software there may be fragmentation, but anything branded MeeGo (and therefore compliant) must be fully compatible.

App Stores and business models

MeeGo is an open source project, not a company. This means it comes without strings attached, compliance rules aside. There are no limitations on the business model of a MeeGo device manufacturer, no mandatory online services or app stores to enable, and no royalty payments.

With this, each vendor can decide what they want to enable their users to do with the device. An embedded device might have no concept of installable applications, a tablet might come with the vendor's own app store.

For those who do not want to go through trouble of building their own developer ecosystems and app stores, there are some generic solutions available in the MeeGo sphere:

Intel's AppUp is a "white label" app store. This means that a device manufacturer, or even retailer or operator can get an instance of AppUp with their own branding and a revenue sharing deal with Intel. Developers submit software only once and it will be available on all the different branded AppUps.

On the more open side, there is also the upcoming MeeGo Community Apps, a fully community driven "store" of free software written for MeeGo. It comes with its own, OCS-compatible client application, a web frontend, and clear set of crowdsourced app quality assurance processes. The similarly handled Maemo Downloads has served over 80 million downloads for the Nokia N900, so the user and developer interest is clearly there.

The future of MeeGo

At this early stage of the project it is hard to make predictions, but there are many things MeeGo gets right. I think it has a bright future ahead of it, especially in more specialized devices. There the shared infrastructure and clear development schedule give manufacturers substantial advantages in both development time and cost.

Product development times in the embedded sector are quite long, and it may well take years before we'll see MeeGo in a airline multimedia system. But if the project shows the necessary durability and longevity, this will eventually happen. Now many of those systems run on customized Linux distributions that their manufacturers have to spend quite a bit of money to maintain. MeeGo removes that problem, and allows easier collaboration through the compliance rules.

As for consumer devices like tablets and handsets, that area mostly requires there to be a vendor that wants to properly differentiate itself from the grey masses of the Android ecosystem. MeeGo provides all the necessary tools on both systems side and user interface development to make that happen.

Currently there are many different ideas floating around on how to build user experiences on connected devices. There is the "wall of apps" approach of iPhone, there are the fully cloud-connected WebOS and Android approaches, and now Microsoft is also starting to enter the game with their own ideas.

I don't think the "post-PC" world is yet complete. What MeeGo gives is a fast way to build products differentiating from that crowd. It just needs companies who are willing to go for it.

The next couple of years will be quite interesting.

On cross-project collaboration

Posted on 2011-03-11 13:08:48 UTC in 60° 0.000 N 24° 0.000 E 28km S of Lojo, FI to . 1 comments.

There is currently quite stern discussion going on between GNOME, Canonical and KDE about collaboration on the free desktop. Angry words have been written, and I believe much of the tension arises from the situation with MeeGo. Suddenly many developers and projects feel much more marginalized than what the future looked like, pre-112. Hopefully cooler heads will prevail before the Desktop Summit, and we can again have beers and discuss things together.

Cross-project collaboration is hard. I know. For many years I've been pushing for location-awareness across desktops, for using shared content repositories instead of application-specific file formats or databases, and most recently for having a common client-side data representation and manipulation layer on content management systems. Some of these ideas have moved forward. Some others, less so.

What is important to remember is that each project has their own use cases, user experience goals and set of selected technologies to build on. If a collaborative approach you propose doesn't fit those, it is highly unlikely that the project will adopt it. And there is nothing wrong with that.

Instead of looking at the failures, we should think of the ways cross-desktop collaboration has moved forward. Here are some examples:

So, if you want to get a specification accepted between projects, how to go about it?

First of all, you should communicate early and clearly the use cases your specification aims for. And then there should be a reference implementation available, not only as a library, but also as something already integrated in your UX.

If you want projects to actually use your reference implementation instead of building their own, then it is important to remove as many obstacles from adopting it as possible:

  • Use permissive licensing and try to avoid copyright assignments or other requirements potential users would find onerous
  • Host the project on neutral ground. For web projects, Apache is quite a good home. For desktop projects, Freedesktop is probably the best option
  • Use technologies that don't impose too many constraints. Libraries should be quite low-level, or provide D-Bus APIs that can be used with any system
  • Avoid technology-specific dependencies. For example, KDE has found GeoClue hard to adopt because it uses GNOME-specific settings interfaces
  • Talk with the other guys. If you're from the GNOME project, go to aKademy and give a talk, and if you're a KDE developer, go and talk in GUADEC. IRC isn't bad here either
  • Finally, accept that not everybody will use your implementation. But if they at least implement the same ideas, then collaboration is still possible.

And even if your ideas haven't been adopted by other projects, as long as your implementation solves the use case for you it hasn't been in vain. After all, delivering software, and delivering great user experience is what counts.

The Universal Runtime

Posted on 2011-03-09 11:32:58 UTC in 60° 0.000 N 24° 0.000 E 28km S of Lojo, FI to . 4 comments.

In the coming years another billion people will get online. They will do it with their smartphones instead of what we consider computers. And their experience will be quite different from ours when we initially started using the internet.

Despite its promises, it looks like the post-PC ecosystem will be a lot more restrictive than the PC one was even in the worst days of the wintel duopoly. For a while it looked like software freedom might be one of the cornerstones of the new world, but since then it has been shown that the tech giants Apple and Microsoft, together with the American content industry, will ensure that this new environment is more tightly locked down than anything we've seen before.

These companies will have a say on who gets to create something, who to distribute it, and who to use it. Users will be 'protected from themselves' by enabling these devices to run only code approved by the company. We've already seen that this approval can be declined, or even retroactively withdrawn on a whim, and on grounds more political than technical.

If we want to ensure digital freedoms for ourselves, and for the people only now reaching across the digital divide, we must act. We must find ways to enable creativity to happen on these new devices. We need to find ways to enable people to create, distribute and use any software on their phones, regardless of what locked-down ecosystem their mobile operator pushed them into.

Luckily there is one programming environment, one runtime that even the most restrictive players haven't had the courage to lock down: the web. Web browsers, coupled with the modern, fast JavaScript engines, could be the tool to build the next step of the free software revolution. We must embrace it.

JavaScript is already fairly prominent in free software development. The GNOME Shell has been largely written in it, Qt Quick builds on it, and most of the common JavaScript libraries are free software. There are even ways to run JS as a server or build your own desktop applications with it.

For those looking to get started with JavaScript, here are some useful resources:

While there will never be a "one true language" to program in, JavaScript has the potential to be a big thing. And for writing and sharing software across platform boundaries, it may be the only way. It runs even on the most walled of gardens.

Better one file in the cloud than ten on the hard drive

Posted on 2011-01-10 15:17:58 UTC in 60° 0.000 N 24° 0.000 E 28km S of Lojo, FI to . 6 comments.

Yesterday, after returning from a trip to Kenya, the hard drive on my old MacBook Air decided to die. Eventually I was able to recover most of it, but many files on my home directory were simply gone. But this isn't such a big problem, as everything of importance is anyway online, conforming with the Linus backup strategy:

Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it.

So, where do I keep my stuff?

With all this, the network is truly the computer. The main hassle with a dead hard drive then is reconfiguring all of these, making checkouts of the code repositories etc. I wonder how much this could also be automated?

Privacy is the other obvious concern, making ownCloud an interesting prospect on the longer run. Update: Here is Paul Carr, who earlier moved most of his life into the cloud rethinking it because of recent US government privacy abuses:
Now, with everything in the cloud, the decision whether to hand over my personal information is almost entirely out of my hands. And unless, as happened with Twitter, the company storing my data decides to fight for openness on my behalf, there’s every possibility that I won’t even hear about the request until it’s too late. That’s just not how things should work in a free society.

Of course, it remains statistically unlikely that I’m going to be the subject of a subpoena any time soon. I’m hardly an enemy of the state. But then again, until recently, neither were many of the supporters of Wikileaks. Who’s to say that an innocuous organisation I give support to today won’t suddenly become highly controversial tomorrow?
Title for this post comes from the "modernizing traditional Finnish proverbs" Qaiku thread.