Requests for comment/MediaWiki Foundation
|Implementation status||not implemented|
- 1 What deficiency is there in MediaWiki only being a Wikimedia Foundation project?
- 2 What would the goal of a MediaWiki Foundation be?
- 3 What would be solved or improved by having a MediaWiki Foundation?
- 4 How would the MediaWiki Foundation choose/prioritize what projects to work on?
- 5 Alternatives
- 6 References
- 7 See also
What deficiency is there in MediaWiki only being a Wikimedia Foundation project?[edit | edit source]
MediaWiki was originally developed for Wikipedia, and is in use on all Wikimedia projects, but it has become a software product in its own right, used in wiki farms, like Wikia; corporate or governmental knowledge bases, which are often hidden from the public; independent hobbyist sites; and personal wikis used by a single person.
The Wikimedia Foundation is an organization dedicated to the open creation and distribution of knowledge.
Donations made to the Wikimedia Foundation are made with that goal in mind and it would be irresponsible of the foundation to use significant portions of that money to further the development of large MediaWiki development projects that do not serve the Wikimedia Foundation's goals.
Development on MediaWiki is done by:
- Wikimedia Foundation employees and contractors on projects directly and indirectly beneficial to the WMF.
- Employees of third-party organizations on projects of use to the organization.
- Volunteers who develop in their spare time outside of work, school, and other commitments.
This means there are few developers contributing to MediaWiki whose ability to take on large MediaWiki development projects is not either biased towards what is in their employer's interests or restricted in how much time can be spent on those projects.
What would the goal of a MediaWiki Foundation be?[edit | edit source]
The goal of a MediaWiki Foundation would not be to replace the Wikimedia Foundation in anything related to MediaWiki. Instead the MediaWiki Foundation would take over things the WMF believes are outside of the scope of its goals. The MediaWiki Foundation would seek to improve areas related to third-party use of MediaWiki that have not received attention from the WMF.
What would be solved or improved by having a MediaWiki Foundation?[edit | edit source]
- In another RFC moving release management outside of the Wikimedia Foundation is being discussed. Having a foundation dedicated specifically to MediaWiki and its non-WMF uses would help ensure there is someone working full time who is capable of doing tarball releases of MediaWiki. As opposed to tarball releases being subject to how much spare time a volunteer has.
- There are many large feature ideas lying around. Many of these would be useful to MediaWiki installations outside of the WMF. However, due to their size they do not get attention from volunteers with little spare time, or WMF employees who similarly have little 20% time and are not tasked with these projects due to not being important to WMF's core mission, and 3rd party companies who cannot justify writing a large, abstract, and generic backend MediaWiki feature when they could just put together a small ugly hack that suits their specific purposes. The MediaWiki Foundation could take on these projects and contract or employ developers to ensure their completion.
How would the MediaWiki Foundation choose/prioritize what projects to work on?[edit | edit source]
There is a near-infinite number of things to develop for MediaWiki. We have over 1.5k open bugs in the MediaWiki component alone, plenty of open RFC pages, and many of our community members have even more ideas for things to add to in MediaWiki. How would the foundation decide what the developers it hires should work on?
Idea #1: Anarchy[edit | edit source]
It's not a very conventional, organized, or – from an outside perspective – purposeful way to organize projects for the developers. But it is necessary to understand that we have volunteers who pick out things they see as missing from MediaWiki in their own spare time (10% or 20% of their programming time) and work towards fixing that hole. For some of these people if we simply hire them and let them choose projects themselves they will continue fixing the many things in MediaWiki we are missing. But this time using all of their programming time for MediaWiki development. And now knowing that they have the resources and time to work on large features they would not have tried to start writing before.
From the foundation's goal of boosting MediaWiki development. Especially in large areas that don't get touched now. This would already be a big aid to the goal. Many of these volunteers we may hire will leap right into some of the big projects that are overdue without any pushing from the foundation. And even the small bugs they may pick up will still be in favour of the foundation's goal.
Idea #2: Community / donor driven prioritizing[edit | edit source]
One possibility is to set up a system similar to that used by the International Monetary Fund, in which voting power in the organization is apportioned to members in proportion to their donations. Voters could barter with one another to determine how the money should be allocated. Other wikis benefit not only from MediaWiki code but from being able to borrow the templates, images and so on used on Wikipedia, so people whose main concern is those other wikis would still have an incentive to vote to fund Wikipedia.
Alternatives[edit | edit source]
Idea #1: MediaWiki Department[edit | edit source]
Make a fully-funded and staffed MediaWiki specific department within the WMF Engineering Department. Setup a MW specific fund to collect donations, perhaps with WMF matching or supplementing these donations. Priorities would be set by a volunteer advisory board (similar to the funds dissemination committee) while HR supervision and release management would remain under WMF. Rather than focusing on WMF project specific areas of MediaWiki, this department would focus on broader MW needs, such as installer or extensions of greater value to third-party wikis than WMF projects.
Idea #2: Add representatives from non-WMF wikis to the WMF Board of Trustees[edit | edit source]
It would be necessary to decide how these representatives are to be selected and how representation is to be apportioned, however. It would defeat the point if the Board were to be permitted to select the representatives; then the Board would probably just appoint yes-people who agree with the appointing Board members. Many, if not most, non-WMF wikis are autocracies rather than democracies, so the same problem potentially arises as happens in the United Nations when governments are put in charge of representing their people's interests before the world body.
Idea #3: Status quo[edit | edit source]
Let the WMF continue to coordinate MediaWiki development and to make final decisions on what is to be included in the core, and do not create a MediaWiki Foundation. Wikipedia-centrism in MediaWiki development is not necessarily a bad thing. Some wikis use MediaWiki for the very reason that it has been engineered to be well-suited for the needs of huge, highly active wikis. The current system allows for extension and core code to be developed that will allow MediaWiki to meet the diverse needs of the rest of the wikisphere.
The best way to ensure that MediaWiki remains high-quality software is for an organization with deep pockets, whose main revenue-attracting project is dependent on MediaWiki, to fund and coordinate MediaWiki's development. Therefore, the current situation, in which the organization that administers the largest MediaWiki-based wiki farm in the world also coordinates MediaWiki development, is ideal. Some kinds of expensive code development are only cost-effective for an organization that is able to leverage economies of scale; e.g. an extension that costs $10,000 to develop might not be worthwhile if it will only bring in $2,000 in donations (or other benefits) to an organization, but could be worthwhile to a larger organization. Relying on a group of donors with a variety of agendas and interests due to their affiliation with different wikis runs the risk of encountering greater diffusion of responsibility in which everyone hopes someone else will devote resources to making the desired changes.
It is true that certain enhancements, such as a configuration database, that would be beneficial for smaller wikis have been neglected. However, many of these proposals have drawbacks anyway, which often explains why the changes have not been made. Also, if the developer community lacks resources to devote to such projects because those resources are needed for more important projects, it is unclear how setting up a new foundation would address that problem. That would merely amount to coming up with a different way of cutting up the resource pie — perhaps in a way that would be suboptimal compared to what we do now — rather than making the pie bigger.
Ultimately, what's good for WMF wikis is good for the rest of the MediaWiki-using community, and vice versa. WMF has an incentive to look out for the interests of the other MediaWiki-using sites so that they will continue to use and develop MediaWiki code. Some code eventually used on WMF wikis starts out as code implemented for the benefit of non-WMF wikis, and vice versa. The interests of sites using MediaWiki are so closely aligned that there is no need to split off MediaWiki development coordination from WMF; it would only increase coordination costs by increasing the number of decision-making bodies. It could also tie the hands of WMF, the organization with the most resources in the wikisphere, from easily making the changes it would like to see.
References[edit | edit source]
- E.g. BoyWiki's Wiki Engine Analysis notes, "MediaWiki is an extremely popular Open Source project with high usage and scalability. . . This is the same engine written and used for the Wikipedia Project, a high-profile site which is prone to vandalism and attacks. It is proven, well-tested, well-maintained, and actively developed. BoyWiki will be able to leverage the fire-tested security that this engine now offers."