Evaluate and Decentralize Technology Components

Q 1 What is your Recommendation?

Currently the majority of the decision making and execution of software development is performed by the Wikimedia Foundation. This recommendation proposes determining what type of decentralization is appropriate and work towards decentralizing some of the technology components based on that evaluation. The three main types of decentralization to consider are geographic, organizational and project-level (wiki-level) decentralization. A few different activities are required for this to be possible. First what software is going to be built needs to be determined, next who is going to build the software and then finally how. We recommend that WMF retains ownership of and focus on underlying platform development, but that other projects and components are evaluated to determine if better served by being developed by other organizations and groups of community members.

The scope of this recommendation is as follows:

Set-up an iterative strategic consultation in which long-term goals and visions can be determined in a participatory manner. This process should lead to a maintained public roadmap with project dependencies outlined.
From the roadmap affiliates and volunteers can make proposals to build components of the roadmap. These proposals will be vetted for their technical merit, cohesiveness with the technology architecture through the “Technology Council”.
The proposed software is developed
After delivery of the software projects they will be reviewed to determine the success of the project. This review will be used as input into further decisions regarding these groups award of future proposals.

Q 2-1 What assumptions are you making about the future context that led you to make this Recommendation?

In order to provide “knowledge equity’ it is important those building technology to enable that equity are from backgrounds representing the world’s knowledge (“Nothing About Us Without Us!”). Currently the movement is mainly supported by the Wikimedia Foundation which is a San Francisco organization. To achieve equity so the members of the movement should be empowered to build their own tools and make their own decisions to the extent possible. By decentralizing technology development it allows greater opportunities for people from varied backgrounds to contribute as well as a broader range of views and use cases to be taken into account.

Wiki communities should be co-decision makers in their projects and this should be reflected in the governance structure. Knowledge as a service requires responsiveness to opportunities and local differences and decentralizing is a way to achieve that.

Q 2-2 What is your thinking and logic behind this recommendation?

This recommendation aims to increase the diversity, equity and autonomy of those building the technology components within the Wikimedia movement. The success of Wikidata is a good example of how resourcing of affiliates can be a good way to expand the capacity to development technology within the movement.

Q 3-1 What will change because of the Recommendation?

Expected outcome is broader range of inputs and development base. Competition between proposals and for resources will lead to a more efficient use of the latter, as well as a drive for partners to involve more funders and participants on their side, thereby increasing projects’ growth.

Q 3-2 Who specifically will be influenced by this recommendation?

WMF, 3rd parties, affiliates and developers

Q 4-1 Could this Recommendation have a negative impact/change?

If not coordinated well the maintenance costs of maintaining software build by so many different groups could be unsustainable.
Uncoordinated development could lead to fragmentation and loss of interoperability.
There is a risk if WMF remains to serve as a gatekeeper that it could become a bottleneck in this process.
There is a risk to the Wikimedia brand and/or community trust if an organization does something bad under the Wikimedia name.
There is a risk that decentralization could simply enforce existing power structures (decentralized execution but centralized governance).
Without adequate governance and training it may be difficult for groups to make difficult decisions.

Q 4-2 What could be done to mitigate this risk?

Each proposed project should have a maintenance plan on how the software will be maintained into the future.
A strategic technology vision and plan is required to make technology development cohesive.
Resourcing processes appropriately to reduce potential bottle necks.
Responsibilities and expected capabilities of organizations doing development need to be defined.
Process design need to be inclusive and develop an inclusive decision making process not to reinforce existing power dynamics.
Governance processes need to be designed to allow effect decision making.

Q 5 How does this Recommendation relate to the current structural reality?

Currently the Wikimedia Foundation develops the majority of the software deployed on Wikimedia Foundation servers. The exception to this is Wikidata which is mostly development by Wikimedia Deutschland. This process would change that so more people would be contributing.

Q 6-1 Does this Recommendation connect or depend on another of your Recommendations? If yes, how?

This recommendation connects to the recommendation “Developing an Evolving Technology Vision” without that vision it would be difficult to decentralize technology in a reasonable way because there would not be a guiding plan. The Open Product Proposal Process and Deployment Council recommendations could be part of the governance process for building and deploying components in a decentralized but coordinated fashion.

Q 7 How is this Recommendation connected to other WGs?

Resource allocation, if technology components are decentralized without having resources allocated it would be difficult for those components to be developed in a sustainable way.

Roles and Responsibilities as they also have recommendations that involve models for decentralization.

Capacity building as to do effect decentralization organizations and individuals must have the adequate skills.

Q 8 Do you have anything to add that was not covered with previous questions, yet essential for understanding the recommendation?

To execute this process there would have to be multiple steps. Choosing a single product, service or feature group to run as a pilot would make sense. MediaWiki is the core technology used across the Wikimedia Movement and already has interest by a variety of other parties that are not WMF. Specific MediaWiki extensions could be chosen to be developed outside of the WMF through this pilot process. Beginning this could happen through a consultation to create a one year roadmap and determine specific features to be built by parties other than the WMF.

Appendix

Decentralisation terminology:

When saying a decentralisation is needed we need to understand on what level we are trying to decentralise.

We thought about 3 layers of decentralisation:

Geographic
Organisational
Project

The intent and motivation for each layer is different and fosters various angles resulting in a variety of components that may or may not make sense to decentralize.

Components:

Development tooling : things like git, gerrit, phabricator, CI etc

Tech operations - Hardware : physical server layer

Tech operations - Personnel : Operational teams

Underlying Platform : Mediawiki core, API, wikibase

IaaS: Cloud services, Containers

Server-side features: Extensions, templates, lua modules

Client-side features: JS, skins, UI, gadgets

Contributor tooling : pywikibot, scripts, apps

Decentralisation grid (green means already the case):


	Geographic (resilience, capacity, subsidiarity, diversity)	Organisational (resilience, capacity, subsidiarity)	Project (resilience, innovation)
Must be central	Development tooling	Tech operations hardware Tech operations personnel Underlying platform Development tooling	Tech operations hardware Development tooling
Might be decentralised	Tech operations hardware	IaaS
Should be decentralised	Tech operations personnel Server-side features Client-side features Contributor tooling	Server-side features Client-side features Contributor tooling	IaaS Server-side features Client-side features Contributor tooling

Movement Strategy/Recommendations/Iteration 2/Product & Technology/1

Contents