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."
This word sounds like Phone, I am representing my client thomas edison and taking a 100% commision for you trampling all over his IP. My dad from the SCO conned me into doing this.
1888 Franklin St.
This says a lot about good documentation and decent ease of use. I've seen many perfectly intelligent people come up against the brick wall of Zope's usability, and sit there scratching their heads going "wtf?". Luckily zope IS very powerful, otherwise it'd never end up being used.
While it's testament to the skills of the plone team that now there's a solution, and indeed that's the OSS way - if a solution is needed someone will write it - the years that zope's existed WITHOUT some kind of help it desperately needed is telling.
Problem is, a "byte-sized" article would be one-half of a Unicode character, or shorter than all but two words in the English language. Not probably a constructive article.
#define DRM chmod 000
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.
>>esr>>
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.
Less is more !
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... ;)
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:
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.
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.
I've been dealing with Zope for quite some time now. What has been said here and in the interview about the weedy unfinished stuff and the (still) inconsistent documentation of Zope and it's Products ('Product' is a technical term in the Zope Appserver) is generally true. .Net, SunONE and IBM WebSphere look like some IE plugin in beta stage. Shure it can be a serious slowpoke on standard PC's, but nevertheless have I and some people I work with bet on Zope. When Zope - 3.0 is going to take a big step - reaches maturity in terms of documentation and community standards for developing, computers will be fast enough to make Zope the tool of choice for any server side thing one can think of.
If you don't have a knack at OOP *and* aren't willing to read through some messy, redundant and unfinished third party code experiments you're gonna have some hard time getting going with it.
Beyond that Zope is nothing less than the ultimate refrence for the way all server side stuff will be done in the future. Zope comes with a fully integrated object relational Database, runs with and on, what I call the fully GPLd equivalent to Java, Python and is an absolute breeze to develop with.
Technology wise Zope makes BEA,
We suffer more in our imagination than in reality. - Seneca
Err, well, you've missed the mark a little.
:-)
Here's my quick standard reply:
Zope is an open source Web Application Server, developed allmost exclusively in Python (some speed parts in C) with an integrated object relational database, aka ZopeDB and a web frontend with access to all interal components.
That pretty much summs it up for Zope.
Now for Plone:
Plone is a CMS and a content syndication system programmed for and with the Zope Appserver. These Zope Applications and 'addons' are very easy to develope and install on Zope (naturally, if you consider the description above) - think 'plugin' - and are called Zope 'products'.
So Plone it a 'tad' more than you're standard CMS, be it slashcode/e107/Nuke/whatever, since it can very easyly utilize the vast power of the underlying Zope and other products, like Webshops, syndication mechanisims or webcrawlers and data-mining bot's, just to mention a few. Zope actually severely blurrs the edge between database, application and frontend and leaves it completely to the developer where to draw the line between those components.
Imagine an appserver where you can just drop of data for storage at whim without having to mess with DB abstraction layers, conectors and stuff, that comes with a full featured web interface where you can track and modify the inerts of your appserver either by custom coding (in whatever language you fancy that has conectors to Zope, Perl for instance) or by using the interface options and elements - which you can of course provide with your own extensions.
That's what Zope and thus Zope/Plone is all about.
That one can't exactly say what Plone is in standard terms actually shows the power of Zope. Basically it's whatever you make of it.
We suffer more in our imagination than in reality. - Seneca