Co-creation leading to co-development?

skunkworks

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

8994 ●62 ●67 ●71

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

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

Comments

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 +0300 )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 +0300 )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 +0300 )edit

12 Answers

Sort by » oldest newest most voted

12next page »

answered 2013-12-25 15:09:22 +0300

fk_lx

10250 ●49 ●66 ●65

http://twitter.com/fk_lx

updated 2013-12-25 22:29:30 +0300

I don't expect Sailfish UI part to be fully open - I'm not that radical, especially that Jolla plans to license its OS to other hardware vendors, which I believe and strongly hope that they will succeed and we'll see mobile devices with preinstalled Salifsh OS from multiple hardware vendors.

What really concerns me is the quality of collaboration with community in the already source open parts like Nemo. I would like to exclude here Glacier UI from the bellow considerations, because it is a part of Nemo that works well when it comes to open collaboration and co-creation. The problem is with the whole rest. I understand that Jolla had a product to deliver to market, so it is justified that they did a little take over of Nemo in order to not waste precious time on discussions. This resulted in ending bug triages and putting discussions, decisions and features roadmap behind the closed doors of the company. If someone would compare Nemo year before and earlier with Nemo nowadays it is quite clear that it is less "open" in terms of open collaboration (open source is not only about open code, but also about the way it is created and collaboration). Anyway launching product can result in some trade offs, but now that Jolla device is on the market we can work on improving it. Here are my points:

Roadmaps for each of the subproject/parts in Nemo (list of bug/issues to be solved, stuff that needs improvement, ideas) needs to be open (I guess it's currently only on Jolla internal bug tracker what will be done with what parts of Nemo)
No more project drops - it should be discussed when new lib/subproject is added. I don't expect never ending discussions, because that would be fatal and could stall development, but I see it like that some Nemo contributor writes his proposal of adding new lib/subproject to Nemo on the mailing list and we leave 48 hours for the discussion around that (best if he first describes the plans what he plans to do, not something he already done and tries to push)
Changing the sailors attitude to collaboration in Nemo from "We know better as company" to "Community & company together knows the best".
Regular weekly or monthly meetings on IRC where Nemo future is discussed openly - anyone can take part in such discussions
Return of bug triages - return of weekly bug triages

In my opinion if those above points will be met we will have a chance for true community and company collaboration on Nemo. If Jolla doesn't want to completely dominate Nemo development like it is currently and see more active community involvement then something must change for sure.

edit flag offensive delete publish link

Comments

For Nemo mobile, I guess you listed all the problematic points.

Sfiet_Konstantin ( 2013-12-25 16:00:42 +0300 )edit

+1 This is the best idea that I've read so far!

Venemo ( 2013-12-25 22:30:12 +0300 )edit

answered 2013-12-24 22:55:02 +0300

Sfiet_Konstantin

6385 ●45 ●72 ●97

http://sfietkonstantin.wo...

Ah, this topic reminds me of the good old days.

As I agree that opensourcing something is not the answer to this, I think that Jolla needs to allow source inclusion at some point. This ask board is already a good start, as it gathers ideas coming from community, that (I hope) will be read by both developers and designers at Jolla. However, good ideas are not enough, for a good software stack we also need good code.

Having Mer and Nemo opensourced is also a good start. People can pick the middleware they want and push improvements to it, or provides enhancements in the core OS. But it is impossible, for now, for developers to provide enhancements or fixes to Sailfish OS UI. Sadly, the UI is where people want to tweak the most.

I agree that many components inside Sailfish OS might not be opensourced because of deals / contracts or because of development issues, but starting opening some non-critical applications can be interesting (think: clock, calculator). If it is not about opensourcing, providing interfaces for the community to easily add feature can also be something to think about (media player plugins, gallery plugins, settings plugins).

As for opensource development, I'm thinking about a two to three level contribution style. A first optional level is a community-only repository. People can submit patches and they are tested by other members. If enough members accept the patch, then it is pushed further.

Then, there is another level that is an engineer-only driven repository, where community can propose patches, and Jolla engineers (or some elected members) accept them. There must be some level of quality for the code to be accepted: documentation, tests etc.

At the end there is the top level, that consists of Jolla repositories. Engineers selects the most promising patches, that are also reviewed by designers, and that are included in Jolla software stack, and released as updates.

edit flag offensive delete publish link

Comments

I too think that open sourcing apps would be a good start. Something like the 'clock' app could be forked and a 'world clock' feature added. The community code for this could always then be reused/adapted by Jolla in an official update at a later time, after ui/testing requirements.

mattaustin ( 2013-12-25 13:30:58 +0300 )edit

I don't like the idea of Forking. Instead of forking, why won't community people tracking Jolla's source tree and rebasing if needed ?

Sfiet_Konstantin ( 2013-12-25 13:58:45 +0300 )edit

An initial idea I had on this topic was a 'staging' branch that was merging multiple proposed branches by community (prototype -> have a design -> get test cases -> merged ; and then have changes be accepted into mainline.

Another view: that people who go through co-creation process leading to probable co-development would get access to execute modifications in the code / access to bits of Sailfish. Bad/good idea?

Stskeeps ( 2013-12-30 15:35:39 +0300 )edit

@Stskeeps: I like the idea of allowing modified builds in Sailfish. This allows beta-testing, and feature testing, and makes merging easier if we know that the code is already tested. Staging branch is also interesting, it is also what usually happens in SW dev.

Sfiet_Konstantin ( 2013-12-30 16:43:39 +0300 )edit

I'm citing above "Sadly, the UI is where people want to tweak the most."

darvari ( 2014-09-29 14:49:03 +0300 )edit

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

levi
572 ●5 ●6 ●8

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

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

Comments

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 +0300 )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 +0300 )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 +0300 )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 +0300 )edit

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.

edit flag offensive delete publish link

Comments

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 +0300 )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 +0300 )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 +0300 )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 +0300 )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 +0300 )edit

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.

edit flag offensive delete publish link

Comments

You, Sir, have several good points.

Okw ( 2014-12-02 17:22:16 +0300 )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 +0300 )edit

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?

edit flag offensive delete publish link

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.

edit flag offensive delete publish link

Comments

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

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

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

Stskeeps

8994 ●62 ●67 ●71

http://twitter.com/stskee...

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

fk_lx

10250 ●49 ●66 ●65

http://twitter.com/fk_lx

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

Comments

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 +0300 )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 +0300 )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 +0300 )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 +0300 )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 +0300 )edit

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.

edit flag offensive delete publish link

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

edit flag offensive delete publish link

12next page »

Co-creation leading to co-development?

Comments

12 Answers

Comments

Comments

Comments

Comments

Comments

Comments

Comments

Question tools

Stats

Related questions

Co-creation leading to co-development?

Comments

12 Answers

Comments

Comments

Comments

Comments

Comments

Comments

Comments

Question tools

Public thread

Stats

Related questions