2. October 2008: A call to reconstruct Maemo
• Tablets are not under-powered embedded systems, they are powerful, power-efficient,
economical handheld computers.
• Make Maemo a general platform for tablet devices.
• Make it more developer-friendly.
• More hackable.
• Align with standard Linux distributions.
2
3. October 2008: A call to reconstruct Maemo
• Separate device and platform code
• Open development of the Maemo platform - the device-specific and vendor-specific
differentiation development can be closed.
• It should be easy to port existing desktop applications - platform peculiarities should be kept
to the absolute minimum required for the mobile use-case.
3
4. Engaging developers
There's a competition for open-source contributors – and Maemo is in a position to
receive a lot of contributors – but we're not ready to receive them.
It is important to engage developers when they show up at your doorstep.
A developer should always be able to find out:
• how to contribute
• what they can contribute with
• where to contribute
• who to ask if they need advice
It should be easy to contribute!
4
5. Mer: Having a clear entrance for developers
Informal signup for contributors
• Gives the project information on the contributor
• Gives the contributor information about the project
• Gives access to sprint administration system
• Gives a feeling of being part of a project
5
6. Our recipe for engaging developers in Mer
Sprint system:
• You can contribute to the project by doing tasks (What)
• The creator of the task is your mentor (Who)
• Sprint system helps keeping track of delays, problems, notes, time used on task etc.
6
7. Motivating and keeping developers
• Making new developers feel welcome and feeling like an equal participant in the project.
• Making sure there is always work to be done.
• Assisting awareness through microblogging and encouraging discussion.
• Work that increases ones knowledge in the field.
• And most importantly: Having fun developing and taking pride in your effort!
7
8. st
1 part of the project: Sprintbased devel
Collect ideas into a sprint backlog.
Mentees see what needs to be done from the sprint backlog
Mentees develop on packages based on tasks under guidance of mentors
(DVCS? git? - How does that work then? , Contributing with Git & Gitorious)
Packages flow when stable from our :Devel to our :Testing repository in OpenSUSE Build Service
(Building for Mer)
One week before release :Testing is frozen and will only receive bug fixes. A sprint lasts a month
and results in a snapshot release of :Testing repository (Mer from a user's perspective)
8
9. Maintaining the long tail
December 2008: Maemo 5.0 (Fremantle) pre-alpha
“This early release comes with an invitation to build variants based on Maemo 5 compatible
with existing hardware like the N800 and N810. Maemo SW can't promise commercial quality
for such configurations but through maemo.org we are able to collaborate at a community
level with technical support, license changes and code.”
9
10. Mer isn't a Fremantle backport
.. exclusively.
A backport to support older devices would die out by lack of interest as more people move
onto to newer devices.
It was more important to activate the community and get an organization going.
This is noticeable in our UIs and choices done along the way.
Think of Mer more of a 100% OSS community distribution of Fremantle APIs and desktop.
And Mer isn't won't just be Fremantle..
10
12. Fremantle thoughts from Mer perspective
Great:
• Extensive codedrops and progressive opening of packages.
• MMDW
• Relicensing offers
Not so great:
• No early open theme templates or HIG. Open packages depending on closed packages.
• Hildon Input Method.
• No idea of when the next codedrop would arrive.
What we could have done better;
• Not stray off into our own UI design.
• Get vendor repositories working long time ago.
• Not have used Hildon Desktop 2.0.
12
13. Roadmap & Sprintbased development
Our variant of sprint based development is good for proof of concepts and rapid development –
but we need to grow up..
Planning ahead - indicating high level goals for each sprint and mentors within each area
generate tasks to be done from this.
Coordinating between stakeholders and making clear what is expected from each area.
Roadmap including what we expect from stakeholders and collaborators.
13
14. Future: Transforming maemo.org
maemo.org - the community counterpart to Maemo Devices.
A community embracing, integrating and contributing back to open source products.
Less talk – more doing! Make the community capable of fixing things themselves.
A place for multiple vendors and device communities all surrounding, collaborating, developing
for and on the Maemo SW platform.
A network of volunteer and paid contributors within all areas relevant.
14
15. Future: Transforming Mer
• The community counterpart to Maemo (the OS)
• Work together towards a open source target-agnostic reference Maemo Platform
• Base Mer (and other variants implementing the Maemo Platform) on top of this
• Make Maemo Platform the no. 1 platform for open* devices
(* open described as devices that satisfy our Vendor Social Contract)
15
16. Future: Transforming Maemo
Community developing the Maemo Platform in cooperation with Maemo Devices
• Public roadmaps of platform
• Shared collaboration spaces (Gitorious)
• Establishing clear entrances for developers wanting to contribute
• Procedures for contributions and definition roles in projects
16
17. Questions?
To learn more about the Mer project:
http://wiki.maemo.org/Mer
#mer on irc.freenode.net
Talk with Mer team members (recognise them by the Mer logo on their devices!)
17
