Browsing around among the Google Summer of Code projects, I noticed
that a lot of the links to "ideas" pages pointed to MediaWiki
installations -- many sites even used MW as their only CMS. I decided
to do a quick count of the wiki engines and CMS used, which might be
interesting to others as well -- SoC is a valuable sample as these are
many of the leading open source projects.
28 static pages or unidentified (usually custom) CMS
22 MediaWiki installations (Beagle, Blender, Creative Commons,
Etherboot, FFMpeg, Inkscape, Jabber, Mars Space Flight Facility,
Moodle, MythTV, One Laptop Per Child, OpenOffice.org, OpenSolaris,
OpenSUSE, ReactOS, NASA World Wind, Mono, Mozilla, Wikimedia,
wxWindows, Xiph, XMMS)
14 MoinMoin wikis
8 Drupal installations (CMS with some wiki-like elements)
5 TRAC installations (very cool integrated bugtracking/wiki/everything)
3 TWikis (wiki.java.net only counted once)
2 UseMod (keep up the good fight!)
2 Confluence "enterprise wikis"
1 unidentified bugtracking system
1 unidentified blog engine
1 JotSpot wiki (evil proprietary engine! ;-))
1 EditMe wiki
1 "Wicked" wiki
1 Joomla CMS
1 Plone CMS
1 unidentified wiki
I found it funny that quite a few of the MediaWikis use CamelCase
though they don't have to. This is often because they were migrated
from other wiki engines.
I was quite surprised by how well MoinMoin is doing, and how poorly
TWiki. If even the geeks don't like TWiki anymore, I guess it's dying.
Of course MW's showing is excellent - and a bit scary. I will be very
happy when all these typically English-only wikis become fully capable
of accepting multilingual content -- this could benefit _huge_ numbers
of people outside the Wikimedia community, where we achieve
multilingualism through a complex multi-database setup that most sites
will not care to replicate.
Just a quick mention that a lot of projects choose something to
supplement or replace mediawiki only because mediawiki lacks _simple_
access control mechanisms per-page and per-namespace.
I've seen one guy initially go to drupal because of it, then switch to
mediawiki after some fussing about (linuxcaffe.com). I've seen one
project go to confluence partially because of that and because they
wanted an "all in one" system (watir.com/.net). Others have squirmed
around with the issue (gtalug.org) and ended up just not bothering.
Some just went with whoever was fastest to the gun (pclinuxos.com).
A lot of businesses use mediawiki for private purposes. Mine has four
installations for various uses. =/
Some just choose mediawiki because the one guy who was interested
bulldogged for it (trug.ca). For me.. I tend to leave a trail of
mediawiki installations wherever I go, and walk away from places that
use other engines.
MediaWiki is popular because it's running the wikipedia (etc) and
because it's so easy to set up.
> Just a quick mention that a lot of projects choose something to
> supplement or replace mediawiki only because mediawiki lacks _simple_
> access control mechanisms per-page and per-namespace.
One of the wonders of developing mediawiki is that we do not *have*
to "sell" a product. The prime objective is to develop something
that's usefull for the wikimedia foundation, for use on their various
projects. If, by incident, the software is usefull in other contexts,
that's a nice bonus.
Since the goal for the WMF is openness, and will likely continue to
be so, it is highly unlikely that the mediawiki codebase will include
ACL's beyond our current needs, ie. restricted acces to particular
Adding a fine-grained ACL is not one of the core requirements, and
since it would bear a severe performance hit, I don't see this as
coming anytime soon. *Maybe*, and that is pure speculation on my part,
the future development will eventually bring hooks for som external
ACL mechanism. But this is not something I see coming within the