I was going to comment on Martijn Faasen's reply to Paul Everitt's reflection on agile content, and then it turned into this post-sized thing...

To recap: Paul thinks that there was something really great about Zope's through-the-web (TTW) development, that it brought in content developers to the development process and facilitated a sort of agile practice on the part of those content developers. Underlying that is a critique of the move in Zope 3 (and even in later Zope 2 developments) towards components, and towards a programmer-centric model. Martijn's reply is that maybe TTW was a nice idea, but it was unmaintainable, and that programmers and sysadmins have certain requirements that Zope/ZODB development didn't fulfill.

I'd counter that content requires just as much discipline to manage well as code does; TTW didn't serve programmers well, but its actual implementation can't serve content developers well in the long term either. As programmers we've developed lots of techniques to manage our code; these happen to be filesystem-based, and thus unavailable to ZODB-based code. But more importantly is just that they exist. They didn't and don't exist in a reliable way for TTW (Zope) development. Instead of bringing programmers into the underpowered TTW world, it would have been better the processes that programmers use to content developers.

Every feature that source control systems have is applicable to content. Merging, branching, conflicts, tags... they all have meaning there, and with a little education I believe that that content developers can appreciate the purpose as much as programmers. (Those processes don't come naturally, to programmers or content developers, but I think it is clear that they are worth learning.) And reading Paul's post, it occurs to me that many version control systems are actually very sloppy in a lot of ways. They record changes, but they don't check your syntax, and they generally don't apply any external policies or workflow. (Interestingly Zope does check your DTML syntax and won't save bad files; this is annoying in practice.) Version control systems generally work on flat files which they don't interpret in any way. That's the kind of underlying infrastructure that makes for a flexible, developer-friendly environment that Paul is talking about; flat files aren't a complete interface, but they provide the kind of flexibility that facilitates agile workflows and tools.

And maybe it's useful to note that this sloppiness is true of open source version control systems in particular; true of the things programmers build for themselves, without the misplaced micromanagement that proprietary systems find themselves catering to.

The parallel to CMSs is fairly obvious; it's not programmers that make a CMS into a labyrinth of creativity-crushing exercises, it's the blasted managers who drive the CMS vendors to implement misguided features. Paul's rather minor dig at component development is much less central to his thesis than the larger dig at managers and the typical CMS design.

The open source aspect is interesting too. When we build tools for ourselves, we build good tools with which we won't piss ourselves off. (Well, often we piss ourselves off, but we then we keep rewriting those tools until we feel better.) Unfortunately, it's hard for content developers to make their own tools in the ways that programmers do; it's even harder for them to rewrite and reform those tools. Paul is wishing they could; Martijn knows that in practice it doesn't work just out of desire.

But authors can build good tools in some way; I think people are trying to build the infrastructure for these things right now under a variety of names. I think that's what Jotspot is about, what Aaron Swartz's startup is trying to do, and lots of other efforts too, direct and indirect. Blogging software reinvigorated simple content development, but it did so without any tools for building tools, without any real user-accessible extension mechanisms; but this next round of software might be changing that.