Forgot your password?
typodupeerror
This discussion has been archived. No new comments can be posted.

O'Reilly Interview with the Plone Founders

Comments Filter:
  • by Knight55 (742458) on Sunday January 18, 2004 @03:15AM (#8012389) Homepage Journal
    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.
  • A bit telling (Score:5, Insightful)

    by Saven Marek (739395) on Sunday January 18, 2004 @03:16AM (#8012390)
    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.
    • Re:A bit telling (Score:5, Interesting)

      by Malcontent (40834) on Sunday January 18, 2004 @03:43AM (#8012454)
      While I agree that plone is better documented then zope I disagree that it's "easy".

      Zope is just confounding. Plone makes it easier to get some things done. But sooner or later you are going to have to create a template or a script and then you'll be scratching your head and saying "wtf".

      When I was first using plone it would take me hours to find where some text on the screen was being produced or where to go to change it. I am still perplexed about where the actions for the user bar are for example. And of course sooner or later everybody will get a visit from the "spammish aquisition".

      I am waiting to see what zope3 and plone 2 are going to be like. I hope they make it easier for mere mortals to use them.
      • i hear things like this about zope all the time, i guess this is why i've been hard pressed to try it out. (completely aside from the fact that something about the name 'zope' just bugs me. 'plone' too, for that matter.)

        so i'm left confused, what exactly is supposed to be made easier by this? it sure seems like a possibly good idea gone wrong.
        • Re:A bit telling (Score:2, Insightful)

          by jalet (36114)
          Perhaps you could... try it.
          • my point is, why would i want to try it when i hear so much that's bad about it... confusing, poorly documented, etc, and the only thing i hear in its defense is just to try using it and see for myself?
            • Re:A bit telling (Score:3, Informative)

              by jalet (36114)
              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.
            • " my point is, why would i want to try it when i hear so much that's bad about it."

              Because it has a log of stuff built in. User authentication (properly abstracted so it works against pretty much everything), database abstraction, authority delegation, workflow, templating, etc. You get a lot out of the box. With all that power you also get complexity.
      • by axxackall (579006) on Sunday January 18, 2004 @05:00AM (#8012577) Homepage Journal
        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.

        • 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.
          • Yeah, I like. And I use Arhitypes in my projects too for the very same reason. However each time I am thinking about other people and that's why I use only stable Architypes. but PCNG guys requre Arhitypes from CVS HEAD, and THAT make PCNG unusable for normal site for at least half of year. If not longer. Ignoring other users is not the best type of behaviour we can find in Open Source.
      • Plone 2, Archetypes (Score:5, Informative)

        by supton (90168) on Sunday January 18, 2004 @05:30AM (#8012639)

        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 [plone.org] 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 [sourceforge.net]), 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 [zopezen.org] and improved documentation [zopezen.org] 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 [sourceforge.net] list - there's a high likelyhood that someone will have an answer to just that question... ;)

        • That's a nice review - thanks!
        • My biggest wish for plone and zope is a more productive working environment. I really miss my filesystem tools like grep. The find button does not work great at all and takes too long.

          I keep thinking it would be great if there was a cvs like tool where you could check out the subtree to your hard disk and work on it with your favorite editor and then check it back in.

          If not that then an eclipse or a jedit plug in would be awsome.
          • by Anonymous Coward
            Synchronizing to the filesystem is built into Zope 3. It's just a shame that Zope 3 isn't finished yet. Someone should backport fssync from Zope 3 to Zope 2, or to Plone, then you'll have what you need.
    • Re:A bit telling (Score:4, Interesting)

      by the_rev_matt (239420) <slashbot.revmatt@com> on Sunday January 18, 2004 @10:34AM (#8013281) Homepage
      I've been using Zope for 4 years now, and I still don't get this view that Zope is inscrutable. I have been trying to work with Plone for over a year now and it's damn near impossible to create your own product for it.

      While Zope documentation can be kindly described as minimalist, Plone documentation simply doesn't exist and what little there is is 100% wrong. Hell, I've had some of the plone developers send me solutions to problems and their solutions don't work (usually because they've skipped 2-3 major steps in their directions, assuming that I know as much about their undocumented product as they do).

      I think Plone is a great project, and it will likely become an integral part of Zope, if you want to do anything other than slap a different skin on it you are SOL. I'm particularly bothered by the fact that they override many of the default behaviors of Zope/CMF and there is NO way around it so it is not possible to port a Zope/CMF product to Plone without completely rewriting from scratch.
      • straw person... (Score:3, Informative)

        by supton (90168)
        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
        • I disagree with that. I have worked on plenty of production systems using CMF.

          I'm not saying the plone isn't good (it is, it's an incredible product really) just that it isn't strictly necessary. CMF is lighter weight and easier to manage. And I've had plenty of trouble getting anything written for CMF to work in plone. Plone takes over form processing and there is no clearly documented way around this that works. To reiterate, there are several documented ways to get around the form mangling, none of
      • I learned Python and Zope both in two weeks, and I was quite able to make a database driven web-site in those two weeks while learning, that took me a month to make in PHP, and I had used PHP quite a bit in the past.

        Comparing Zope to PHP, I think most people will come to the conclusion that not only is Zope easier to develop for, but also it's easier to maintain since it gently encourages you to move your data-access/queries into a seperate space.

        I've had a Zope server running without a single hickup for
  • by cgranade (702534) <cgranade AT gmail DOT com> on Sunday January 18, 2004 @03:22AM (#8012403) Homepage Journal
    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.
    • Actually the description is a reference to BYTE Magazine [byte.com], so in actual fact the article is relatively voluminous.

      Anyhow, even if they *did* mean 8 binary digits, if they printed them with a HUGE font size, then the article could be quite large indeed.
  • What's Plone? (Score:4, Informative)

    by Eric S Rayrnond (739458) on Sunday January 18, 2004 @04:37AM (#8012543) Homepage
    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? (Score:5, Interesting)

      by dracvl (541254) on Sunday January 18, 2004 @05:29AM (#8012637) Homepage
      Actually, the popular MAESTRO Mars Rover [telascience.org] site is also a Plone site.

      Does anybody else find it slightly amusing that Plone is running on Sun's network - on Sun hardware no less - and no Java in sight? ;)

  • by 2.246.1010.78 (721713) on Sunday January 18, 2004 @05:52AM (#8012668)

    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.

  • by 0x0d0a (568518) on Sunday January 18, 2004 @06:38AM (#8012725) Journal
    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?
    • by darnok (650458) on Sunday January 18, 2004 @06:57AM (#8012735)
      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.
      • Good description, but I disagree with your assessment that "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."

        On the contrary, with built-in authentication, roles, template engine, through-the-web editing, etc, etc, Zope makes it easy to build simple sites quickly with little digging into documentation. Heck, the outdated built-in tutorial is good enough for that, and the Zope Book (free online) is very good at gettin
    • by Qbertino (265505) on Sunday January 18, 2004 @07:33AM (#8012796)
      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.
    • by Anonymous Coward
      0x0d0a, I imagine, right now, you must be feeling a bit like Alice, tumbling down the rabbit hole?

      Well, we are trained in this world to accept only the rational and the logical. For a while, we were all able to escape that together. As children, we do not separate the possible from the impossible which is why the younger a mind is the easier it is to free, and why they were able to create Plone out of nothing but five letters and some hype. But now the rules have reasserted themselves. And it is harder tha
    • 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.

      This is one of my pet peeves though -- nothing requires a CMS to do any HTML publishing whatsoever. There should be some more specific term for CMSes (WCPS, web content publishing system) that are mostly used for maintaining web sites (which, granted is majority of things called CMS nowadays), since it'd make more sense for l

  • by Qbertino (265505) on Sunday January 18, 2004 @07:02AM (#8012739)
    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.
    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, .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.
    • Please don't mod this down, I don't want to start a discussion, I'd just like to know.

      ...*and* aren't willing to read through some messy, redundant and unfinished third party code experiments...

      I am *absolutely* positive that I wrote 'weedy' (as in 'weed') as the code isn't 'messy' but 'entangled'. 8-O
      Are there people editing comments for readability? I'm shure there's no 'bot substituting 'messy' for 'weedy'.
      Fact is, somebody or something edited my comment. That's fine, I'd just like to know who and ho
    • I am running Plone on a 400 MHz machine with 384MB of RAM, so not exactly a top of the line machine. And it works beautifully.
    • Beyond that Zope is nothing less than the ultimate refrence for the way all server side stuff will be done in the future.

      That is a little presumptuous. Anybody can say the same about their favorite tool or framework.

    • [Python is] what I call the fully GPLd equivalent to Java...

      Python is not "GPLed"; its license is an OSI-certified BSD-style license.

      Also, being "equivalent" to Java is not really Python's goal. Python strives to be considerably higher-level than Java, and incorporates more unorthodox features, such as generators. Python could better be described as a semantic cross between Java and Lisp, with more pleasant syntax than either.

  • by gunga (227260) on Sunday January 18, 2004 @07:23AM (#8012773)
    Plone is cool when you begin to use it because it seems to work immediatly, has a ton of functionality and looks good. I don't doubt it's a fine piece of software but there are big problems with it.

    First, Zope's internals are overly complex and sometime guided by ideological choices (the object database IMHO). It's a closed world with its own culture and logic. Its culture doesn't promote interoperability (again that's my feeling). It takes you out of the Web and into Zope Universe (after all this year, there are still problem when you want Apache and Zope to talk together, eg. Digest authentication).

    Zope is often dubbed (I think Jon Uddel first said this) "Python's killer app" but I find it very non-Pythonic: overly complex, non-explicit and un-welcoming. Plone adds another layer on top of CMF, Zope, the object database... it is very difficult to understand.

    I think that the best web setup is still a light and fast frontend (and PHP is good at that), a solid Database (PostgreSQL is better than a lot of people believe) and a third "business logic" tier which can be a separate application or shared between the frontend and stored procedure in the database. It's not the perfect theorical model but it's manageable, it stays simple (if you work hard enough to keep it simple) and you can evolve a simple website towards this model without restarting from scratch each time the requirements change ("embrace change", remember?).

    I'm fascinated by Zope and Plone because they do so much and frankly, I don't know if I'd be able to write such a piece of software. But I think it goes in the wrong direction: the application server direction. It tries to coerce the light, simple and stateless nature of the Web into the heavyweight transactional world of corporate applications, just like the Java world does (Java Server Faces seems to make it worse). It is difficult to make a good Web application, but it's even more difficult when you fight against the Web and the way it works.
    • In theory, I strongly agree with what you're saying. In practice, however, having set up my own Zope/CMF/Plone side on Debian unstable (yes, unstable) and Apache, I'm gonna have to disagree.

      It took me a while to set up Zope/Plone. There's a nasty bug in Debian's distribution of Plone, but thankfully there's a super easy workaround in the BTS [debian.org]. It also took a couple visits to #plone@irc.gnu.org to set up an actual Plone instance, but in retrospect it wasn't that hard. I got the Apache passthrough working
    • by MartinB (51897)
      Interestingly, you don't have to use the native object database - there are connectors to most sensible third party databases, including PostgreSQL [zope.org].
  • I've tried eZ publish [ez.no] which is a PHP based CMS. Does anyone know both systems enough to point out the differences in performance, setup, maintenance? Thanks.
    • The main difference is scope.

      Plone is big, it's a full Intranet-in-a-box. If EZpublish is enough for your site, you don't need Plone.

      But you should do this (I did it). Take one or two days and prepare 2 mock websites (a standard corporate site and a community/portal site). Download a few 'CMS' and try them with these sites. It seems obvious but you'll discover a lot not only about their capabilities but the way you're at ease with them or not.

      If EZ Publish is too little you should check Drupal. But test
  • Since when is 42.14 KB byte sized?
  • It stores all of your data in one big fat file. I had a guy at work using it for a small workgroup. That one big file got a little bit corrupted, and he lost the entire thing. Everything was gone.

    It would make far more sense, to me, to store things in separate files. That 'all your eggs in one basket' thing, you know.
    • he should have had backups.. you can take exports of it as well in both Zope export format and XML.
    • I have been using it for a year with no negative side-effects. Of course, I do backups every week.
    • Err, yeah, we'll how about that: A File gets a little bit corrupted and can't be used anymore. I have a little bit corrupted CD - it just won't boot anymore. And a corrupted kernel will panic on me. Would've you guessed?
      If this incident is a KO criteria for you, I'd suggest you reconsider your evaluation strategies.
      I'll bet my right arm that a corrupted ZopeDB File is easier to restore than a corrupted Outlook file. The other difference between them being that Outlook has a huge track record of being unstab
    • in addition to the obvious fact that backups would have saved your friend, it's also true that there is an alternate storage mechanism for Zope called DirectoryStorage which stores the ZODB as a directory tree (one file per object), instead of the monolithic FileStorage mechanism that Zope uses by default.
  • by AShocka (97272)
    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/
    • Mailing lists [plone.org] (or nntp/www via GMANE) are where all the discussion lives. Between the Plone users, developers, archetypes lists etc, I would guess about a volume of 600 messages a month, and equally that volume on the various Zope lists. The community discussion is VERY active.

      Resource hungry? Yes, well so is PHP, JSP, and any other system relying upon a VM. You can serve pages statically out of Zope, even from the filesystem, with the right add-ins. And by simply spending 5 minutes adjusting your ca

      • You're missing my point. If you want to showcase a product such as a CMS, then make your site show it's features so that users can see these features in action. Why can't a forum discussion module be built into Plone? Why can't it get a feed from GNAME and incorporate it into Plone. Show us what it can do. What this says is "It's too difficult" or "we don't consider discussion forums worthwhile". Doesn't really make sense. From a community point of view Plone.org still looks like a ghost town to me (r

If the code and the comments disagree, then both are probably wrong. -- Norm Schryer

Working...