Note:	Please see AppealToCodevCommunityByCoreTeam, it goes boyond the scope of this request -- PeterThoeny - 05 Aug 2003

---

Dear Peter,

There have been many calls and supporting motions to request that the CoreTeam set up a separate web (PleaseCreateNewWeb) in which interested parties can discuss the features and architecture for future versions of TWiki. We understand that this is something that you do not see the need for - in ThankYouPeterThoeny you say that "the process can be improved over time".

Throughout the 15 months taken to release BeijingRelease, people have called for you to RestructureCodevWorkFlow. 22 months later we still wait. In the meantime you acknowledge that the CoreTeam has too much to do, that you will "consider" the CoreTeamNominationDiscussions process yet that "Many ways lead to Rome." with "a way that has proven to work in regards to process and contributions". I put it to you that it does work, but for too few and too slowly.

In the last 2 years many events have occurred in both the Perl world and the Open Source world. ApplicationServers have become popular, and have matured for Perl. CPAN has gathered momentum and SourceForge has become the de-facto way of attracting new developers. And, perhaps most poigantly, competition for TWiki's supremecy has begun to appear on the horizon.

TWiki is the best in its class. We want it to stay this way. Yet, its class is changing. Other development efforts are using newer techniques, not just faster in execution speeds but faster to code. Competitors are more modularised and better at leveraging other modules written by other people.

We want TWiki to remain the best in its class. Staying still won't acheive this.

We have many more developers, architects, usability experts and other interested parties now at TWiki.org. But we have fewer members of the CoreTeam. No wonder you feel under pressure. Everyone has an opinion, has ideas and has an expectation.

With so many more people now involved there is a mismatch between the level of process required and the level of process in place. Like a small company that's been hugely successful we've become too big for one office. We need to specialise. We need roles. We need process.

We have no wish to fork. That would be in no-one's interest, and is a last resort. We don't want you to apply-all-the-half-baked-patches-immediately. We know that many are not ready. We don't even want to mandate the choice of a technology such as CPAN.

We want you to give us responsibility.

We'd put in effort to RestructureCodevWorkFlow - if we had permissions to write to WebPreferences. We'd sort out the patches, assign work to people in such a way that they could be sure that there work would be used in the future.

We want you to endorse our ideas. To tell us about the design decisions, and we want your input on strategic aspects.

Please Peter, give us some freedom and responsibility. The very thing TWiki frees us from in the content base - the OneWebMasterSyndome - is what we, your frustrated and not-able-to-contribute TWikiContributors, are suffering from in the code base.

As it is, people are working independently, around the CoreTeam, and to the detriment of TWiki. If it comes to it we will just end up forking.

-- MartinCleaver - 01 Aug 2003

If you agree wholeheartedly, please sign here

-- MartinCleaver - 01 Aug 2003
-- WillNorris - 01 Aug 2003
-- PavelGoran - 04 Aug 2003
-- ColasNahaboo - 04 Aug 2003 But in favor of fork, see my comment
-- WoutMertens - 04 Aug 2003
-- ArthurClemens - 04 Aug 2003
-- PeterMasiar - 12 Aug 2003 in favor of ColasNahaboo fork/distro.
-- AndreaSterbini - 03 Sep 2003 in favor of a TNG web for FriendlyForkers

If you disagree, please sign here

Other comments

Not agreeing and not disagreeing. Why? It's not my project. Not my tree. TWiki is a gift, not a right. The time people have spent on it is a gift, not a right. This goes for contributors of ideas, patches, plugins and especially those on the Core Team who answer questions and contribute code. It's easy for people to forget that.

That said I suspect it's easy for the CoreTeam to forget that the flip side also holds. Not one person has to provide them with extra ideas, or patches, or bug fixes. (NB. Nor do they have to accept them) I'm sure they are aware that more than one person in the past has given up attempting to contribute (deliberate choice of word) to TWiki (I certainly gave up about 18-24 months back) for various reasons. In many cases these people do not cease using TWiki, or developing their own TWiki's, but they do cease contributing to the core code. As indeed some CoreTeam members have done.

Would a separate almost free-for-all unstable branch see that off at the pass ? Who knows. It would allow checking for interoperability and perhaps force performance issues (say with lots of plugins installed) to be resolved. Then again it might go nowhere due to lots of highly conflicting patches and chaos. Are the CoreTeam obligated to provide this branch? Of course not. Might it happen anyway - but leaving TWiki as the poorer cousin? Maybe. Would this be a bad thing? I doubt it - the two would feed off each other anyway (I'd hope) - as any two good trees do.

Not my decision. I do have a rhetorical question though: how come the plugins world is flourishing, and the main TWiki code not advancing as fast (ie shrinking and shipping stuff out to plugins ideally) - what's different about contribution policies?

I think this might count as an "other comment"

-- MichaelSparks - 01 Aug 2003

"I Shot an Arrow Into the Air - It fell to earth I know not where." I feel the words from this poem by Henry Wadsworth Longfellow refelct the attiudes of many here, not just the core team.

-- AntonAylward - 02 Aug 2003

ColasNahaboo:
I think that the best solution now would be a "friendly fork", that is a fork with the forkers doing all that is possible to contribute back their modifications to the core if/when the core team agrees. TWiki is a great tool used by many people for many different uses, so I understand that the Core Team and Peter have a hard time accepting patches, since many people have different agenda and different goals, and it is quite difficult to envision all the problems that could arise in a real-world situation by accepting this patch.

So I think that TWiki is ripe to become an underlying technology, and that it is time to build "distributions" on top of it. Actually, many open source projects work this way:

• Linux: There is the kernel, and on top of it users choose red hat, madrake, suze, debian. You can even argue that red hat is a "kernel", on top of which the RPM-based distribs are made. Or you even had at one time forked 3 kernels (3 people choosing to apply a coherent set of diferent patches for the Virtual Memory system). The kernel example is nice, as it allowed people to try the different approches in real situation and ponder the merits of the different architectures.
• Emule: the P2P program sustained a hefty rythm of development (even when the main programmer quit) because other people maintained "mods", as ready-to-use modified versions with their own view of what patches were importants.
• Mozilla: The latest advance came from "forks" like firebird, which are now becoming the main distrib.

So, I think trying to keep everything in TWiki.org is too hard, one of the main reason is that people on this page wanting more changes will want different kinds of changes. The directions could be:

• TWiki.org stays as the reference site, the "R&D" wiki site where all ideas and concepts are originated and discussed.
• TWiki admins (people wanting to download and install a TWiki engine), should be directed to download not directly on TWiki, but from a "TWiki distrib" site. This should be proeminently mentioned on TWiki.org front page.
  This is the part that will be hard on Peter
• TWiki distribs should try to be only a set of coherent patches, that is, they should upload all their patches to the main TWiki.org sites for other to use and modify, and for the Core Team to optionally put back into the main core (just like what I did with the SavemultiCgiScript). They should also provide a running site with the distrib so that other can try the new features.
• TWiki distribs authors should agree to be ready to devote time to help the Core Team integrate the features they see valuable in the core TWiki "engine".
  These 2 points will be hard for "forkers"

I will surely begin such a distrib, based on the KoalaSkin work, in the coming days, since the above describes actually what I have been doing for months with the "skin", except the "ready-to-download-and-run" part.

This is really not an attack on Peter. he is doing a fantastic job, but I know for having authored Open source efforts how hard it is to sustain a sucecssful (read: with many users) project. This is sincerely the way I see that could best help him and the TWiki community as a whole.

-- ColasNahaboo - 04 Aug 2003

I also neither agree or disagree. I am very disappointed with the rate of improvement in the core, but I don't think pressuring the CoreTeam to throw open the doors to change will help. The reason is that I don't think Peter's heart is in these changes, and without his support they will be stillborn. At the end of the day it's his leadership that holds TWiki together, and without it, TWiki will shatter into a dozen derivatives each of which will fail.

At the same time I'm afraid that ColasNahaboo's approach is too weak. There are some fundamental shortfalls in the current core that can't be cured by patches alone. As soon as a fork is in place it will diverge so fast that the differences will soon be irreconcilable; even more so if the response time of the CoreTeam remains the same.

As MichaelSparks observes plugins are more lively than the core. Some of the reason why:

• Plugins are mini-projects. The author is sole dictator. Many are simply thrown over the wall into the community. They are not bound to timescales. As a result the authors don't feel the timescale pressure that the CoreTeam is under.
• Plugins are not compulsory; they are "at your own risk". As a result the authors don't feel the quality pressure that the CoreTeam is under.
• An author frustrated by the inadequancies of the core can address many of them in a plugin. May not be as efficient, but where needs must [Plugins.FormQueryPlugin]. I find it very difficult to get an opinion on such initiatives out of the core team - to quote from Alien II "I don't ask because it takes two weeks to get an answer and when it comes, it's always 'don't ask'" - but a plugin is a good way to 'put your money where your mouth is' without breaking everything and forcing a branch.
• I've long felt that the way to leverage this energy is to lighten the core, move stuff out into plugins, focus on performance and architecture in the core, and not features. I think this view is shared by others, but apparently not by the CoreTeam.

I really want to hear the CoreTeam's take on all of this. I've been sitting on the fence for some time, trying to decide between

• accepting the limitations of the core as it is,
• forking, or supporting a specific fork,
• transferring my company, and my efforts, to a different wiki implementation (such as Tiki) that has more energy behind it.

-- CrawfordCurrie - 04 Aug 2003

Crawford, I agree with what you say. However, plugins have drawbacks:

• complexifies: install/maintainance/upgrade: If you tell a new user that he has to install TWiki, then a lot of plugins, he will run away. He should download a bundle, packaged so that all needed plugins are there pre-installed in a seamless way... a distrib.
• interoperability: the risk of coding a feature that breaks another module (or doesn't work correctly with) grows with each module, and testing this becomes quickly hell.
• quality: as you say, there is less pressure on quality for plugin authors...

All 3 issues that could be handled by a distrib (aka plugin and patch master).

On the other hand, it is true that Tiki seems more and more impressive. But it has drawbacks (no html, not usable from netscape 4.x...)

-- ColasNahaboo - 04 Aug 2003

I am happy that this topic popped up, because I felt like posting something along these lines as well. I made some changes that I would like to contribute, and that I think would be beneficial, but I kind of gave up trying, mostly because there doesn't seem to be much response.

-- WoutMertens - 04 Aug 2003

I like the idea of distros layered upon a TWiki base. It seems to me an sensible way to spread responsibilities for creating and maintaining functionalities.

-- ArthurClemens - 04 Aug 2003

I think that Colas' issues with respect to complexity, interoperability and correctness are all valid concerns, but I also think they're solvable within the context of Twiki.org:

• Complexity. Why ask a user to either download a single monolith or a core plus a bunch of individual plugs? Why not take the time to create a good installer/admin app that can lead a user through installation and allow him/her to select desired addons and then have them auto-downloaded and installed - think CPAN, only for TWiki!
  • Autodownloading ? This is something about CPAN I hate - I've been burnt too many times by CPAN's download and install to trust it. I've only seen one thing get this right so I'm doubtful in a situation like TWiki it can be done both cleanly and correctly. That said distributing TWiki with a large number of optional easy to install plugins and installer is the kind of direction I think the TWikiUnixInstaller would benefit from. (But then I'm biassed) -- MichaelSparks - 15 Aug 2003
• Interoperability. If TWiki had a test suite, then much of this concern can be reduced by requiring that an addin both pass the an existing test suite and also must submit a script to augment the test suite for future integration validation with it. (I might point out at this juncture, that if TWiki where more OO and/or the notion of namespaces where introduced (in the XML sense, i.e. for tags), some of the interoperability issues might never come up in the first place.)
• Correctness/quality. See the previous bullet about Interoperability. Test Suite to make it sweet!

-- DavidLeBlanc - 13 Aug 2003

There is a limited test suite under tools in CVS that I've mentioned a few times in Codev. I don't think I've ever had feedback on it. Best tests are for OO meta data implementation and RcsLite.

The text above refers to fundamental shortfalls in the core. Anything can be improve, but for the job intended TWiki is pretty good. I don't lack of OO being a fundamental flaw, not too sure what specifically is being refered to. Workflow can be a will be improved. But large changes to the core will require more developers than are currently contributing.

-- JohnTalintyre - 16 Aug 2003

I agree with MichaelSparks and PeterMasiar ... there is now enough people that would like to start working on TWikiOO / TWikiNG.

I would like that TWiki remains the best Wiki around.

My personal priorities are (roughly):

• get rid of global variables (see ModPerlize)
  • to run TWikiFarms
  • to use ModPerl at its best on high-load servers (we have 5000 students clicking at the same time)
• Object Orientation
  • to gain speed with ModPerl
  • e.g. to use different storage systems (DBI, Text, CVS, RCS) or template systems (our, TemplateToolkit ...)
  • to use TWiki as a data handler in Apache or in TemplateToolkit
  • to empower our friend fellow coders that could work easier
• an authorization handler for Apache/ModPerl
  • to cache the authorization settings when a page is stored
  • to use WebDAV to edit attachments
• a cache system
  • to "compile" at storage time all the info that is taken from the topic (e.g. as I am doing in ProgramsPlugin)
  • I am looking at ImprovePluginStartingTimes ... it seems that the most time-consuming step is the read of preferences
    • I am working on indexing the plugin inizialization on the basis of the tags declared
• to see TWiki raising in the Wiki community:
  • a better usage of SourceForge tools so that we show up in the active projects list
  • more kind of distributions (CPAN, RPM, Debian)
• a test framework (has anybody used Apache::Test?)

To this aim I embrace the TWikiNG proposal and the request of PleaseCreateNewWeb.

• the new web will show how good TWiki will be
  • using our better skins (Koala, Gnu)
  • installing all the more useful plugins (this reminds me that it's time to start a PluginSecurityModel )
  • showing how good is the work of other FriendlyForks
    • forks are a normal part of opensource development (see BewareOfTheQuietLeavers)
    • FriendlyForks show that TWiki is alive
    • I dislike competition, I like cooperation

This remembers me that in the far 1999 I wrote ModularizationAndCommonTwiky ... I was a dreamer

-- AndreaSterbini - 04 Sep 2003

Responses from the Core Team

See above.