Peter Thoeny, it must be very difficult to read through Codev in the spring of 2003 and keep seeing words like "sucks, unmanagable, ineffecient, painful upgrades, we need to fork twiki, badly designed" surface with alarming regularity and growing virility. Please understand that nobody spends the time to pick something apart at this level of detail and thoroughness unless they recognise the fundamental goodness, utility and potential of their subject. None of us would be here if it wasn't for you. We would all be lobbing our complaints over the corporate firewall of the likes of Microsoft and IBM while wishfully listening for a cogent reply if you had not decided to release twiki to the world under an open source license. Please see that every time we whine, bitch and complain about twiki that we do so because we care -- you know, an inverse backhanded-compliment.

I sincerely hope the proposalsTimDistroDev,1 and deep insights2 of recent days are not lost in the noise. Please don't remain silent in the face of controversy. A lot of the complaints being expressed have their roots in the fact that there are no clear rules or guidelines for how to effect change in the core and no list of things for which changes will not be accepted.

Everybody else, a set which includes me by the way, please remember to take the time to drop a thank you and job well done to PeterThoeny, and the other people who contribute to the twiki code, as the occasion warrants. If all he hears is griping it isn't going to make him feel like donating even more time on top of the many thousands of hours he has already given us.

Also, Peter is a quiet person. He doesn't say much, while a lot of other people here (me for instance) spend a lot of time filling the airwaves with many ideas but little code. Consequently some relevant things are lost in the churn. For example, seven months ago Peter said SavemultiCgiScript is a good idea, it could replace the core scripts save and preview as long it was tested and shown not to break forms and a couple of other functions. Nobody undertook the testing and we still don't have direct save on twiki.org, yet savemulti is listed as one of the top desired features in ConsolidateFunctionalityFromSkins.

Peter, thank you. Your work is truly appreciated.

-- MattWilkie - 29 May 2003

Agreed, Peter (and the rest of the core team) have done a good job - I don't think anyone has suggested otherwise - frustration at speed of acceptance of some changes perhaps, BUT this is an open source project with no guarantees of speed. People who get frustrated can (and do) go off and do forks, and benefit from doing so, end up providing feedback from real environments, which at the end of the day is much more important than just "talk" IMO.

-- TWikiGuest - 29 May 2003

Peter and the core team have been the "heavy lifting" "Saturn 5" that has lifted a wiki out of the gravity well - which pulls and sucks - and into orbit. In energy terms, as those of us who are rocket and space enthusiast know, that is as much effort as it takes to get from orbit to deep space.

We get blazee seeing SF TV and movies, and forget that "big first step". I'm in no way belittling Peter and the core team for what they have done.

But where are we going now? The Belt; The Oorrt Cloud; The Juiper belt; -- NO! "The Stars My Destination"

The USA put a man on the moon and hasn't done anything above synchonous orbit since Harrison H. Schmitt landed the Apollo 17 module at Taurus-Littrow on December 11, 1972. That's over 30 years of no-progress. Those of us who grew up in the 60s and 70s and read the SF of that era and dreamt of space and went to work in Aerospace as the leading edge hi-tech have been let down. Yes, there are still activists such as Rutan (http://news.bbc.co.uk/2/hi/science/nature/3051177.stm) but the impetus of the nation has been lost. Even the much vaunted shuttle is just an under-powered delivery truck that doubles as a bus.

Other threads have made it clear that TWiki has lost its impetus. Difficulties with obtaining it (registration), installation and upgrade, are affecting its adoption by people who aren't sysadmins, Apache and Perl gurus. That's not my observation, its the observation of many others.

To say that we need to move on is no belittlement of the work that has been done. As Fred Brooks said "build one to throw away".

(-- TomKagan - 29 May 2003 removed <verbatim> from above block to make it work as intended. I always felt the usage was nonintuitive. Obviously, I'm not the only one. )

Yes, I know I'm disrupting the status quo. But consider:

• I'm trying to build on the base of what Peter, the core team and many others have built, as opposed to shruging my shoulders and going elsewhere, such as CPAN:CGI::Wiki, CPAN:CGI::Kwiki or CPAN:CGI::pWiki. (-- TomKagan - 29 May 2003 Actually, I think CPAN:CGI::Kwiki would be an excellent starting point for the next TWiki)
• I'm trying to involve people who have made contributions that have made TWiki different and those that feel frustrated because they want to make TWiki "do stuff" and are running into hurdles.
• Twiki has grown beyond its original design boundaries, both in what people are doign with it and what they are demanding of it. This indicates a watershed. Once the log-jam is broken we'll see a massive spurt of new innovation that will make TWiki the "Next Generation" of collaborative application platforms.
• Much of SF, and not least of all the Bester reference above, deals with the social consequences of technology. Technology as technology is sterile. So long as TWiki is log-jammed its not going to be widely accepted and hence its nt going to have any social impact.

Thank you Wernher Von BraunPeter Theony.
Without you a Wiki would just be a collaborative blog.
With you TWiki is something more, an application platform.

Now we've made orbit, lets head for the stars. Are you going to lead us, Peter? You've done a great job so far.

And no, I don't consider myself to be the analogue of the the namesake of the 10th Lord Dundonald in "ST:FirstContact". I'm just another PM.

-- AntonAylward - 29 May 2003

Matt, this is great page. Great idea.

PeterThoeny, you know how OpenSource works. If somebody doesn't like a package, just moves elsewhere without a word. So all this complaining and whining means that we like Twiki and want to improve it. SOmetimes (quite ofteen now) is beyond your original plans - and I hope beyound your dreams. Because twiki is the most powerfull wiki in Perl world - so you can be proud of your work, and rightfully so. If you or somebody else ever thought I do not appreciate what CoreTeam does - it was misunderstanding, and I apologize. (I may not understand all aspects of it , but I do appreciate).

JohnTalintyre in TWikiMission said that it's important to make sure changes are non-disruptive - and I agree with him: we need stable Twiki for production. But I agree also with AntonAylward (and many pthers) that major refactoring of the code is required to make twiki easier to install, use, upgrade and extend. Without changes, other wikis will steal ideas (and GPL code) from Twiki and will beat Twiki in mind (and market) share.

I like Anton's allegory about Twiki being launched to the orbit, hoping to go for stars. Let me use another allegory: Twiki is out of childhood now. Like any teenager, it rejects parents (to return couple years later) and goes for the world, and there is nothing parents can do about it. So do not be afraid and let it (Twiki) go.

Thank to excellent code and your leadership (and thousands of hours of spent on support) we have Twiki developers community now. Part of developers values more stability, and prefer small incremental changes.

Others feel like current twiki was just a prototype, and now we know for sure how many decisions should be done better (this is not to criticize design decisions - compromises were crucial to keep the core stable, and we all understand that). These "radicals" are trying improve and refactor Twiki, only question is if they do it by themselves in the fork, or with full support of Twiki developers community (and making sure community can use results, if they will turn out good).

Maybe refactoring will be a bomb (and "radical" will be happy to have stable twiki to fall back), or (as I hope) it will be wild success, and we will be able to convert existing user base to Next Twiki easily. We shall see.

Yes, it mean many disruptive changes. Yes, many of them will be not that you personaly will prefer, and what you would not allow is you will be in charge like you were untill now. But Twiki is not your private project anymore. Now it truly belongs to whole Twiki community.

It will be big change to all of us, but I hope it will open whole new horizonts.

So Peter, thank you for leading us to this spot - and where are we going next?

As practical matter, I propose to create new web (something like Next or NG), where we can discuss refactoring Twiki into new, improved body. This will remove disruptive proposals from Codev web, and will also allow developers of stable branch to cherry-pick ideas from Next and re-implement them in Stable Twiki, if desired.

What do you (and not only Peter T) think about it?

Later:

Link about how OpenSource Eclipse project is managed. We do not have to go this fancy, but nice difference between user, developer, comitter.

-- PeterMasiar - 29 May 2003

Thank you Matt and all for the kudos. I would like to extend that especially to the CoreTeam and to the many contributors. TWiki definitely grew bejond the scale of a one person project.

I attribute voices like "sucks, unmanageable, inefficient, badly designed, etc" mainly to the fact that the CoreTeam did not find the time to incorporate contributions quickly enough. The CoreTeam will address the quantitative question shortly, some changes like new members and clearly defined roles and responsibilities will be done to facilitate that.

In the mean time, please note that the best chance to get spec, code and patches incorporated is to make it easy for us, e.g. terse "get to the point" explanations and quality code. TWiki has a high quality standard, probably higher then the majority of open source projects, so code that is tested is more likely to get accepted.

A note on the current design: While not perfect, I believe there is room for evolutionary expansion without a complete rewrite. Some design decisions done in the past might not be obvious at first, but do have a fundamental justification. For example, DatabaseForPreferences has good elements but misses on a crucial design decision done earlier: A complete audit trail that includes everything like meta data, access control, preferences is a must have in some corporate environments.

Feedback is always good, in fact it is an essential ingredient for realigning the strategy. Lets focus on constructive feedback, a "Collaboration Guidelines" section needs to be added to ReadmeFirst.

We do have some vocal voices, some might say that the signal to noise ratio decreased recently in Codev. In case you have not discovered already, loud voices get the least amount of attention from the CoreTeam, especially me. I try to use my time as productively as possible, that means my eyes are on concrete (and terse) spec proposals and high quality code contributions. That is the reason for me being "quiet" (well look at the topic contributors in the Main, TWiki, Codev, Plugins and Support webs). I estimate that I work at least 600 hours per year on the open source TWiki, and this for a couple of years now. I have no choice but use my time productively, this week I have 10 hour "regular" work and 2.5 hours commute per day.

Anton, I like your story. I do not consider myself as a Werner Von Braun of modern times. I am more like a captain who's goal is to steer the ship steadily towards the TWikiMission, with currents and winds trying to move the ship into different directions. There are great things ahead, adventurous folks stay on board!

-- PeterThoeny - 30 May 2003

I, for one, am very glad that you have chosen to address the issue in this topic. As much as you may dislike "loud voices" we (myself included) are only loud because we care about TWiki and we've found that subtlety is met with silence.

Silence from the CoreTeam on fundamental issues does little to reassure people or win hearts and minds, it just frustrates and disturbs us and makes us more likely to be another group who went and ForkedOff. I appreciate that you work hard, and I agree that WebStatistics in every web ranks you highly but I do believe that changes like your recent formatting corrections in the Plugins web is not where you can add the most value. If such administrative changes must be done, request someone to do a role similar to that which MikeMannix did using the CoreTeamNominationDiscussions process.

The worst thing the CoreTeam can do is let people discuss strategic issues without guiding us, this is a recipe for discontent on both sides. Without your collective input, sooner or later the rest of us will implement the new design in a way that we are happy with but in a way that contradicts and that will never win your approval. This is what happened with the now separate PhpNuke / PostNuke communities, and at that point it gets next to impossible to find agreement.

I don't believe any of the contributors want that to happen with TWiki, and I don't believe it is in anyone's interest for this to do so. Not addressing issues will convince us that this is either what you want, or that at least forking off is the best we are going to get.

Please address the issue of creating a NG web, set some goals for CairoRelease and some direction for DakarRelease and beyond.

-- MartinCleaver - 31 May 2003

I think a core issue is one of converting ideas into code. An OpenSource project is always more likely to take on board code rather than design ideas or requests for new functionality. At my company we had some small Wiki sites, brought these together in TWiki and then wanted some improvements (e.g. attachments under revision control, different look etc). Peter was happy to have these as code contributions and helped a lot with the quality of our code, including many detailed design discussions at Codev. This took some time and included changes to better fit in with TWiki. I think anyone who has code to contribute and is willing to put in time so that it will work for all will feel very at home in TWiki. I'm sure some more code contributers will soon join the CoreTeam.

How shoud loud discussions on how designs should be changed and on new functionaltiy that is required be handled? If there isn't a developer willing to act on them they will not make in into the core. However, that's not to say a developer it won't pick up on them later; I try to respond to some of these discussions, but it's often hard to relate the reality of working on the core code to much of what is said in some of the longer design disucssions.

In summary, good coders will quickly find a home at TWiki. It's much harder for non-coders, but many have and continue to make great contributions to TWiki - more patience is required though is many ideas will not be acted on.

-- JohnTalintyre - 01 Jun 2003

JohnTalintyre, does your opinion count as a "no" for PleaseCreateNewWeb?

• I'm not sure what PleaseCreateNewWeb (bad name?) is for. I support tidying up TWiki where appropriate (including extensive refactoring in some cases), but if we're talking a new code base (e.g. OO re-write), then that sounds like a different project to me. [ JohnTalintyre 01 Jun 2003 ] It doens't to me, it sounds like, and that's the predicate I'm building my OO design on, like a refactoring of the code under a new vision. [ AntonAylward 01-JUN-2003 ]

-- PeterMasiar - 01 Jun 2003

Good coders, I found out many years ago, need a good design and good tools.

(As a sidebar, I'd point out that code doesn't count. Its delivered systems that the customer is happy with and that fulfill his needs that count. Code is just part of that, necessary but not in its not sufficient. A good design that tkaes into account the users needs, good "usability", a coherent conceptual model, and responsive support are all also essential. And from a business point of view, all those droids in suits that do the thngs you so despise, like find finance, sign the pay-cheques and sell the product are esential as well. All those are non-coders.)

Good tools, such as the seminal UNIX was in the 70s and 80s and as described in Software Tools demonstrated one facet of this. Windows was blocked until good GUIs and IDE tools came out.

But a good design is essential. Design and architecture go hand in hand. We rarely see how beneficial good design can be until we see a good design beside an mediocre one. This is illustrated by ArthurClemens in the discussions we have on skins.

In my programming days I was found to have a productivitry about 20 time that of my peers when the full lifecycle - including debugging, testing, revisions, integration and documentation - was accounted for. Management eventually figured out why. My work had very little re-work. To coin a phrase: "Code? Why that's the last thing I'll do". Work out the design and its implications. Document everything. Design and built the test harnesses. Document everything. Design the test and integration plan. Document everything.

Yes, I know this in't the trend today. "Programmers hate to document". Then I'm not a programmer, I'm a guy who produces working systems. If that involves code reuse, downloading from CPAN or buying a package that's cheaper than coding it myself, so be it. I don't have the Ego Association with my code. Code, like flesh, is grass, but a good design endures, perhaps not, like the word of God, forever, but it does tend to survive evolutionary and revolution pressure.

I'm aware that many managers today want to see code - first and fast. I grew up in an enviromment where the end-user alpha and beta testing that is common for PCs would kill many people and cost millions in damages - Aviation. I've adapted to the "PC world" by doing what I do best - designing and documenting, analysing the spanning sets and defining the boundaries and interfaces to make the system buildable, testable and maintainable - at a low cost. Yes, I know this is "Open Source", but that doesn't mean we shouldn't have a professional attitude, that the result shouldn't be used professionally in commercial settings and be of professinal quality. "Bind", the DNS code that is the backbone of the Internet, is "Open Source", and its quality has to be exemplary. (I won't comment on sendmail) We see other examples such as the GNU compilers, and Apache. Look at the documentation and thought that has fone into the design of the functionality and the interfaces - not least of the that of the "plug-ins".

Yes I can code, very effectively. But I differentiate between the quick hacks that are "proof of concept" and and mission- - or flight- - critical code that I deliver and will stand by and present for use in aircraft, power stations, and to run power distribution grids.

Ideas have to be converted into code. You can't run documentation! But a good design, supported by clear documentation that conveys to the programmer what has to be built and why, what its boudnaries of operation are, how it is to be tested and deloyed, makes the job of coding and testing a LOT easier. And faster.

-- AntonAylward - 01 Jun 2003

As I said earlier, I agree with much of what you say. I and others in the core are also very experienced in design, including OO based design. My point was that there's been much similar discussion in the past, but backed by little or no code. Much of my contribution to TWiki could have been better coded, but much was the subject to considerable design discussion on Codev. I don't see the TWiki code as a quick hack!

-- JohnTalintyre - 01 Jun 2003

John:

The camel may be the icon of the perl community, but there is the saying about it and the horse and the commitee. Luckily, Perl has the guiding vision of Larry Wall, who is fortunate enough to be able to devote time and effort to pushing Perl forward and maintaining the coherency of vision.

That many good ideas are not implemented is more indicative of the nature of an Open Source project without commercial backing and "professional grade" project management. There's no Project Manager to whip the coders into a disciplined approach to addressing the issues raised by the users, to ensure an adequatre level of docuemtnatin, to pull the design ideas together into something coherent. A Wiki can be great for this, and in my role as PM for my clients I use TWiki for that. But it is focused and managed and there is a discipline - a set of fundamental governing precepts, restraint, focused and coherent pattern of action (although this meaning, the noun,seems out of vogue in America these days in favour of the transitive verb meaning to punish) - behind it. My main use is for documentation: documenting the design, design changes, justification behind the design, without the WikiThickets we see here. Focus. Focus. Focus.

The Creationist-Evolutionist debate is illustrative of a point here. In between is Lamarkism. TWiki is Lamarkist. It responds with more 'design' that a simple short-term evolutionary response - solve the problem with a quick hack - but it lacks the God-like insight into implications and conseqences. A Neo-Creationsit might say that God tried with Dinosaurs and saw it was an example of what Fred Brooks called "the one you build anyway to throw away". So She dropped a rock on them.

Brooks model also emphasises the importance of roles other than that of the coder. It is an area of people management and appreciation that is sorely lacking in the Open Source approach.

He foes on to talk about the importance of separation of the architectural effort from the implementation. Of course this is a heresey to most of the Open Source coders and a very emotion isue, as this thicket illustrates. "The architect of a system is the user's agent. It is his job to bring professional and technical knowledge to bear in the unalloyed interest of the user, as opposed to the interests of the salesman or the fabricator". And later: "Architecture must be distinguished from implementation. Where the architect tells what happens, the implementor tells how it is made to happen."

Brooks also talks of "conceptual integrity" and uses the example of European cathederals where later builders were tempted to plaster improvements over the old structure. "Against these, the architectural unit of Reils stands in glorious contrast," he points out. Or as I say, Focus, Focus, Focus. Function, not simplicty, is the measure of coders. In the disussion of skins, Arthur has pointed out how adding function has impacted coherence. If a system is to have conceptual integrity, someone must cotnrol the concepts. Actively, not by ignoring them. As Peter Theony points out, he no longer has the time to devote to the amount of effort now requried. Many coders think that design is 'fun'. Doing it properly is a lot of hard work and not what they call fun - documenting, planning for test, dealing with budget (time and resoruces as well as the money needed to live), dealing with end users, and so forth. Letting every coder do his bet of the architectural design, as opposed to designing the code that fits the specification he was given, is a sure way to destroy Conceptual Integrity.

The pressure, the ground-swell, is that TWiki is bottle-necked in its present design, that is has reached a watershed. A new vision is needed. An few Focus.

That there is a group here that wants to stay with the community and not, like so many other other open source projects that have 'forked', take their ball and play elsewhere, is a complement to the community and all those that have contributed thought and effort.

Please don't alienate them or feel they are unappreciated. Many of them are your "customers".

Being recidivist, John, is unproductive. Conway's Law (no, not THAT Conway) predicts that "Organizations which design systems are constrained to produce systems which are copies of their communication and documentation strcutures." I would point to the thicket that is Codev as evidence of the strcuture of TWiki. Old stuff doesn't get purged, refactoring is rare and up to an individual. Its become an agllomeration of .... well, whatever. The lack of application of user supplied updates and patches is justone illustration among many.

-- AntonAylward - 01 Jun 2003

I won't attempt to respond to most of the above. But, I will say that user supplied patches are very welcome and almost always applied. They and other contributions are very very welcome. I think you misunderstood what I was trying to say.

-- JohnTalintyre - 01 Jun 2003

I disagree.
The evidence reading through Codev is that its not clear what patches have been applied, reading through Plugins its very clear that many pathches -have not- been applied.

If your response is that the core team take care of Codev and "the core" - all well and good. But the POV of the "customer" - the end user, perhaps in a professional setting where a level of "quality and reliability" is expected based on other Open Source tools such as Bind, Postfix and the suite of tools from Gnome and KDE - is going to be different. Its all of a 'product'. If you're putting it up in the "main" sections as opposed to clearly marking it "experimental" or "obsolete/unsupported" as other Open Source sites do, then they are going to be viewed as "core.

In my notes about Tng I'm using the terms "kernel", which is teh Twiki engine, and "core" which basic set of supported extentions. Some things that are in TWiki.pm I think should be plugins and some things that are in in lib/TWiki/Plugins should be differentiated beteen:

• pipe-line (i.e. flowthough such as 'grep', 'nl') rendering
• chunky (i.e like 'more', 'less', 'awk' as filters) rendering that can "do" backtracking,
  For example, 'TOC' reads the topic then backtracks to insert the TOC at the begining.
• and plugins that have nothing to do with rendering.

Different hooks would make for cleaner interfaces, instead of one place for plugins and more "yes-but" additional hooks to solve problems as they come up. The desing of CGI::Kwiki is very clean in this regard. (Its also proof that YAML is applicable.)

-- AntonAylward - 02 Jun 2003

Many ways lead to Rome. Here in Codev we have a way that has proven to work in regards to process and contributions. May I remind everyone to review ReadmeFirst and TWikiMission to see how. In addition, each release has a focus, see CairoRelease for the current one. The process can be improved over time, the CoreTeam is open to constructive suggestions. I do not consider the current design as the bottleneck (although a lot can be improved), it is the lack of time of the CoreTeam, and this will be addressed as indicated earlier.

-- PeterThoeny - 02 Jun 2003

Well put Peter. The design will evolve over time but I've not found it holding back development. The activity in the Plugins Web have been very impressive, I get the feeling we should consider putting more into Plugins, even some of the core code, so that more people can get involved.

-- JohnTalintyre - 02 Jun 2003

I don't think we should be throwing away any of the current code, that's one of the Things You Should Never Do. I think part of the problem is a lack of process. More effort is needed to RestructureCodevWorkFlow for increased productivity, and to make it easier to see where progress is being made.

The following is off topic but I have to say that I picked up a copy of The Stars My Destination (see above) in a second hand book shop and it was one of the best finds I've ever made, that review is right, it's an absolute page turner.

-- SamHasler - 03 Jun 2003

Has anyone looked at how TikiWiki do it? AFAICS there's a lot of developer activity there, and what looks like a tremendously functional product (though I'm having real difficulty finding any actual users). But the key win I can see for TikiWiki is the fact that they seem to have recruited other projects to integrate with TikiWiki - htmlarea, JGraphPad, Galaxia being the most visible. This approach is building visibility and is going to build a critical momentum behind TikiWiki, that may well take it ahead of TWiki in terms of adoption (if it works as well, that is).

The suggestion, then, is that the barriers to becoming a TikiWiki contributor are lower than for TWiki.

If you want to contribute to TWiki, you have two routes. Either write a plugin or three, or become a core contributor.

Write a Plugin or two or three. That lets you establish you technology advances, but you remain limited to what the core code lets you do. At some point you reach a limit - I'm at that point now - where the limits of the core code are such that I don't want to invest in more plugins, because I can see that the core code has to change and I don't want to duplicate what has to be there anyway. For example, I have a QBE interface to searching data in forms that is incredibly useful, but I really don't want to release because it defines various objects (Meta, Topic, Web, Search, Renderer) that are almost certain to appear in the core code at some point. In the past I've had to maintain duplications of functions that it was obvious the core code should have, and then wait a year for the next release, and then have to re-work the plugins to use the new core functions instead of my hacks. Scope for 'smarter' plugins is limited to the capability of the Func interface (unless you want to risk roasting your toes by using core functions directly). This means that the heavy reconfiguration required to do something really clever just isn't an option, short of forking TWiki. If all you want to do is expand smilies, then you're on a roll ;-). But if you want to implement threaded, live discussion groups with configurable sorting, you're facing a challenge. You'll have to re-implement a lot of what the core code already does.

Become a core contributor The current team have done a terrific job moving the core code ahead. The quality is very high. However, this team has such a mass of experience now that to become a contributor to this team you have to know the code, and the reasoning behind it, inside out. There's just no way for a tyro to become an effective contributor any more.

TikiWiki has it relatively easy, because it's a new development that started out with a large developer base. It's also architected using object-oriented techniques, so I guess it's relatively easy to move a subset of functionality forward without excessively impacting the rest of the system. This in turn means that developers shouldn't need that deep, core team, knowledge to contribute. I imagine it also means that the Tiki equivalent of the Plugin author has access to the whole core implementation via published interfaces.

What's the answer to all this? Well, the first idea is that maybe it's time for TWiki to fork. But not in the sense of creating son-of-TWiki. There are a ton of ideas out here in the non-core-developer community that are begging to be tried, but we don't have a good way to manage this right now. So how about this. Instead of the core team owning the responsibility of making all changes to the core code, why not permit the core to be branched. The core team can look at the sub-branches as they evolve, and merges good ideas back to the core. The branch owners have the responsibility for staying up-to-date with the merges performed by the core team, but apart from that, they are on their own. The bottom line constraint is that the branches must maintain the support published for use by plugins, though obviously plugins that tunnel under that support are on their own (sigh).

Maybe some day a branch will evolve into son-of-TWiki; personally, I hope not. There are so many wiki implementations out there already, it's embarrassing. But we've got to be able to explore new ideas in a structured way.

The second idea is to build on what Tiki are doing to leverage other projects. Let's get in touch with the guys and gals in htmlarea and JGraphPad, and point out to them the value of integrating with the best intranet wiki implementation on the pla-net.

The third idea is for people like me to shut up and put our coding skills where our mouths are. The core team has asked for volunteers to contribute, with little response to date. I know we're all busy, but we manage to find time to write missives like this page, so we must have at least a little time to write code as well.

BTW, has anyone else noticed that quite a number of regular TWiki contributors (code and words) are managers? I wonder if this is typical. We're hanging on to our technical skills by our fingernails......

-- CrawfordCurrie - 04 Jun 2003

Addressing your ideas in turn:

1. Forking as you propose it would create as much work for the person managing the fork as the core team, who's going to want to take that on?
2. In princple I argree however it depends on the project. I think that this should always be done as a plugin so that core functionality isn't dependant on code that the community doesn't work with.
   • htmlarea I'm not so keen on because it I think wysiwyg editors take the focus away from the content, and also it makes adding syntax more difficult.
   • JGraphPad, I am in love! Can someone write a plugin for this?
3. I think that people are disappointed with a lack of progess, or vissable progress, and are blaming it on the design of the core code. I think that even if the core code was OO or whatever it still wouldn't encourage code contributions as much as if we were to RestructureCodevWorkFlow! I know that I for one would contribute more code if I could see a clear process by which it could get into the core code instead of attaching a patch to a topic and waiting to see if someone picks it up.

-- SamHasler - 04 Jun 2003