Re: [Wikimedia-l] Using non-free elements vs our values (Apple Maps vs Wikipedia iOS app)

[Gergő Tisza]

On Tue, Mar 21, 2017 at 7:22 AM, Dan Garry  wrote:

> The size of your app can significantly reduce downloads [1].
> [1]: https://segment.com/blog/mobile-app-size-effect-on-downloads/


That article seems super sketchy. They took a 3MB app, increased it to
100MB+, and interpolated the retention changes linearly. They even point
out that the drop in installs was mostly due to negative reviews (since
they reverted the app size and the installs didn't climb back up) and the
reviews were mostly along the line of "WTF is this simple calculator app a
hundred megabytes?".

The Wikipedia app is 39MB and the SDK seems to add one MB per [2] which
does not sound like a big deal.

[2] https://www.mapbox.com/blog/mapbox-mobile-polylines/
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Using non-free elements vs our values (Apple Maps vs Wikipedia iOS app)

[Rogol Domedonfors]

Dan,

On Tue, Mar 21, 2017 at 6:24 PM, you wrote:

>
> Please do not twist my words. I said technical considerations are relevant,
> not that customer needs do not come first. If something is incredibly
> difficult to do, that is factored in to prioritisation, alongside the size
> of the audience and expected impact. That is very basic product management.
>
> Sadly, as is typical with this mailing list, we've now delved into a world
> of hypotheticals, idealisms, and misrepresentations. It would not be a
> productive use of time (and, indeed, donor money) for me to participate
> further in this thread.


That is unfortunate.  I had been hoping to hear an answer to the very
concrete question of why this issue is being raised with the community only
after so much work has been done, rather than before.  I would have thought
that very basic product management would have involved engaging with the
user community at the planning stage, and determining the customer needs of
which you write.  Indeed, I raised that point here ten days ago.  But it
seems that it will have to go unanswered.

"Rogol"
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Using non-free elements vs our values (Apple Maps vs Wikipedia iOS app)

[Strainu]

În 21 martie 2017 20:24:49 EET, Dan Garry  a scris:
>On 21 March 2017 at 18:02, Strainu  wrote:
>
>> 2017-03-21 18:17 GMT+02:00 Dan Garry :
>> > On 21 March 2017 at 14:34, Gerard Meijssen
>
>> > wrote:
>> >>
>> >> Technical considerations are imho less relevant. What trumps it is
>> >> functionality.
>> >
>> >
>> > Technical considerations are very relevant if one is doing
>something
>> > technical, for example developing an iOS app or a maps tile
>service.
>>
>>
>> I wholeheartedly disagree. OSS projects often forget that the
>customer
>> should come first, mostly because of lack of funding. But since WMF's
>> software development is a secondary activity (and a very well funded
>> one IMO), it should not make the same mistake. Spreading free
>> knowledge must come first, technical considerations second.
>>
>
>Please do not twist my words. 

I don't see how is that twisting your words. Gerard said that technical 
considerations should be secondary to functionality and you implied that was 
not possible without explaining why. 

>I said technical considerations are
>relevant,
>not that customer needs do not come first. If something is incredibly
>difficult to do, that is factored in to prioritisation, alongside the
>size
>of the audience and expected impact. That is very basic product
>management.

The wording in the wiki page does not suggest an "incredibly difficult" 
technological issue, but more of a political issue (WMF's mapping efforts are 
in maintenance) and the possibility of minor extra costs for the users (with 
the possibility of improvement over Apple maps clearly listed). That makes this 
list the best place to discuss such issues due to the large and diverse 
audience. 

Strainu 

>
>Sadly, as is typical with this mailing list, we've now delved into a
>world
>of hypotheticals, idealisms, and misrepresentations. It would not be a
>productive use of time (and, indeed, donor money) for me to participate
>further in this thread.
>
>Dan
>
>-- 
>Dan Garry
>Lead Product Manager, Discovery
>Wikimedia Foundation
>___
>Wikimedia-l mailing list, guidelines at:
>https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
>https://meta.wikimedia.org/wiki/Wikimedia-l
>New messages to: Wikimedia-l@lists.wikimedia.org
>Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Communicating plans and consultations

[Pine W]

Hi Chris,

Thanks for the comments. Would you and Edward be willing to meet with me
(and anyone else who might be interested, such as Lodewijk as well as
someone from WMF Communications) to discuss the current situation and
brainstorm ideas about how to improve it? We could set up a meeting
off-list. Anyone else who wants to participate would be welcome to email
me/us privately to be included in the meeting. After we meet we can come
back to this list with our notes from the meeting and suggestions for
future actions, possibly including a survey and/or consultation about mass
communications and information management.

In terms of scheduling, the earliest that I can realistically schedule a
meeting is in April, so we might be looking at May or June for the
timeframe in which we might come back to this list with notes about future
directions.

Thanks,

Pine


On Mon, Mar 20, 2017 at 1:58 PM, Chris "Jethro" Schilling <
cschill...@wikimedia.org> wrote:

> Hey Pine,
>
> Had to laugh a little bit about a consultation about consultations, but I
> understand the rationale for it.  Your point is well taken that information
> management is important to think about when there is much going on.
>
> I think the community notification calendar
> 
> that Gergő has mentioned above is a good place to start thinking about
> improvements of managing information.  Anecdotally, some of the issues I
> have seen and heard about are:
>
> * having to follow mailing lists that are too active (like this one),
> * having to follow too many disparate mailing lists,
> * getting pinged too many times from user talk page messages sent through
> Special:MassMessage.
> * Too many consultations focused on overlapping audiences
>
> A centralized calendar can help mitigate some of these issues.  In
> general, the calendar has been used for planning and scheduling purposes,
> but I like the idea of making it more usable to for folks wanting to know
> what consultations are happening.  Lodewijk recently suggested to me that
> some filters and other descriptors (e.g. country, projects targeted) will
> be needed to help users see what is relevant to them.  Building those
> components is one technical challenge, and would be making sure the
> calendar gets used by the relevant consultation audience is another.  We
> would need to think about how to inform people about the calendar without
> also falling back to doing more announcements on the usual channels a la
> "Hey, this new consultation is on the calendar."
>
> One issue I don't have a good answer for right now is how we can solve the
> problem of having too many announcement channels while also being confident
> that when a consultation is announced (by anyone) in some set of approved
> channels, can they expect to get sufficient and representative
> participation?  That might be something we can figure out in a survey about
> consultations generally as you've suggested.
>
> - Chris
>
> Chris "Jethro" Schilling
> I JethroBT (WMF) 
> Community Organizer, Wikimedia Foundation
> 
>
> On Mon, Mar 20, 2017 at 1:40 AM, Pine W  wrote:
>
>> Attempting to summon Chris Schilling over here from the other thread. (:
>>
>> I think that some kind of analysis about optimal use of consultations and
>> surveys would be beneficial, and I'd welcome seeing something like that in
>> the next Annual Plan. Perhaps there might even be a consultation or survey
>> about consultations or surveys, which I know sounds ironic but may be
>> helpful in figuring out how much is too much or too little, timing,
>> locations, etc.
>>
>> Information management is a big deal. We have watchlists, email, social
>> media channels, Echo, and lots of other tools, but even so -- or perhaps
>> because -- there are so many channels, it's easy to drown. I imagine that
>> holds true for both staff and community members, and I'd welcome some
>> initiatives to improve the situation. Perhaps someone will have some ideas
>> that they can submit to IdeaLab.
>>
>> Pine
>>
>>
>>
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Using non-free elements vs our values (Apple Maps vs Wikipedia iOS app)

[Leila Zia]

On Tue, Mar 21, 2017 at 11:24 AM, Dan Garry  wrote:

>
> Sadly, as is typical with this mailing list, we've now delved into a world
> of hypotheticals, idealisms, and misrepresentations. It would not be a
> productive use of time (and, indeed, donor money) for me to participate
> further in this thread.
>

​Without manually labeling all the comments made on this thread and by
quickly going over it again: What I see is that most of the comments on
this thread are not hypothetical. They are idealistic, but that's the
nature of the work we do (Building Wikimedia projects is idealistic at its
core.). If one conversation doesn't go where you want it to go, please
don't give up on the whole thread. There are many good points raised across
this thread. What's being discussed here is very important.

And of course, I respect how you want to spend your staff time and what you
think is the best use of your time. :)

Best,
Leila​



>
> Dan
>
> --
> Dan Garry
> Lead Product Manager, Discovery
> Wikimedia Foundation
> ___
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Using non-free elements vs our values (Apple Maps vs Wikipedia iOS app)

[Dan Garry]

On 21 March 2017 at 18:02, Strainu  wrote:

> 2017-03-21 18:17 GMT+02:00 Dan Garry :
> > On 21 March 2017 at 14:34, Gerard Meijssen 
> > wrote:
> >>
> >> Technical considerations are imho less relevant. What trumps it is
> >> functionality.
> >
> >
> > Technical considerations are very relevant if one is doing something
> > technical, for example developing an iOS app or a maps tile service.
>
>
> I wholeheartedly disagree. OSS projects often forget that the customer
> should come first, mostly because of lack of funding. But since WMF's
> software development is a secondary activity (and a very well funded
> one IMO), it should not make the same mistake. Spreading free
> knowledge must come first, technical considerations second.
>

Please do not twist my words. I said technical considerations are relevant,
not that customer needs do not come first. If something is incredibly
difficult to do, that is factored in to prioritisation, alongside the size
of the audience and expected impact. That is very basic product management.

Sadly, as is typical with this mailing list, we've now delved into a world
of hypotheticals, idealisms, and misrepresentations. It would not be a
productive use of time (and, indeed, donor money) for me to participate
further in this thread.

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Using non-free elements vs our values (Apple Maps vs Wikipedia iOS app)

[Strainu]

2017-03-21 18:17 GMT+02:00 Dan Garry :
> On 21 March 2017 at 14:34, Gerard Meijssen 
> wrote:
>>
>> Technical considerations are imho less relevant. What trumps it is
>> functionality.
>
>
> Technical considerations are very relevant if one is doing something
> technical, for example developing an iOS app or a maps tile service.


I wholeheartedly disagree. OSS projects often forget that the customer
should come first, mostly because of lack of funding. But since WMF's
software development is a secondary activity (and a very well funded
one IMO), it should not make the same mistake. Spreading free
knowledge must come first, technical considerations second.

Strainu

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Using non-free elements vs our values (Apple Maps vs Wikipedia iOS app)

[Gerard Meijssen]

Hoi,
Apple maps do not provide the same maps (not as up to date) as OSM does for
a country like Haiti. That has nothing to do with "ignoring technical
difficulties" but has everything to do with the quality of the service
provided.

When you consider that work IS done on historic maps in an OSM context it
is again you ignoring functionality that you do no offer. The excuse that
"it is not on the cards" is one from your perspective; one where functional
expectations apparently do not have value.
Thanks,
 GerardM

On 21 March 2017 at 17:17, Dan Garry  wrote:

> On 21 March 2017 at 14:34, Gerard Meijssen 
> wrote:
> >
> > Technical considerations are imho less relevant. What trumps it is
> > functionality.
>
>
> Technical considerations are very relevant if one is doing something
> technical, for example developing an iOS app or a maps tile service.
>
>
> > Our maps have to be good everywhere and as far as I know OSM
> > is superior in places where there is profit to be made from maps.
>
>
> If you choose to ignore the technical difficulties and half of my earlier
> email, then yes, that may be true.
>
>
> > Current maps world wide and historical maps are what we need. How would
> you
> > use the Apple maps for a map of the Ottoman empire?
> >
>
> Given that our maps service does not support this, and will not any time
> soon, this is very off-topic.
>
> Dan
>
> --
> Dan Garry
> Lead Product Manager, Discovery
> Wikimedia Foundation
> ___
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Using non-free elements vs our values (Apple Maps vs Wikipedia iOS app)

[John]

As a programmer myself I understand that free vs non-free causes more work
for you. However you cannot ignore one of the foundations of the wikimedia
movement because it makes a little more work for you. I honestly don't
understand why you thought that Apple maps would be acceptable at all. You
have both a breach of our privacy policy and a violation of our free
software enforcement policy. Yes using OSM adds work and increases the
download size, but is a valid option. If OSM or other free software wasn't
possible then we might consider non-free  alternatives but that's not the
case.


On Tue, Mar 21, 2017 at 12:18 PM Dan Garry  wrote:

> On 21 March 2017 at 14:34, Gerard Meijssen 
> wrote:
> >
> > Technical considerations are imho less relevant. What trumps it is
> > functionality.
>
>
> Technical considerations are very relevant if one is doing something
> technical, for example developing an iOS app or a maps tile service.
>
>
> > Our maps have to be good everywhere and as far as I know OSM
> > is superior in places where there is profit to be made from maps.
>
>
> If you choose to ignore the technical difficulties and half of my earlier
> email, then yes, that may be true.
>
>
> > Current maps world wide and historical maps are what we need. How would
> you
> > use the Apple maps for a map of the Ottoman empire?
> >
>
> Given that our maps service does not support this, and will not any time
> soon, this is very off-topic.
>
> Dan
>
> --
> Dan Garry
> Lead Product Manager, Discovery
> Wikimedia Foundation
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Using non-free elements vs our values (Apple Maps vs Wikipedia iOS app)

[Dan Garry]

On 21 March 2017 at 14:32, John  wrote:

> This reminds me of en wiki's non-free policy.
> https://en.wikipedia.org/wiki/Wikipedia:Non-free_content_criteria#1
> highlights the point fairly clearly Usage of non-free materials is often
> easier and higher quality than using the free equivalent . However
> Wikimedia's mission and goal's are to support and promote free content, yes
> you will need to jump thru a few more hoops and adds a little more work.
> But without those driving factors we will often see the free options wither
> and fail.


In general I do not think attempting to apply English Wikipedia policies to
product development is particularly meaningful, given that writing an
online encyclopaedia is very different from developing software.
Regardless, I do not think there is anyone opposed to this ideological
statement, but as I have explained in my email, ideology and reality
sometimes come in to conflict.

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Using non-free elements vs our values (Apple Maps vs Wikipedia iOS app)

[Dan Garry]

On 21 March 2017 at 14:34, Gerard Meijssen 
wrote:
>
> Technical considerations are imho less relevant. What trumps it is
> functionality.


Technical considerations are very relevant if one is doing something
technical, for example developing an iOS app or a maps tile service.


> Our maps have to be good everywhere and as far as I know OSM
> is superior in places where there is profit to be made from maps.


If you choose to ignore the technical difficulties and half of my earlier
email, then yes, that may be true.


> Current maps world wide and historical maps are what we need. How would you
> use the Apple maps for a map of the Ottoman empire?
>

Given that our maps service does not support this, and will not any time
soon, this is very off-topic.

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Using non-free elements vs our values (Apple Maps vs Wikipedia iOS app)

[Gerard Meijssen]

Hoi,
Technical considerations are imho less relevant. What trumps it is
functionality. Our maps have to be good everywhere and as far as I know OSM
is superior in places where there is profit to be made from maps.

Current maps world wide and historical maps are what we need. How would you
use the Apple maps for a map of the Ottoman empire?
Thanks,
  GerardM

On 21 March 2017 at 15:22, Dan Garry  wrote:

> Hey Magnus,
>
> There are a few other factors to consider in addition to those listed. For
> example, development cost. Our maps tile service is not compatible with the
> iOS app out of the box. This isn't surprising; Apple wants you to use
> things like Apple Maps rather than your own solution. Android is, by its
> nature, a more open platform, so I am not too surprised that it was easier
> to integrate our tile server into the Android app than the iOS app. Sadly,
> it's not as simple as just switching over to OSM-based tiles; on the
> contrary, it's a significant amount of work.
>
> Now, using our tile service would also have required the iOS app to use the
> MapBox SDK. This is the size of all their other third party libraries
> combined, significantly increasing app download size. The size of your app
> can significantly reduce downloads [1]. Switch a single feature over to a
> different set of map tiles, and possibly decreasing downloads of the app,
> seems like a dangerous and counterintuitive tradeoff to me.
>
> So the question is, given all this, is switching over the nearby feature to
> use OSM-based tiles instead of Apple Maps worth it? In the long run, if
> these problems could be solved, I'd say it absolutely is worth it. But, in
> the short term, the work would take significant time and effort, and could
> actually decrease app usage by decreasing the app download rate; that
> tradeoff doesn't seem worth it to me.
>
> Thanks,
> Dan
>
> Disclaimers: These are my opinions only. I worked on the apps in the past,
> but haven't for two years; my statements about development costs may be
> wrong, and the apps folks may well disagree with me about things. I work in
> the department responsible for Wikimedia maps, but have only worked on the
> team working on maps for a couple of months.
>
> [1]: https://segment.com/blog/mobile-app-size-effect-on-downloads/
>
> On 15 March 2017 at 09:25, Magnus Manske 
> wrote:
>
> > Hi Josh, all,
> >
> > I am not one hell-bent on "FOSS or death"; I tend to use whatever works
> > best.
> >
> > That said, the cost-benefit analysis of using Apple Maps seems to boil
> > down:
> > * Apple Maps has slightly better rendering (didn't check, but I assume)
> > * Apple Maps uses less mobile bandwidth
> > * Apple Maps is not free (as in freedom)
> >
> > Now, looking at these points:
> >
> > * Somewhat better quality is not an argument. If it were, we would have
> > stayed with Britannica, and skipped that whole Wikipedia nonsense.
> > Wikipedia became better, in part, because people actually used it, saw
> the
> > issues, and fixed them. And OSM rendering might be not quite en par with
> > Apple Maps, it is quite usable, in my experience.
> >
> > * Less bandwidth usage is not an argument either. I doubt we are talking
> > about a significant percentage of an average users' data volume here. If
> > Android users can afford the bandwidth, so can people who buy an iPhone
> > (source: used to have iPhone).
> >
> > * The price tag is the "non-freedom". As far as I can tell, this would be
> > the very first Wikimedia "product" that incorporates non-free technology
> > and data. It sets a precedence. It also has the potential to poison the
> > otherwise great relations between the Wikipedia, Wikidata, and OSM
> > community. It says "OSM is not good enough (at least for Apple users)"
> > quite plainly. How would we feel if OSM started to remove Wikidata tags
> and
> > replace them with Britannica links?
> >
> > All in all, IMHO, the cost is too high for the (at best) flimsy benefits.
> >
> > Cheers,
> > Magnus
> >
> >
> > On Wed, Mar 15, 2017 at 12:52 AM Joshua Minor 
> > wrote:
> >
> > > Hello,
> > >
> > > My name is Josh Minor, and I am the Product Manager for the Wikipedia
> iOS
> > > app. I wanted to speak to a couple specific issues and
> misunderstandings
> > > raised by this email thread.
> > >
> > > First, please take a look at
> > > https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service
> > which
> > > provides some background on this decision. Jonatan linked to it, and it
> > > covers several of the concerns raised on the thread and gives our
> > > reasoning. I'd also suggest subscribing to this ticket:
> > > https://phabricator.wikimedia.org/T157763 which Jonatan filed, and
> where
> > > you can track efforts and issues with replacement maps.
> > >
> > > A few clarifying points:
> > >
> > > 1. The Places tab[1], and its use of Apple’s maps tiles, is not part of
> > the
> > > articles or article display, it is a navigational aid to help you find
> > > articl

Re: [Wikimedia-l] Using non-free elements vs our values (Apple Maps vs Wikipedia iOS app)

[John]

This reminds me of en wiki's non-free policy.
https://en.wikipedia.org/wiki/Wikipedia:Non-free_content_criteria#1
highlights the point fairly clearly Usage of non-free materials is often
easier and higher quality than using the free equivalent . However
Wikimedia's mission and goal's are to support and promote free content, yes
you will need to jump thru a few more hoops and adds a little more work.
But without those driving factors we will often see the free options wither
and fail.

On Tue, Mar 21, 2017 at 10:22 AM, Dan Garry  wrote:

> Hey Magnus,
>
> There are a few other factors to consider in addition to those listed. For
> example, development cost. Our maps tile service is not compatible with the
> iOS app out of the box. This isn't surprising; Apple wants you to use
> things like Apple Maps rather than your own solution. Android is, by its
> nature, a more open platform, so I am not too surprised that it was easier
> to integrate our tile server into the Android app than the iOS app. Sadly,
> it's not as simple as just switching over to OSM-based tiles; on the
> contrary, it's a significant amount of work.
>
> Now, using our tile service would also have required the iOS app to use the
> MapBox SDK. This is the size of all their other third party libraries
> combined, significantly increasing app download size. The size of your app
> can significantly reduce downloads [1]. Switch a single feature over to a
> different set of map tiles, and possibly decreasing downloads of the app,
> seems like a dangerous and counterintuitive tradeoff to me.
>
> So the question is, given all this, is switching over the nearby feature to
> use OSM-based tiles instead of Apple Maps worth it? In the long run, if
> these problems could be solved, I'd say it absolutely is worth it. But, in
> the short term, the work would take significant time and effort, and could
> actually decrease app usage by decreasing the app download rate; that
> tradeoff doesn't seem worth it to me.
>
> Thanks,
> Dan
>
> Disclaimers: These are my opinions only. I worked on the apps in the past,
> but haven't for two years; my statements about development costs may be
> wrong, and the apps folks may well disagree with me about things. I work in
> the department responsible for Wikimedia maps, but have only worked on the
> team working on maps for a couple of months.
>
> [1]: https://segment.com/blog/mobile-app-size-effect-on-downloads/
>
> On 15 March 2017 at 09:25, Magnus Manske 
> wrote:
>
> > Hi Josh, all,
> >
> > I am not one hell-bent on "FOSS or death"; I tend to use whatever works
> > best.
> >
> > That said, the cost-benefit analysis of using Apple Maps seems to boil
> > down:
> > * Apple Maps has slightly better rendering (didn't check, but I assume)
> > * Apple Maps uses less mobile bandwidth
> > * Apple Maps is not free (as in freedom)
> >
> > Now, looking at these points:
> >
> > * Somewhat better quality is not an argument. If it were, we would have
> > stayed with Britannica, and skipped that whole Wikipedia nonsense.
> > Wikipedia became better, in part, because people actually used it, saw
> the
> > issues, and fixed them. And OSM rendering might be not quite en par with
> > Apple Maps, it is quite usable, in my experience.
> >
> > * Less bandwidth usage is not an argument either. I doubt we are talking
> > about a significant percentage of an average users' data volume here. If
> > Android users can afford the bandwidth, so can people who buy an iPhone
> > (source: used to have iPhone).
> >
> > * The price tag is the "non-freedom". As far as I can tell, this would be
> > the very first Wikimedia "product" that incorporates non-free technology
> > and data. It sets a precedence. It also has the potential to poison the
> > otherwise great relations between the Wikipedia, Wikidata, and OSM
> > community. It says "OSM is not good enough (at least for Apple users)"
> > quite plainly. How would we feel if OSM started to remove Wikidata tags
> and
> > replace them with Britannica links?
> >
> > All in all, IMHO, the cost is too high for the (at best) flimsy benefits.
> >
> > Cheers,
> > Magnus
> >
> >
> > On Wed, Mar 15, 2017 at 12:52 AM Joshua Minor 
> > wrote:
> >
> > > Hello,
> > >
> > > My name is Josh Minor, and I am the Product Manager for the Wikipedia
> iOS
> > > app. I wanted to speak to a couple specific issues and
> misunderstandings
> > > raised by this email thread.
> > >
> > > First, please take a look at
> > > https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service
> > which
> > > provides some background on this decision. Jonatan linked to it, and it
> > > covers several of the concerns raised on the thread and gives our
> > > reasoning. I'd also suggest subscribing to this ticket:
> > > https://phabricator.wikimedia.org/T157763 which Jonatan filed, and
> where
> > > you can track efforts and issues with replacement maps.
> > >
> > > A few clarifying points:
> > >
> > > 1. The Places tab[1], and its use of A

Re: [Wikimedia-l] Using non-free elements vs our values (Apple Maps vs Wikipedia iOS app)

[Dan Garry]

Hey Magnus,

There are a few other factors to consider in addition to those listed. For
example, development cost. Our maps tile service is not compatible with the
iOS app out of the box. This isn't surprising; Apple wants you to use
things like Apple Maps rather than your own solution. Android is, by its
nature, a more open platform, so I am not too surprised that it was easier
to integrate our tile server into the Android app than the iOS app. Sadly,
it's not as simple as just switching over to OSM-based tiles; on the
contrary, it's a significant amount of work.

Now, using our tile service would also have required the iOS app to use the
MapBox SDK. This is the size of all their other third party libraries
combined, significantly increasing app download size. The size of your app
can significantly reduce downloads [1]. Switch a single feature over to a
different set of map tiles, and possibly decreasing downloads of the app,
seems like a dangerous and counterintuitive tradeoff to me.

So the question is, given all this, is switching over the nearby feature to
use OSM-based tiles instead of Apple Maps worth it? In the long run, if
these problems could be solved, I'd say it absolutely is worth it. But, in
the short term, the work would take significant time and effort, and could
actually decrease app usage by decreasing the app download rate; that
tradeoff doesn't seem worth it to me.

Thanks,
Dan

Disclaimers: These are my opinions only. I worked on the apps in the past,
but haven't for two years; my statements about development costs may be
wrong, and the apps folks may well disagree with me about things. I work in
the department responsible for Wikimedia maps, but have only worked on the
team working on maps for a couple of months.

[1]: https://segment.com/blog/mobile-app-size-effect-on-downloads/

On 15 March 2017 at 09:25, Magnus Manske 
wrote:

> Hi Josh, all,
>
> I am not one hell-bent on "FOSS or death"; I tend to use whatever works
> best.
>
> That said, the cost-benefit analysis of using Apple Maps seems to boil
> down:
> * Apple Maps has slightly better rendering (didn't check, but I assume)
> * Apple Maps uses less mobile bandwidth
> * Apple Maps is not free (as in freedom)
>
> Now, looking at these points:
>
> * Somewhat better quality is not an argument. If it were, we would have
> stayed with Britannica, and skipped that whole Wikipedia nonsense.
> Wikipedia became better, in part, because people actually used it, saw the
> issues, and fixed them. And OSM rendering might be not quite en par with
> Apple Maps, it is quite usable, in my experience.
>
> * Less bandwidth usage is not an argument either. I doubt we are talking
> about a significant percentage of an average users' data volume here. If
> Android users can afford the bandwidth, so can people who buy an iPhone
> (source: used to have iPhone).
>
> * The price tag is the "non-freedom". As far as I can tell, this would be
> the very first Wikimedia "product" that incorporates non-free technology
> and data. It sets a precedence. It also has the potential to poison the
> otherwise great relations between the Wikipedia, Wikidata, and OSM
> community. It says "OSM is not good enough (at least for Apple users)"
> quite plainly. How would we feel if OSM started to remove Wikidata tags and
> replace them with Britannica links?
>
> All in all, IMHO, the cost is too high for the (at best) flimsy benefits.
>
> Cheers,
> Magnus
>
>
> On Wed, Mar 15, 2017 at 12:52 AM Joshua Minor 
> wrote:
>
> > Hello,
> >
> > My name is Josh Minor, and I am the Product Manager for the Wikipedia iOS
> > app. I wanted to speak to a couple specific issues and misunderstandings
> > raised by this email thread.
> >
> > First, please take a look at
> > https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service
> which
> > provides some background on this decision. Jonatan linked to it, and it
> > covers several of the concerns raised on the thread and gives our
> > reasoning. I'd also suggest subscribing to this ticket:
> > https://phabricator.wikimedia.org/T157763 which Jonatan filed, and where
> > you can track efforts and issues with replacement maps.
> >
> > A few clarifying points:
> >
> > 1. The Places tab[1], and its use of Apple’s maps tiles, is not part of
> the
> > articles or article display, it is a navigational aid to help you find
> > articles. This doesn’t mean it’s exempt from considerations raised here,
> > but just want to clarify that this is not about editor created maps in
> > projects, but rather an app-specific discovery mechanism.
> >
> > 2. The feature doesn’t violate our privacy policy[2] and was reviewed by
> > Wikimedia Foundation's Legal department before entering beta. The App’s
> > access to the users’ geolocation to recommend nearby articles, with the
> > users’ explicit consent, is already part of both apps. The new feature
> > merely adds a different way to visually view nearby articles - the user
> > must, as before, still p