Crisis of Faith: The Messengers Have Been Shot

By the way, the crisis of faith mentioned in my last post may be minor. There is a lot about Zope 3 that I like. There’s a lot about classic Zope that I’ve liked. But I feel frustrated. That frustration is felt on more than one level too. I’ll get to the positives soon enough.

Again, I’ll mention that I’m not necessarily a good person. I haven’t contributed any actual code for more than a couple of years now. I don’t even run checkouts from Subversion. I must deliver results to my customers on as much trusted, supported, and released software as possible. I try to keep up on the general discussions on the mailing lists, but can only keep up on a few usually.

But I do have a passion for this. I want beauty, I want happiness, I want Python, I want Zope. I want others to want this and have it. But if I’m having frustrations, what are they going to feel?

Gripe 1, Message message message. There is no message.

Well, if there’s a message, good luck finding it. Now, a lot of people say “Python has a lot of web frameworks”. Well, I wouldn’t call every Python programmer’s one-off a real “framework”. There are a lot of options. But there are only two others that have a lot of buzz and momentum behind them, are usable today as complete options, and look like they might actually make it to a 1.0 release and beyond. Let’s look at what they offer (keeping in mind of course that it may change after the time of this writing):

TurboGears has a nice site with a narrative text and clear links to what’s important. You can quickly learn what Turbogears is about, and can quickly see tutorials that deliver something usable and understandable. I think what I like best about the current version of the TurboGears site is that the text is readable. It’s prose, but full of links. It’s not just bullet points (we’ll get to this in a minute).

Django also has a great site. The main focus is on some great introductory text (again, with links) about where Django came from. Elsewhere on the page, in nicely and subtly separated section, are links and text (with links!) about the essentials of the framework, documentation, showcase sites, and weblog entries about the project itself. The weblog side is small (title, description only). It shows that there is movement and momentum in the project, but it doesn’t overwhelm the page as the central piece of information. The newspaper mentality of the core Django developers shows through here. Like the front page of any good newspaper or news site (emphasis on the ‘good’ part), there are headlines and columns and information that opens up into inner pages, and it all seems pretty appropriately weighted.

And while it’s not a Python framework, a quick visit to the framework that has made the dynamic language set in vogue again, Ruby on Rails. It’s opinionated. It’s got big buttons – “Get Excited” – promotional screencasts, presentations, and more; “Get Started” – the download link (big clear ‘1.0’ with a release date underneath the big shiny button); “Get Better” – API references, books, documentation, etc, for both Rails and the Ruby language; “Get Involved” – community resources.

And what about Zope 3? Zope.org does have a nice introductory paragraph. Personally, I find it a little hard to focus on with a noisy lists and lists and lists of links design. Beyond the introductory paragraph, there’s not much real text on the page. “Zope 3” is buried down in the “Developers” section in the list of links on the left. On a 1024×768 screen, it may or may not even make it “above the fold”.

The Zope 3 page is full of many sins. It’s basically the development wiki for the project. Quick – can you spot the download link? Visit the ComponentArchitectureOverview page. Is it up to date with how things have worked since Zope 3.1? Back to the front page – is there anything on there your eyes are actually happy to land on and spend a few minutes soaking in?

The sites for TurboGears, Django, and Ruby on Rails all have wikis, but they’re not the prominent interface. They’re the backup resource. I believe they also all use Trac. The Zope 3 project is older than Trac. But I often wish it would find a way to move to it. Trac’s unification of subversion browsing, bug tracking, milestone managing, and more is a great feature. I love the turbogears roadmap which is just a Trac generated page. “what’s going on with the 0.9 release? Oh, there it is.” The Zope 3 Roadmap? – Nothing. It’s a good attempt at providing useful information.

Some systems provide proposal tracking, where proposals are documents with metadata that are attached to a milestone and release. Granted, this information is only as useful as people keep it up to date. But man, I wish I knew what is coming in Zope 3.3, or might be coming, and the status of it. A wiki can’t get me that information. It’s a terrible interface for information like that. How can I get excited? Excited enough to actually get involved and contribute? Excited enough to say “well, Zope 3.2 didn’t quite do what I wanted, but if that new thing is coming in 3.3 and it will be released this summer, I’ll definitely come back and check it out then.”

But can you get any of that information out of the Zope 3 Proposals page? No. What about the zope 3 subprojects page? Nope. What about the projects that have been discussed (or sometimes just mentioned in passing) on the mailing lists? And why should they go in the Wiki anyways? It’s hard to navigate. It’s hard to query. It’s hard to make information stand out. It’s hard to group associated tickets, subversion branches, etc in right with it.

Of course, I’m biased against wikis in general. With very few exceptions, I’m screaming and cursing within the first few links into any wiki. And contributing / editing is just as bad, as most of the “structured texts” of the world tend to really bite. The question marks that show up unwanted in text, the FunNyCapitAliZation (especially of words like ZoPe and PyThon) that can show up makes me cringe, and makes any text very hard to read as my brain has to stop and take the word apart and put it back together. Augh. Frustrating.

The thing is: the whole Zope 3 community knows this. There’s no good web site that gets people excited, shows motion, offers easy and obvious download(s), offers introductory tutorials, or takes a stand and says “Zope 3 Kicks Ass”.

And, well, there is no message. There’s no stand. Debates are still going on about whether to give Zope a new name. Whether to use silly release/code names (a terrible concept, I think). Whether Zope 3 means the core set of technologies, whether it means the full stack and half assed content pieces that ship with the current Zope 3 download (which basically provides the “Zope 3 Application Server”), or whether it means something on par with Zope 2 and offers a future for Zope 2 and Zope 3 as we may (or may not) know them today.

So no one can say “this is what Zope means”. They don’t know. I don’t know. And we can’t agree. Zope 2 offered so many ways of working with it that it was hard to agree. “You can develop your web site like this… Or you could do it like this… Or you could do it like this…”. Not that there is anything wrong with that kind of flexibility. But it’s ultimately too many features, too many options, too many different ways of doing things that aren’t compatible. And we suffer from this in Zope 3 already. Not as badly as in Zope 2. But … I don’t know. I really don’t.

I don’t know why whenever I start a new project / application I’m not excited. I always feel like I’m having to copy / load / configure / tweak / copy quite a bit, still, to get started. It doesn’t take that long, and I’m sure I can extract it out into a usable starting kit framework. But even for me, after all of these months working with Zope 3 and years of working with Bobo/Principia/Zope 1 and 2, it’s hard knowing the best way to start. There are “easy” features we could use. For immediate results, we have a couple of different options. But none of them grow easily into a real application.

Having those is a distraction. There’s a user set that I’m sure they’re useful for. But as I mentioned in the last post, I’d love not only the core simple concepts of Bobo (Python object publishing). I’d love one that was stripped of these distractions, but was otherwise Zope as we know it: easy container/containment relationships. Pure persistent Python content objects. But most of all, it’d be one that could be installed and used with a tutorial that didn’t have to spend time explaining “this ZMI thing” or “that i18n file add menu item”. The slate would be blank, the possibilities wide open. Concepts that don’t apply to the situation don’t need to be learned. For me, things that don’t concern me don’t need to be pushed out of the way. With this tool, you’d still be signing up for certain aspects of the Zope experience: the object database (or maybe a really well integrated object-relational mapper), etc. But you wouldn’t be signing up for the bigger set of tools that build on that. Put that in another release.

And a message. We need a message. We need to prove that message in code examples, tutorials, etc. The fact that it seems to be so hard to even come up with this message is not good. And after a night of wrestling with decoding ZCML directives and vocabulary lookup and binding to write a test to prove (and then fix) a bug in my code – many many many many lines of setup support in a test harness (setup support that acts nothing like it does when used in the application environment). The bug fix? 3 lines of Python plus 1 line of adapter registration. That seemed very disproportionate. And as I grumpily sat at work the next day, the lines from David Heinemeier Hansson’s presentation about Ruby on Rails at Snakes and Rubies kept running through my mind (especially as I started reading their PDF book, Getting Real): Beauty leads to Happiness, Happiness leads to Productivity. I’ve spent just enough time wrestling with things that I shouldn’t this past week for that to be very appealing.