My first day as maemo.org distmaster

Starting from today, I will be officially starting my work as maemo.org distmaster. Nokia has gracefully sponsored this position for the community at the request of the maemo.org community council.

The current maemo.org team cover areas such as bug management, system administration&collaboration spaces, documentation, forums and maintaining software repositories. All these positions facilitate development and collaboration in the community - one based around the Maemo platform and the Nokia devices. But one particular area is missing: the facilitation of tablet/device operating system development.

While maemo.org currently targets developers building on top of the OS, many people within the community is interested in improving the OS, since it is what they have to deal with daily - as Maemo users. In my time within maemo.org I've found there's been a reliance on Nokia to provide fixes for problems - instead of looking within the community for people who were capable enough to fix the problem, deliver the solution and publish it in a manner that non-developers can utilize the fix.

One of the maemo.org 2010 Agenda goals is to provide Maemo variants - which would be the pipeline for delivering community fixes.

Maintaining a Maemo variant is not a easy job - you have to deal with a lot of different stakeholders in a diplomatic manner, mentor and engage new developers, often do a lot of the heavy lifting yourself, faciliate the developing and invent new collaboration spaces for this.

Facilitating and engaging the community in this manner is a day job - which is why we have the maemo.org team.

I will have 20 hours per week (part-time until January of my own choice) where I will be doing mostly community work and some internal Nokia work as needed.

The primary role as a distmaster is defined as facilitating the development of Maemo variants (Mer, Diablo/Fremantle Community Variants, etc):

* Developing collaboration spaces for developers of Maemo variants
* Mentoring and engaging developers in order to move the Maemo platform and variants ahead
* Communicating with stakeholders (Nokia, distributions implementing the Maemo platform, users and developers)

Secondary role is serving as a paid system developer for the maemo.org community:

* Developing fixes and features for the Maemo OS & variants either on his/her own based on the input of maemo.org community council
* or through activating, mentoring for and collaborating with community developer(s) in order to get it completed in collaboration with upstream developers.

As I am also maintaining the ports and base system area for Mer, I will focus myself on the hardware support for Nokia devices and let other team members deal with other device communities/vendors to avoid any potential conflict of interest situations.

As primary facilitator for the Mer project I've successfully helped activate many developers within the community in order to get Mer to where it is today. A lot of these developers came to the Maemo project at the hope of being able to develop the OS but ended up contributing few pieces to move ahead - but there was noone to group all these things and incorporate them in the system, so the brilliant pieces ended up gathering dust - until now. Now there's a official community position to make this work happen.

Looking forward to working even more closely with this community.

Maemo Summit talks of interest to Mer team members

So, Maemo Summit 2009 is coming up - and many people who are contributing to Mer are going to this event.

From my perspective, there are some interesting talks that apply to Mer contributors and I can recommend seeing:

Friday:

10:15 Maemo 5 and the Nokia N900 by Ari Jaaksi, VP - Maemo Devices @ Nokia

12:15 Harmattan Highlights - Developer Opportunities by Janne Heikkinen, Director - Maemo Product Planning @ Nokia

14:15 Why the Maemo Community matters to Nokia - Alan "qole" Bruce of Maemo Community Council interviewing Ari Jaaksi, VP - Maemo Devices @ Nokia

15:00 N800 room: Cross-platform with Qt - live - Ariya Hidayat, Software Engineer, Nokia
15:00 N900 room: UX panel (Tim Samoff et al)
15:00 N810 room: UI design of Maemo 5 apps - Annu-Maaria Nivala, UX team, Digia

15:30 N810 room: Developing widgets on Maemo 5 - showcase Foreca Weather,Juha Järvi, Software Designer, Foreca
15:30 N800 room: Mer - how the community innovates - Carsten Munk, Lead Developer, Mer project

16:00 N810 room: Developing apps with Qt for Maemo5 - Kate Alhola, Forum Nokia, Chief Guru on Maemo
16:00 N800 room: Your foundation for open-source innovation: TI’s OMAP processor-based Zoom platform. - Ameet Suri, Texas Instruments

16:30 N810 room: Developing apps with Qt on Harmattan - Ville Lavonius, Product Manager Developer Offering, Nokia and Jussi Mäkinen, Maemo Marketing, Nokia

17:00 N800 room: Harmattan Architecture Overview - Juha Tukkinen, Principal Engineer, Architecture and Sys, Nokia

20:00 Maemo Party in FlexBar coordinated by Jussi Mäkinen. It's a public bar and the doors are open to anybody. Our program will go until 23h or so, but the bar is open until really late with good music. Don't forget the Saturday schedule, though. :)

- where I'll have Mer stickers for your devices along for registered Mer contributors :)

Saturday:

11:00 N900 room: Designing UI for Maemo 5 - Mox Soini
11:00 N810 room: PyQt application development on Maemo - Attila Csipa

12:00 N810 room: Introducing the Harmattan UI framework - Tomas Junnonen
12:00 770 room: BOF, Extras/autobuilder/interfaces round-table (for those interested)

14:30 Lightning talks:

Development Nirvana: How Maemo Application Development Should Be - Andrew Flegg

DVCS? git? - How does that work then? - David Greaves (you'll want to know this skill)

15:45 N810 room: Adapting GNOME applications to Maemo Fremantle - Joaquim Rocha
15:45 N800 room: Contributing with Git & Gitorious - Johan Sørensen (we use Gitorious extensively in Mer)

16:15 N900 room: Mer - a year after - Carsten Munk (a talk on what has gone on in the last year regarding Mer)
16:15 770 room: Git hands-on workshop - David Greaves (useful skill)

16:45 N900 room: maemo.org Bug Management - Andre Klapper

17:30 N800 room: The Qt Mobility Project - Alex Luddy

18:00 N810 room: Maemo and oFono - Aki Niemi, Rémi Denis-Courmont
18:00 N900 room: The Maemo 5 Address Book - Mathias Hasselmann, Travis Reiter
18:00 N810 room: Publishing your software through maemo.org
Niels Breet
18:00 770 room: BoF: The future of GTK+/Hildon in Maemo Harmattan, Alberto Garcia, Claudio Saavedra

Sunday:

11:00 N800 room: Building for Mer - David Greaves

11:30 N800 room: Designing QT application for Maemo 5 and Maemo 6 - Sergiy Dubovik, Ian Monroe

12:00 N800 room: Maemo Platform Security: Principles and Concepts - Elena Reshetova
12:00 770 room: Extending the Hildon desktop - Marc Ordinas i Llopis (we are switching to Fremantle hildon-desktop in 0.17)

12.30: N900 room: Towards painless and quality translations - Dimitris Glezos
12.30: N810 room: Telepathy on Maemo - Marco Barisione
12.30: 770 room: What to do about /opt in Fremantle - Marius Vollmer

14.30 lightning talks:

How to speed up your Maemo application development - Raul Herbster
N900 HW architecture overview & power management - Igor Stoppa
From corporations to communities: responsible and effective engagement - Randall "Texrat" Arnold
Mer from a user's perspective - Tomasz Dominikowski

DebConf thoughts, part two: On cross-compilation environments

This post is part two of my DebConf thoughts series, first post here. At DebConf we also attended three talks directly related to something we use quite often in Maemo and Mer: cross-compilation. The first was by Riku Voipio/suihkulokki about Scratchbox 2 (mirrored by me as I can't find the original URL) - which was also a maemo.org talk like ours, as well as the round-table session on Multiarch and a talk by Wookey on Crossbuilding on Debian for a derived distro.

Scratchbox 2 is the successor of Scratchbox 1 - which most of you know from Maemo SDK. It is different from SB1 in many ways. It operates with the concept of a host tools distribution - tools which are used to accelerate certain parts of a compilation process. Comparing to SB1, with their devkits and such, this approach is much more flexible in terms of maintaining the tools distribution and keeping it up to date with current packages to match your target. This was previously difficult to maintain in SB1 and has been the source of much headache for developers on Maemo to having to deal with old and broken tools which no longer was able to build 'modern' packages.

Multiarch is the term being used to refer to the capability of a system to run applications of multiple different binary targets on the same system. This means that the different architecture files (libraries, binaries, development headers etc) are hosted in the same file system. The proposal also includes ability to have cross-architecture dependancies of packages. This would mean it would be easier in the same system (such as Debian) to build packages for different architectures within one system. It would however often also mean that you would need same package versions in all architectures as the one you're targetting.

This problem leads me to what I intend to discuss: The builder approach of cross-compilation vs a user environment approach for cross-compilation.

A cross-compilation environment has to user-level emulate as much as to make the cross-compilation of the Debian package succeed.

A user environment will have to provide a full environment with interactive shell, editors, etc - and emulate 'being' the target architecture system. This imposes a greater strain on emulation and is more difficult to achieve.

What most Maemo developers encounter, is the Scratchbox SDK. It is a development environment for all your needs and supports different targets both native and foreign architectures. It provides an emulated Maemo environment for developers to test in and should be enough to develop for the Maemo platform.

Marius Vollmer once wrote a post on "The cardinal sin of Scratchbox". It mentions the overreaching redirection that SB2 inherited from SB1 - that almost everything from doctools to python is redirected in the Python environment. This sin extends to the emulated Maemo environment - and that's what harms developers. The emulated Maemo environment is skewed by the redirection of the cross-compilation environment, to the point that Scratchbox Maemo has little to do with how Maemo on device works.

In Mer we began back in the Maemo Reconstructed proposal to ponder how SDK could be different. What we ended up on is that the entire Mer system should be able to run on a given host for development. We currently do this through chroots and virtual machines. This means, when you develop and test your applications - you develop them natively, first for your host architecture and then test it on your host.

The host is a 'real' Mer environment like on every other device and should behave the same no matter device or architecture. Once you're done developing, you can either send the source package to a builder farm (in our case, OpenSUSE Build Service) - which will spit out cleanly built x86, ARM etc. packages for us to put on our devices and test or cross-compile locally with an automated cross-compilation environment. With Mer, it's even possible to build for ARM on your own ARM device - it's just a Debian/Ubuntu laying underneath the surface.

We've had great success with the builder approach of cross-compilation in Mer. Might it be worth considering making - in abstract terms X86 chroot tar.gz's/VMDKs of full Maemo (themes, icons, etc) for developers to use to match the experience without inference by the cross-compilation environment?

One for development - dpkg-buildpackage is possible (coreutils instead of busybox) and one that matches a typical Maemo device. And then when you want to build for a different architecture, abstract it away in a one-liner that takes a source package as input.

DebConf thoughts

Recently, zenvoid and I recently participated in DebConf9 and presented an one hour BoF session on Mer - made possible by sponsorship by Nokia for our travel and accommodation.

Arriving in Caceres, Spain - after an exhausting and 20 hour journey from Denmark (train, flight, metro, and then train again) and meeting up with my local travel companion zenvoid - we found our hotel, which had free WiFi - with working power saving management, a must for tablet users. :)

At our first day there was a talk on 'HP and Debian' where some abstractions were presented that apply very well to the Mer project. Quote from presentation:

A key attribute of Linux and many Free Software applications is that they are developed and supported “by the community”
What does that mean?

• No one company in charge
• A range of contributors with varied interests, abilities, and motivations

Innovation often comes from surprising places, thanks to “the long tail of contribution”

The Mer project likewise consists of a lot of different contributors from different device communities. Some are testers, some are developers, some are artists and some are users. Mer is effectively the result of a long tail of contributions from these people. Our innovation is the mix of this long tail of contribution - and the responsibility of the project is to direct future contributions in the right direction that will encourage new contributors to join in, maintain current contributors, mentor new developers and to encourage users to actually use our software.

Another part of this presentation is the angle of HP - what it wants and a comparison to what Debian developers want. Many comparisons between maemo.org and Nokia/Maemo Devices can be drawn in this part. HP needs revenue, growth, differentiation and corporate reputation. Differentiation is a word often heard in a negative context when speaking of closed source parts of Maemo. The reason why differentation is needed - is the fact that those 20% closed source parts together with the hardware is what generates the revenue, growth that makes it possible to have the 80% open source (and free) software such as Hildon and other Maemo APIs exist. And have active developers developing on them.

This is the reason why we, in Mer, realize that differentiation is needed to compete in the mobile device market. However, like Android, we provide a full base system - and understand that device developers needs to differentiate on top with extra bits. What we're trying to do in our vendor social contract is to have both a open system and yet allow the users of their devices to remix and alter their devices, even though closed source bits (codecs, firmware, special applications for vendor, added value) exist and are needed for full functionality. It would make the user able to use their devices even to the fullest even after the vendor has long given up on the device in question.

In the second day, we had our presentation - in the BoF room, no projector and a deadly hot room with noisy aircondition- but 20 people approx showed up to hear the talk. The TuxBrain/Freerunner buzzfix people were friendly and recorded the session on video (TBA). What we did was to put Mer on Freerunner, N810, N800, 770, SmartQ5 and simply line them up - and after the talk invite people to come and play with the devices and Mer.

I'm often very critical of my own talks - but all in all it went well, even though I did forget the one key element to any presentation: telling people where they can find out more about your project :). People seemed to poke curiously at our touchscreen devices and ask questions about them. One thing to notice about DebConf was the large amount of Nokia tablets and Neo Freerunner's represented.

After our session the OpenMoko buzzfix party went on, where we showed Mer on Freerunner to different people - and saw how people used their Freerunners. Something that really caught my eye was Qalee , which is a Qt-based environment for the Freerunner. Seems like the guy making it sure has a talent for both code and UI design. See screenshots here

In between the talks, we spent most of our time in the hacklabs, - where we met people like suihkulokki (Riku Voipio) and p2 (Peter de Schrijver) from Maemo Devices - and we even saw a N810 debug board with JTAG and serial ports.

In order to get to talk to people, we put out all our gadgets running Mer on the table, and began hacking - hoping it'd attract. And it did. - we met and talked to a lot of people and we hope that they think of Mer next time they'd like to have an environment for their tablet-like devices - or if they talk to someone who would.

Debhelper in Maemo is fairly old - we saw a talk 'not your grandpa's debhelper' - where it's shown how simple a debian/rules file can look these days with a modern debhelper. What really impressed me was this example:

#!/usr/bin/make -f
%:
dh $@

Which would autodetect if the package used autotools, setuputils, etc, and then build the package according to this. It obviously supported overriding things as well, and in a fairly simple manner.

This is the first out of a small bunch of posts about experiences from DebConf (this is the first), and thoughts on communities creating technology.