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

v t e Movement Strategy Working Group recommendations (September 2019) Now merged into the final 10 recommendations
Advocacy	1. Transparency 2. Diversity 3. Global conversation 4. Knowledge management 5. Advocacy Hub 6. Common positioning 7. Partnerships 8. Empowerment of advocates 9. Self-Determination 10. Protection of Advocates
Capacity Building	1. Building Capacity for Capacity Building 2. Matching human assets and online knowledge resources with capacity building needs 3. Capacity Building Should Occur in Context 4. Provide Capacity Building for Organizational Development 5. Resources for Capacity Building 6. Evaluating Capacity Building 7. Online Training 8. Mentoring and leadership development 9. Recognizing Individuals 10. Independently governed Capacity Building ‘Unit’
Community Health	1. A joint set of rules we all agree to live by (a.k.a. Code of Conduct) 2. Redefining power structures to better serve the communities 3. Building the leadership of the future 4. Structure for handling conflicts- before, during and after 5. Investing in building an inclusive global community 6. Newcomers are a key indicator to the success of the movement 7. “Democratizing” participation (making Wikipedia/Wikimedia everyone’s responsibility) and reducing barriers for participation 8. Privacy and security for everyone 9. Opening the circle: All terrain readiness 10. Network to continually support community health 11. Aligning resource allocation with community health goals 12. Investing in equity-centered technologies
Diversity	1. Introducing people-centered principles within the Wikimedia movement 2. Reaching a self-aware and dynamic structure aimed at community diversity and health 3. Redesigning the platforms for more diversity of people and content experiences 4. Planned community diversification 5. Reflective policies for participation and governance 6. Establishing partnerships in order to represent and protect worlds’ cultural diversity 7. Decentralized administrative structure for resource allocation 8. Bridging different local contexts and Wikimedia projects' notability and verifiability policies
Partnerships	1. Provide the knowledge needed for understanding and solving global issues 2. Wikimedia as steward of the Free Knowledge Ecosystem 3. Shared ecosystem of services and tools for content partnerships 4. Data partnerships approach to fulfill the vision of knowledge as a service for our partners 5. Focus on knowledge equity when determining priorities for Partnerships 6. Partnerships as part of a Distributed Vision 7. Partnerships as a shared and equitable resource and activity 8. Prioritise documentation 9. Invest in sharing knowledge about partnerships across the movement 10. Support the skills development of people working on partnerships 11. Invest in the leadership potential of community members 12. Establish recognition principles for new partners for attribution and content donation 13. Additional research for areas where we have identified issues but haven’t made recommendations
Product & Technology	1. Evaluate and Decentralize Technology Components 2. Support Community Decision-making 3. Open Product Proposal Process 4. Deployment Council 5. Disseminate Product Knowledge 6A. Improve Technical Contributor Engagement 6B. Modernize Technical Contributor Tooling 7. Realize the Potential of the Third-Party Ecosystem 8. Movement Technology Ethics Review Process 9. Monitoring Product Trust and Availability 10. Developing an Evolving Technology Vision and Strategy
Resource Allocation	A. Set Common Framework of Principles for Resource Allocation B. Design participatory decision making for Resource Allocation C. Recognize privileges / Design for equity D. Distribute existing structures E. Build Thematic hubs – to provide services to the free knowledge movement long term F. Ensure flexible approach to resource allocation in a complex, fast moving and changeable space G. Allocate resources for capacity and sustainability H. Allocate resources to new types of partners/organisations (essential infrastructure of the free knowledge ecosystem) I. Include knowledge consumers
Revenue Streams	1. Turn the Wikimedia API into a revenue source 2. Provide Paid Wiki-related Services 3. Monetize merchandise 4. Expand global fundraising 5. Develop non-fundraising revenue streams for affiliates 6. Set a goal of financial sustainability for all movement actors 7. Diversification of revenue channels
Roles & Responsibilities	0. Scenario 1. All of this exists to support our primary purpose: free knowledge and its distribution (Original) 2&3. Decentralisation and self-management 4&5. Establish a Movement Charter 6. Wikimedia movement organisations will be governed by inclusive, diverse, and accountable boards 7. Capacity building