History shows that the best software has been developed by small teams who have the skills and are allowed to innovate within boundaries. Accordingly, splitting the Tcl into a language core and several modules would allow for faster evolution as each could have its own team (with a greater sense of “ownership”) and independent release cycle. If you’re going to eat an elephant, don’t attempt it in one sitting.

Strategy

• split Tcl into core language and modules
• break lock-step between language core and modules
• build smaller teams with a degree of autonomy
• retain TCT governance for API stability, but accommodate more rapid evolution

The modules would be those parts of Tcl that could (and should) evolve at a different rate than the core language.

The key is that each module would have it’s own semi-independent development team and release cycle, but retain TIP governance w.r.t. the API version that is considered “stable”. This would allow the module to evolve more quickly (or be intelligently designed ;-)) until the API settles down and people begin to rely on it.

For example, the networking module is crying out for IPV6 and UDP socket support - it shouldn’t have to wait for another full Tcl release rather than progress at its natural rate as features are added. Likewise DavyGravy’s iocp channel support on Windows.

Under this model, Tk itself would become just another module (or collection of modules).

The “Tcl language platform” would be the core Tcl features, plus a snapshot of each module API that the TCT is comfortable incorporating (more on this later). This introduces a distinction between the development and stable versions of a module, but in a way that hopefully would meet the goal of stimulating progress whilst preserving the core values.

Non-TIP managed modules might be included - for example parts of tcllib, SQLite or critcl. This would just mean that the Tcl language platform contains a known, stable version of each - not that they would be brought under direct TCT governance. But think of the benefit for newbies - you get Tcl + a GUI toolkit + an SQL database plus the ability to embed C code if you need to.

Likewise, new modules might be added

• system - to access system specific features such as a posix interface, bgexec, win32 API (similar to winico), OSX features, tty support, etc
• imagecore - a.k.a George’s megaimage extension for manipulating graphics from Tcl scripts
• event - the virtual events extracted from Tk
• Kevin’s symbolic differentiation extension
• Larry et al’s L language extension
• others? ideas please

The “Tcl language platform” would provide single point to get the “best of breed” or recommended functionality at the source code level. For example,

• a Linux distribution package maintainer would have a single port of call to get a reasonably complete set of features
• a Tcl “batteries included” distribution builders might add other 3rd party modules or even development versions of core modules.
• a distribution for an embedded device might only have a subset of modules relevant to the platform

Note that the initial emphasis here is governance not source management. If the existing source management tools (specifically CVS on SourceForge) aren’t sufficient to support this model then consideration should be given to using alternative tools. Even a best-of-breed proprietary one like BitKeeper (assuming that Larry and the community can work out a licensing arrangement that doesn’t preclude people like Kevin from using it). A future goal should be to separate each module into an individual source trees.

As Joe has put it - the Tcl Language Platform is a set of “modularized components with individual, independent release streams, collected and bundled up in a neat package by the Tcl Language Platform team”.

In summary, as Colin has said ...

“we know Tcl has heaps of value. Others don't. Adding puff, by putting space between the bits, makes it look less like a monolith, and gives outside eyes more to see ...It occurs to me that splitting out the bits, and giving them names, makes the language appear larger. So, Python has 'twisted framework' and that's like rilly rilly cool. Whereas Tcl has that and more, but it's hidden inside the language.

I can envisage/imagine the press release 'Tcl Community Team announces the Tcl Language Platform' make it sound like an expansion of the language, but all it really is is picking apart the threads and giving them individual names. It's really just leavening the mix.”