The Wikemacs Experiment: 300 Days Later

21 Jan 2013

This pattern has happened over and over and over again. Someone built the system, they assumed certain user behaviors. The users came on and exhibited different behaviors. And the people running the system discovered to their horror that the technological and social issues could not in fact be decoupled. — Clay Shirky, A Group Is Its Own Worst Enemy

It really sucks that when Bozhidar Batsov put his big talk about how shitty EmacsWiki is into action, the only thing we got out of it was another shitty wiki.

It bugs the everliving hell out of me that even though engineering is supposed to be a rigorous discipline, we throw all kinds of shit at the wall to see what sticks, without ever looking at the walls in the last four or five rooms to see what the hell worked the last time.

So now some people are putting information in one wiki, and some people are putting information in another wiki. And nothing has really changed to address either the needs of the community, or the needs of the people who don't have a say, who just need the help, who just wanted one resource that wasn't shit.

The Problem

We all know that there is a fine line between writing one to throw it away and burning it all down for a fresh start. What EmacsWiki needed was evolution, and what we got is just another terribly manned wiki spreading obsolete, contradictory, and just plain wrong information.

I'm just going through this and it's driving me mad.

"Are you a maintainer of a Built-in Package? If you don't find information about your package, please add it." Do you really think that's going to happen? Do you really think whoever wrote Diary is going to fucking... what, join your tumbleweed-infested wiki to discuss his implementation? Meanwhile, the page on Diary mode on the EmacsWiki is chock-full of syntax examples, and code snippets, and alternatives, and links to patches.

Look at all the fucking work that went into documenting Icicles on the old wiki! And on the new wiki, a single sentence: "Icicles is an Emacs library that enhances minibuffer completion." Fuck community, how the hell are you going to get that one guy who really gives a shit about Icicles to recreate all his work somewhere else? Are you crazy?

"Org is the de-facto authoring tool within Emacs." Oh, really? Who did you ask to figure that out? How did you define 'authoring tool'? How did you determine whether or not Org fit that description, and if it fits it to a 'de-facto' tee? Or is this just some nonsense that doesn't help anyone? And if so, how well is your new little wiki really working out? How come you cared more about MoinMoin versus MediaWiki than the confused beginner who read this and was not helped?

And now we're having two separate sets of conversations about two separate wikis, in countless places, discussing spam in two different places, discussing licenses in two different places.

The problem is the new Emacs Wiki didn't solve a single bloody problem of the old Emacs Wiki, and that's a pretty big fucking deal if we're going to walk around like big-boy-pants engineers.

The Architecture

The EmacsWiki is written in Oddmuse, which appears to be maintained almost exclusively by Alex Schröder. There's a whole buncha shit here. I don't know Perl but some of this code looks pretty tite, and he uses strict so he can't be all bad, right?

Do you really want to re-implement all that functionality in another Wiki engine? Do you even know all the features that are available in it? Hell, does the author even know? Did anyone ask what features Oddmuse offered and then checked to see that equivalent behavior existed in MediaWiki, or could be quickly added?

Not to mention, would someone be willing to pick up the slack and hammer out the terrible PHP that would be necessary to add the functionality to MediaWiki if it didn't exist? Did someone prostrate themselves to a Perl monk to look at the code and even determine if it was in a maintainable state? Did someone talk to the people who worked on Oddmuse to see if the desired features could be added with some level of ease and effectiveness?

No, of course not. We just installed some PHP app on a server and called it a day. This is really stupid.

The Code

I don't know how I'd even go about articulating this. If there's Emacs modules and source code snippets on the wiki, and people of all walks of life and using all different versions of Emacs are using those libraries, and don't want to just switch to using a new tool because you say the markup language in your wiki software is better, that's a real problem. And it has several real facets to it.

There are real problems with the code on EmacsWiki.

The biggest problem is that it is insecure. Not that it's not in GitHub. It's insecure. Anyone can edit any of the pages that contain Elisp code. I have personally spoken with people who are turned off by EmacsWiki because of this. They find it untrustworthy. So, what are you going to do about that? I didn't see a single word on either of Batsov's posts about security.

The second problem is that it's not in an environment that is conducive to maintaining robust software. It's hard to tell who the maintainers are. It's hard to tell what version of the software the documentation on the wiki is talking about. It's hard to file bugs against, and it's hard to contribute to.

How on earth did anyone say that we needed some wiki revolution when not a single one of these concerns was addressed?

The Community

EmacsWiki has the same problems as every other online community that has ever existed. And every single online community has had to ask difficult questions about the kind of place they want to be, and what they're willing to do to get there.

We're super lucky because we already have a mission statement!

The EmacsWiki collects, apart from fun and jokes,

Do we need to buck some of these things? Do we need to streamline our goals? Do we really need to make it a priority to keep crap about XEmacs? Maybe! I have no idea! But I don't think anyone did, and I don't think anyone bothered to find out.

I mean, I could be wrong. Someone could point me to a mailing list discussion where these questions were asked, and answered with some level of rigor that allowed the discussion to continue. I would love to be proven wrong. But for some strange reason I don't think these discussions happened.

We have a benevolent dictator for life. Alex runs the wiki. People like him for doing that. He doesn't even ask for any money, for fuck's sake. So I really feel strongly that we erred here and that we need to approach this like adults.

Okay Asshole, You Suggest Something

Well, I already have. The real problems need to be talked about in a mature, rigorous fashion, and eventually someone needs to put their foot down and say, "if we don't decide about this now, we're never going to, so let's pick the best solution we have, and move on."

So here's a few sample ideas. I think we need to deal with the authority problem first. If we're going to take a lightweight approach to accountability, people should need a valid, active e-mail address to modify source code in the wiki. If we want to bring out the big guns and require some other means of identification, then we need to have that conversation, and then we need to make a decision and live with it until we can evolve it slightly again.

People need to be able to determine how useful code is to other people, and they need to be able to file bugs against it. And yes, it's going to suck, and no it's not going to be glorious. This work isn't gonna get you on the front page of Hacker News. One of us is going to have to go through the wiki, and determine if, say, this module for Amazon web search from 2007 still works. We may have to put out calls to action for code that requires a maintainer. But download counts would be nice, ratings would be nice. Why isn't there an Emacs extension so we can rate and file bugs against code we're using from the EmacsWiki, and see from the server side what people are using what versions of Emacs to access what content?

Maybe someone could work with Alex to add gist-style code snippets to Oddmuse, and make it so that code can be cited inline on Wiki pages, so that anyone visiting the page is automatically looking at the most up to date version of the code.

Maybe Oddmuse needs username branches of code so you can have and and

Yes, this is going to be a lot harder than the current plan. We can't just tell everyone to use GitHub and MediaWiki, and ignore them when they say, 'No'.

And about the community?

EmacsWiki is a fantastic resource! We should be lucky to be stuck with it. The people who are dealing, thanklessly, with all the bile and misinformation on it are to be commended. You don't see the stage crew but it doesn't mean they're not there. And you can't just assume they're going to speak up, either. Maybe they don't want to make a fuss. Maybe they're too busy quietly doing the un-glamorous janitorial work of mopping up the vomit from the rest of the community. Without Alex we wouldn't even be having this conversation. So what are his goals for the wiki? How do they coincide with the community's? Do we all have the same priorities? Can we have a conversation like adults to help us align our priorities so we don't waste everyone's time and effort?

And in general I guess my advice is this. I know programming makes it feel like you have access to some infinite canvas, and that no problem is too large to solve with the power of software. But you can't do everything, and code doesn't solve every problem. Every once in a while you might have to sit down and focus on actual grievances. And find compromises. And accept that if it's really important to you, then it might be important to others. And that working with them to improve what you have is an idea orders of magnitude better than throwing the collective work of hundreds into the dustbin just because.

There's a lot of frustration here. I don't mean to single anyone out. We all suffer when we let this happen to our communities. We have decades of recorded experience of how to keep strong online communities. And we know how easy it is to get into 'engineer' mode and open up our editor and code the problem away. So let's learn from our mistakes, and love what we do enough to make it truly better.