Post by Chris Lewis
I hope I am emailing this to the right group. My concern was about mediawiki and it's limitations, as well as it's outdated methods. As someone wo runs a wiki, I've gone through a lot of frustrations.
-Default skins are boring
-Very limited in being able to make the wiki look nice like you could with a normal webpage.
-A major pain to update! Wordpress upgrades are so simple.
-Better customization so people can get a wiki the way they want. It should be more like the wikis on wikia, except without me having to learn css and php to make those types of customizations. Give me some option, some places to put widgets. Not every wiki is going to be as formal as the ones on wikimedia sites. And don't the people at Wikimedia commons get tired of always having to make changes so it actually suits their site? If they had some of the options from the get go, i'm sure they'd appreciate it too.
-I don't want to go to my ftp to download my local settings file, add a few lines then reupload it. This is caveman-like behavior for the modern internet.
-Being able to manage extensions like wordpress does.
In short, it's time to spend some money from those millions of dollars from donations to make this software more modern. Being stubborn in modernizing it will only make this software less relevant in the future if other wiki software companies are willing to do things the people at Wikimedia aren't.
This is not a wrong list for this, though there's no perfect one.
All of this in my humble opinion - and please keep in mind that I'm
not a core developer of the MW code, though I do PHP and other
programming and web apps design on and off...
There have been for several years at least on and off extensive
discussions about the software platform, a next-generation MediaWiki
concept, etc. In general, such discussions have ended when backwards
compatibility problems poke up.
The existing software set is extremely complicated and featureful -
and, regrettably, most of that complexity and features set is in
active use within the Wikipedia and related sites environments.
A clean-sheet design which could throw out compatibility would
undoubtedly be easier and cleaner and could be done with reasonable
chances of project success. However, converting Wikipedia and related
sites to a non-backwards-compatible environment seems ruinously
impractical at the moment.
The reality of the situation is that MediaWiki isn't the Wikimedia
Foundation's product; the information content in Wikipedia and the
other projects is the WMF's product, and the MediaWiki software is a
spinoff. To the degree that MediaWiki is useful to people, that's
great. To the degree that changes to the software would negatively
affect the information in Wikipedia and other projects, though, the
software is very much a secondary concern. In this sense, the
software is very user driven, but it's not driven by the median
installation (many thousands of small MW wikis out there), but by the
one huge one (Wikipedia and related projects). Donations to the
Foundation are nearly entirely focused on the information content and
delivery - with some acknowledgement that software development has to
happen to support that - but not donations intended to improve the
Adding in a backwards compatibility mode to a new clean-sheet project
seems to more or less require grafting a full MediaWiki installation
on the side as a plugin module, as currently understood, which more or
less renders the point of a new clean-sheet project moot.
One could possibly design a new wiki system as a pass-through layer,
with MW as a back end and with functionality being migrated forwards
into the new system over time as people got used to it.
I think there's an opportunity either for a reconceptualized
enterprise oriented MW like system, but done in a clean sheet project
and partly or entirely outside the Wikimedia Foundation, or for such a
project as a passthrough layer intended to eventually replace MW and
done within the Foundation. Whether either of these will ever happen
I don't know. The most common Wikis seem to be MediaWiki (with all
its warts), Twiki (with all its lack of functionality and
administrative warts), and SharePoint (*cough*gack* - though I use it,
too). None of these is optimal for the typical wiki environment,
users or administrators. We seem to be muddling through.
I know open source software developers with large software project
architect and management experience; I've asked some of them about
this. They agree it'd be a great idea, if someone else did it.
If you happen to know someone else, I have people who would likely
commit some supporting coding effort and time and architecture and
management experience, including myself. But someone else would have
to get the project off the ground and spearhead it. I have too many
balls in the air (and a couple in nearby space and suborbital
trajectories) at the moment...
-george william herbert