One very serious element of this decision-making really should be the fact that Google is blatantly violating the CCA-SA by reusing Wikipedia content without making their derivative work open.
- *Share Alike*—If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license.
On Thu, May 5, 2016 at 9:58 AM, Andreas Kolbe jayen466@gmail.com wrote:
On Thu, May 5, 2016 at 5:00 AM, MZMcBride z@mzmcbride.com wrote:
I used the phrase "run amok" based on comments at https://meta.wikimedia.org/wiki/Knowledge_Engine/FAQ. Specifically, Brion Vibber writes:
"Former VP of Engineering Damon Sicore, who as far as I know conceived
the
'knowledge engine', shopped the idea around in secret (to the point of GPG-encrypting emails about it) with the idea that Google/etc form an 'existential threat' to Wikipedia in the long term by co-opting our traffic, potentially reducing the inflow of new contributors via the 'reader -> editor' pipeline. [...]"
Jimmy Wales replies:
"It is important, most likely, that people know that Damon's secrecy was not something that was known to me or the rest of the board. I've only yesterday been sent, by a longtime member of staff who prefers to remain anonymous, the document that Damon was passing around GPG-encrypted with strict orders to keep it top secret. Apparently, he (and he alone, as far as I can tell) really was advocating for taking a run at Google. [...]"
I find it interesting to compare Damon's purported concerns with those voiced by Jimmy Wales in his October emails to James Heilman, as made available to the Signpost:
https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2016-04-24/Op-ed
There we read that Wales said:
<quote> Right now the page at www.wikipedia.org is pretty useless. There's no question it could be improved. Is your concern that if we improve it and it starts to look like a "search engine" in the first definition this could cause us problems?
Are you concerned that in due course we might expand beyond just internal search (across all our properties)?
Right now when I type "Queen Elizabeth II" I am taken to the article about her. I'm not told about any other resources we may have about her.
If I type a search term for which there is no Wikipedia entry, I'm taken to our wikipedia search results page – which is pretty bad.
Here's an example: search for 'how old is tom cruise?'
It returns 10 different articles, none of which are Tom Cruise!
When I search in Google – I'm just told the answer to the question. Google got this answer from us, I'm quite sure.
So, yes, this would include Google graph type of functionality. Why is that alarming to you?
...
I don't agree that there's a serious gulf between what we have been told and what funders are being told.
...
Imagine if we could handle a wide range of questions that are easy enough to do by using wikidata / data embedded in templates / textual analysis.
"How old is Tom Cruise?"
"Is Tom Cruise married?"
"How many children does Tom Cruise have?"
The reason this is relevant is that we are falling behind what users expect. 5 years ago, questions like that simple returned Wikipedia as the first result at Google. Now, Google just tells the answer and the users don't come to us.
<end of quote>
When told that there clearly had been an attempt to fund a massive project to build a search engine that was then "scoped down to a $250k exploration for a fully developed plan", Wales replied:
<quote> In my opinion: There was and there is and there will be. I strongly support the effort, and I'm writing up a public blog post on that topic today. Our entire fundraising future is at stake. <end of quote>
Wales's concerns don't sound all that different from Sicore's to me.
Both seem to have perceived developments at Google as an existential threat, because users get their answers there without having to navigate to Wikipedia or Wikidata (which are among the sources from which Google takes its answers).
Nor do I think these concerns are entirely unfounded. By opting for a CC licence allowing full commercial re-use, years ago, Wikipedia set itself up to be cannibalised in precisely that way.
For better or worse, it relinquished all control over how and by whom its knowledge would be presented. It should hardly come as a surprise that commercial operators then step up to exploit that vacuum, set up commercial operations based on Wikimedia content, and eventually draw users away.
Moreover, the current search function does suck. Anyone looking for a picture on Commons for example is better off using Google than the internal search function.
What I don't understand is why all the secrecy and double-talk was necessary.
These same individuals posted to this mailing list:
https://lists.wikimedia.org/pipermail/wikimedia-l/2016-February/082150.html
https://lists.wikimedia.org/pipermail/wikimedia-l/2016-March/083163.html
This reported secrecy and cloak-and-dagger behavior is what I'm referring to when I say Damon ran amok. I suppose we can leave it as an exercise to the reader whether "run amok" is accurate phrasing given the evidence presented. Upon reading the previous comments that Damon, not Lila, was responsible for the secrecy, I'm perplexed by your recent comment regarding "Lila's decision." What am I missing?
Damon left in July 2015. Secrecy around the Knowledge Engine project and the Knight grant lasted until February 2016. Perhaps this no longer involved GPG encryption, but as late as 29 January 2016 Lila still led the community to believe that "donor privacy" issues were the reason why the board didn't publish the Knight Foundation grant agreement:
https://meta.wikimedia.org/wiki/User_talk:LilaTretikov_(WMF)/Archive_12#Why_...
Yet the donor was in favour of full transparency ... _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe