TooManyWikiEngines

There’s tons of different WikiEngines (or WikiClones) out there. This provides a vibrant diversity of ideas, but it also means that the sum total of wiki developer effort is split into 1000 pieces.

One aspect of the problem is that in order to try out a few new features, often a developer simply forks a WikiEngine. The different wiki engines are like lots of small tidepools, each of them with a few unique features, most features being stuck to their WikiEngine.

Similarly, it is hard for a new feature or a new WikiEngine to be adopted by many wiki communities; wiki communities are “stuck” with their current wiki engine, because it is hard to move the content to a new one.

My personal effort to improve the situation is not to try and get convince people to stop forking wikis, but instead to create tools which make the situation more fluid. Tools to allow new features to flow more easily from one WikiEngine to another. And to allow WikiEngines to fluidly flow into one another. Another word for “fluidity” here is probably “interoperability”.

First, the WikiGateway project will allow wikis to better interoperate with each other and with other software.

Second, the WikiGateway project will allow the PageDatabase to be exported from one wiki and imported into another. Eventually, it will also translate from one style of WikiMarkup? to another. This will allow wiki communities to switch their WikiEngines painlessly.

Third, the WikiWindow project will allow different users to interact with the page database using whatever WikiEngine frontend each user desires.

Fourth, CommunityProgrammableWikis will allow users communities to add features to exisiting WikiEngines without forking them, even if the WikiEngine’s developer is too busy to approve the features.

Fifth, CommunityProgrammableWikis will allow developer communities to merge and refactor different WikiEngines together. For example, one could set up a CommunityProgrammableWiki housing UseMod, OddMuse, and all of the other UseMod descendents, and then a community of developers could refactor the code together just like text on wiki pages.

::See CommunityProgrammableWiki:SpwIdeas for some of Mitchell Charity’s ideas for CommunityProgrammableWiki which I think could be applied here.

These tools will

This is what I mean by making the situation more fluid;

BayleShanks

See Also

CategoryWikiTechnology

Discussion

I would want this page to be named something else. I’d call it “TowardsEasilyAmmendedWiki,” or something like that. I want to link to it or copy it to WikiFutures. – LionKimbro

Feel free to copy the page. I think the name TowardsEasilyAmendedWiki doesn’t quite capture the topic of this page. Things like ExtensibleWikis, CommunityProgrammableWiki, and WikiPlugins seem to be part of making wiki software easy to change. But ideas like making it easy for individuals and wiki communities to change WikiEngines, and making it easier to merge different wiki forks seem to be different from that (although related in that the ultimate goal of both is to speed up wiki software evolution).

BayleShanks

I agree with Bayle, the new names don’t improve the situation. How about WikiEngineFlexibility or WikiEngineIndependence or WikiEngineDependence (depending on how you want to phrase it). – AlexSchroeder

How about WikiFlexibilityPlan?? LiquidWikiPlan?? WikiDiffusionPlan?? BaylesDiffusionPlan?? – LionKimbro

Maybe this page should be split: One to explain the goal (independence from the underlying wiki engine), listing various technologies to achieve that goal with a short description, and then move the details to the appropriate pages. – AlexSchroeder

I thought that’s what I did :). Anyhow, my thinking on this page is based around a problem (there’s too many wiki engines and so developer time and ideas are scattered), rather than a single goal. I am dealing with the problem with a few qualitatively different goals. For example, more independence from the underlying wiki engine treats the symptoms of the problem by making it matter less that there are a thousand different engines. Community programmable wiki treats the cause of the problem by removing some of the need for developers to start their own projects.

BayleShanks

As a caveat, could I throw in the idea of a ParadigmShift here? Maybe the reason the original WikiEngine has not forked in the common understanding of the term but more “exploded”, is because we’re still exploring ways of understanding an addition that is not another step on the evolutionary expansion of a paradigm (e.g. though emacs has gone further beyond the paradigm of a text editor it can still be used that way which is perhaps why the exploration of EmacsWiki is still less consciously the exploration of something totally new than the exploration of the radical possibilities of the NewFeatures? rather than anything else - OK, maybe that’s a bad example) but something new?

Yes, I agree, that’s a big part of the reason there are TooManyWikiEngines. A wiki is a new very large, very different class of thing; it’s as general and as basic as a “book”. – BayleShanks

How about UnifiedWikiEngines? (c.f. UnifiedWikis, UnifiedRecentChanges, UnifiedClusters, yadda yadda.) The name of this page is a statement of perception, whereas you want a statement of intent. Then make it a cluster :) It sounds rather interesting.

For a year and a half, there was a brief explosion in wiki development as the principle wiki developers started exchanging ideas and code on MeatballWiki. Currently the major wiki developers are no longer enjoying the dot.com funding that gave us the leisure time to hack wiki. Alternatively, we’re bored and off onto other things. Now bloggers are entering the fray and reinventing the wheel for several different reasons. The path is to ignore the wikis that ignore you, and focus on those clustered around c2.

Don’t forget that “wiki” is an abused term; they are so simple they are almost a style rather than a technology. People will add technology they want just like people will change the CSS on their homepages as they want. It’s easy, so it will be done. That’s cool and interesting and not worth worrying about. The question is what wikis do you want to cater to? I’m interested in wikis as OnlineCommunities. Others are interested in WikiLogs, others are interested in WikiAsPIM, others are interested in wikis as Wiki:CollectiveNotepad, and many are interested in WikiPedia-like things. All will and have diverged. – SunirShah

I agree that the idea of “wiki” is too large to be served by one or a few programs. But I also think that the number of wiki engines targeting each similar subset of goals is so large that developers’ time is being split too much.

I think the lack of developer time due to the dot com crash points towards the same conclusions; if developer time has become more scarce, then perhaps the number of simultaineously developable projects must drop, just as industries consolidate when their profits dry up. – BayleShanks

They are. Wiki engine projects will die. Only those with viable communities will survive, like TWiki and MoinMoin. UseModWiki might die. That’s evolution. – SunirShah

Yeah, I suppose that might take care of things. But there might be a resurgence, too. It just seems that with wikis, project fork all the time.

For example, UseMod has already spawned OddMuse, as well as a few other UseMod:UseModDescendents. The parent, UseMod, may die. But there’s just as much fragmentation if any one of the children survive, and more fragmentation if multiple children survive.

And in the meantime, the time spent implementing new features in OddMuse doesn’t benefit UseMod, or UnrealWiki, or IAwiki, or CommunityProgrammableWiki. And vice versa.

So, I’d like to make it so that, first, it becomes less necessary to fork a wiki in order to add new features, and second, it becomes more common for forks/children to become re-incorporated into the parent (refactoring of code across related projects). – BayleShanks

These are/were/are the goals of the InfiniteMonkey project. – SunirShah

Great! Then everyone’s thinking along the same lines, it seems. – BayleShanks

Couple of thoughts, I love these ideas! I think what is being discussed here sounds like SeamlessWiki? - which moves in the direction that Sunir pointed out, Wiki isn’t neccessarily a technology anymore, rather a style or quality. --MarkDilley

Hmmm, I’d still say it’s a technology. If the internet didn’t exist, I can’t think of any mode of behavior that I would call a “wiki”.

Standardize on a wiki engine

Another strategy is to standardize on a small group of wiki engines.

As I explained above, this is hard to do, so I think the better strategy is to try and increase “fluidity”. However, it’s worth discussion.

I noticed that in the most recent SlashDot article on wikis that a couple of people are saying that MediaWiki should become the de-facto standard.

So, why not at least make an attempt to focus our development on MediaWiki? The most compelling reason that I can think of is that different programmers will prefer different programming languages; the second most compelling reason is that they will like different wiki software architectural styles. Another reason is that it’s easier to add features to your own project than to get them into someone else’s (but this last reason isn’t so compelling because I suspect that you will get your feature into the other software, it’ll just take a few weeks).

For example, why doesn’t AlexSchroeder spend his time adding cool features to MediaWiki instead of continuing to develop OddMuse? I suspect it’s because 1) Alex likes Perl rather than PHP, and 2) Alex likes to be able to add whatever features he wants to the project without getting anyone else’s permission (am I correct?).

My preference, though, would be that we make at least a small attempt to mostly standardize on one wiki engine per programming language; my current personal picks are:

  • OddMuse for Perl (although, realistically, TWiki probably has to be included, too)
  • MediaWiki for PHP (PHPWiki is great, and I’ve never actually tried MediaWiki, but everyone else seems to like it)
  • MoinMoin for Python

Python is my current, personal favorite language, so I’d be in the MoinMoin camp, I guess. Although I like OddMuse better. I suppose this should manifest in me making MoinMoin more like OddMuse.

I guess you are right about the reasons for having my own project; I’d probably add “ease of installation” ot the list of features I consider important. I think on #wiki we’re starting to see what is going to happen more often now: Through the recommendations we make against PhpWiki and for PmWiki, we already guide users. I think we need more criticism of projects, more well-founded recommendations, basically we need more competition. The original list of engines (Wiki:WikiEngines) is failing our expectations because it is an unordered and uncommented list. That is no good, since you have to try them all in order to make an informed decision.

So, one thing to note is the great Wiki:TopTenWikiEngines list, which does a nice job of narrowing down the field of contenders for new implementers.

I think choosing MediaWiki as the de facto standard wiki engine is a horrible idea:

  • MediaWiki development has always and will always be focused on Wikipedia.
  • It is difficult to extend.
  • The code is indefensibly badly written. I know – I’ve written quite a bit of it.
  • It is difficult to skin.
  • It requires a database.
  • No WikiWords.
  • It is so slow that it requires tons of Squid server, memory cache add-ons, etc., etc. just to run correctly. The code is developed as if you have all these extra servers available, and if you don’t they’re stubbed out.

That’s not to say that I don’t think that MediaWiki is important for any discussion of wiki technical interaction, but I don’t think MediaWiki is the VHS of the wiki world. I do think that wiki engines should have an easy way to turn on “MediaWiki syntax mode”, so that admins who know they’ll have a WikiPedia-savvy community can easily get started that way. (I think PmWiki 2 will have MediaWiki syntax as an option.) But as we move into the WysiwygWiki era, I think that’s going to be less important.

Thanks Evan, that’s just the kind of thing that we need to hear! As Alex said, that’s just what we need: more critical evaluations and competition.

I propose that CommunityWiki hold an ongoing (or at least bi-annual) WikiSoftwareAwards?. We’ll have various categories, such as “overall best wiki engines (top 3)”, “best python engine”, “best perl engine”, “best new engine”, “best wiki-related software package that is not a wiki engine”, etc. The results could be announced on the CommunityWikiBlog.

Whether of not we’ll be able to reach consensus on everything is uncertain, but let’s give it a try; the discussions this will generate may force out the kind of critical comparisons that we want to generate.

I’m interested in doing something about the situation. I think we agree that tables with feature lists are not suitable. Assuming we actually go ahead with this, I think what would reflect our insights best is a collection of opinion pieces.

That way we can write a short piece of text arguing the case for every wiki engine nominated. The discussion could be along the categories you propose, but in effect, the main arguments could be different for every contest. It all boils down to us writing maybe four pieces with titles like the following: “Easiest to Install”, “Most Useful Featureset”, “Best Suited For High Traffic”, and “Favorite Wiki Engine For Python Hackers”. In each piece we’d recommend a wiki engine. Next semester we’ll write another four pieces recommending a wiki engine each.

Define external redirect: LiquidWikiPlan WikiSoftwareAwards BaylesDiffusionPlan NewFeatures WikiFlexibilityPlan WikiMarkup WikiDiffusionPlan SeamlessWiki

EditNearLinks: WikiPlugins MeatballWiki WikiEngine ExtensibleWikis MoinMoin WikiClone PhpWiki WikiWord UseModWiki UnrealWiki WikiMatrix ParadigmShift OnlineCommunities UseMod InfiniteMonkey PageDatabase WysiwygWiki WikiLog EmacsWiki MediaWiki PmWiki SunirShah WikiAsPIM

Languages: