Interview with Marcus Ramberg, Creator of MojoMojo

There are so many different wiki packages out there, what made you start a new one?

I had been using Ingy.net's Kwiki package previously, and was pretty unhappy with it's performance, as it was built on top of a VCS that made it really slow. I decided to build a Perl-based wiki with a pure SQL storage, for performance reasons. I was also interested in learning more about this new-fangled AJAX stuff that I had been hearing about, so I used mojomojo originally as a test-bed for learning Prototype. That's one of the reasons why MojoMojo has more JavaScript functionality than most other wikis out there.

It doesn't use prototype anymore though, right?  What library is it using now? Why did you choose that?

We have recently migrated all the Javascript code to JQuery. We really love how compact and unobtrusive javascript we can write with it. The selector system is just incredibly powerful. I had already converted all our sites like iusethis and Phiary to use it, so it just made sense to make the switch.

You mentioned that you originally worked with Kwiki and found it's base on version control to be problematic.  MojoMojo has versioning on page edits right?  Were there any challenges making that work well? 

Sure, MojoMojo has full versioning and diff between older revisions. The entire storage is handled by DBIx-Class, which made it fairly easy to implement. The other hard lifting is done with some handy CPAN modules, most prominently Algorithm::Diff.

What do you feel sets MojoMojo apart from other wiki software?

A major difference in how it works is the whole tree-based system. Rather than having a 1 or two level wiki namespace, MojoMojo supports unlimited levels of nesting of pages, for instance /Engineering/Meetings/Development/2008-01-01 would be a perfectly valid wiki node in MojoMojo. We also support a very powerful ACL mechanism which lets you set permissions rules on any level of the tree. 

Also, as I mentioned above, we're providing a rich user experience, for instance, we generate live previews of the wiki markup as you type, as well as the toolbars you traditionally see in other wikis (for instance mediawiki). We also provide batch uploading with progress bars. Once you've uploaded some images, we autogenerate galleries for those attachments.

That sounds neat.  Are the galleries page specific?  Are there any other media related features in MojoMojo?  Are you thinking of adding any more?

Yes, the galleries are per page, but you can also categorize them with tags, which gets aggregated downwards in the tree structure. There is a formatter that lets you embed entries from amazon based on their URL, and there's a youtube one in the works that will make it into the next CPAN release.

I've also started work on an OEmbed formatter, which seems like our best bet at programatic embedding other content at the moment. OEmbed works by querying each site for their embed code based on the url. Hopefully it will get widely adopted.

Do you have any specific goals for the MojoMojo Project?

The most important goal now is to reach 1.0, and freeze the final details of our wiki-syntax. From there, I mostly want to make MojoMojo even more customizable and extensible.

I know MojoMojo has worked with various markup libraries and modules, Markdown, etc.  Is MojoMojo's syntax a hybrid now? How do you see this developing over time? 

The syntax system of MojoMojo has always been pluggable, so that which primary formatter to use (Textile and Markdown at the moment, but others could easily be supported) is a system-wide choice. This also means you can easily write your own custom formatters to do things like parse irclogs or embed widgets. 

The system currently works using Module::Pluggable::Ordered, so that the formatter chain runs in a predictable order. However, we are considering supplying this with using Template Toolkit so that many plugins can just be written as functions or filters in TT.

Currently, we have about 8-10 people who contribute regularily. Historically we've had a lot of other people who've contributed source to the project though.

I think it's pretty fair, considering that we haven't been on CPAN that long, and that we still haven't reached version 1.0. I believe that one of the barriers to adoption has been the heavy dependency chain of MojoMojo, which is one of the reasons I was pleased about it being packaged for FreeBSD recently. I also hope to see a debian package of it in the near future. 

I think a lot of the power of MojoMojo comes from all the great CPAN modules we use. Of course, it can be an inconvenience to have to wait for all the tests to run, which is why it has been important to me to find alternative distribution methods like FreeBSD Ports and Shipwright. However, I think it's more important that the tests pass. I think that the relentless work of the CPAN smokers [cpan testers -ed] has been instrumental to build a product on the shoulders of as many giants as MojoMojo has done. 

Test reports also show up in search.cpan.org, so a tip would be to check smoker reports from modules you consider using in your open source project.

There has been some work in this area, both using PAR (Catalyst supports building PAR archives of your app), and Jesse Vincent's Shipwright system. We hope to have this in place for the 1.0 release. The disadvantage of the PAR approach is that it is architecture specific, so we would have to distribute separate distributions for each OS.

The project has been a very long running one for me, but I really feel that it's just recently gotten more attention. I thing the future is bright for MojoMojo, and I am excited to see what all the other brilliant developers contributing their time to the project comes up with. 

Thanks to the open nature of Git versioning, we're now even getting contributions from people who haven't even talked to us. I think it's brilliant when I get a pull request in the mail from someone who's forked the codebase and written a DocBook formatter or some other useful addition to the project.

I don't personally plan to start any encyclopedia, but I think it could absolutely make sense as one. For instance I think it would be well suited to implement the kind of workflows in use by the national Wikipedia competitors.

Thanks Marcus!