A few months ago during development of Textile 2.2 the idea was floated that it would make sense for Textpattern and Textile to part development company. Textile would of course remain shipped with Textpattern and be the default installed markup system, but development of the engine should be spun away from Textpattern’s core.

The reasons for this are numerous:

  • Faster development cycle for Textile which could satisfy third parties that integrate the language in their products, as they would not be bound by Textpattern’s release cycle
  • Attract a wider development base—especially in porting the engine to other languages such as Python or Ruby
  • Present a one-stop shop for official downloads, documentation, a user/developer testing environment, and Issue reporting
  • Push Textile further in terms of localization and feature sets
  • Allow Textpattern to merely ‘include’ the latest Textile version at release time, just like we do with jQuery

With this in mind, we will begin the process of separating the two projects after Textpattern 4.3.0 is officially released.

Where to?

We need a home for Textile. Perhaps a top-level domain if we can secure funding for it. Then we can migrate the tools and documentation that we developed for testing Textile 2.2 to the new location. The current official locations—thresholdstate.com and textism.com—house out-dated versions and documentation. We’d also need some volunteer authors to help with putting together a newbie introduction, official detailed usage docs, quick-reference cheat sheets, etc.

Putting the docs on the Textpattern user documentation site means lots of hoops to jump through since we’d have to mock up the Textile output: it would be far better to have docs on a Textpattern installation, despite it being more ‘closed’. Hosting it here is a possibility but having an open—or even hardened—textarea on the site for user testing doesn’t feel quite right from a security standpoint. Similarly, Textpattern Resources is no good because it’s becoming a plugins-only repository.

A dedicated domain and environment is most attractive on the surface, so if anybody has any ideas of a name/location or wishes to be a benefactor in donating to the domain costs then please raise your hand. We can probably host here on Joyent—details to be discussed.

There is, however, the important matter that Drew McLellan brought up on the dev list. We’re maintaining the PHP implementation of Textile. So does, for example, gettextile.com imply that all versions are available to download and try from there? Therefore other ports would have to be uploaded too, meaning the respective teams would have to submit the code to us for inclusion. And what if someone tries Textile (against PHP, because that’s on the server) with features from an older port and doesn’t get the expected results? We might receive a bug report that we can’t replicate. Messy.

So is a PHP-specific domain better, e.g. textile-php.com? Or could subdomains like php.gettextile.com be used, giving the relevant subdomain management to the interested parties, perhaps leaving the docs on the root domain? Or are downloads not hosted on the TLD at all and deferred to the local repos? Or do we not bother with a TLD at all?

Call to arms

Splitting the development means choosing developers—or at least garnering interest in the project such that an initial team can be formulated to make a few decisions. As current Textpattern devs, we do not wish to dictate where the project should be hosted when handed over. Google Code? GitHub? SVN? Mercurial? Who knows? Whatever is best for everyone; as long as there’s a place we can grab the latest version and put it in the core at release time.

With that in mind, are there any people who would like to be involved in running with this at the outset? Anyone care to decide where the code repo should be hosted? Steve (net-carver) has already registered a root project on GitHub “just in case” and is willing to take an active role in developing Textile (PHP), but the decision over the toolset ultimately rests with whoever wants to help with the development legwork. We will also need some people to put the official site together—in Textpattern—and keep it maintained.

It should be noted that this change won’t be overnight. We probably need to unpick the hard-coded references to /lib/classTextile.php in the core and do some bits ‘n’ bobs of maintenance first to ease the transition for plugins. We’ll post more news as we have it.

So who’s up for taking Textile to the next level? And what are your thoughts on the domain issues? The floor is yours…