Sunday, November 3, 2013

A SailfishOS Co-creators Community in 2014?

co-created by Filip Kłębczyk and Carsten Munk


There is a challenge that stands before Jolla and that is how to create a well working community that would support the efforts of the company and help build the ecosystem around the Sailfish OS and Jolla's products. Until now Jolla has been very successful in creating a large community of fans, especially in Finland, so in other words the potential future customers of Jolla devices. 

Creating demand for the products is needed, but nowadays successful mobile products also require developers willing to develop native software for them and do other kind of community contributions. 

That is needed especially because Jolla is a young company and has limited resources. In order to compete with big mobile devices market players like Samsung or Apple, Jolla has to utilise community potential as much as it is possible. 

In order to make that happen, certain steps must be taken to attract people, not only previously connected with Maemo and MeeGo platforms, but also completely new ones or coming from other platforms/backgrounds. 

Building a community of co-creators in which everyone would feel needed and respected is a challenging task and this document addresses possible ways how that could be handled by Jolla.

Analysis of community programs/interaction in other companies/projects.

Maemo/MeeGo (Nokia, Nokia and Intel)

Nokia's method of building Maemo community was very effective. The act of providing a whole portal - with mailing lists to discuss and tools to host application projects was a good bet. It was amongst the first to provide this kind of infrastructure for mobile device application developers.

A large focus was placed on open source application developers and less on the participation in OS development, though that was later improved by supporting community projects such as community-supported updates to the device. Commercial software developers were handled through Forum Nokia in a seperate manner, which was tried to be unified later on.

Nokia also organized events like Maemo summits and actively participated in existing open source conferences, which were important for integrating community also outside the Internet. Additionally, developer programs with early access and providing developer devices also boosted interest in the platform.

Nokia of course didn't avoid mistakes such as making bad decisions in areas where community worked well itself. Old habits of corporate behaviour were hard to kill and so many initiatives were not properly balanced with the needs of a growing community.

One of the bad things that happened in the opinion of the community was that Maemo platform was abandoned in favour of MeeGo platform, which was dramatically different and Nokia support ended too early. On positive side is the fact that community is still supporting the Maemo platform and that content and software was moved to community server infrastructure.

MeeGo(.com) project put a lot of emphasis on working in the open, upstreaming, inclusiveness and meritocracy. Main problem was the realisation in practice of all above and changing old patterns of working with the result that MeeGo was very negatively perceived by the community since it in practice was a regression from the previous state at

The introduction of new project also came with new infrastructure, so in result there were actually two places for communication - new and old and hence it divided the community. A full migration from community to the MeeGo project never happened.

BlackBerry 10 (BlackBerry, previously RIM)

BlackBerry was very successful in attracting developers from different communities in 2012. The company organized several big events, but most importantly a lot of small 1-day events around the world. They've hired a lot of evangelists, often connected with former communities (like MeeGo or WebOS). A lot of attention by BlackBerry has been put on attracting people who were previously developing Qt applications for Nokia platforms (Harmattan, Symbian) to develop for BB10. 

The main form of convincing was giving developer devices to those who already wrote some mobile apps in the past and were willing to write/port an app to BB10. In addition to that to motivate even more those who actually wrote/ported app, BlackBerry has given limited developer edition of the final device in exchange for developer device. 

Additionally developers, including Android developers were being convinced to port their applications and games during virtual events called porthathons and as a reward money was offered for each ported app. One of the problems BlackBerry had at some point, was trouble in handling all those people they've attracted with different promises given by different evangelists, which caused some bad PR in social media like Twitter. Also some people pointed that rules of Built for BlackBerry program weren't so clear.

BlackBerry was also succesful in cooperating with universities, by creating the BlackBerry Academy program. They were providing devices for usage in laboratories and student projects, but also materials like ready to use slides and lab scenarios. Besides that, BlackBerry used that channel also to inform about the events like coding camps they were organizing.

Tizen (Samsung and Intel)

The Tizen project website became public in September 27th 2011 with the announcement on the same day at that community should now move to MeeGo successor - Tizen. 

Even though the website had similar layout and communication channels offer to community like had, the big move didn't happen. The main problem was lack of communication with community and lack of announcements - Tizen website was mostly dead until release of the source code preview in January 2012, so for around 4 months. 

Another problem was that the project was divided between Samsung and Intel, without much cooperation between those two companies to be seen in public. There was also not enough focus on the open source aspects. What is more Samsung and Intel at beginning weren't much interested in attending 3rd party conferences and promoting the platform, instead they did a major event in San Francisco where they did distribute developer devices to attendees. Later, after the conference, they've also provided some developer devices to those who applied through their website. 

The situation got improved when Tizen 2.0 was released - website got renewed and some more succesful actions to attract interest have been taken. Tizen is now more visible at the events and the conference in San Francisco is still a major event, but not the only one now. What is important is that the Tizen project looks for building community of both app and platform developers - splitting the website with sections for each group.

Also, it is worth to mention that Samsung and Intel didn't offer any program for cooperation with universities although some small, not centrally coordinated steps, are being taken in that direction.

Ubuntu Touch (Canonical)

Canonical started it's actions by announcing the plan to introduce Ubuntu on different mobile devices. Although their first mobile Ubuntu "version" was mainly a set of mockups, an important part of that move was providing an image to popular Android devices like Nexus 7, so a lot of people could actually try and have a feel what Ubuntu on mobile devices will be like. 

It was all connected with a professionally prepared website, where developers were suggested to sign-up for more news and even volunteer to help in making first apps. A form was provided where interested developers could leave their e-mail contact and information about their skills in C++, Javascript and QML. 

As a result Canonical from community formed teams of people working at certain Ubuntu Touch apps. Meeting of those teams took place publicly on IRC and at least on begining course of those meeting was available on the Ubuntu Touch Wiki. All the above efforts were quite easy as Ubuntu is a strong community brand.

Things that are certainly on the good side is regular blogging by Mark Shuttelworth. Canonical also managed to drive successful, from marketing point of view, Ubuntu Edge crowdfunded campaign. Despite they have failed in gathering the required sum, they have managed to spread the word about the platform effectively on the Internet and outside of it, reaching popular medias and attracting new people to join the project.

The main advantage of the Ubuntu Touch community is that it is extension of an already well known Ubuntu community as Ubuntu Touch is a version of Ubuntu for new mobile devices. 

Canonical was until last year organizing Ubuntu Developer Summits events which happened in different places around the world (mainly U.S. and Europe) and were targeted at the community of developers working on Ubuntu. Now they've replaced by more frequent virtual developer summits happening every quarter. That makes participating in them more accesible to people that couldn't afford travelling to physical summits, but the downside is that community misses the summits where real face-to-face contact was possible. What is more, not everyone likes or feels comfortable in video chats.

Firefox OS

Community around Firefox OS is relatively new one as it's a young platform pushed by Mozilla. Project was called Boot to Gecko on beginning and it was announced on the mailing list back in 2011.

Since the beginning Mozilla has been quite active in the public space, organizing it's own events and taking part in 3rd party events, so in other words the project has good visibility. 

Mozilla and it's partners takes also advantage of appearance in places like hackerspaces. Futhermore, Mozilla also seems to delegate a lot of activities to already established local groups or actively seeks new ones. For example they've aided people that were creating community websites by providing trainings for them and including in the national Firefox OS launch team.

On the platform developer side, there is a gap in terms of openness due to tight project relations with ODMs making Firefox OS devices where hardware adaptation licensing and availability is making platform developer entry difficult.

How Jolla could improve it's relations with community and expand it?

Understanding the needs and expectations community has from company is the key to maintaining good relations with community members and most of all expanding it by attracting new people. Healthy community is one that grows, actively participates and takes care of new challenges.

Communication and openness

More contact with community where it is possible (not only open code but also open relations with community).

For now the news sources are mostly third party pages and it is hard to follow what is new and what is officially confirmed and not just only a rumor or gossip. In other words social networks like Twitter for communicating news are clearly not enough.

A good solution would be preparing some dedicated page or blog for interaction (with RSS for those who only want to read what's new) and at least communicating announcements and new features there. 

Announcements like new versions of SailfishOS SDKs with changelogs are already happening on a mailing list, which is of course good practice, but finding those posts if someone's not a regular subscriber might be time consuming.

Public SailfishOS bug tracker and collaborating on reporting/fixing the bugs in the open is a must.

For now a devel mailing list is used for that purpose, which is only a workaround and not solution to the problem - especially that some of mentioned bugs don't get fixed or noticed at all.

The current community around SailfishOS and projects on which it is based (Mer, Nemo) is mostly consisting of people previously involved in Maemo and MeeGo projects. 

This situation is quite natural and understandable as SailfishOS is a successor of that projects. On the other hand it should also be an alarm as it shows that community is not growing and attracting new people. The solution would be putting more focus on diversity and also attracting contributors from outside of former Nokia's circles and communities like for example people from XDA developers forum. 

Furthermore also actions focused on attracting women to get involved are needed as a male-only community is something not only badly perceived, but also a less creative place.

Stimulating other companies to get involved/cooperate is also a must

An idea can be to create an ecosystem of specialized companies focused on different areas, instead of one main company doing everything from start till the end. To attract such cooperation in the areas that are important for companies and individuals some steps must be taken. Spreading the word and showing benefits of cooperation in Mer/Nemo and also maybe some financial encouragement like bounty programs.

Gamifying community efforts

Gamification ideas on community portal

* Point measuring system for certain activities where contributor is a player
* Time point reduction - points gained by contributors dissappear with time, when contributor has no activity (motivate people to be active all the time, prevent making a glass wall between veterans and newcomers)
* Contributor profile to be similar like character profile in RPG games, so depending on type of contributions a person could earn certain character classes and gain levels in areas like code, design, documentation, community. Character classes could be for example - code wizard, design master and to make it more elastic a lot of mixed classes would be available
* Some community challenges/sprints every months/two months - porting applications marathons, finding bugs marathons etc
* Big minus points for offensive/arrogant or discouraging actions against newbies/newcomers (report abuse option)
* Awarding people with possibilities such as meetings in person with Sailfish OS or Jolla device creators. Or maybe some special trainings for such people?
* Community metrics to show how community is developing

All the gamification ideas should be well balanced implemented with caution in order not to divide community, so to award all types of contribution (code,  documentation, community building etc.). In other words every person being active in community should feel he/she is important part of the community and things he/she is doing are important. Evaluation of how gamification elements work and careful tuning will be certainly needed here.

Developer documentation

* In form of a wiki with possibility for non-Jolla employees to do moderated edits (moderators not only from Jolla, but also trusted community contributors should be involved in moderating)
* Two versions of documentation - one with user comments/feedback on bottom (maybe not only on bottom, but on the side also) of each page and one without user comments. Good example of that approach is PostgreSQL documentation.  This could also be done as some layer you can enable with possible user corrections/patches on it. Bottom part could also contain links to some real code examples (apps), use cases of certain functions/components.
* Additional supplement of documentation could be cheat sheets (especially for beginners, but also for advanced)
* Quick guides on how to migrate from other platforms for developers coming from different platforms such as Android, iOS, Windows Phone etc. 
* For Android developers: Page about UX and other benefits an application will have if they'll create a native Sailfish app instead of just pushing Android app to Jolla store
* Images, diagrams and other graphical elements will help to make documentation more attractive (maybe even comics or funny stories) and help to understand more deeply important/complex parts of it.
* Ability to submit bugs in the documentation - currently it is not possible and many of the bugs mentioned on sailfish-devel@ mailing list seem not to get fixed and even if, there is usually no information about that.
* Being open to suggestions from developers and community how the documentation should look like - some short survey about the form of documentation
* Some screencasts and tutorials would be also a plus, beside that one place with links to all videos and other materials from talks about SailfishOS application development and connected topics that happened on the conferences and other events.
* Information what is the best way to do certain things on the platform - store data, store settings, access to hardware features etc.
* Besides official documentation and other materials website also regulary monitoring services like StackOverflow and answering questions there.

Financing/sponsoring challenges:
* Aid projects and groups of people collaborating instead of single person projects. In other words motivate people to collaborate with others on doing interesting/needed projects.
* Discount offerings for devices/accessories to most active people, but not giving devices for free
* Giving/borrowing devices to places like open devices labs/hackerspaces, where they would be accessible on-site for many people that would like to test their apps on Sailfish (or test self-made Other Halfs)

Collaboration with groups/organizations/universities:
* Collaboration with local Linux users groups in order to spread the word, involve people and to have help in organizing events (getting venues) etc.
* Collaboration with hackerspaces, places where makers and co-creators usually gather
* Summer of Code like programs, but connected with projects during the semester (also a mentor from Jolla or Nemo community needed for each project)
* Devices can be provided/borrowed to partnering universities, but there should be a report every semester how the devices are effectively used, what kind of projects are being created by students etc.
* Group of some trusted advisors in each of the countries should be created, that could help Jolla to get the picture what groups/communities are there, which one are active etc. In other word some local coordinators/ambassadors.

Events for community/partners:
* Have one annual big event, that moves between different countries (different place each year), involve local communities to help in organizing it
* Supporting local conferences, do mini-events on them (the thing is that Apple and Google are supporting and doing mainly only their own events, which from perspective of different conference organizers makes difficult to invite people representing those companies, which can be an advantage for Jolla). Supporting local events is much cheaper than doing own ones and is a great occasion to reach new people/communities.

These are the ideas we'd like to present. We encourage you to give us feedback and your improvement proposals in comments.

Filip (fk_lx) & Carsten (Stskeeps)


  1. Great article!! I'd only recommend proof-reading once more, there are quite a few spelling/linguistic mistakes. :-)

    I would recommend modelling the community portal after the maemo one: that one was really great to use. So, creation of online forums would be nice, and mirroring with mailing lists would be a plus.

    Also, a build service would be great. Mer is already using OBS, so I think it's just a matter of developing some tutorial (hello world app, from setting up the SDK to submitting the app to the build service).

    1. I'd avoid OBS since many projects struggle with it and developers don't like it. Intel has already moved to GBS although that is based a good deal on OBS and very few other projects have taken up OBS.

      I'd suggest that Yocto recipes be considered since that has a lot of traction and is designed for embedded environments.

    2. +1 For a Sailfish OBS. Well, even just adding a Sailfish target to the Mer OBS should be both easy & practical, as all Mer, Nemo and Sailfish development could use the same OBS instance with all the related network effects.

      I've been using the late MeeGo COBS and really liked it & I already have a few packages on the new Mer one. :) It realy makes packaging easy once mastered and enabled for easy automatic packaging and frequent releases.

      And another nice aspect of OBS, that is oftne overlooked, is that t makes library porting and development much easier. You can for example pull a library from the OpenSUSE OBS instance with osc, tweak the specfile to the Nemo/Sailfish packaging standard and add any patches needed to make it build on the given project target (Nemo/Sailfish).
      Then you either submit a request for inclusion in on of the middleware repos for Mer/Nemo or just host it in a custom repo with the software that is making use of it.
      This is much easier than doing it all by hand.

  2. good analysis on where we are and some good ideas on how to attract new contributors.

    If I may a plug for a local event,

  3. great analysis, I think that the model maemo was good but everything can be improved. Then it is obvious that a lot will also depend on sales of the device. As far as discounts on device go favorites I think those who contribute to the community (in any way). The strategy of Microsoft / Nokia to give device to those has done 3 app, i think will not benefit the ecosystem (and I do not think jolla can also afford the economic point of view - unfortunately). The apps that people want to have those are fashionable (angry birds-instagram, etc.).

  4. The single most important step is for Jolla leadership to understand and embrace FOSS.

    There is widespread skepticism that this can be done at a corporate level. Nokia had difficulty trusting the community despite the excellent Maemo project. Many ex-Nokians have a case of NIH, and are unwilling to contribute themselves to the broader community as a company although they often have leading contributors as employees. This is part of the culture that has to change at Jolla and not just be a marketing slogan.

    Oh, and ship hardware, that'll help.

  5. I would definitely love if #jolla builds a community portal like the That was simply the best place of solution and sharing ideas and paradise for devs.

  6. For me as a developer to be interested in Jolla I want all the docs, tutorials, howtos and resources to be in one single place, cross referenced etc. API docs should reference suitable examples (of which there should be a lot) and all examples should be included in the SDK. The SDK should be one single file to download for all OS:es, no fiddling with extra downloads. When the SDK is installed I want to be able to start a new project and get a working template application that I can run in a simulator or on a plugged in device by clicking "Run".

    Yes, I'm spoiled rotten, but the other big mobile OS:es have shown that all my requirements can be done. But none of them have got all parts yet. Apple have the SDK part working perfectly but awful docs handling, Android has better docs handling but awful tools etc.

  7. This is very welcome! Having some central hub for communication would be very useful, and it's good that you plan to implement it at last.

    As for developers, you should consider how to handle shared repositories for Sailfish. I.e. open source community packages and their dependencies especially for libraries. Pointing to OBS and letting it "sort itself out" is not a very good way to handle that.

  8. Maemo extras, along with the extras assistant and the latest QtSDK integration was an excellent system. It did promote collaboration, in a true open-source way as you could just start maintaining another developers project, you could depend on other packages so that you didn't have to include everything in your project (especially for daemons this was super-effective as a developer can use an already existing daemon and minimize running processes on users' devices), and publishing (the most boring part of development) was just a couple of clicks without ever leaving Qt creator. You could then promote via the packages interface.

    The seperation of extras and ovi was also good as the community-controlled extras made users feel "at home" and safe from adware and nagware and allowed people who care to only use free packages.

    An easy to use and welcoming packaging/publishing infra is very important for the community development. OBS is good but it really can't be classified as welcoming.

  9. Outstanding analysis! Would love to see the proposals realized, and hope i can help.

  10. Some truly excellent thoughts Carsten, wish I'd seen this earlier, haven't read most of it yet, but certainly will soon, when I can find the time (jalyst).

  11. I personally have had great difficulty getting support on tizen build problems. As you outline the support just does not exist for the community. Hopefully this will improve in the future.

    Excellent write-up.