[SailfishDevel] Nemo MW to Mer

[Filip Kłębczyk]

W dniu 06.04.2014 09:57, Bernd Wachter pisze:
>
> Filip Kłębczyk <fklebczyk at gmail.com> writes:
>
>>>> 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.
>>>
>>> I find it hard to correlate that with "lets talk about being more open". Lets
>>> not pre-judge.
>>
>> No one is pre-judging - my reaction was to Thomas Perl statement:
>> "alternative would be to have a private/downstream fork of Mer/Nemo
>> and not contribute to Mer/Nemo - would that be better?"
>>
>> So it sounded like we have two choices, accepting status quo (Jolla
>> maintainership/ownership/domination or however the current state can
>> be called) or that Jolla will abandon supporting open mer/nemo
>> (creating private fork).
>
> Mer was designed to allow private forking from the beginning.

I think you misunderstood me. There is nothing wrong with private 
forking - everybody does it, that's how open source works. I only didn't 
like the statement that sounded like a choice between keeping status quo 
(NemoMW taken over by Jolla with questionable collaboration quality like 
it is nowadays) and alternative that Jolla completely ends to support 
Mer/Nemo. It sounded a bit like a strong warning (accept this or else!).

> If you look at changelogs of packages on the device you'll notice that
> _all_ Jolla internal packages contain JB#xxx bug references, while
> almost none of the Nemo or Mer packages have those[3]. That's because we
> think it's wrong to reference a private bugtracker in a public git
> repository, and we have a policy that you should not do that. The few
> ones you see are either in HW adaptation related projects, or the
> developer made a mistake.

What I've seen wasn't for sure in hardware adaption part and yes it was 
seen on Github, not in the package changelog.
The problem is that when average person encounters that (in a project he 
is potentially interested) he instantly asks himself - what the hell is 
that #JB? In result it's very hard to contribute/engage to open source 
parts that have such comments, because you instantly get a feeling that 
there is some closed roadmap/list of issues to address/features to 
implement that you don't have access to (when approaching such open 
source part or subproject). It's a bit like you would play a poker and 
the opponents knows what cards are on stack and you don't. I bet you 
wouldn't be satisfied to play such game and especially betting money in 
it (hint: think that currency here is time/engagement).

>
> Now we start having the resources, so to improve our _internal_ release
> process we need start making use of the public bugzilla again, and make
> the public release process better.

That's very good to hear!

> We admittedly mostly took over
> Nemo MW -- just because for a long time we were the only ones doing
> something.

I think that's "we were the only" is an overstatement. I remember for 
example that Venemo contributed to lipstick and he is not a Jolla employee.
For example I also wanted to engage myself last summer in Nemo MW, but 
when I've seen Nemo MW became a code (pull request) dump with no public 
roadmap I've realized it will be very hard (not impossible, but very 
hard) to engage in sth like that.

> It's still run in a way enabling things like building of
> Glacier UI,

Glacier UI is something where open collaboration works.

> though, but basically the whole "keep Nemo running on
> community OBS" is overhead for us without us benefitting from it at the
> moment. We're just doing it because it should be done like this[2].

Well I wouldn't call it "overhead", the more appropriate term in my 
opinion would be a "fair trade" - it gives you right to tell that 
SailfishOS is mostly open source and that Jolla contributes back to open 
source Nemo MW. In terms of marketing and attracting people it has a big 
value, that shouldn't be underestimated - otherwise Sailfish would be 
yet another mobile OS.

Regards,
Filip