[pmwiki-users] Selecting a Wiki engine...

Ben Wilson dausha at gmail.com
Tue Oct 3 11:09:48 CDT 2006


Before I get into the crux of responding to the lone developer/active
community argument, I would like to share what were the compelling
reasons I converted to PmWiki.

I had used Drupal before, and I was beginning to write modules.
Between minor revisions (e.g. 2.2 to 2.3) and sometime trivial changes
(e.g. 2.3.1 to 2.3.2) changes in the Drupal core were so significant
that modules I'd written a couple months before required significant
rewrite. These changes were virtually seasonal, so the code was very
unstable. I can only have my anthill kicked so many times before I
give up. (I help non-profits, and it's pretty bad when the software
you're using to support them encourages them to find your
replacement.)

I played with a few other wiki engines (noteably Twiki and MediaWiki)
but they left me unsatisfied. There was a lack of customizability in
the first, and the learning curve in the second was a bit higher than
I had time. I also lost enchantment with using RDBMS to store page
data. I'd used "the original wiki" as my guide to wiki.[1]

After feeling around a bit, I found PmWiki (the 1.x series).
Well-documented and intuitive in many ways. The 2.x series only
improved upon the first. The interfaces for supporting modules is very
effective in helping create modules. But, stability is what I craved
most.

You don't get stability from an "actively" developed wiki. You get
stability from a developed wiki that conservatively adds features. I
have recipes that date back a year that are still sound. I don't fret
that a recipe will suddenly fail with a new bug release or feature
release. The pagelist and page text variables are still settling a
bit, but I don't think I have recipes that rely on those.

I also like how easy it is to customize the wiki---not just the code,
but also the skin. It is the easiest of the wiki's I've used/tested.

I would offer that if PmWiki is substantially complete. By this, I
mean that one does not need an actively development cycle to get the
most out of PmWiki. Breaking my own protocol, I would offer these
links to show the level of development:

   * http://pmwiki.org/wiki/PmWiki/Features
   * http://www.pmwiki.org/wiki/PmWiki/FeaturesAtAGlance

I'm afraid I forgot the wiki-comparison site that I found the features
from. About four months back I cobbled together these pages, and a few
went behind me and corrected the list.

On 10/3/06, Oliver Betz <list_ob at gmx.net> wrote:
> "Ben Wilson" wrote:
>
> [Availability - Pm and other developers]
>
> > With any software project, there is always the risk "loss of key
> > personnel." One advantage to OSS is that the owners could toss the
> > code over the fence, and it is still available to the community. Thus,
>
> exactly - _could_. That's why I asked. If there are not enough
> developers with enough time, development will slow down extremly.
> That's why I'm switching from PhpWiki. Not many people can invest
> much time.

IMO, PmWiki is already "essentially" developed. Much of what can't be
done with the PmWiki Core can be done via recipes; the core is module
friendly. This is in part the side effect of one developer, but more
importantly the intent of PmWiki.

Take markup as a rather bland example. I've personally never been
satisfied with how most wiki engines handle headers (using multiples
of ! or =). I prefer Markdown's approach, the header comprises the
header text followed by a row of = or - depending on the level.[2]
When viewing the source, the headers jump out at you---and I tend to
use this approach when writing emails needing headers. PmWiki's design
encourages amending, even replacing, the core markup.[3]

By perusing the Cookbook, you'll note many features which are readily
available. When a feature seems really useful, Pm has been known to
incorporate that recipe into the Core. His current round of
development is aimed at improving a few dynamic features. I'm not even
sure those features exist in other wiki.

However, I doubt the community would let PmWiki fade. I know I would
not, and I know there are others equally supportive. Regardless,
developer security you're rarely going to get with any OSS project.
Such projects as MediaWiki are developed for a specific use and
tangentially find other uses. So while its use suggests it would
always be supported, it is perhaps less responsive to its user base
than its primary use. PmWiki is more of a general use wiki that
encourages customization and is responsive to its user base.

When you narrow your pick down to a few candidates, I encourage you to
install each one and take them for a test drive. This is ultimately
what I did in 2004; PmWiki fit my own software philosophy. I still
occasionally test drive my original candidate set to see how they've
developed. But, I stick with PmWiki. My point is, I would not worry
about developer continuity but how the wiki fits your needs and
approach.

-- 
Ben Wilson

[1]: http://c2.com/cgi/wiki.
[2]: Markdown borrowed what it considers "best practices" of ASCII
email markup, so the header approach is from somewhere else.
[3]: However, by completely replacing the Markup, you lose most of the
power behind PmWiki's punch (dynamic code). I've since learned how to
make PmMarkdown work with PmWiki markup, although the mature version
of the recipe has not been published as I seem to be the only person
who cares. :-)




More information about the pmwiki-users mailing list