Distribution/Use cases

This page summarizes different use cases for our distribution and packaging efforts. It does not consider large third-party organizations (including specialized MediaWiki hosting services) with the resources to do their own packaging and deployments.

1) Shared hosting without shell

 * The user uploads code with (s)ftp, using a bundle tarball.
 * Can't install anything globally without root rights, so minimal features and performance.

2) Shared hosting with non-root shell

 * The user can use (s)ftp uploads as in 1)
 * The user can't install anything globally without root, so minimal features and performance.
 * If git is installed, the user can use git directly on the server.
 * The user can manually download composer to their home directory, and use this instead of git.

3) Root on a (virtual) server

 * The user can install packages.


 * The user can do any of the above (tarballs, git, composer).

4) Wiki farm
From a handful to thousands wikis.
 * Sysadmins have root access
 * Shared codebase across several wikis
 * Sysadmins and possibly normal shell users should have an easy way to create new wikis using the shared codebase
 * Extensions might differ per wiki
 * Need bulk upgrade support for all wikis per system

5) Developer on a typical single-user machine (Mac/Windows/Linux)

 * Runs a (typically small) test wiki off git
 * Contributes code back to MediaWiki
 * Goal is to make the process of contributing the first patch as painless as possible
 * Painless and *temporary* -- for infrequent contributors it should be easy to uninstall packages and undo whatever configuration changes are made after the patch is submitted/merged.
 * Applies to mediawiki, its dependencies, and to the bug tracking, version control, patch submission, and code review environment.
 * Typically has root in development environment, but doesn't like to use it.
 * When possible, root should be used only to install distro packages (via apt, yum, homebrew), not to make arbitrary changes.
 * When possible, tools should be able to install and run from a local user directory with normal user permissions (, , server ports >= 1024, etc)
 * Frequently updated dependencies shouldn't require root to track.
 * For example,  is infrequent and thus fine, but I shouldn't need root to update third-party dependencies in the middle of a normal.
 * Protected from typical newbie mistakes
 * For example, a new developer shouldn't have to install and remember to run a linting tool. It should either be transparently integrated in the code review environment or else the lint should be run on WMF hardware as part of integration tests.

6) Vendor branch
This approach is found in corporate environments that develop proprietary wiki extensions. Official MediaWiki code is not deployed directly, but merged into the company version control system using a vendor branch model.

This use case is most similar to the ordinary tarball release, as everything else happens behind the scenes at the company. However, it's important that Wikimedia not break this use case.


 * The user downloads latest release's bundle tarball, unpacks it, and adds the contents to the company version control system (subversion, git, or whatever).
 * A diff is calculated between the company codebase and the official release using a vendor branch approach.
 * This diff is merged into the company codebase, bringing it up to date with the official release.
 * Very likely, this merged release is deployed to development, test, and production environments, some of which may be server farms.

Relative distribution of use cases, trends
We are lacking historical data on the distribution of users, and on any changes in this distribution. However, for public wikis there is a fairly representative queryable dataset: wikiapiary:WikiApiary:Hosting providers is one example report, more can be added with some SMW charts.

There is speculation and anecdotal evidence that use case 3) is becoming more popular as virtual servers are now available at a price point similar to shared hosting.