Photographer: - / Illustration by Lia Avant

Alan Runyan - Plone Visionary.

Alan is one of the "Benevolent Stereo-Dictators for Life" of Plone.

I discovered Zope about 4-5 years ago after a posting on slashdot. At the time the company I was in was building IIS/ASP/SiteServer applications. It seemed we ended up having to build one-off administrative interfaces for all of our applications. And I saw Zope as the Be-All-End-All of web administrative interfaces. Slowly I picked up DTML and not wanting to learn Python (yet another language, right?) I constantly bloodied my head against Zope. My feeling was Zope was powerful, reusable (i.e. ZConfera and Squishdot), cross-platform and more complex than I had time for. So I put it down for a number of months.

About a year later I went to the 8th International Python Conference and became completely addicted to the language, the community and Zope.

Well, I'd had a bad run-in with the PTK (the predecessor to the CMF) and then the CMF came out and I sort of dismissed it because of its ancestry. After about 1.2 I realized that it was much nicer and offered higher level services than the core Zope framework. But it was impossible for developers or managers to see the value of it. It was pure function and no form.

As "emerging":http://www.emerging.com/ (my former employer) was collapsing under its poor management decisions, I started doing Python full-time at work. During the death throes of the company I was hanging on the fledgling #zope channel on efnet. Alexander Limi (aka dracvl) was also on the channel and asked about product development. I had sort of gotten the hang of Zope product development at that point (although I was still afraid of Zope) and helped him through his problems.

We started talking about the state of the CMF and agreed that it lacked sex appeal (visually). I told him if he could give me a nice design and some HTML/CSS I would skin the CMF. He came back in about 48 hours with the first set of HTML. About 72 hours later we had a dtml version. Collaborating over a month together (via .zexp) we moved what we had to the filesystem and shortly after that abandoned DTML for ZPT. This let Alexander focus on the presentation (HTML/CSS), freeing me up to work with Python -- which I enjoyed. The rest is history *wink*.

Uhm, localization is a big niche and is always something you can point at, "look you can have Plone in one of 30 langauges". But since I only speak American I would opt for Integration. I would like to see Plone leveraging Archetypes' transformation system, i.e. upload a Word/Excel file and have it transformed into HTML. And I would like to see versioning of content in subversion (SVN). I want people to be able to work from their desktop and administer the content through the Plone interface. This is the road to world domination – ubiquity and integration with quality projects (OpenOffice for transformation, SVN as a content repository). Plone needs to focus on being a proper content management system.

Archetypes is WONDERFUL! It's not quite ready for secretaries (well... it won't be until we land Through The Web Archetypes -- patrons needed!) but for developers it is a blessing. Ben Saller, the creator. really sums it up: "lowering the entry bar to the complex requirements Zope places on new content objects." If you have done any Python Product development in Zope you know there is quite a bit of boilerplate to deal with. Archetypes saves us from 95% of the boilerplate and lets us get on with our development. Technically it's a tribute to Python's runtime flexibility.

Plone relies on infrastructure such as Archetypes, CMF, and FormController. It's very important to understand that Plone wants as little infrastructure in its core as possible. We want to spread the infrastructure responsibility across the community and not across the Plone development team. So in one sense I see Archetypes' importance as letting a group of developers focus on infrastructure (outside of Plone). The most tangible benefit for Plone is the lowering of the development bar. People define "schemas" of how they want their content types to work. They don't need to worry about the details of class hierarchies, security and, to some degree, storage!

I get to code less and less these days. Now that I am running RUNYAGA, LLC. and attempting to wrangle the entropy that is the Plone development process I depend on others to do the heavy lifting (coding). Reportlab is really fantastic software but we use it in conjunction with Zope. I really enjoyed working with Jython when I worked at a Java shop (although I don't miss Java). Oh...of course I use SpamBayes for spam filtering!

Hanging out (Alma Watching films (Fast, Cheap and Out of Control). Attending lectures (Noam Chomsky). Exercising (swimming). Reading (The Muse is Always Half Dressed in New Orleans). Walking (Bazil and Chunky, my dogs). Museums (Stedelijk). Concerts (Radio Head). Listening to Music (James Booker). Events (Art Car Ball). Food (Nutria). And of course being with family (Aunt Joy)

I have seen *a lot* of (pragmatic) Java refugees come to Zope and Plone looking for faster development turnaround. Explaining the roles and responsibilities of CMF components would be nice. The whole reason why we are here is because of Python. I would like to see more examples detailing: traversal, security, ZODB, ZSQL, cache managers, and core components of the Zope infrastructure for which people do not have time to peruse the sourcecode. And of course examples, lots of examples (). We should focus on the educated developer - the ones that can contribute quality software back to the community.