Co-creation leading to co-development?

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

simo
29079 ●345 ●466 ●481

http://reviewjolla.blogsp...

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

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 ;)

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

sajithvk
63 ●1 ●4 ●9

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

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

ossi1967
15990 ●198 ●253 ●259

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.

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

condo4
3878 ●22 ●34 ●40

https://github.com/condo4

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.

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

simo
29079 ●345 ●466 ●481

http://reviewjolla.blogsp...

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

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.

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

shmerl
9435 ●44 ●70 ●69

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

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.

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

fk_lx
10250 ●49 ●66 ●65

http://twitter.com/fk_lx

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

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?

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

arjwright
3038 ●20 ●30 ●36

http://antoinerjwright.co...

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?