Thinking about ways to resolve basic issues regarding Edinburgh...

First, there is the TWiki Mission statement:

Development guidelines

User considerations

• Good OutOfTheBox experience
• Easy to install, use and administer
• Protect user investment, ensure data integrity
• Open & stable APIs
• Graceful degradation
  • on client and server sides
• Make it beautiful
• Kick ass Web 2.0 extensions
• Multi-language support
• PerformancePerformancePerformance

Community perspective

• Many small steps
  • Evolution is preferred over revolution
• Maintainable source
  • Follow CodingStandards, write clear, descriptive comments, use intention-revealing naming and simple and obvious structure
• Architectural integrity
  • Don't just hack in fixes; go the extra mile to make them fit
• Maximize test coverage
  • Test everything, and automate tests wherever possible
• Tests must pass
  • If the tests ever fail, drop everything and fix them
• High production quality gates
• Functional elegance

Then there's CDot's thoughtful and thought-provoking comment in TWikiCompatibilityDiscussion, much of which I've excerpted below:

Compatibility is enshrined in the TWikiMission. There are good reasons for this. It is forcefully mandated, to the point where you have to look carefully at each change and decide if it is "TWiki" or "Not TWiki". There is no option to release "TWiki" unless it is compatible. If it is not compatible, it is "Not TWiki".

While I understand the drive for stability, I personally believe that TWiki is a long way behind the curve, and to make real progress, we have to push beyond the "Not TWiki" point. I am specifically thinking of the architectural decisions made early in TWiki the project which were right at the time, but are now insuperable barriers to progress. These are what I call the P's; protections, preferences, plugins and perl.

We can decide now; is Edinburgh release a clone of Dakar (100% compatibility)? Or do we take on the P's in the hope of arriving at something so significantly better, that it blows questions of compatibility out of the water? Are you willing to take the risk of developing something on DEVELOP branch that is subsequently branded "Not TWiki"? The last four months of Dakar release involved reeling DEVELOP back in to be "compatible"; and I can't recommend it as a life experience.

One possible way to resolve what may well be incompatible goals -- keeping 100% compatibility, including at most on-the-fly updating of topics -- would be to split TWiki development into two tracks:

• a "clone of Dakar" which includes as much improvement as possible without violating 100% compatibility.
• a path towards creating something significantly better that out of necessity violates at least that portion of the TWikiMissionStatement

the second of which I'm calling TWikiPro, as many software products have used the "Pro" suffix to break free of backward-compatibility requirements.

By internally forking in this way, those to whom 100% compatibility is of primary concern could continue to work on TWikiClassic and merge in anything from TWikiPro that is compatible while those who aren't willing to "take the risk of developing something on DEVELOP branch that is subsequently branded "Not TWiki" but would like to create something significantly better could productively contribute to TWiki as a whole.

-- Contributors: PeterThoeny, CrawfordCurrie, MeredithLesly

Discussion

A TWiki fork which is not TWiki.

Anyone can do that. There are plenty of wikis out there. I am sure that it would be even easier to build a new Non-TWiki based of one of the other more scaleable code bases.

I am sure the majority of the TWiki team don't want to leave all our faithfull and loyal customers behind with a stale product that quickly will die.

I prefer making TWiki a better product and keep our customers. I work together with many users that have worked hard on creatings topics and twiki applications. We will soon run into the scaleability problem and then a non-compatible TWikiPro will be of no use.

Many TWikiContributors try to make a living from their expertice and services related to TWiki. Those that can expect to survive in the future and become successful are the ones that understand the importants of building customer loyalty through quality and commitment. No matter what business you are in, total customer satisfaction is generally accepted as the basic foundation of success. And this is also why TWiki has survived as a popular product for so many years.

Use of wikis in companies is really started to catch on now and for those that are willing I am sure there is a market for consultants with a prosessionel business behavour. And for us that are on the customer side I hope that these continuous statements of dropping compatibility and forking out is a minority oppinion. Because I am personally getting very nervous and I am sure this debate is scaring away other customers both from the TWiki project and from the consultants that affiliate themselves with TWiki. If I had arrived to the TWiki project today and read all the last weeks of debate I would have chosen a different project. I am sure this will also create negative press soon when TWiki is evaluated against the others.

I am happy that I know so many of the TWikiContributors that have worked on this project for so many years and know that almost all are very dedicated in making TWiki a product you can trust and which gets better and better. I am also happy to see some new faces that have thrown themselves in with great energy. Yeah there are bugs. But they get fixed faster than on most projects. So I am still optimistic. Nervous but optimistic.

-- KennethLavrsen - 11 Apr 2006

It all depends on how you define compatibility, I guess. In the best of all possible worlds, I would prefer a much faster, totally compatible TWiki, with everyone working in the same direction. So this isn't a position I'm advocating -- in fact, I don't expect to run into the performance problems large companies run into because I have a completely different client base -- but merely a possibility that came to mind when I thought about how we were going manage to improve performance significantly without violating the TWikiMission.

Let's assume that, as some of the most knowledgeable people have suggested, an important key to greatly improved performance is a alternative store and search module. This, by definition, requires topics to be stored in a different manner than currently used, which in turn implies that one or more webs, if not an entire install, will have to be converted for a company to enjoy the improved performance. And that would appear to violate the last bullet item of the TWikiMission, unless I'm misunderstanding what Peter means by it.

In some sense, then, you'll still have much of my hypothetical TWiki and TWikiPro, only in module form instead of completely separate builds. (Which, by the way, is probably the best way to do things unless performance and compatibility collide more extremely than this.) Companies that choose not to convert to the new storage model will be free to do so and will continue to run slowly.

Even though I don't have a personal stake in existing installs, I do in fact feel it's important not to abandon existing customers. I have been using the Macintosh since it came out, and Apple took great care to support old software when it felt the only way to dramatically increase performance was to switch to another chip set. (In fact, I've just bought a laptop which has the second chip set switch, and it also allows older apps to run, although I think not the ancient ones.) But the fact is that applications that were not rebuilt to take advantage of the new chip set ran considerably slower than those that were (and eventually died). Similarly, companies with sizable installations may have to convert their topics or continue to have Twiki run slower and slower as the number of topics grow.

The bottom line is that no upgrade scripts may inherently conflict with achieving significant speedups and so a decision will have to be made. Edinburgh can be marketed as "200% faster than Dakar", but doing so will be an implicit lie to existing customers if that speed is only available to new installations. I, for one, am not comfortable with that; my hypothetical Twiki and TWikiPro at least would be honest in what each offered.

-- MeredithLesly - 11 Apr 2006

I'll be in TWiki, but I'll be watching you

-- SteffenPoulsen - 12 Apr 2006

Thanks Steffen for the best comment I've read during the last weeks (since Druzilla is poking around) and thanks Kenneth. If I could confer TWikiHearts these two guys would get one each.

-- FranzJosefSilli - 12 Apr 2006

you can edit TWikiHearts, btw

-- WillNorris - 13 Apr 2006