Schools of thought concerning integration of extensions into the core

An extension should be bundled with the installer after it has become extremely widely used. There are a couple major schools of thought concerning other extensions. The centralist view is that it is better to let the different extensions compete for acceptance on an even playing field unless and until the wikisphere settles on a clear favorite, the idea being that such a decentralized process harnesses the knowledge and creativity of a larger group to create solutions, and incorporates useful feedback about their preferences into the standard-setting process. The decentralist view is that it is better for the developer community to play a leadership role of picking what everyone should use rather than waiting for system administrators across the wikisphere to reach consensus; this helps progress by facilitating the emergence of widely-used standards, thus avoiding unnecessary delays or inconvenient VHS-vs.-Betamax situations.

A major issue is whether adopting one standard will interfere with another. For example, adding a new special page or API module is unlikely to interfere with other desired functionalities. Changing how the parser renders wikitext might be a different matter. Then again, if such parser features were to be adopted by major WMF wikis such as Wikipedia, it would likely be adopted widely across the wikisphere since wikis would want to be able to have pages imported from Wikipedia render properly. So, some centralized standard-setting may be unavoidable. Perhaps a good rule of thumb is that if wikis will need the extension (e.g. Extension:ParserFunctions or Extension:Cite ) in order to properly render pages imported from Wikipedia, then the extension might as well be bundled with the installer or integrated into the core, because almost everyone is going to end up installing it on their wikis anyway.

When deciding whether to integrate an extension into the core, one should consider the likelihood, if any, that extensions will be written that depend upon that functionality, and the prospects that it might be later desired to remove that functionality from the core, which would break those extensions. Extensions with uncommon external dependencies should generally not be bundled with the installer or integrated into the core.

Arguments for merging to core

It's not good to have a bunch of different extensions for every possible functionality system administrators might want to switch on; Wikipedia already has more than 100 extensions, and it's daunting for system administrators to go about installing and configuring all the ones they might need, especially since there is no centralized list of configuration settings for all the extensions, as there is for the core. Sometimes it's better just to put functionality in the core, if it's a boolean setting with a simple implementation, rather than something that could have any number of different complicated and widely varying implementations (such as ConfirmEdit CAPTCHAs). This is especially true if the cleanest implementation can be accomplished by putting it in the core; e.g. if the code fits in well with what is already there.

Quim Gil writes, "Upgrading MediaWiki is easy, upgrading a MediaWiki site using extensions is not. Versioning extensions and aligning them with MediaWiki versions is not done consistently. And how would you know which extension version works for your slightly older MediaWiki, e.g. because you are using a LTS version?" When everything is kept in the core, these compatibility problems are not an issue.