[pmwiki-users] PmWiki past, present and future (was: Any hope for 2.2.0 stable release?)

John Rankin john.rankin at affinity.co.nz
Thu Jan 15 16:39:09 CST 2009


First, I agree that taking Pmiki 2.2 out of beta would be excellent.
Even though it is far more stable than many so-called "production"
releases of other software, risk-averse organisations may simply
have a policy not to use "beta" software. This is a shame.

I propose an updated release page to list things that will be 
added to turn the current beta into 2.2.1. This could be an empty 
list, as several people have suggested. I own up to one change 
I'd really like to see, that would prevent my having to patch 
every release so that pagelists work with the PublishPDF recipe. 
However, this is selfishness on my part. The change is trivial 
and does not affect functionality in any way. I am sure others 
have their own pet change requests. The criterion for inclusion 
could be, "Pm deems it trivial".

Turning to the question of PmWiki's future... I look back at
the past.

One of the things that attracted me in the first place, and
has kept me actively using the engine and enhancing various
recipes, is that PmWiki has a very low barrier to entry. A
user does not need to know Php to make local customisations.
In my case, I hadn't written a program for (mumble) years and
knew nothing about Php. I believe this is one of the reasons
Pm chose Php -- non-developers could be empowered. Would I
need to learn object-oriented programming to create complex
recipes in future, for example? While this may be a good
thing, it is also a barrier for the non-developer. And would
many existing recipes break?

Also, PmWiki runs on just about anything. My hosting service
only upgraded from Php 4.1.2 [sic!] to Php 5 about 2 weeks ago.
Mac OS X Tiger still runs Php 4.something, I believe. There is
a balance between moving with the times and creating a barrier
to entry. Perhaps by the time PmWiki 3.0 comes out, Php 5 will
be ubiquitous and it will not matter. Is Php still the best
tool for the purpose? I do not have an informed opinion.

The other thing that attracted me was the idea that the core
functionality is kept tight, with plug-ins to do other things.
Much as I like the functionality added in 2.2, I find PmWiki 
has become somewhat daunting in its breadth of capability.
In my case, 2.1.27 is a pretty sweet balance of power while
still small enough to hold it all in my head. Adding more
functionality can make a good product worse. An example is 
the Ford Thunderbird which morphed from cool to beige through 
20 years of improvements. So I am cautious about adding more 
things to the core, and a case could be made for a PmWiki 
starter option, where most of the advanced features are off 
by default. There is now a huge amount of stuff for new users 
to get their heads around. 

There is a saying, "House finished, man die." But if a piece
of software fulfills its purpose, it is finished and need not
be "enhanced". Adding features is easy, but results in bloated
software (insert your favourite bloatware here). Deciding
which features to leave out is hard, but much more useful.
Pm has, in my view, been exemplary here.

Looking forward...

As a starter for 10... "Smaller core, bigger optional feature
set, cookbook a hotbed of innovation."

I'd like to suggest that PmWiki would lend itself very well
to moving in the direction of the LaTeX model of "packages". 
That is, the distribution consists of a relatively small core, 
that does all many people need "out of the box". Included in
the distribution is a wide range of "approved" (to be defined)
third party packages, all disabled by default. To be approved,
a package would have to meet various quality criteria and meet
agreed documentation standards, for example. Packages could add
functions or skins, of course. The Cookbook would continue to 
be the route by which innovation happens at the leading edge. 
This structure would also facilitate creation of "A short guide 
to PmWiki" documentation. Choosing what forms the core would 
no doubt be hard; my guiding principle is "better out than in".

This model could let a distributed community organise itself
in very flexible ways, while retaining the open and inclusive
nature of the community that Pm has nurtured over the years.
It also sounds similar to the Drupal community Ben Stallings 
so eloquently describes. I do think that PmWikihas reached a 
critical mass of capability where something between the 
tightly-managed core and the wide-open Cookbook may be needed
to manage future developments, while still encouraging innovation. 
I think this could also help to improve the documentation. 
For example, to be accepted as a package, documentation would 
have to meet a minimum standard. To be part of the core feature 
set, the documentation standard would be higher.

So I think my fundamental question is this: Is there an existing
successful community model that aligns with the PmWiki philosophy 
and would help PmWiki evolve to a new stage of development?

Finally, it's great to see this topic being aired with so many
constructive contributions. That's one of the nice things about 
the PmWiki community. This is just my 10¢ worth.

JR
-- 
John Rankin
Affinity Limited
T 64 4 495 3737
F 64 4 473 7991
021 RANKIN
john.rankin at affinity.co.nz
www.affinity.co.nz





More information about the pmwiki-users mailing list