Upgrading MediaWiki

The MediaWiki software that runs Wikipedia is available as open source and has been widely deployed. But have those deploys been kept up to date? Who's problem is that?

I've worked my way through a long thread on this subject that includes many observations by key people in MediaWiki's long developmental history.

I quote here statements that turned the conversation with only light editing for readability. At heart this is a question of scale and purpose that is close to our own interests.


What will happen to the numerous MediaWiki installs on shared hosting providers when running MediaWiki requires multiple stand alone processes to function? post

The question is: what will we gain and what will we lose by making MediaWiki unusable by 95% of its current user base? post

Maintaining the ability to run MW in crappy environments has always been a losing battle ... it might be the time to officially declare that we don't care about supporting environments without shell access. Still, shell access does not equate to root access. post

These days I'm not convinced it's our job to support every possible scale of wiki install. There's several simpler and smaller wiki solutions for people who can't do more than FTP a few files to a folder. post

In this case the problem is leaving users and their wiki content unsupported. Because they won't move while it "works", even as it becomes a Swiss cheese of security holes. Because their content is important to them. post

What you're forgetting is that WMF abandoned MediaWiki as an Open Source project quite a while ago (at least 2 years ago). There's a separate org that gets a grant from WMF to handle third party use, and it's funded just well enough to keep the lights on. post

The net effect is that people will keep their existing MW installs at their current version or even install old versions of the software so they can look like Wikipedia or whatnot, rife with unpatched security vulnerabilities. I cannot fathom that the WMF would be ok with leaving third-party users in such a situation. post

It would be great if the problem was solved, but people have been asking for it for over 10 years now and it hasn't happened. post

The number of MediaWiki instances out there is meaningless. The value we get from 3rd party use correlates much more strongly with the number of users, not the number of instances. ... It's simply not possible that shared host installs can achieve enough usage to be relevant. post

The number of users involved does not reflect the importance of the information presented any more than that a project exists at all. ... MediaWiki is a platform that empowers all of these, and to turn your back on them directly contradicts Wikimedia's overall mission. post

I would argue that many small projects would be better served by good wiki farm hosting than trying to maintain their own sites. post

In many cases when folks run their own wikis, this is why - they either need something specific, or want to maintain some form of control over their own content/communities that isn't necessarily afforded otherwise. post

We just have a legitimate tension between needing to focus as an org on what donors are supporting us for, vs. potentially very tangentially related needs. post

MediaWiki for third parties is effectively abandonware since no one is maintaining it for that purpose. ... I don't understand why there's a conversation about it. It's putting constraints on its own [Wikipedia's] architecture model because of a third party community it doesn't support. post

This tension applies to all of the non-Wikipedia projects ... [as they are] not a part of the movement that donors tend to know about? post

It should be possible to define minimum capability and have ability to degrade from full-power install ... to reduced-capability install while still keeping the same architecture. post

The problem there is that the PHP implementation is likely to code-rot ... [unless] both methods could share a majority of the code base, rather than rewriting things from scratch in an entirely different language. post

I don't believe that with continuing demand / development of new features, you can make the same codebase work for WMF's expanding feature set and for a lot of small wikis who are content with simple wikitext-based wikis without any of the additional complexity. post

This [separate codebases] is not a great idea because it makes WMF wikis unforkable in practical terms. The data is worthless without being able to run an instance of the software. This will functionally proprietise all WMF wikis, whatever the licence statement. post

WMF should concentrate on the large-scale hosting case ... including better support for creating and maintaining large farms of small independent wikis. We should also either spin off an affordable for-pay no-ads wiki hosting company, or let people create one (or multiple) and direct people to them. post

The shared hosting environment has never been preferred, and I'm not particularly attached to it. Support for it is an accidental consequence of MediaWiki's simplicity and flexibility, and those qualities should be valued for their own reasons. post

We should be proud of how popular MediaWiki has become across the Internet and we should support its growth because it ultimately supports our own. post