[SailfishDevel] Nemo MW to Mer

[Filip Kłębczyk]

W dniu 05.04.2014 11:41, Thomas Perl pisze:
> Personally, I see it more like “claiming maintainership”, if anything
> - maintaining a set of well-maintained and packaged middleware
> components in Mer that other projects can decide to use or not (the
> alternative would be to have a private/downstream fork of Mer/Nemo
> and not contribute to Mer/Nemo - would that be better?).

Isn't there a private fork of Mer/Nemo in Jolla already?
Sorry, but this sounds like, either it will be "our" (Jolla way) or we 
are taking toys and are going to different closed sandbox to play. But 
then why claiming with big letters "truly open" on jolla.com website? 
Jolla told us lot about openess, collaborating in the open, doing 
together etc. and partly thanks to that they've received a lot of 
support and credit from OSS community in terms of spreading the word 
about Jolla, doing talks, installfests etc. before and after product 
release. In my opinion Jolla should have in mind that OSS community 
treated that words entirely seriously, not as an empty sets of marketing 
slogans.

> My personal MW turf for example is SDL 2 and Python 3 at the moment,
> both of which are currently in SFOS Nemo Middleware. Pushing those
> (very generic, even non-mobile-related) middleware components from
> Jolla’s Nemo Middleware or non-Jolla Nemo Middleware to Mer means
> that Mer will have those two properly maintained middleware bits /in
> its repos/ instead of in some vendor-specific downstream distribution
> (and not available in Mer at all, or unmaintained in Mer, etc..).

It all sounds great from practical point of view, but the real problem 
is how things are pushed to Mer/Nemo without any discussion. Where was 
discussion about including PyOtherside in Nemo for example? For sure not 
in public but behind company doors someone gave green light. Did 
community or other vendors were involved? Nope. (for example alternative 
approach could be porting PySide to Qt5 or adopting PyQt).
If people don't feel they have any influence how things are added, they 
don't want to contribute and they don't want to get involved. Simple as 
that. PyOtherside is just one small example, but there are numerous 
examples of other packages dropped by Jolla employees into Nemo out of 
the blue. Sure someone can say that Jolla does the most for Nemo, so 
they don't need to ask or consult with anyone, but then why talking 
about openess (vs. decisions behind closed doors) and community.
>
> Other vendors and projects can still choose to not install or pull in
> those middleware packages (or provide their own versions of it), but
> more packages being available (and maintained!) in Mer instead of
> only in a vendor-specific Mer snapshot/“fork” is a good thing?

That's all under condition that there will be any other vendors. If 
Mer/Nemo will be totally controlled by one company in a closed way, 
don't expect any other vendors to engage in anything.

> “Vendor-neutral” sounds nice in theory,

I completely disagree.

> but in practice even in Mer
> right now, there are certain “vendor-specific” decisions made (the
> Linux kernel, systemd, glibc, zypp, RPM, Qt, to name just a few) that
> favor one project over others

Sure, but that was part of Meego heritage and the fact Mer+Nemo was 
Meego based. But the future development of the project should be 
discussed in the open.

Most importantly I think this whole discussion whether to merge Mer and 
Nemo shouldn't take place here, but on Mer mailing list. It's like 
talking about sth that affects people, but not inviting them.

I also think that modularity, openness, clear decision making process 
and inclusion gives chances for getting more parties involved in Mer.

Regards,
Filip

PS. How to get involved in development of PyOtherside? No, I'm not 
talking about writing apps based on it, but in the PyOtherside itself. 
Is there any roadmap or things to do list already somewhere?