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