Declarations

• I have a commercial interest in TWiki, insofar as I run a consulting business that provides services (mainly research and development) to TWiki users.
• I am a member of the WikiRing, a network of consultants who often work together to provide services to clients.
• I have a number of TWiki resources that I have not released for general distribution, as they represent added value to my business, and I want to protect them from predators. I always operate within the constraints of the GPL (and other applicable licenses) with respect to these resources.

Organisational Vision

My priorities are:

• To secure the future of TWiki as a community-led, open source project, free of any commercial constraints.
• Create a community of peers where creativity, initiative, and hard work, are all recognised and rewarded.
• Openness in everything within the community. There should be no barriers.
• I want to make it easy for everyone to use TWiki for free, without over-constraining those who want to make money using it.
• TWiki should be a model for other community-led projects.

Technical Vision

My vision of TWiki is a TIM - Team Information Manager (c.f. PIM). In my vocabulary a TIM is an integration platform; a portal or gateway that provides a consistent, configurable view onto data held in many applications, and provides a simple means to perform common processing tasks on that data to integrate different applications together. I believe I share this vision, to a greater or lesser extent, with all of my TWiki-using clients. These are all small to medium sized businesses, or business groups within large corporations. Their expectations of what they can get from TWiki fall into three broad categories, with many overlaps of course:

1. Featureful traditional wiki user (text only, discussion, collaborative authoring, but with lots of smart plugins),
2. Document store,
3. Highly user-configurable mini-database applications, mainly for issue tracking and lightweight project planning (TWikiApplications),
4. Industrial strength database interfaces and application integrations .........
5. .........that can be rolled out as customer solutions.

This is a continuum; I see "trad wiki" usage as entry-level, and industrial strength DB as expert level. Most have reached (3) and are knocking on the door of (4).

At the moment TWiki caters pretty well for (1), fairly well for (2), moderately well for (3), badly for (4) and not at all for (5). So my roadmap is all about filling in the gaps. Here are the things I think are missing. These are not in order.

Trad wiki

• We have been so focused on the original wiki model that we have to some extent lost sight of the fact that wiki meta-language was created to address the fact that no WYSIWYG editors were available. Trad Wiki usage will mainly be improved by WYSIWYG editing.
  • Post WysiwygPlugin, I believe we need a PluggableEditingComponent.
  • Also want an architecture for plugging TWiki Variable - specific editors into TinyMCE.
• A second uncomfortable fiction is the WikiWord. Word and phrase linking needs to be sorted out. RationaliseAutomaticLinking.
• Further out is the idea of providing better indexing - whether that is google-like searching, or keyword linking, at this stage I don't know. ImproveTextSearchingAndIndexing
• More flexible notification
• CacheingForPerformance Main.MichaelDaum has done this

Doc Store

Pretty much there, but could do with

• RobustContentTransformation to/from popular tools (M$ and OO)
• BetterAccessControls for attachments

DB

Possibly the most common use of TWiki, and where IMHO it is hurting most, is in the building of TWiki applications. I think we need:

• A much better model of content processing than difficult SEARCH and clunky uncontrollable plugins. For example, a PipelineModelForContentProcessing. Focus most plugins authors on writing TWiki applications - they should be able to do most of what they need from the browser.
• PerformancePerformancePerformance
• Brainless 3rd party application integration e.g. using HTML ripping without having to write perl code
• ContentAccessSyntax - REST services for DB content access. We laid the groundwork for this with the %IF syntax, and Sven has been taking it further.

Reuse

• Having recently gained a lot of experience with Dojo, I am well aware of the potential of reusable UI components, and how difficult they currently are to integrate with TWiki.
• AJAX is one possible technology

Industrial strength

• Ability to map a database as a data store. Any database (DBIStoreInterface).
• High speed SQL search & results presentation, supported consitently for all store implementations (again via DBI).
• High quality, high reliability (more test suites!)

Rollable-out

To be able to roll out TWiki applications as customer solutions requires

• Automatic packaging of a pre-wrapped TWiki application, for rollout on customer site (BuildContrib) (RequirementsForATWikiApplicationPackager)
• Simple management for very inexpert customer IT people (configure interface)

Restful access to data

• TopicObjectModel and ContentAccessSyntax, access to TWiki data via HTTP requests is the single biggest stumbling block for opening the gates to AJAX

Roadmap

This is work I would like to, and feel able to, undertake myself, and does not reflect a vision for the project given infinite resources. Also, these priorities may change in response to client requirements.

• TWiki 4.3 - UTF-8 support, but if and only if at least one regular UTF8 user steps up to participate in the development work.
• TWiki 5.0 - database store incl. SQL search (probably with SvenDowideit), BetterAccessControls
• TWiki 5.1 - consistent architecture for pluggable UI components, pluggable WYSIWYG editor extensions
• TWiki 5.2 - TWikiApplication packaging

-- CrawfordCurrie - 17 Nov 2004, 31 Jan 2008, 22 Jul 2008

Comments

I like this personal roadmap a lot. Thanks for this document, that will serve me as a kind of template ...

-- MartinSeibert - 02 Aug 2008