Rodent of Unusual Size wrote:
>Frank Shearar wrote:
>>So I think the people
>>talking about forks were really moaning about the apparent lack of activity
>>in the project. I must confess, I too worry about this lack.
>i would be more than glad to help out -- if i could figure out
>how the hell it works in the first place. as with anything of
>this nature, people tend to scratch their own itches, so i'd only
>be helping out in the areas that interest/affect me at the moment.
>except i can't even do that because i can't figure out how to do it,
>and my requests for assistance have gotten limited responses at
>best, and no responses at all at worst.
>forking also happens when someone wants to take a project forward
>and doesn't want to/can't do so in its current development framework.
Well, speaking for myself, I've just gone and did what I wanted with the
code - over the course of a year, I've added a few useful plugins,
referral tracking, etc. I've held out on "real" attachments (i.e.,
inserted into the database) and real access control (i.e., along the
lines of CoWiki) due to lack of time, but I've removed vast swathes of
unused or "transitional" code in the process. I've also hammered out my
own set of templates and fixed some of the inconsistencies I found in
the (absurdly complex) CSS, but that's just layout.
After a year or so of puttering around with the sources (and yes, I've
compared mine with the current CVS a couple of months back), I've come
to the conclusion that PhpWiki is stalled. The existing code base has an
excellent structure (it's well designed, even if somewhat obscure at
times due to the amount of abstraction used), but bits of it (like the
block parser and the database layer) seem like they should have evolved
further and were frozen while people waited for further redesign.
My wiki (currently at http://the.taoofmac.com) is smallish (only 1200
nodes), but is already big enough to warrant some sort of commitment to
a codebase - and by that I mean a codebase with some sort of roadmap (I
don't mean to be harsh to PhpWiki developers, but progress has been
extremely difficult to measure these past few months - maybe it should
be better publicised).
I have also deployed an internal PhpWiki for technical documentations
that enjoys mild success, but which would definetly be much more popular
if people could attach documents (stored in mySQL, not a "free-for-all"
directory, with some sort of thumbnails/icons) and had some sort of
"real" access control (the "libertarian" view of free access most Wiki
purists defend won't cut it with corporate rules, where you _must_ have
decent authentication and acccss control).
That said, I'm looking at CoWiki with some interest - The only reason
I'm not investing time in migrating to it already is the fact that it
currently needs a bleeding-edge version of PHP5, and another of the
traits I value in software is stability...