User:Tgr (WMF)/Turn MediaWiki core into an embeddable library

(This was originally written as a position statement for the Developer Summit, but then I ended up submitting a different one: Sister project incubator. There is also another non-submitted position: Make MediaWiki commercially viable.)

We should turn MediaWiki core into an embeddable library.

The new strategic direction calls for providing infrastructure for the whole open knowledge ecosystem, beyond the boundaries of the Wikimedia movement. Our current infrastructure being free software, promoting the use of it would be an obvious means for this. However, MediaWiki has seen limited adoption by knowledge organizations so far. What can we do to change that?

One possible answer is making it possible to reuse MediaWiki as a library. There are many examples in the free software world of vastly increasing adoption by decoupling the core of a system from the way users normally interact with it. Drupal has rebranded itself from a content management system to a content management development framework and has seen great adoption. Linux has failed to gain adoption as a standalone operating system but became ubiquitous as the underlying infrastructure powering various embedded and mobile interfaces. Chromium has beaten Firefox in developer attrition mainly by making itself much easier to embed. Similarly, MediaWiki's core functionality (a collaborative document editing engine with excellent internationalization, and support for highly configurable social interaction cues and anti-abuse features) could be disentangled from its current user interface and use cases so that other organizations could easily plug it into their systems (to support, say, user-curated descriptions of museum items, or reader-provided updates to news articles).

The architectural changes needed for such a move are largely congruent with generic best practices (and make sense even if the goal is merely to reduce tech debt):

  • push through the mostly stalled effort to introduce dependency injection,
  • replace direct references with clean and well-documented interface,
  • librarize components which make independent sense,
  • modularize the code and minimize coupling between classes in different components,
  • separate framework code (entry points, configuration, installer/upgrader) into its own repo.