Category Archives: MediaWiki

Addons, Extensions, and Mods – Oh My!

I’ve been doing a lot of work, recently, in three different projects: MediaWiki, Minetest, and Etherpad Lite.

In each of these projects, there exists at least one way to add on small, additional features, or change the way the software behaves. It has struck me as a very interesting construct, and I think that it could be a very useful thing for almost any project to have. So, I’d like to share what I’ve learned.


My experience with MediaWiki extensions is mostly through the two I’ve helped so far: EtherEditor and UploadWizard. They both do a lot of different things, and they both tie into the MediaWiki interface in one way or another, but the really interesting part of the development of an extension is that, while there may be a lot of interplay between the extension and MediaWiki proper, the extension very much feels like its own project. You can easily install and remove the extensions, and they sometimes have their own code hosting. Having this separation is immensely helpful for the developers, because it gives a sense of independence, and allows for much more modular code.

Of course, it’s also a gateway to modifying the core of the project. While I did fix most of the bugs I found in UploadWizard by simply changing the UploadWizard code base, there were a few instances where I was forced to enter the MediaWiki code, and fix something there. Maybe that seems undesirable, but having worked with the extension for a few weeks by then, I was relatively well-versed in the MediaWiki style, and could dive in with relative ease to find the problem. This leads to another benefit of this kind of contribution: It makes for very literate contributors, and since everyone has to play in the same sandbox, they very often contribute any patches to core back to the main project.


I’ve talked about Minetest before, but this time is a bit different: The modding API has existed for many months now, and in the words of Perttu Ahola, the main developer, game content has exploded.

The really interesting thing about the Minetest system is, while the core game is written in C++, the mods are all written in Lua. This was a choice made early on, and it somewhat separates the two communities—modders and “core” developers. While I’m not sure there’s any way to circumvent that separation, I feel it could be handled better, and perhaps I can muse on that in a later post.

In any case, the Minetest system also offers a very interesting benefit: People have dived in to create something, and hopefully learn something, who otherwise might not have learned to program at all. This is a parallel to the World of Warcraft modding community, and even uses the same language. People who happen to learn the game, and enjoy it, eventually learn something of the Lua API and start playing with it. After talking to the rest of the community and learning from them, they learn even more about programming.

Another confusing part of the Minetest modding community is that, while mods are simple to install, there is no real central place for them as yet. I’ve done my best to create a starting point, software-wise, but it has mostly been stagnant, and nobody appears to be interested in using it. The forums for Minetest house the majority of the release announcements and documentation, but the community could definitely use a move to a more comprehensive place for issue tracking, wikis, and code hosting.

Etherpad Lite

The final example is one near and dear to my heart. Etherpad Lite, a fork of Etherpad, has been recently building a more robust community, filled with new faces. A lot of documentation was provided, and suddenly the Plugin API was useful, and people started writing code for it.

The most interesting change here is that, while a lot of people have enjoyed using the Plugin API, there are still a lot of missing features. Almost every plugin that gets discussed in the IRC channel (#etherpad-lite-dev on Freenode, come join!) will require some form of modification to the core. But the really cool thing is, the contributors are able to just do it! Now, with MediaWiki, it’s definitely possible to contribute a patch to core. But the response time is usually pretty high, which is fine, but it makes for some very slow integration time. If a company wanted to deploy an extension, but needed a new hook to do it, they might need to wait weeks, unless they made a lot of noise, to see that new hook integrated into the core. There’s a danger, there, of losing potentially helpful contributors. To the credit of the Etherpad Lite devs, they have responded with a latency of, at most, a day or two. And they’re getting more numerous, and faster.

Conclusions, take-aways, do this with your project

I wanted to compile the really useful, bare-bones, what-you-must-absolutely-know points of this post, so that anyone interested in adding this sort of system to their project, or anyone interested in improving their existing system, can use them. Here they are:

  1. Allow as much freedom as possible to your contributors. I’ve seen projects that require a specific API be used, that require registration and/or payment for the SDK….none of that, please. If you’re going to let people build on top of your project, give them an open field to build on, not some gated community.
  2. Choose a simple language. Now, if you’re paying attention, #1 should mean that you allow any language, but assuming that’s not possible, please don’t choose a compiled language. Use something interpreted, and make it at least somewhat relevant to your project. For MediaWiki, PHP was an obvious choice, but Minetest’s choice to use Lua also made some sense.
  3. Make it sort-of-centralized. However much I disagree with GitHub, I have to begrudgingly say that they have a nice system for this sort of thing. I use Gitorious to host my mods and plugins, but they don’t offer issue tracking, so if you do go that way, be prepared to set up Bugzilla or something. Don’t, for example, host your mods on a forum. It’s not easy enough to access, and the information is too sluggish to access.
  4. Document it really well. Minetest does a pretty great job of this, since there is a big file with *all* of the API methods and tables, as well as the “default” mod which has pretty good examples for just about anything you might want to do. MediaWiki tries, I think, but they could use something a little more concrete.
  5. Make good examples. This is a sub-part of #4, but it also deserves its own separate item. With Etherpad Lite, we made a separate repository with the skeleton all built out. Neither of my other examples, to my knowledge, have such a thing–or at least, it’s not easy to find!

Please take these five simple points to heart, and do consider using this idea of allowing small additions to a project via simple, separate modules. It’s a really great way to build a huge community of awesome developers.