Interview: Paul Everitt

Paul Everitt is one of the leading people in the Plon and Zope communities. Zope is a Python web application framework, and Plone is a content management system (CMS) built on top of it. At FOSDEM 2007, Paul will present Plone 3.

What's your plan for your FOSDEM talk?

I'm always sympathetic to the audience. If I was listening, what would I want from a talk? Would I get bored?

I want developers to walk out knowing the 3 things that might make them interested in Plone 3, along with the specific first steps to get started. I don't need to show a thousand points of details or 30 slides of theory.

What's your opinion about the "ecomic impact of FLOSS" report by the EC?

Zea Partners is a non-profit business partner network of the people involved in building Plone and Zope. We have participated in some of the EC projects that interoperate with the FLOSS studies and were specifically mentioned.

As such, we have a particular voice on this subject: small business and independent contractors. I'm happy to see things in the report such as "Almost two-thirds of FLOSS software is still written by individuals; firms contribute about 15% and other institutions another 20%." and policy strategies of "Encourage partnerships between large firms, SMEs and the FLOSS community".

You're involved in both Zope and Plone. Does that lead to conflicts of interest sometimes?

Not at all. Plone is a CMS application, built atop the Zope application server. Zope is written in Python. Thus, supporting Plone means supporting Zope and Python. All layers in a stack.

Are the two projects heavily related?

The Plone core team participates in Zope development and provides a large portion of new Zope users each year. Also, Plone-based companies have funded some initiatives in the core of Zope. At the same time, more needs to be done to move Plone work down the stack into Zope, or even Python, where possible.

What is planned for Plone 3.0?

Jon Stahl, the organizer of Plone Conference 2006, wrote a nice tour of the features. In summary: inline Ajax, versioning/staging, portlets, wiki-style linking, and link checking. Under the hood, [there is] more of a push to use the component architecture of Zope 3, as well as improved support for Python packaging.

And how is Zope going to change in the future?

As background, Zope spent time from 2002 through now on a major new version named Zope 3, which focused on a vastly improved programming architecture. Many of the things Zope 2 did right were improved, but many things that developers complained about were also rethought. This effort has reached maturity now, with 3 upgrade releases (Zope 3.3 is the current) and 2 books, one of which was just released in its second edition.

The effort now is on doing things with Zope 3. First and foremost, getting Zope 2 and Zope 3 to converge. This has been happening since the Zope 2.8 release and is really picking up momentum now. As Zope-based projects such as Plone start to depend more on this integration, Zope 3 technologies will become the norm.

Additionally, there are efforts to scale Zope 3 down, making it easier for developers to get started. There is a project called Grok that aims to make the first 10 minutes of Zope 3 as effective and fun as possible.

The lower part of the Plone/Zope/Python stack, Python, is not (yet) as mainstream a language as PHP is. Do you feel this is a burden, or does it also have advantages?

They are both mainstream languages. PHP certainly has an order of magnitude more users, but Python definitely passed the tipping point years ago. Amongst people that just want to get a series of dynamic pages on the web, PHP owns that market. However, when writing a larger-scale project, and certainly when making a platform such as a CMS, the choices are more even.

Thus, I view it as an advantage. The Zope and Plone world, as applications written in Python, want to appeal to a certain audience. That audience appreciates the balance of power and elegance that we feel Python provides.

PHP, Python, and others are all popular, and will never eliminate each other, simply because different people like different approaches and have different needs.

What do you like most about Python?

Everything is so immediately obvious and natural. It fits my brain. It also, though, scales up (in formalism and performance) to larger-sized projects. Thus, someone like me, on the low end of the skill level, can co-exist on a project with all the smart people.

What are the main activities of ZEA partners?

We are involved with several European projects, bringing our voice as a collection of small businesses that create FLOSS. We are also involved in other non-development activities, such as working together on tender responses, giving the company founders a place to swap experience with others, and similar activities.

In your experience, does the open source world has any similarities with the military?

I was a military officer in the early 90's, so it's a particularly appropriate question. I went from the Navy directly into Python and the Web.

With that said, my experience (combined with my crummy developer skills) made me an oddball. In the Navy you had individual accountability. Specifically, at the junior officer level, you had enough coercive control to force, or push someone to be accountable for the result.

In open source you have group accountability. And you can't push, you have to pull. On one hand, "getting things done" can't be dictated. On the other, there is still a role for following up and keeping things moving. Getting that balance, and achieving group accountability in the culture of a project, is one thing that separates a young project from one that is mature.

Additional links:

This interview is licensed under a Creative Commons Attribution 2.0 Belgium License.