O'Reilly Interview with the Plone Founders

Alexander Limi writes "Just in time for some light weekend reading, O'Reilly's OSDir.com has published a byte-sized interview with the two founders of Plone. This is a nice follow-up to the earlier discussion on Slashdot, and covers a lot of the unanswered questions people directed to us earlier as the surprise winners of the O'Reilly COMDEX competition."

Comments

What's Plone?

[Eric S Rayrnond]

Plone is built on top of the open source application server Zope and the accompanying Content Management Framework which have thousands of developers around the world supporting it.

Plone is ideal as an intranet and extranet server, as a document publishing system, a portal server and as a groupware tool for collaboration between separately located entities. A versatile software product like Plone can be used in a myriad of ways.

Who uses Plone? Many organisations. NASA / Jet Propulsion Labs, Lufthansa, the Austrian Government.

Re:What's Plone?

[CapnKirk]

Ok. Here's the long description:

Zope is a web application server. It is written in python. It has a builtin web server or you can run it behind apache, squid, whatever. It maintains all data in a object-oriented database. What zope does is generate dynamic html pages on the fly. You write a page template and when the user GETS that page, the variable information is inserted and then returned to the user.

Another feature is that a Zope website -- and much of Zope itself -- is managed via the web. And it has a very sophisticated security and permissions facility. It uses the concept of "roles" to which permissions and access to objects can be attached.

CMF (Content Management Framework) is a zope application that creates a set of services for the website developer: navigation, calendar, new items, workflow, etc. It also provides the basis for css-based "look-and-feel".

Plone, as was noted in the interview, started out as a CMF "skin." It has evolved into kind of a "CMF best-practices". It's philosophy is -- in part -- to permit the creation of *sophisticated* web content in a collaborative environment by users who know little or nothing about html, etc.

There's lots more to be said, of course. But I've been using Zope for two years, and Plone for nearly a year. My preferred scripting language is Ruby, but Zope/CMF/Plone is so valuable, I went out and learned Python in order to read the source code. Today, most of my work involves writing a page template and maybe some snippets of python code to go along with it -- often less than ten lines. Simple.

If your need is collaborative web content creation/management, web portals, etc., and Joe Sixpack is your user, then Zope/CMF/Plone is the way to go.

A very satisfied user,

Kirk

Plone is self documented

[axxackall]

While I agree that plone is better documented then zope I disagree that it's "easy".

Plone is still in a deep lack of being documented. For example "Plone for web-designers" is till missed. Many API details I still have to get from the source code itself.

Also, one of the best Plone's documentation is a set of already existing and still being actively developed Plone applications.

But in general Plone still keeps guiding app developers, and thus leaves them more chances for future interoperability.

I wish that one of issue collectors/trackers in Plone will stabilize. Currently I use CollectorNG, which can already beat Bugzilla. I am not sure what PloneCollector developers want to achive by completely rewriting CollectorNG. As for official Zope/Plone issue collectors - they are kind of primitive.

Another wish: Zope and Plone sites will have forums with functionality of CMBoard, which I think is beating PHPBB already.

Re:Plone is self documented

[kalistra]

The single most significant improvement of PloneCollectorNG over CollectorNG, IMO, is that the Plone version lets you define your issue schema dynamically, through the web, using a very simple interface.

Also, because PCNG is built using Archetypes, the hooks for TTW schema editing have been backported to the Archetypes project, allowing for simplified development of TTW schema editing for ANY Archetypes based pieces of web content.

Re:I am going to sue these people.

[martyn s]

Alexander Graham Bell.

Re:A bit telling

[jalet]

I agree that beginning to use Zope without any documentation at hand is a bit confusing (to say the least). But really you should be able to setup and use Plone to create a basic working website with publishing workflow, membership, themes, i18n, etc... within minutes, and without having to type any line of code.
Then of course to go further, you have to read some doc, but just like with all powerful software.

Plone 2, Archetypes

[supton]

I think things are getting better - much better, much faster. Soon-to-be-released Plone 2.0 and Archetypes are contributing to this - the learning curve for all aspects of Plone is getting flattened.

Zope has a "Z-shaped learning curve" -- or so goes the saying; this is becuase Zope (well, Zope 2) has a deep tree of class inheritance - a "deeply object oriented" system (to borrow a phrase from Jon Udell, not sure if that's his intended meaning). When someone tells you to "read the source" -- that's usually becuase Python is remakably easy to read -- but you still you end up with a task that's fairly involved and somewhat academic (not to discount this - once you get it it is quite rewarding).

What the CMF and Plone do is put a "wide-not-deep" framework on top of the Zope app server to abstract most of that tedious, academic learning curve for serious developers. The CMF hard-codes a really simple MVC-like design-pattern for best practices for component-oriented development, where lightweight components interact (global "tools" like search/catalog, workflow, etc and content objects in folders/containers (the model) - and UI/automation skin code (view/controller)). Each component is lighter-weight and pluggable (with defined interfaces and unit-tests), and CMF, Plone, and unrelated Zope 3 development are working towards not just pluggable components, but user/admin configurable components. The Plone 2 control panels are a good start towards making this more human. The ease-of-development and deployment story is getting better. The UI is also more configurable in Plone 2 via CSS.

Getting better by the minute: Archetypes is the secret weapon for Plone's future success; Archetypes makes schema-based development for content items, along with relationships among content items, not just easily possible, but much less tedious. It's architecture, in many ways (though it is still maturing), is superior to the same concepts in WinFS in M$ Longhorn. Archetypes will make development of content types easier to learn and develop day-to-day, whether you as a developer prefer to live in Vi (or Emacs), UML modelling tools, or a web-based schema editors. Simple, usable, documented examples for Archetypes development in Plone are popping up every day. Developing global CMF tools (singleton services/utilities for all objects in the site) has always been trivially easy, but underdocumented. Plone 2 is making the UI easier to customize, and I expect that forthcoming books and improved documentation on Plone 2 will make this straightforward.

Keep in mind, the Plone/Zope/Python stack is much less complicated and easier to learn than equivalent technology stacks in Java app servers (and less messy than inline web apps in PHP/ASPX/etc). And seriously, if you have to say WTF, say it on #plone on freenode or the plone-users list - there's a high likelyhood that someone will have an answer to just that question... ;)

litte plone commercial

[2.246.1010.78]

I really liked them talking about increasing 'mind share' in the interview, because when I had to set up a new website for my local political party youth organization, the hardest part was convincing people that plone is exactly what we wanted - they never heard of it and it takes quite some time to explain the whole thing to people that aren't geeks at all.

what we wanted was:

• something with decent security - this rules out phpnuke
• something that is standard compliant, xhtml and the stuff
• something that is once set up and than easily managable by joe doe
• something that serves as a depository for information and relates the information to other relevant information
• something that seperates content and markup, plone1 does this halfway decent

Plone fit the bill and I think we can be quite happy how well it works, if you never tried it out: take the time and toy around with it a bit. The learning curve is a bit steep at the beginning (at least for the person that sets the whole thing up), but afterwards it is really a beautiful piece of software.

What exactly *is* Plone?

[0x0d0a]

I'm trying to figure out exactly what all of the hubub is about. From what I can tell from a quick Googling, Plone is a piece of software that helps people use Zope more easily, by slapping a GUI on it. Zope is a Python-based content management system. Content management systems are apparently something vaguely along the lines of Slashcode -- they store data in a database and let you more easily generate webpages from said data. They would be used by someone who wants to set up an e-commerce website or a blog-capable website.

I may be utterly wrong -- I'm a little surprised that I couldn't immediately turn up a simple explanation of what these things are on the web. If I'm missing something here, can someone clarify?

Re:What exactly *is* Plone?

[darnok]

OK, I'll go first - I'm sure people will correct me if/when I'm wrong...

Zope is a Python-based, Web application development system. It runs on *nix and Windows, and I'm pretty sure Macs as well. One of its key strengths is that it allows Web page designers, content generators and Web logic coders to work together without stepping on each other's toes - that's a big challenge with most Web application tools. You do all your work within Zope using a Web-based GUI, which is another unusual feature. There's a lot more to Zope than this, but that's enough for starters.

CMF is a Content Management system that runs on top of Zope. Content Management is for those sites where you want relatively non-technical people to be able to contribute "content" without having to worry about HTML and other nasty techo stuff. Think of people providing articles for your local school's newsletter - they should just be able to supply ASCII text, and someone else deals with typesetting and page layout. In this case, the "someone else" is CMF. There's more to CMF than that, BTW...

Plone sits on top of CMF, and adds extra tools such as workflow to CMF. In the school newsletter, you would probably have an editor who checks all the incoming articles, fixes typos and ensures nobody's said anything nasty. The contributor of the article would send it to the editor, who would then either accept or reject it. The "workflow" in Plone lets you implement this editor-type role in software. Again, there's a lot more than Plone than that...

Hope this helps a bit. I really like Zope, but as many people have said, getting your head around it is a bit challenging at first. Unlike many tools, it's difficult to "start with the easy stuff and learn the tough stuff as you go along" - Zope doesn't really lend itself to that approach, which I think is where many people struggle with it.

straw person...

[supton]

There are not "default" behaviors of Zope/CMF - CMF is a framework - NOT NOT NOT a product. CMFDefault is just an example application. Plone is a CMS application on top of the framework an app server product. It is not "impossible" to port of CMF product (i.e. a product designed to work with CMFDefault) to Plone - there are very few differences. I do this all the time. I'd like to point out that CMFdefault is rarely used for any serious (paying) work or production products by anyone (not Zope corp, not independent CMF developers and consultants); Plone on the other hand codifies best practices learned from real installs.

Also, use archetypes - it is easy to create your own content type products with Archetypes. This isn't that hard, and the documentation is getting better.

For All It's Merits...

[AShocka]

and there are plenty, as stated by many here, the problems I see with it are;

• Why isn't the Plone site a bazaar for the Plone community? Most other sites like Drupal show a very active community, but Plone.org seems like a ghost town compared to the others; no online discussion forum, which is a much better interface than email, especially when a new user wants to just check in and see what's happening. This scares a lot of users off, because this should be the centre of activity for a community. Zope/Plone/Python developers seem to tend to be focusing on consulting businesses, that's great, there's nothing wrong with that, but if that is the case, then Plone will remain a niche CMS because it does not function like other OSDNs. As a consequence it is not going to get the community involvement as other OSDNs do
• Resource hungry and no ability to write to a static htdocs dir. I know there are caching mechanisms in the Plone book, but it still does not really address this need. This may not be an issue for many of you that can run your own server and connection, and just throw resources at it, but for those of us who want a solution even running on a dedicated server (which usually have very little RAM), it can be a resource hog. Then, on top of that, having to dynamically serve content, that might just as well be served statically, is a huge price to pay on your server. There should be a way to use this app as a publishing tool and write the production version in static html as an option.

These are two issues I think the Plone/Zope community need to address if they want to be seen as a very accessible solution, because a lot of users will see it as a great solution to implement, start building something, then when it starts to really get difficult, the only real solution left is to hire a Python/Zope developer or consultancy, cause there just is not enough real solutions in online forums or documentation.

You can use a lot of other CMSs without having to become an expert under the hood, but everyone here is saying it's easy if you just read a bit of code. That's okay if you are either a great coder or dedicated to this CMSs path, but not for someone that may be just involved in web publishing and comes to Plone/Zope hoping for a complete web based interface solution. After all, isn't this the intention of Plone/Zope?

This scares off a lot of potential adopters. Even Cocoon and Axkit are better documented and have a lots of user discussion (admittedly on email lists)