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.
quote
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
.