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

[Henrik Bechmann]

Interesting concept of shipping but only optionally including features. 
Others call it "plugins". Would require tighter certification and 
testing of "recipes" here, which would be good, IMO. Possibly a slightly 
tighter interface.

- Henrik


John Rankin wrote:
> 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
>   

-- 

Henrik Bechmann
bechmann.ca