We have moved to a new Sailfish OS Forum. Please start new discussions there.

Co-creation leading to co-development?

asked 2013-12-24 22:40:20 +0200

updated 2013-12-24 22:42:21 +0200

An obvious step up from how we are doing co-creation here on Together is to take an idea and factually co-develop, co-design, co-debug it, etc. There's a few challenges regarding that.

SailfishOS is currently built from:

  • Mer Core (open source, openly developed), http://www.merproject.org

  • Nemo Middleware (open source, openly developed)

  • Sailfish UI (closed source currently, not openly developed)

  • A hardware adaptation (typically closed source, full of 3rd party bits and pieces)

I believe personally that unless you can factually be open about plans, directions, during the development of open source SW, there's really not much worth in open sourcing it. Plus - a mobile stack is -big-

In addition to that, there is a challenge with UI and applications - especially a modern mobile UI:

  • Is going to be heavily designer driven - as in, there may very well be a requirement to have an accepted design before your feature is merged
  • It needs to be fluid, 60fps and you need to take care of your feature and be responsible for it
  • It needs to have test cases and integrate well into a complex system

And that really complicates typical open source development methods.

I think that if we (as in Jolla) as a small company, work from the perspective that we start with co-creation of ideas, then work with contributors in these ideas and bug reports to focus where the real openness effort needs to happen, it'll help a lot.

What do you think? How can we do realistic co-development? Answers such as 'open source everything' is not what I'm looking for. It's easy to ask for openness, but it's hard to do in practice.

Here's one for thought:

  • co-develop first on the most common pain points of a mobile UI - e-mail, calendar, browser comes to mind. Help nuture ideas into features and get them implemented.

Hi, I'm Carsten Munk, Chief Research Engineer at Jolla. Let's try to grow the skunkworks of Jolla and SailfishOS together. Use the tag 'skunkworks' for your ideas and thoughts. Rule #1 of skunkworks: stick to something that is not short term (rest of site is good for that), but is possible 6 months from now or beyond that. I believe that the best research department a mobile OS can have is a worldwide community of passionate contributors and users. Let's prove this theory right.

edit retag flag offensive close delete



I'm not a developer, but in my humble opinion this is probably the most important topic here.
Hope for (even) more openness from Jolla than Nokia was the single biggest reason for me to support jolla. So far I am pleased, and I hope I will have the same reason to buy the next phone too.

Nilux ( 2014-01-29 10:34:22 +0200 )edit

@Stskeeps: Hi, I have a suggestion for enabling more co-development, rather than just co-creation. I made it a Question here: https://together.jolla.com/question/38722/make-sailfish-oss-front-end-ui-open-source-but-not-the-ui-back-end/ I am happy to make it an Answer under this question if you think it belongs here more than where it is now. I would be very happy for any comment.

00prometheus ( 2014-04-14 05:25:52 +0200 )edit

Umm, “fluid UI” ... how is closing off the source helping with that? And if it does, are we going to get a fluid UI eventually? Because sailfish so far has been, sadly, everything but fluid.

mornfall ( 2014-12-02 17:30:14 +0200 )edit

12 Answers

Sort by » oldest newest most voted

answered 2014-12-07 20:17:36 +0200

simo gravatar image

updated 2014-12-07 20:22:58 +0200

Feels kind of odd to add a 12th answer to this great thread... But when there's an issue, you try to find the correct place to post it.

Recently, a new member joined TJC. He seems like a fan of BB type of user interface, and after a week of using Jolla he posted about his wishes for changes in Jolla's UI. By that time, he had gathered some 300 karma points with few posts, and he followed the existing help+faq+guidelines in his new post.

After this rather opposite opinion and maybe a couple of bad (but not that bad) comments and unaccepting the most voted answer, he got bombed down to 1 point and got a few bad (but not that bad) feedbacks as well, mostly for these reasons:

  • He's opinion didn't seem to fit into the core elements of Jolla's UI
  • He had a list of questions as a question, and he wanted to keep this question open, as he saw it as important for his user case (it was also posted by the guidance existing)
  • He sounded like he wants to use another phone (For me it seems he just wanted to change the UI in Jolla in a way better suiting his user case)

Now I'd like to bring our voting behavior towards a new member into this table. He might have valuable posts before,and possibly later too contributing to the community. If he'd been around for a couple of months, I might have downvoted a couple of his questions as well, but after we see that the message is clearly delivered (many disagreeing already), why add another downvote? IMO it just drives people away, instead of making them feel welcome to our forum. Thanking for even totally opposite opinions, guiding to how TJC is supposed to be used might be a better way to go. Let's adopt, adapt and improve on this! And yes, you're welcome to disagree ;)

edit flag offensive delete publish link more



I understand what you are saying, and I agree that we should welcome all input and discuss our different points of view openly. Diversity enriches the community and strengthens the project as a whole. The way I understand the voting system is quite simple. If I disagree about an issue I downvote, if I agree I upvote, if I'm not sure or do not care I do not vote and let the other users discuss the issue more throughly. I, however, do not check who posted something, nor how much karma he/she has before I vote, because all that I'm interested in is the issue at hand. If we start pondering about the political correctness of up voting or downvoting we would be harming the democratic process itself. By not downvoting things you don't agree with, or by upvoting things you don't agree with, you are skewing the results and thus harming the system as a whole. I don't think anyone should take their downvotes personally, nor worry too much about karma. The important thing is that we keep discussions open, civil and always focused on the issues at hand, so that we as a community can contribute to to make the Jolla project more successful. Sail on!

shfit ( 2014-12-08 02:26:45 +0200 )edit

You have great points there about the effect to the system. Maybe some kind of a "point shield" for new members for few week would be another option, downvotes still having effect to the question/answer itself. I must admit I'm especially careful in downvoting any post by anyone with only some karma points, even if I wanted to. I usually leave a comment instead.

simo ( 2014-12-08 02:37:44 +0200 )edit

Or maybe we could just put a limit to the amount of karma you can loose with a single question. That way we do not completely disencourage users from bringing up unpopular issues.

shfit ( 2014-12-08 03:10:40 +0200 )edit

Btw, maybe it would also be a good idea to give users karma points for extending or updating wikis and for posting comments and the upvotes their comments receive. If the point of karma is to encourage participation, then all kinds of participation should be rewarded.

shfit ( 2014-12-08 03:17:08 +0200 )edit

I agree with @shfit.

nthn ( 2014-12-08 12:13:32 +0200 )edit

answered 2014-12-04 06:54:35 +0200

sajithvk gravatar image

Open development of the UI components is not critical. However, a clear open-source license is very important. It is a user's freedom to know what is running on his system, and make changes to it.

Jolla need not accept user's code changes. However, you should open-source your codebase. Please refer fsf.org

edit flag offensive delete publish link more

answered 2014-12-02 17:09:20 +0200

ossi1967 gravatar image

I take the challenge to revive this old thread. :)

What do you think? How can we do realistic co-development?

Several points:

  • Offer one central entry point to access the sources of the already open components per Sailfish OS release in one central place (either under the merproject or sailfishos domain) and advertise it. Even after one year (as a non-developer, I have to add), I'm constantly amazed to find out where sources pop up. I'm usually still unable to find out if the code I'm looking at is running on my phone or is in preparation for a future release. If possible in any way, incude in this portal binary packages or at least descriptions of closed components. (It might help to understand the mechanism of two open parts if you know that there's a closed layer that provides the glue.)
    Benefit: The amount of open code will be visible, it will be easier to contribute (if Jolla accepts contributions, see below), Sailfish OS will be de-mystified.
  • Do not openly develop the user experience. Welcome ideas on TJC, accept mere bugfixes to open code parts, but make sure Jolla keeps in control. This is not a matter of open vs. closed code - the code may well be open if there are no other reasons to keep it closed. It's a matter of decision and accountability.
    Benefit: Avoid "design by committee"
  • Be clear about where you can't use community contributions because decisions are dictated by business needs. For example, if some piece of code is open source, but will be controlled by Jolla other than for minor bug fixes, state it clearly. If discussions arise on TJC about feature sets etc. that (from Jolla's point of view) must be decided based on commercial or legal reasons, close the discussion.
    Benefit: Avoid frustration because community members invest their effort into things that cannot be changed.
  • Actively communicate where input would be useful at the moment: Invite people to fix bugs or expand features in packages where such open development is possible and co-development will be helpful. Set goals. Ask questions about desired features etc. if you're really open for input. (Do not simply put polls online, listen to what is said, not how many say it.)
    Benefit: Give those who want to participate a place to start, a clear to-do list.
  • Make it visible where code contributions actually happen and where open code basically could as well be proprietary because it's being worked on only by Jolla.
    Benefit: As long as there's closed code, there's the feeling that all bugs would be squashed in no time and development would drastically accelerate if only everything would be open sourced. Visibility of community contributions may make things appear more realistic.
  • Bug tracker. TJC just cannot do what a real bug tracker can: There are no structured input fields here about OS version used and other basic information that's vital if you want to even reproduce the bug. When I read TJC, I see things like "My mail doesn't work", followed by lots of "me too" or "try this". Bug trackers I know usually, after a few posts, come down to at least identifying a certain piece of code that behaves badly. This doesn't solve the problem, but it's a much more useful public documentation of where people could start to help.
    Benefit: A more systematic approach to bugs, including priority and includig wontfixes which are also important to know about.
edit flag offensive delete publish link more


You, Sir, have several good points.

Okw ( 2014-12-02 17:22:16 +0200 )edit

I am especially in favor of the first point, a central place to learn about all components that make up sailfish OS. Maybe we can do this by ourselves as a wiki in the meantime.

simonschmeisser ( 2015-01-21 11:33:21 +0200 )edit

answered 2014-01-20 14:28:25 +0200

condo4 gravatar image

I think Mer project is not a good point for a totally and simple for the community to have a "good" open source OS.

I look for documentation to build from scratch the project, to contribute... and I can't find clear documentation nor easy way to do that... In addition, there is not a "Git" tree of recipe where I can find how Mer project is built.

I think OpenEmbedded and Yocto project is a best approach... It is very useful for community to contribute, and it need less work for Yocto team to integrate and test contributions... The Git recipes tree contains all information to test / build / understand how the project works...

It's a pity that Mer Project, and/Or Sailfish was not based on this project... Yocto used also Wayland and many other common piece with Mer.

edit flag offensive delete publish link more

answered 2013-12-31 01:01:34 +0200

levi gravatar image

updated 2013-12-31 01:03:17 +0200

I agree with shmerl's answer above, i.e. availability of source code and license terms are of utmost importance. Everything else can be fixed eventually. Let me quote again the license information section from sailfishos.org:

"Our goal with the Sailfish OS is to develop an open source operating system in co-operation with the community [...]."

I think it is obvious that keeping parts such as the UI closed is in direct contradiction with this goal. Thus I am surprised to see that so many are okay with this state of affairs in particular given that Jolla is advertising Sailfish OS as a "truly open" operating system. I can only wonder what your point of reference is? To me it seems that my Nexus 4 with Cyanogenmod + F-Droid is the truly open system and Sailfish OS is just a mishmash of proprietary and open-source pieces with no coherent policy behind (cf. Clarification of open-source policy).

You said:

"I believe personally that unless you can factually be open about plans, directions, during the development of open source SW, there's really not much worth in open sourcing it."

On the contrary! It begins with open-source and if you are able to put a working community involvement on top then all the better, but not providing the source is a non-starter. The obvious reason for this is that without the source all communication is essentially asymmetric. It is between those with access and those without. Why anyone interested in a software project would accept this asymmetry is beyond my scope.

edit flag offensive delete publish link more



Stskeeps hinted that opening UI can make the company unsustainable. I have no way to verify that and it wasn't really explained. But stuff like this: https://www.youtube.com/watch?v=b0w36GAyZIA makes one think more than twice before using any closed stuff... And even that isn't enough.

shmerl ( 2013-12-31 18:27:53 +0200 )edit

I must admit that I was very close to buying a Jolla phone (the FOSDEM rebase almost made me do it), but that the system is not as open as I thought it would be made me very unsure again. Maybe you are right and “Nexus 4 with Cyanogenmod + F-Droid is the truly open system” and hence what I should be using.

nomeata ( 2014-02-08 21:53:06 +0200 )edit

@nometa I think with that option you will be much better off than the people who preordered this heavily overpriced hardware in the hope of getting a truly open (as in FOSS) OS with it.

torpak ( 2014-03-25 13:51:39 +0200 )edit

Totally agree with you. I wanted to buy Jolla too, sad to see it's not so open as I wondered. It seems I should take Freedreno with bootstrap and dig into freedom on my own.

Adonai ( 2014-08-04 11:44:36 +0200 )edit

answered 2013-12-30 17:54:34 +0200

simo gravatar image

updated 2013-12-30 17:56:28 +0200

To reduce the workload of your small (yet) company, and as an answer to comments from @Sfiet_Konstantin @Stskeeps: (this answer is limited to beta testing)

If Jolla wish to have a great test group, you can provide the users the latest development versions as updates (with a simple bug reporting tool implemented). As not everybody want's to take part to the Beta testing, the user should have option in the phone settings for accepting notifications for development updates (default setting: Only public updates).

Both in the public and development updates, a link (provided in the notification) to the changelog would be great, so that users could consider if they install it or wait for a newer release. Actually, I beleive you'd have quite a large group of somewhat skilled beta testers already among your customers. If in any lack of those, some nice, small rewarding of active and factually working bug reporters would propably handle that issue.

As we have this together portal now, maybe the best (and most open) way to use the implemented bug report tool would be to open a form in the phone, pushing the post here (autotagged with "SailbugTool" or whatever name you choose for the posting app). The "SailbugTool" could be available for everyone via Jolla Store.

edit flag offensive delete publish link more



The "stable" and "testing" branches approach used i.e. in Debian development could serve as inspiration.

strnous ( 2014-01-02 01:20:05 +0200 )edit

answered 2013-12-30 17:20:02 +0200

shmerl gravatar image

updated 2013-12-30 17:23:41 +0200

Actually unlike others above I expect the Sailfish UI and core applications to be fully open (besides 3rd party closed stuff and so on of course). Because licensing the UI to others sounds like a pretty bad idea to me. However I agree about technicalities which make open development hard to address. But they should be solved gradually. Open development helps building trust and transparency.

About common pain points (browser, e-mail) - those are core components of any usable frontend oriented OS, and not only that, they are communication related. IMHO it's critically important for them to be open from security and privacy standpoint (and given all the latest revelations even more). One of the areas where Sailfish can be competitive is trust and privacy, and that's where most other mobile systems are severely lacking. Being closed doesn't help that.

So, having some bugtracker for Sailfish (and not just for Nemo and Mer) would be a good start for collaborative effort. I understand that resources are limited, but this is critical really.

edit flag offensive delete publish link more


Try to add this article to your analysis, and think from the point of view of what's in there of points said by Jolla CEO. What would a company need to do to keep things viable from a business point of view?

Stskeeps ( 2013-12-30 17:32:38 +0200 )edit

@Stskeeps Why not open-source everything that hasn't licensing problems with a little notice explaining why patches are not accepted yet? (if I understood correctly). Is it possible to achieve something like this? I've just entered the Jolla community and this would make it the perfect place IMHO.

xcv_ ( 2013-12-30 18:04:00 +0200 )edit

From there:

We won’t get money by selling the OS. It has to be something else on top of that. It can be applications, services or advertising. Whatever is their revenue model, we should be able to get a slice of that

So, Jolla isn't making money on the OS itself, so it can be mostly open?

shmerl ( 2013-12-30 18:26:22 +0200 )edit

I share shmerl's expectation. If you advertise with phrases such as "truly open" or state that your goal is to develop an open-source operating system you should not be surprised. Turning around saying "how do we run our business then?" is quite disingenuous.

levi ( 2013-12-31 01:12:27 +0200 )edit

This is a co-creation site, you get to discuss all angles of the same thing in order to figure out a direction. I've been in the same position in my own past - pushing openness and transparency and from all the data you have at that point it all makes perfect sense. When you're at the other side of the table and get to see the full data set, you start to wonder how you would put bread on your table, be able to sustain your open source activities - so I'm asking these questions to help people get a broader understanding of what is needed to be sustainable. I'm all for practical and sustainable open source.

Stskeeps ( 2013-12-31 10:05:57 +0200 )edit

answered 2013-12-30 16:59:05 +0200

fk_lx gravatar image

updated 2013-12-30 19:36:47 +0200

Here is my answer to @Stskeeps answer:

Roadmaps - nobody ever said there must be a global long-term unchangeable roadmap, but the thing is that Jolla employees contribute to Nemo projects not just out of the blue. They have some micro-roadmaps or list of issues to be solved but those aren't available openly - Nemo bug tracker is essentially dead. Currently it's that issue and its solution appear exactly at the same time moment/quant on Nemo Github area. It is clear that those two things don't happen at the same time moment - first there is an issue or certain need, then solution is being made and finally in the end pull request appears. The problem is that what we see are only pull request of complete solution of not known earlier issues. I agree with @Stskeeps that those should be in open bugtracker or put on the issues list at Github, giving potential possibility to be fixed by those who are interested. That is co-developing and possibly would be a wind blowing into sails, because bugs and issues could be fixed by both developers from Jolla and from community.

One of the sailors replied to this issues raised earlier on IRC some time ago "We don't want you to take and do our job" and that in my opinion is essence of non-colaborative way of thinking of that particular person. It should be obvious if someone does some part of your job, you can have more time for the other part or do something completely new and useful. Experts shouldn't be afraid of open collaborating.

Project drops - I see the point, but in my opinion silently putting whole projects/libs without even short discussion and hearing different point of views is not the way to go. Seriously give 48 hours for possible open discussion/questions (yes discussion, not approval of something), it can only improve things. Maybe someone will suggest something that can be a better solution than the one that is nowadays silently dropped into Nemo repos without any reflection. Open communication should be essential.

Collaboration - no one proposed democracy, instead what was proposed was openness. Now it's really like "We know better what is the best", so if it's the best solution why there is a fear of putting it under open discussion? Look at Ubuntu Phone mailing list - platform development is discussed there by Canonical employees with community whereas Mer/Nemo mailing list is completely silent (sadly Nemo contributors from Jolla are not discussing anything there anymore).

Bug triages - Mer & Nemo bugzillas are dead and it doesn't mean that bugs suddenly stopped to exist, they just appear but on some other non-public bug tracker. I do agree with @Stskeeps that if there is no topic to discuss, then there is no sense in making a meeting. Problem is that Nemo development continues and there are no contributor meetings on IRC (neither component nor general ones).

@Stskeeps Q: Why not instead do "Sailfish Core" with all these SW components included? Much clearer contribution model for people - most want to contribute to SailfishOS.

@fk_lx A: Sure, but what about platform development, not everyone is interested in app or top OS layer development, please accept that people have different interests. Even Tizen has two separate sections for those who want to do platform development and for those who want to do app development. I really recommend looking at these slides regarding their collaboration model planned to start from Tizen 3.0. They are admitting their mistakes (source-available -> open source + open collaborative) and presenting steps that will be taken. For me it is a positive sign and while wishing all the best to Jolla I am afraid that one day Nemo might be less open than Ubuntu or Tizen. My point might be ignored, but if you are a small company, that promised a lot of openness (I remember very well what was said on Slush 2012) then please keep that promise.

@Stskeeps Q: Why not merge Mer Core and Nemo Mobile middleware into a Mer Mobile Core?

@fk_lx A: Why not, but what about projects that are using Mer Core and are not using Nemo Middleware parts? What clear advantages do you see in merging those both parts?

edit flag offensive delete publish link more

answered 2013-12-30 15:30:11 +0200

updated 2013-12-30 19:41:01 +0200

fk_lx gravatar image

In response to fk_lx's question.

I'll (my own personal views) try to address some of the problematic parts here - just hear out my thoughts a bit on how I think of things.

Roadmaps - let's imagine for a second that this site is the roadmap for what Jolla chooses to work on - in order to make customers of it's device happy. A suggestion yields a number of implementation points in different SW components; and when a suggestion is taken into a iteration by Jolla team members; that's when it happens. It's difficult to roadmap ahead when you are developing like this in agile mode. There's really not such roadmap items in a Jolla bugzilla - but there is technical debt listed and bugs - with no time schedule. Admittedly, a lot of that should be reported and dealt with in an open bug tracker.

But at same time there's a major challenge since some components may factually be on a stable branch in a SailfishOS shipped release image, versus a development one. And that is hard to deal with when development has moved way beyond that (example - now supporting Qt5.3 than 5.1). Let's see if we can find some practical solutions to this kind of issue.

Project drops - Nemo MW is a collection of software. The collection of packages in github/nemomobile/ is historical and for all intents and purposes what it is - a collection of software. It has always been a melting pot of Mer-based mobile software. Basic discussion of if something goes into Nemo has traditionally been very open - and that's how it has grown - that if something is mobile related, be it apps, middleware, or UX - that's the key parameter for merging. There has been a strong JFDI feeling over it since day one. A similar model exists in Jolla, there's no key parameter for adding something to the repositories, just keep it separated and sanely layered - no need for a lot of bureaucracy.

Collaboration - I will make it very clear: a democracy is not the way to develop software or design UI. I'd rather rephrase it: there's many different stakeholders for your software - listen to different views, review and integrate patches liberally without a lot of red tape, empower others to be contributors and remember to give reviewer and commits rights - but in the end somebody will have to make the decision on the path a component will take.

Bug triages and meetings: yes, but I think that meetings should start per component or area. You can't enforce meetings without having anything to talk about - in early Nemo, we found that in practice we had already spoken about most issues and the meetings turned to be silent. People just did things and pushed the features forward, to build a better product. Bug triages are important - for sure, but I would also say that we need to go over Nemo -and- Mer bugzillas and take a fresh look at them.

I'll play the devil's advocate and start this discussion too:

  • Why not instead do "Sailfish Core" with all these SW components included? Much clearer contribution model for people - most want to contribute to SailfishOS.

  • Why not merge Mer Core and Nemo Mobile middleware into a Mer Mobile Core?

edit flag offensive delete publish link more



I'd like to see the MW merge happen. The distinction about what-goes-where was always rather arbitrary, and has grown increasingly fuzzy due to operational requirements (e.g. QtDocGallery? it's Qt, but it depends on tracker, so it's in Nemo). That then leaves a clear place for open UI to happen too.

Robin Burchell _ w00t ( 2013-12-30 16:22:40 +0200 )edit
  • Roadmaps: agree, but more communication done on what's being done on Jolla sprints won't hurt external devs.
  • Projects drops: agree.
  • Collaboration: agree, but there is a need to empower contributors. The learning curve to integrate Nemo dev is very steep.
Sfiet_Konstantin ( 2013-12-30 16:48:05 +0200 )edit

I disagree about merging Mer and Nemo. Nemo components are useless for anyone that uses Mer but wants to provide a different stack or their own UI, etc.

Venemo ( 2013-12-30 17:40:56 +0200 )edit

One can argue exactly the same thing about Connman (in Mer), Qt (in Mer), and many other components. And yet, we draw the line somewhere.

Just because they are in the same umbrella does not necessarily mean there cannot still be layering - and I'd support that - but having a clear distinction of where the base part of the OS leaves off and the UI begins makes life easier in many ways.

Robin Burchell _ w00t ( 2013-12-30 17:45:43 +0200 )edit

Roadmap would be nice. It does not have to be detailed in a sense that "in this sprint I do this", but giving things like Qt5.2 Q1/2014 gives quite good idea what we want to achieve and when to expect major things are coming. At the moment Mer/Nemo does not really communicate such things at all.

veskuh ( 2013-12-30 18:09:27 +0200 )edit

answered 2013-12-25 22:07:29 +0200

I need to read this again, but I've got something that's in my head now:

  • should a UI be openly designed and if so, what's its vision that holds it together
  • Should a UI be designed to design itself over time (if you will, build the components openly which adapt themselves to various user needs

In reading this, that's what came to mind. I think that the process doesn't matter as much as the vision does. What does SailfishOS want for itself? Is what it wants open-design, or open processes to improve it?

edit flag offensive delete publish link more



I want you to clarify what you mean by openly designed. Because openly designed (IMO) leads to design by comitee, and this leads to poorly designed stuff. I appreciate Jolla providing the design, guidelines and reviews, and would prefer contributions to be only technical at first.

Sfiet_Konstantin ( 2013-12-26 17:38:15 +0200 )edit

I totally agree with @Sfiet_Konstantin comment above. That's why I was more talking about Nemo in my post, because I see room for improvement there (middleware - technical stuff).

fk_lx ( 2013-12-26 22:54:51 +0200 )edit

@Sfiet_Konstantin that's exactly what I mean. Understanding what we are assuming towards with the platform puts the process and purposes of components in their right place. Right now, or at least how this question is made I don't know that Jolla has done that to the extent that question asks.

arjwright ( 2013-12-27 00:48:37 +0200 )edit
Login/Signup to Answer

Question tools



Asked: 2013-12-24 22:40:20 +0200

Seen: 5,287 times

Last updated: Dec 07 '14