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.
You misspelled . . . oh, wait . . . he he
----
"Ours was a free culture. It is becoming much less so."-Lawrence Lessig
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
At first glance I read "Plone Founders" as "Phone Pounders." Imagine my reaction.
And the brethren went away edified.
Somebody modded this up? WTF? Put down the pipe willya. Informative my ass
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 !
Oh shut up already you ignorant bigot.
Yes, the nations were thriving when run by the whites who had both education and the experience of running the affairs of state. No-one ever bothered to prepare the native population how to run a modern country.
Then when these countries were given their independence, it all fell apart because no-one knew how to maintain the infrastructure. Furthermore, the borders of the nations were drawn arbitrarily across traditional tribal boundaries at gunpoint. When the guns went away, the fighting began.
So, yes, it was Europeans' fault.
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... ;)
That's a nice review - thanks!
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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.
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?
May we never see th
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
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.
I've tried eZ publish which is a PHP based CMS. Does anyone know both systems enough to point out the differences in performance, setup, maintenance? Thanks.
Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
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.
DRM 'manages access' in the same way that a prison 'manages freedom'
Antonio Meucci.
Bell didn't invent the telephone, US rules
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
why nigger?
Biographer's memo
Judge's Ruling in Bell vs. Meucci court case
Bell and Meucci
"Contrary to the implications in HR 269, the courts have looked into Meucci's claims extensively and were very unequivocal in their findings. Meucci was a defendant in American Bell Telephone Co. v. Globe Telephone Co. and others. (The court's findings, reported in 31 Fed. Rep. 729, are attached verbatim.)
The judge was scathing in his criticism of Meucci's claims and his behavior, and concluded that Meucci was deliberately involved in attempts to defraud investors.
The question of whether Bell was the true inventor of the telephone is perhaps the single most litigated fact in U.S. history, and the Bell patents were defended in some 600 cases. Bell never lost a case. HR 269 directly contradicts findings of courts in New York, Massachusetts, Louisiana, Ohio, Maryland, and numerous others states. (See among others American Bell Telephone Co. v. Dolbear, 15 Fed. Rep. 448; American Bell Telephone Co. v. Spencer, 8 Fed. Rep. 509, and American Bell Telephone Co. v. Molecular Telephone, 32 Fed. Rep. 214.)
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...
/. Because I'm suprised and never knew.
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 how and if things like that happen here on
It's OK anyway. I like 'weedy' better, but I guess 'messy' is easier to understand.
We suffer more in our imagination than in reality. - Seneca
What do I win?
Geez, I first read "O'Reilly interview with Ned Flanders". But then again, I'm drunk...
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.
then why are you here???
Was I the only one who read that as "O'Reilly Interview with the P'zone Founders"? You know, the food known to non-retards as a calzone that Pizza Hut sells under the name P'zone, because they are stupid whores?
Interestingly, you don't have to use the native object database - there are connectors to most sensible third party databases, including PostgreSQL.
The only thing you can accurately describe as "Scotch" is a sticky tape made by 3M. And it's
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)
Wow, that's some of the worst ASCII art I've ever seen.
Mailing lists (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 caching rules, Apache or Squid will serve from cache 90% of your requests. Also, you can push static files (with plugin product) - use plone on a workgroup server, and render/push static content out of it like some commercial CMS products. Your traffic can just be served as static pages, with only dynamic pages hitting your Zope, if you like.
Thanks.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."