Photographer: - / Illustration by Lia Avant

Chris McDonough - Developer and Writer.

Chris McDonough is a software developer for Zope Corporation. To say that he helps maintain the Zope Book and other Zope documentation is an understatement. Without Chris' work the Zope Book and Zope Developers Guide would not be the valuable documentation resources that everyone in the community depends on while achieving some "Zope Zen".

In mid-1999, I was a Web developer for a Philadelphia consulting company. The local electric company requested a bid from us for an intranet and I was volunteered to prepare the bid. They weren't in much of a hurry, so I took my time.

At the time, I knew Perl fairly well, so I looked into Perl- and PHP-based solutions. We were a heavy Microsoft shop, so I was obligated to consider some Microsoft solutions as well. I tried out several packages but all were somewhat difficult to install and difficult to customize.

Shortly thereafter, the first Open Source Zope release was issued. I ignored it. A few months later, Zope 2.0 was released. I was curious, so I downloaded and installed it. It didn't work. I installed the earlier release instead. It did work.

I remember thinking that this was a pretty nutty system. Instead of files, you worked with *objects*. The development environment was a *Web browser*. It had a wacky brain-busting contextual inheritance system called *acquisition*. And it was written in Python, of all things. I knew nothing whatsoever about Python, and the sense I got from reading about Python at the time was that its proponents needed to get over themselves and get some real work done.

But Zope had this incredible security system. At the time, I was used to writing CGI code which took a request, checked the request for credentials, and attempted to perform some sort of authorization based on those credentials. We'd typically check the credentials against some sort of ad-hoc role table in a database, performing the authorization check directly in the application code itself. This code was *no fun* to write and writing it permeated all of our projects. We always invented a new authorization system from scratch for each project. I found out that if I used Zope, I was no longer forced to write my own access control routines. It just took care of it for me. That's what made me get over myself and start using it. There were probably other solutions for different languages/platforms that had the same sort of thing, but if there were, I didn't know about them.

At the time, neither ZPT nor Python Scripts existed, and I didn't know enough to write a Product, so all of my initial development was performed via DTML. We actually never got the energy company intranet job, but during the bid process I did write a primitive intranet in DTML that we later used internally for document management. My first foray into Python proper was writing a Zope user folder implementation that authenticated against an NT domain (smbUserFolder) for use with this document management system. By that point, was firmly hooked.

I would later gave a talk about Zope to the local Linux users' group (ironically, in attendance were Perl notables Mark Jason Dominus and Adam Turoff). I corresponded with Paul Everitt at Digital Creations about this talk. I eventually asked him for a job and surprisingly, he gave me one.

I just sort of fell in to it. Amos Latteier and Michel Pelletier were working for ZC (which was DC at the time). They had written the book and were maintaining it up until maybe late 2001 or early 2002. Eventually both left ZC, and the book fell into "officially unmaintained" status.

Lack of adequate documentation for any product is the highest barrier to its wide adoption. I wanted Zope to succeed, so I got it into my head to update the book. I made the book commentable by using BackTalk and I let the comments start to roll in. When there was a sufficient mass of comments, I did a little work, rewrote and reorganized some chapters, added a couple of chapters and so on and put the result up as the 2.6 edition. Then other folks joined in and it began to improve greatly.

As of late, I have been remiss in canonizing the latest edition of the book

as "current", but it represents everything we currently know about Zope. ;-)

Writing good documentation is hard. It's much harder than writing code. This is why many systems aren't well documented. For Zope, documentation is very important because Zope is a framework. A framework is something that you "buy in" to; it's a set of fundamental services that your code depends on. While on the one hand it is much like a set of libraries that you can make use of in your code, it is, on the other, unlike a library since you often need to actually change your coding style and practices to make use of a framework. You can almost always fairly easily excise the use of a library from your application code, but it can be prohibitively painful to excise "framework-ness" from your application code. A framework is something that has the potential to aid you greatly because it does a lot for you, but also has the potential to stop you dead in your tracks when you don't understand how to make it do what you want. Documentation appears to be the key to making a framework your friend instead of your enemy.

Paul Winkler and Peter Sabaini were the most active contributors to the Zope Book. They did an amazing job improving the trickiest chapters of the book.

The other folks that contributed to the Zope Book (who also did a great job) are listed at the bottom of this page:

http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/Preface.stx

There had been a particularly acerbic rant on the one of the Zope mail lists. The author was someone who had given very little to those who were criticized in the rant. I didn't feel the right to criticise was earned, given the inequity.

It was one example of a type of message that comes from a person who has gotten themselves into a situation they cannot easily get themselves out of through bad decisions and promises they've made to other people.

The software and the support is free. Consulting costs more.

External Editor, CMF, VerboseSecurity. Um. That's about it. I really don't use many products, though I should. I typically write my own. Who here has a wheel they need reinvented? ;-)

Mail list archival. I started a project to do this.

https://sourceforge.net/projects/zopemailarchive/

A better collaborative document editing system (BackTalkNG, no structured text).

I'd like to see Zope 3 become a better Zope than Zope 2.

I recently had occasion to download and install Plone on Windows and I was amazed at the amount of work that went in to making it easy to install and control. It's very slick. I'm a bit envious of the Plone Controller for Windows; it (or something like it) should be a part of the Zope distribution for Windows. Andy McKay rocks.

I've not been able to make the time available to really evaluate the applications that make up Plone. I don't run my own Website, so I have no personal need. ZC customers typically need very customized applications (otherwise they wouldn't need ZC), so it's not very often we get to reuse third-party products that are at the application level. Typically, we'll try to reuse components that are at a lower level, like database adapters and such. But when it comes to UI and content management, everybody seems to have different requirements. I'd like to take the time to see if there's any reusable bits of Plone that might work well in a consulting engagement.

The newest version of Zope.org is based on Plone, so I'll certainly be using it more in the future.

I like reading interviews. Your interview with Lalo Martins was very interesting. Do more of those!

I spend time with my (wonderful) girlfriend. We're waiting expectantly for the new season of The Sopranos.

Recently, I've been playing video games on the MS XBox. Ken Manheimer and I have worked our way through Halo in cooperative mode, and now we're about halfway done with Brute Force. I also regularly play the snot out of MechAssault ("mcdonc" is my MS Live "gamertag" lest anyone else out there plays MechAssault ;-).