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 [email protected] www.affinity.co.nz _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
