Here’s a rant by AlexSchroeder as posted to the gnu.emacs.help newsgroup on 2008-10-23. The real information is on MissionStatement. 😊

Haphazard Content

The content, is kinda haphazard. It is somewhat in-between of a encyclopedia-style treatment like Wikipedia and a chaotic online forum. Specifically, when you visit a article, half of article will be dialogues between different users on tips or issues or preferences.

For Emacs, I don’t care about a perfect wiki that can replace the manual. Emacs is and remains the self-documenting editor. As such, the good stuff, the well explained stuff, the carefully thought out stuff, the edited and checked stuff should go into the manual – either the EmacsManual, or the EmacsLispManual, or the EmacsLispIntro. I don’t care. When I set up the wiki I was frustrated with how slow the FAQ was changing and the endless repetitions on the newsgroups and mailing lists. That’s where the wiki fits in: It changes faster than the FAQ, it has less repetitions than the newsgroups and mailing lists, but it is not as structured and honed as the manual is.

Comparing it to the Wikipedia, where the wiki is the real thing, or to the Emacs manual, is a no brainer. Of course it doesn’t compare. But it doesn’t have to. The wiki is in a separate category.

And of course the Emacs Wiki has the benefit of letting other people put their text where their mouth is: If people like Xah feel that the text of the wiki is lacking in quality, feel free to step up and work on it. Just like Free Software, complaining is far less effective than doing.

The only thing I will oppose very strongly is the setting up of guidelines and requirements and all sorts of foolish rules, because that doesn’t improve the text. It just prevents other people from posting. Way to go, social skills.


OtherMichael: I don’t have a problem with the EmacsWiki format – it doesn’t look like the hyper-groomed Wikipedia, but what does? EmacsWiki looks more like the C2 wiki – a wiki for people who do things. I see the same mixture of info-and-comments in the OLPC wiki. Having a “talk” or “discussion” link auto-associated with each page could reduce or redirect some of this, but it will never be perfect (OLPC wiki has discussion pages, and people still make comments w/in the main body).

Switching Engines

Alex, have you considered using a third party wiki engine for emacs wiki before?

No, never. I use my own software because I know exactly what it does, I have full control over the code, and I feel very comfortable extending it. Switching to something else would mean more work for me. That’s why I suggested that anybody interested in it set up their own site, start mirroring Emacs Wiki page content, look at all the background jobs, redirects, URL rewrite rules, text formatting rules, etc. And when they’re finished, handing over the domain name will be a trivial thing by comparison.

But I’m not willing to do the work for somebody else. They need to do it themselves.


If anyone is serious about setting up a mirror, fork or re-engineered emacswiki, the content is available via various methods detailed on the WikiDownload page.

Engine Voting Booth

We might just as well start voting here. If you consider this inappropriate just delete this part of the page.


*OtherMichael notes he doesn’t advocate switching engines, but that if we do, there’s a PmWikiMode available

*XavierMaillard is opened to eventually use ikiwiki (at the very least).

Why I don’t think a vote is appropriate: Because switching engine means, if i read correctly, replacing Alex. Honestly, I would rather keep a buggy software (which is not what oddmuse is) and Alex than see emacswiki run by someone else, even if they set up an alternative.

Alex has been paying for the site (which is ad free), has always justified every choice he made, has welcomed every new user personally, has always responded to every demands made for an enhancement on the site, has written more pages than anyone else which is why emacswiki still exists in the first place etc.etc….I honestly doubt we can find someone half as good for the job as Alex…

I agree with Pierre. Alex is good at this job as already said on the mailing-list.

A absolutely agree, too. Actually I started that booth because I am convinced that the keeping of Oddmuse will receive an overwhelming success. – StefanKamphausen

‘Unstructured’ is not an argument really. Most Wikis are not very well structured. However, it’s easy to find stuff. The search and categorisation is quite neat on this site. A general Google search for and Emacs related issue and the wiki is almost always in the top 5 hits. In that sense, it is pretty authoritative and reliable. As for moving to a new engine, I don’t see any reason why we should. Unless there’s some kind of technical limitation or performance problem with oddmuse, there’s no real reason to move. I’m not aware of any till now. Finally, replacing Alex as the ‘owner’ (in some loose sense) of emacs wiki will be a real dumb move. His involvement with the whole project is the single strongest reason that the site has grown so much. – NoufalIbrahim

I’d like to emphasize a point Alex is subtly making about the current setup: Whether Oddmuse or some other WikiEngine, the EmacsWiki – a collection of both software and authored works – is from top-to-bottom FreeSoftware and FreeDocumentation and it should continue to be. Most online resources are not socially responsible in this manner. Through the measured work of Alex – and a cast of hundreds, he’s given the community the ability and the RightToFork (WriteToFork?). Obviously, he’s contributed immensely to a useful community resource, but most impressive in my opinion is his commitment to software freedom and transparency. This quality of EmacsWiki has enabled Emacs users to emphatically contribute back, and also provides the community the freedom to upgrade EmacsWiki down the road. Thanks, Alex et al! – AaronHawley

The 2012 Rant

More ranting by AlexSchroeder!

(TL;DR: People that don’t like the wiki as it is ought look at the official Emacs documentation instead. I wrote this so that I’d have something to link to in the future. This post was inspired by 2012-03-20.)

Every year or so, I read about suggested changes to the Emacs Wiki. The complaints are the same, year after year.

1. The pages are confusing. 1. The code snippets are wrong. 1. The site is badly organized. 1. The information is out of date.

The solutions invariably have nothing to do with the problem.

1. Switch to Mediawiki, the software used to run Wikipedia. 1. Use a database or a distributed version control system as the backend. 1. Change the text formatting rules to Markdown, Mediawiki markup, or something else that is better known. 1. Separate discussion from the main page. 1. Delete stuff that is outdated. 1. Fix errors. 1. Organize. 1. Moderate.

Why are these suggestions not helpful?

The first problem is the mistaken belief that technology can substitute for social change. Yes, the wiki is badly organized and many of the pages are outdated. Changing the wiki engine, the backend or the formatting rules will not change this, however.

The backend used by the wiki engine can influence performance and resource use, it can make the software harder or easier to maintain and backup—but it will not induce somebody to edit a messy page and fix it.

The second problem is the mistaken belief that moderation can be commanded. You can complain about bad editing and a lack of moderation all day. But since nobody is paying people to do a boring job, we must rely on obsessive compulsive people to fix typos and tag pages.

Maybe we could attract more people by gamifying the experience—offer rewards, badges, scores. But Stack Overflow already does this. It’s the best social question answering machine currently known. The wiki doesn’t need to imitate something better. The wiki needs to do what it does best. We’ll come to that.

The third problem is the mistaken belief that quality control and volunteers go well together. Just compare Wikipedia and → Citizendium (en) and consider the animosity generated by → Deletionism (en) on Wikipedia. How will you encourage authors to contribute if you are telling them that their contributions are lacking the quality you are looking for instead of simply accepting their text and working on it?

You fight spam, you rework text occasionally, you encourage others, you welcome newbies, you lead by example. That’s how you lead.

An abrasive personality, radical change involving a lot of work—those are not the tools you are looking for.

Let me return to the issue of commanding change. Things people have said:

“the content editing should be one with the goal of creating a comprehensive, coherent, article that gives readers info or tutorial about the subject.” – Xah Lee (2008)

“I favor a major reorganization of the wiki material.” – Neil Smithline (2011)

“The articles are littered with crappy advice confusing beginners, have little structure and are filled with ridiculous questions” – Bozhidar Batsov (2012)

“Wiki is a hydra you cannot cut enough heads off to make it die. I tried, and failed miserably. I suggest you don’t waste your efforts and time on that.” – Eli Zaretskii (2014)

“What I propose is starting anew and getting rid of a few common complaints at once.” – wasamasa (2015)

The critics can be unhappy about it all they want, and they can complain about it all they want—but in the end, one needs to understand the forces at work, here. There is no chain of command.

It works just like a free software project. If it doesn’t scratch someone’s itch, nobody is going to add it. I think it’s a fundamental issue with our business model: there is no pay for boring stuff. Plus, documentation is of no direct use for anything—unlike code. Thus, people are mostly motivated to keep their own code and its documentation up to date. I don’t think there is anything we can do about that. That’s why the Emacs Wiki Mission Statement does not mention organization and quality. It cannot be commanded.

Once we accept that this is the sand upon which we are building our house, we necessarily need to scale down our expectations. Personally, I think the wiki exists somewhere between the official documentation, Stack Overflow, the FAQ, the newsgroups, the mailing lists, and IRC. It’s certainly nowhere near the quality of organization and writing that the Emacs documentation has—and I don’t think this is the right medium to aim for this level of quality. I think the people willing to invest that amount of energy to write quality stuff ought to be writing the real Emacs documentation—and they probably are.

What remains are the people using Emacs Wiki for their own pet projects, questions asked, answers given, sometimes organized, sometimes rewritten, sometimes linked to the rest of the site.

Wikipedia works because of its universal appeal. When I added an image to an obscure Indian temple we visited when I was staying in Mysore, the photo was terrible. But it was a start, and enough people cared about the page and it grew, and it found people to tend it, and now it’s big and beautiful.

There just aren’t enough Emacs users and authors out there and the best of us will be contributing to the official Emacs documentation. The wiki exists somewhere between the official documentation and the mailing lists. Lower your expectations.

Given all that, why does the wiki exist at all?

When I started it, I had several reasons:

1. The wikis I knew, C2 and Meatball Wiki, had attracted a particular community and they had created a particular subculture I liked. We talked about the Wiki Now and many other things that made wikis work. The medium itself was interesting.

1. I had been posting on the newsgroups for a long time, and slowly I realized that the same questions kept being asked again and again. The newsgroups and mailing lists were failing as a medium because they were ephemeral. Sure, we kept telling people to search the archives. But the medium afforded asking questions instead of searching.

1. When I looked for Frequently Asked Questions, I found a document online, maintained by a single person. This person was a bottleneck. The FAQ updated slowly.

1. At the time I was getting into Internet Relay Chat. On IRC, conversation is even more ephemeral than on the mailing list. This time, however, “searching the archives” was out of the question. We needed our own archive. And thus I started answering questions on IRC and posting the answers on the wiki.

I think this last point bears consideration: I was creating pages or adding information to pages because it was pertinent on IRC. An index, linking to the page, categorization, returning to the page later and reworking it, all these quality related tasks were not pertinent on IRC. All I needed was a pastebin that I could go back to and rewrite if I felt like it. Often I did not—and I still don’t.

The wiki being on the web, updated every now and then, with pertinent answers to specialized questions, unorganized and raw, ended up being a good resource for the search engines out there. These search engines bring new people to the site. People that don’t understand how wikis work in general and how this wiki grew to be where it is in particular. They are shocked. So many pages outdated! Such a mess in style and quality!

I think those people are better served reading the official documentation. They don’t want this mess, they don’t benefit from it’s loose rules, they don’t understand how cool it is to have a site with no login required. They are better served elsewhere.

I’m sure that one day the Emacs Wiki will have become irrelevant. But just like the old newsgroups never disappeared entirely, so will the wiki transform into something else and remain part of our information landscape.

Perhaps one of the Emacs Wiki critics will one day set up an alternate site, pull all the pages (more than 8500 pages last time I checked), extract the quality content—or rewrite it from scratch—and produce something better. Perhaps they will build an organization that can keep the quality up, encourage new authors to join, provide more value to their readers. But I don’t think complaining about the existing Emacs Wiki is a step in the right direction. Build it, and they will come—elsewhere.

You can leave comments on the original blog post.