You can find some more discussion at https://meta.wikimedia.org/wiki/Talk:Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_3/Promote_Sustainability_and_Resilience#Freemium
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: 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, <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
