You can find some more discussion at

As I mentioned there, the premise of the recommendation is that the
movement needs new revenue sources; in part because the 2030 strategy is
ambitious and requires a significant increase in resources, in part because
our current lack of diversity (about 40% of the movement's budget is from
donations through website banners, and another 40% from past banners via
email campaigns and such) is a strategic risk because those donations can
be disrupted by various social or technical trends. For example, large tech
companies which are the starting point of people's internet experience
(such as Facebook or Google) clearly have aspirations to become the end
point as well - they try to ingest and display to their users directly as
much online content as they can. Today, that's not a whole lot of content
(you might see fragments of Wikipedia infoboxes in Google's "knowledge
panel", for example, but nothing resembling an encyclopedia article). Ten
years from now, that might be different, and so we need to consider how we
would sustain ourselves in such a world - in terms of revenue, and also in
terms of people (how would new editors join the project, if most people
interacted with our content not via our website, but interfaces provided by
big tech companies where there is no edit button?).

The new API project aims to do that, both in the sense of making it
possible to have more equitable arrangements with bulk reusers of our
content (who make lots of money with it), and by making it easier to reuse
content in ways that align with our movement's values (currently, if you
reuse Wikipedia content in your own website or application, and want to
provide your users with information about the licensing or provenance of
that content, or allow them to contribute, the tools we provide for that
are third rate at best). As the recommendation mentions, erecting
unintentional barriers to small-scale or non-commercial reusers was very
much a concern, and I'm sure much care will be taken during implementation
to avoid it.

Wrt transparency, I agree this was communicated less clearly than ideal,
but from the Wikimedia Foundation's point of view, it can be hard to know
when to consult the community and to what extent (churning out so much
information that few volunteers can keep up with it can be a problem too;
arguably early phases of the strategy process suffered from it). This is a
problem that has received considerable attention within the WMF recently
(unrelated to API plans) so there's at the very least an effort to make the
process of sharing plans and gathering feedback more predictable.
Also, the pandemic has been a huge disruption for the WMF. Normally, by
this point, the community would have been consulted on the draft annual
plan, which is where new initiatives tend to be announced; but that has
been delayed significantly due to so many staff members' lives being
upheaved. Movement events where such plans are usually discussed had to be
cancelled, and so on.

(Written with my volunteer hat on. I was involved in the strategy process
and helped write the recommendation snippet Yair quoted upthread; I'm not
involved in the API gateway project.)
Wikimedia-l mailing list, guidelines at: and
New messages to:

Reply via email to