Hoi,
Selling infrastructure is not cheap. The organisations that buy this
service need a service level agreement. They require this service to be
always on. This means that we need at least three times the number of
hardware. One for development and at least two for production. This will
need some staffing that has this as its priority.
No, this is not cheap
Compare it with Labs. It has several people working for it, its reliability
has improved over time but it is nowhere close to what a commercial service
would be.
Thanks,
GerardM
On 18 January 2016 at 06:41, rupert THURNER <rupert.thurner(a)gmail.com>
wrote:
lol, "suggest commercial income" seems to be
revolving every 7-8 years in
our movement. when wikipedia was founded in 2001 larry sanger tried to sell
something (ads), when sue gardner joined she tried to sell something in
2008 (kul was doing business development at the time), and now lila
tretikov again tries to sell something. this did not work in the past and
will not work now. the reason is simple: providing infrastructure is cheap
compared to the rest of what WMF does, and it anyway is the main motivation
for people to give money to WMF. if you sell providing infrastructure to
businesses you risk a direct and hard effect in donation income. of course
you can disguise it through intransparency, various licensing models, etc.
the problem is always the same imo. people who do not edit fail to
understand why people edit, and why they stop doing so. they tend to fail
to understand what else editing folks would contribute. this leads to
mis-representing "growth" in number of employees, or yearly budget, and
trials to directly influence income. it leads to trials that consuming
contents is only good through a WMF owned domain. thoughts like "what data
do we not provide", "what group of persons do we not address well",
"how
can the data be structured so more can be made out of it", "how many
persons do we reach direct or indirect" are not so common. are we a website
operator or a free content provider? i always have to cry when i read
another version of the strategy missing out there.
at times, the search for strategy and what to measure reminds me on an old
east frisian joke:
a drunken frisian searches a key looking around a street lamp. a passerby
helps him. after an hour the passerby asks: are you sure you lost the key
here? the frisian says: no, i lost it back there. but here is the only
place where is light.
best
rupert
On Sun, Jan 17, 2016 at 4:41 PM, Adam Wight <adam.m.wight(a)gmail.com>
wrote:
Charging Google for computing power is a Quixotic
business model.
For comparison, Google's own approach to this same problem, when the N$A
wants to run so many ongoing searches that it would vaporize a little
section of the Columbia River, is to lease a search appliance cluster to
the agencies in question.[1]
We could easily take the same approach, providing a near-realtime feed of
dumps and a basic appliance which can render pages and provide API
endpoints. If the reduced bandwidth needs and better control over the
process isn't enough to incentivize our biggest customers, we could give
them extra encouragement by throttling direct access to our services.
Breaking even would be a nice target either way, it seems like any
"monetization" of access is at best just a charitable subsidy in
disguise,
and not a long-term win.
[1]
https://en.wikipedia.org/wiki/Google_Search_Appliance
https://support.google.com/earthenterprise/?hl=en#topic=2802998
Speculation on why GEE was recently deprecated, lessons we might learn:
http://geospatialworld.net/Professional/ViewBlog.aspx?id=415
Adam Wight
mw:user:adamw
On Jan 16, 2016 6:12 PM, "Denny Vrandecic" <dvrandecic(a)wikimedia.org>
wrote:
I find it rather surprising, but I very much find
myself in agreement
with
most what Andreas Kolbe said on this thread.
To give a bit more thoughts: I am not terribly worried about current
crawlers. But currently, and more in the future, I expect us to provide
more complex and this expensive APIs: a SPARQL endpoint, parsing APIs,
etc.
These will be simply expensive to operate. Not
for infrequent users -
say,
> to the benefit of us 70,000 editors - but for use cases that involve
tens
or
millions of requests per day. These have the potential of burning a
lot
of funds to basically support the operations of
commercial companies
whose
mission might or might not be aligned with our.
Is monetizing such use cases really entirely unthinkable? Even under
restrictions like the ones suggested by Andreas, or other such
restrictions
> we should discuss?
> On Jan 16, 2016 3:49 PM, "Risker" <risker.wp(a)gmail.com> wrote:
>
> > Hmm. The majority of those crawlers are from search engines - the
very
>
search engines that keep us in the top 10 of their results (and often
in
the top
3), thus leading to the usage and donations that we need to
survive. If they have to pay, then they might prefer to change their
algorithm, or reduce the frequency of scraping (thus also failing to
catch
updates to articles including removal of
vandalism in the lead
paragraphs,
> which is historically one of the key reasons for frequently crawling
the
> > same articles). Those crawlers are what attracts people to our
sites,
to
> > read, to make donations, to possibly edit. Of course there are
lesser
> > crawlers, but they're not really
big players.
> >
> > I'm at a loss to understand why the Wikimedia Foundation should take
on
> the
> > costs and indemnities associated with hiring staff to create a
for-pay
API
> that would have to meet the expectations of a customer (or more than
one
> customer) that hasn't even agreed to pay
for access. If they want a
> specialized API (and we've been given no evidence that they do), let
THEM
> hire the staff, pay them, write the code in
an appropriately
open-source
> way, and donate it to the WMF with the
understanding that it could be
> modified as required, and that it will be accessible to everyone.
>
> It is good that the WMF has studied the usage patterns. Could a link
be
> given to the report, please? It's
public, correct? This is exactly
the
point of
transparency. If only the WMF has the information, then it
gives
> an excuse for the community's comments to be ignored "because they
don't
> > know the facts". So let's lay out all the facts on the table,
please.
> >
> > Risker/Anne
> >
> >
> >
> > On 16 January 2016 at 15:06, Vituzzu <vituzzu.wiki(a)gmail.com> wrote:
> >
> > > Thank you for sharing this but, above all, to focus on digging real
> data.
> > >
> > > IMHO we shouldn't forget our mission, so licenses must be as free
as
> >
possible. Turning into something "more closed" would definitely
deplete
> one
> > of the most valuable source (the open source world) of volunteering
we
> have.
> >
> > Crawlers' owner should definitely share our increasing expenses but
any
> > > kind of agreement with them should include ways to improve our
> userbase.
> > > I'm wondering about an agreement with Google (or any other player)
to
> add
> > > an "edit" button to knowledge graph. Sort of a "knowledge
vs.
users"
> > > agreement.
> > >
> > > So, we definitely need a long term strategy which the Foundation
will
> pursue in *negotiating* with anyone who wants a
big scale access to
*our
> resources* (while access to our knowledge
will have no limits, as
usual).
> >
> > Vito
> >
> >
> > Il 16/01/2016 19:21, Lila Tretikov ha scritto:
> >
> >> To share some context of the discussion the board had around this
--
I
> > >> don't think the minutes give enough detail. APIs -- as we are
freely
> and
> > >> rapidly creating them today are important, but are not quite at
the
> core
> > >> of
> > >> the issue we are facing.
> > >>
> > >> Today Wikimedia is the largest internet channel for open free
> knowledge
> > in
> > >> the world. But the trends are against us. We have to face them
> together.
> > >> We
> > >> have to have the answers on how. The strategic discussion next
week
will
> >> help guide us.
> >>
> >> Over the last year we looked at the trends in Wikimedia traffic,
> internet
> >> as a whole and user behaviors. It took a lot of research. When we
> started
> >> the process we have not had solid internal data about unique
visitors
> or
> > >> human vs. crawler usage on the site. For a top 10 website this is
a
> big
> > >> issue; it hurts our ability to make smart decisions. We've
learned a
> > lot.
> > >>
> > >> We found data that supports Leigh's point -- our permissive
license
>
>> supports our core value, we are (I know I am) here for free
knowledge.
> Yet
> >> it allows others to use the content in ways that truncates,
simplifies
> and
> >> reduces it. More importantly this type of reuse separates our
readers
> > from
> > >> our site, disconnecting readers from our contributors (no edit
> buttons)
> > >> and
> > >> ultimately reduces traffic. Is this a problem? I'd like to hear
if
> > people
> > >> on this list see it as such. And how we sustain contributions over
> time.
> > >>
> > >> Meanwhile estimated half of our hosting is used to support
crawlers
that
>> scan our content. This has an associated
cost in infrastructure,
power,
> >> servers, employees to support some well-funded organizations. The
> content
> >> is used for a variety of commercial purposes, sometimes having
nothing
to
>> do with putting our contributor's work in front of more readers.
Still,
> we
> >> can say this is tangentially supportive of our mission.
> >>
> >> As these two trends increase without our intervention, our traffic
> decline
> >> will accelerate, our ability to grow editors, content and cover
costs
> will
> >> decline as well.
> >>
> >> The first question on the upcoming consultation next week will be
> squarely
> >> on this. Please help us. API conversation is a consequence of this
> >> challenge. If we were to build more for reuse: APIs are a good way
to
> do
> > >> so. If we are to somehow incentivize users of SIri to come back to
> > >> Wikipedia, what would we need to do? Should we improve our site so
> more
> > >> people come to us directly as the first stop? How do we bring
people
> > into
> > >> our world vs. the world of commercial knowledge out there? How do
we
fund
>> this if the people moved to access our content through other
interfaces
(a
>> trend that has been accelerating)?
>>
>> Those are the core questions we need to face. We will have to have
some
> >> uncomfortable, honest discussions as we test our hypothesis this
year.
The
>> conversation next week is a good start to prioritize those. Please
join
> >> it.
> >>
> >> Lila
> >>
> >>
> >>
> >> On Sat, Jan 16, 2016 at 6:11 AM, Leigh Thelmadatter <
> osamadre(a)hotmail.com
> >> >
> >> wrote:
> >>
> >> If we are concerned about Google taking unfair advantage of
Wikipedia,
> > one
> > >>> simple solution is to allow content donations with a
non-commercial
>
>>> restriction. Right now, the concept of "free" include commercial
use.
> > An
> > >>> added bonus to this is that we would get a lot more institutional
> > >>> donations
> > >>> of content if we allowed an non-commercial option.
> > >>> My problem with allowing for paying for "premium access"
is that
we
are
>>> allowing Google to have a
priviledged position. There is no way
around
> >>> that.
> >>> What is the impetus behind this proposal? Its not like we are
lacking
> > >>> money. And limiting growth of the Foundation is not a bad
thing...
> at
> > >>> least not to the community.
> > >>>
> > >>>
> > >>> To: wikimedia-l(a)lists.wikimedia.org
> > >>>> From: ricordisamoa(a)openmailbox.org
> > >>>> Date: Sat, 16 Jan 2016 14:13:06 +0100
> > >>>> Subject: Re: [Wikimedia-l] Monetizing Wikimedia APIs
> > >>>>
> > >>>> "Imagine a world in which every single human being can
freemiumly
> > share
> > >>>> in the sum of all knowledge." XD
> > >>>>
> > >>>> Il 16/01/2016 10:23, Pete Forsyth ha scritto:
> > >>>>
> > >>>>> I'm interested to hear some perspectives on the
following line
of
>
>>>>>
> >>>> thinking:
> >>>
> >>>> Lisa presented some alternative strategies for revenue needs for
the
>>>>> Foundation, including the possibility of charging for premium
access
> >>>>>
> >>>> to the
> >>>
> >>>> services and APIs, expanding major donor and foundation
fundraising,
> > >>>>> providing specific services for a fee, or limiting the
Wikimedia
>
>>>>> Foundation's growth. The Board emphasized the importance of
keeping
> >>>>>
> >>>> free
> >>>
> >>>> access to the existing APIs and services, keeping operational
growth
> in
> >>>>> line with the organization's effectiveness, providing room
for
> >>>>>
> >>>> innovation
> >>>
> >>>> in the Foundation's activities, and other potential
fundraising
> >>>>>
> >>>> strategies.
> >>>
> >>>> The Board asked Lila to analyze and develop some of these
potential
> > >>>>> strategies for further discussion at a Board meeting in
2016.
> > >>>>> Source:
https://wikimediafoundation.org/wiki/Minutes/2015-11-07
>>>>> -Pete[[User:Peteforsyth]]
>>>>> _______________________________________________
>>>>> Wikimedia-l mailing list, guidelines at:
>>>>>
>>>>
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
>>>
>>>> New messages to: Wikimedia-l(a)lists.wikimedia.org
>>>>> Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>>>>>
>>>> <mailto:wikimedia-l-request@lists.wikimedia.org
?subject=unsubscribe>
>>>
>>>>
>>>> _______________________________________________
>>>> Wikimedia-l mailing list, guidelines at:
>>>>
>>>
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
>>>
>>>> New messages to: Wikimedia-l(a)lists.wikimedia.org
>>>> Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
> ,
> >>>>
> >>> <mailto:wikimedia-l-request@lists.wikimedia.org
?subject=unsubscribe>
>>>
>>> _______________________________________________
>>> Wikimedia-l mailing list, guidelines at:
>>>
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
>>> New messages to: Wikimedia-l(a)lists.wikimedia.org
>>> Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> >>> <mailto:wikimedia-l-request@lists.wikimedia.org
?subject=unsubscribe>
> >>>
> >>>
> >>
> >>
> >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> >
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > New messages to: Wikimedia-l(a)lists.wikimedia.org
> > Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:wikimedia-l-request@lists.wikimedia.org
?subject=unsubscribe>
> > >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> >
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > New messages to: Wikimedia-l(a)lists.wikimedia.org
> > Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>