I’ve said it before: I like Textpattern. From a design standpoint, it has a great elegance. Templates are XHTML with Textpattern-specific tags in a separate XML namespace, so the whole thing remains a well-formed XML document. Pages can use a library of template snippets. Plugins simply become new tags. Articles can be assigned both categories (like “fiction” or “poem”) and sections (separate page templates/style sheets, analagous to newspaper sections).
From an implementation standpoint, though, things aren’t so pretty. Set aside the author’s baffling choice to require plugins to be uploaded in an encoded form, set aside the “PHP is evil” arguments, and you’re still left with some things that need serious refactoring. Article “excerpts” are made typographically pretty using Textile, but they get mangled on subsequent edits of the same article. The back end requires MySQL. (I don’t share ketrien’s flaming hatred for MySQL, but using PEAR DB to get free compatibility with a dozen databases should have been a no-brainer.) The database architecture is… we’ll just say fragile, with articles associated to categories and sections by name rather than ID, and those associations more a matter of administrative convenience than actual programming. The REST-like clean URIs are bogus:
is the “correct” permanent link, but the
13/ shouldn’t be necessary as an identifier—the idea of permanent links is to not associate articles with database record numbers that could ostensibly change. But it’s the only part that is necessary:
will get you the same story, and for that matter,
will also get you the same story, but now formatted using the template/style from the “about” section. Argh!
All right, all right, it’s beta software. (Dean Allen, the author, inexplicably calls it “gamma,” and further confuses the issue by giving gamma releases a different versioning scheme than the release candidates: release “g1.19” is earlier than “1.0rc2”.) This is all being worked on, right?
Well, funny story there. See, g1.19 was released in June 2004, and 1.0rc1 was released in September 2004. The only new user-visible feature in the release candidate was making the “custom fields” the g1.19 release added to the database partially usable. (1.0rc1 lets you make conditional decisions based on their content, but not actually display their content—fortunately other people have written plugins for that.) 1.0rc1 rewrote the entire tag processing system behind the scenes, which may have been a great thing, but a few tags stopped working. Not so great.
1.0rc1 also saw Textpattern move to a public (read-only) Subversion repository and a bug-tracking system, which was promising. But, as I groused earlier, that promise isn’t fulfilled: the repository isn’t being used and the tickets aren’t being closed.
Instead, what we have is a single thread on the Textpattern support forum with people getting antsier and antsier about the “final” release, which is promised to add no new features and will certainly not address the implementation concerns above and is late. It was supposed to be released January 10th, with nightly tarballs available of current builds before that.
As of yet, no release, no tarballs, and an increasingly shrill shouting match from people getting progressively more irritated matched against people defending Allen’s honor and trotting out a lot of open-source clichés: nobody should be complaining, since it’s a labor of love and you’re not paying for this and if you don’t like it move to Canada and yadda yadda.
This is why I’m venting here instead of on that forum, because I’d probably point out uncomfortable things like: hey, Dean Allen started TextDrive—the web hosting service I use—in part to fund Textpattern development, so in point of fact, he is getting paid to do this.
The main reason Textpattern hasn’t had its little GPL self (openly) forked yet, I suspect, is simply that Allen commands a lot of respect. He is a Minor Big Name in the weblogging world and has earned an awful lot of slack. But there’s a point at which people eventually stop cutting you that slack and say, “You’re a great guy, you’ve started a great thing, but this project can’t just be your baby anymore because you’ve become the main blocking point.”
This is something I’m definitely familiar with as the blocker, so I’m sympathetic. It’s difficult to bring on help to projects even when you want to, and if it’s a project you feel very strongly about the direction of, you may want to hang on very tightly even when you know you’re more drag than driver.
On the other hand, I’m tempted to be the one who forks the project: most of those changes would not be difficult to do. Moving to PEAR DB might be time-consuming and rearchitecting the database would break existing databases, although writing a converter would be trivial. But fixing those things, slapping it into another publically-accessible source site with a new name, and making sufficient noise to get a few more developers… there’s value in that. And I’d just need to get two other people I trusted with commit bits to make it likely that the ball would keep rolling even if I wasn’t actively pushing it from behind.
On the third hand, I’d be more tempted to design a whole new project with a more flexible concept to start with. I have notes for such a beast already. Of course, I’d also be tempted to write it in Python, which would contain its own pitfalls. (PHP takes some justifiable slams from language purists, but it’s dirt-simple to install a PHP webapp, without noodling around with
.htaccess files or Apache module directives.) And getting going on that would, as I wrote earlier, be adding more work to my poorly-managed time. (Note that the time’s probably there, just that I’m not managing it well.) Forking does have the advantage of starting from an established code base. Trying to start from scratch might well mean the project never goes anywhere at all.
Which part of me thinks might be a point in its favor…