Mer: How the community innovates
• By Carsten Valdemar Munk, Mer lead developer




                                      1
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
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
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
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
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
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
st
1  part of the project: Sprint­based 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
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
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
We're getting closer though




                  11
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
Roadmap & Sprint­based 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
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
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
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
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

Mer: How the community innovates

  • 1.
  • 2.
    October 2008: A call to reconstruct Maemo • Tablets arenot 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 deviceand 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 competitionfor 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 forcontributors • 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: • Youcan 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 newdevelopers 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: Sprint­based devel Collect ideasinto 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: Maemo5.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 backportto 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
  • 11.
  • 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 & Sprint­based development Our variant ofsprint 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 - thecommunity 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 communitycounterpart 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 theMaemo 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 moreabout 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