Python Secret Weblog for 2005 April 6 (entry 0)

(11) Wed Apr 06 2005 20:35 What Zope can learn from Ruby on Rails:

Ian Bicking just posted an insightful analysis of what makes Ruby on Rails work. What struck me most was the following:

Zope is also unique among web frameworks, and maybe even among Python projects, in that it's something where people choose Zope first, then Python comes along. With most other projects a developer chooses Python then finds a project in Python. As a result, Zope users are selected not for an aspect of the implementation -- Python -- but because they are specifically attracted to Zope and all its metaphors and design decisions.

This is what Ruby on Rails has. People are selecting Rails, and it just happens to be written in Ruby. This seems weird, because it's a developer framework and intimately tied to the language, but it's clearly what's happening. So as a result, the Rails community isn't going to fork as developers get frustrated with the specific metaphors it chooses. They are choosing the framework, not the implementation. In contrast Python web programmers have been choosing implementations, then seeing if they can accept the framework (and forking when they can't).

Zope has indeed mostly been picked historically for the platform and what is offers, instead of for the language it is implemented in. I think in many cases the decision to go with Zope was not a very technical decision, but more one based on community, visibility, and user-level features.

Zope has a user interface, for instance, and while it looks somewhat old fashioned now, this has been a feature that helped tremendously to sell it to non Python-programmer decision makers. Zope being backed by a company has also been important. Zope being extensible with all kinds of components (Products) that offer to add new functionality in a 'building block' way is also something that looks attractive. The ease of creating dynamic web pages using the web user interface also helped first impressions a lot; the amount of stuff you could do with a few simple (then) DTML pages impressed people a lot (and then the bad part of the Zope learning curve kicks in, but that's after the decision to adopt Zope has been made). That Zope is implemented in Python doesn't play a role for many decision makers at all.

Something that Ian doesn't say explicitly but that I think is very important in adoption patterns by the wider community is one of presentation. Ruby-on-Rails presents itself well. We (the Zope community) can learn from this. Just compare their website:

http://www.rubyonrails.com/

to the Zope one, for instance:

http://www.zope.org/

Zope's presentation is dull in comparison. Almost no images, and no hype.

Zope 3's web presence is even worse:

http://www.zope.org/DevHome/Wikis/DevSite/Projects/ComponentArchitecture/FrontPage

while zope.org is dull, Zope 3's presentation to the wider community positively sucks. Nobody is going to convinced to use Zope 3 by looking at that set of web pages. I know that wiki is not targeted to the wider community at all, but it's the only thing there is, besides the Zope 3 base, which does look somewhat more appealing:

http://codespeak.net/z3

Plone, in constrast, does this a lot better:

http://plone.org/

I do not think it is a coincidence that Plone does presentation well and that Plone took off as it did.

Zope is currently in a phase of transition from Zope 2 to Zope 3. It's fairly well understood in the community that Zope 3 has desirable technical merits; we do not need to convince Zope users of this. We do need to convince other Python programmers of this, but it's clear from Ian's analysis that this is an uphill battle.

If we want Zope 3 to be popular, what we need to do is learn the lesson of Plone, learn the lesson of Ruby on Rails, and do presentation well, and attract new people, from outside the immediate Python community, to Zope. It's likely we need other people for this than the Zope 3 core hackers. I'm not ideal either (just look at the 'design' of this blog), though I can help writing text. How to find the people who are good at this? I don't know, but if we run into some let's give them all the support they need.

Technical excellence and quality are important, but for this to be useful, we also need a community, and to gain a community, marketing can help a lot. So, let's think a bit about buzz, hype, and pretty pictures.

---

Comments:

Posted by Ruben Decrop at Mon Apr 11 2005 17:27

About 2 months ago, I had to implement a new web site. Being a python lover, I looked at different python web frameworks.

In the past I had done some testing with Zope 2.6 and now I gave ZopeX3 a try. I downloaded the Zope3 developers book and tried to develop my small application, which handled online subscriptions for an cultural event. Next to the 10 static pages, It has 3 dynamic pages:
- processing the subscription form.
- a browsing page listing all subscriptions.
- an editing page for corrections, only available for the event manager.

My findings, from a web developer point of view:

- the new component architecture look nice but it is very heavy and has a steep learning curve.
- Writing the 'hello world' product is a nightmare in terms of the number of actions you have to take. Productivity is not pythonic at all. It would be nice, if the component architecture can be circumvented for easy things. Perhaps this is possible, but I could not see how.
- I did not miss the TTW development which is not available (yet)
- Storing web pages in the ZODB has much more disadvantages than advantages. For ftp, webdav, versioning, distributed development, ... you depend on the tools that Zope provides and which are not the best around. This is the main reason that I eventually chose another framework
- the @@ syntax is a mistake
- Zope is a bit blurry about the role of the web developer, who adds functionality to a site and a the role of the content editor who adds static web pages to a site

My conclusion is that one can use Zope if
- one is prepared to invest time and effort before one becomes productive
- one has a large project

For small web applications it is just overkill. The reason for not choosing Zope had nothing to do with the marketing, but with its technical shortcomings.

Posted by Carlos de la Guardia at Mon Apr 11 2005 18:13

I think a lot of Plone's popularity has to do with the attractive design, but another factor that Plone has in its favor is the user friendly setup executable that allows aspiring content managers to have a fully working (and also clean looking) site in a matter of minutes, together with their cool Windows Plone control panel which lets casual users stay away from configuration files. That's a lesson not lost on the Ruby on Rails camp either, witness their 10 minute setup video. Since learning a development tool really well (even Rails) requires a heavy time investment, you need a quick hook, a gimmick if you wish, to attract a huge prospective audience to that first try. When the hype calms down and the cloud of smoke disappears, what you have left is a user community.

It would help Zope 3 a lot to have an easy way to create a first application, automatically generating the required configuration files. That and a cool web site to hype it like crazy all over the net.

Posted by Garito at Mon Apr 11 2005 22:06

Hi
I spend 2 years working with Zope and in my opinion Zope has these problems:

- Bad documentation
- Could be simplified (ZClasses, DTML and some duplicated products will be pass)

Less is more don't you?

Posted by Oliver Marx at Mon Apr 11 2005 22:11

My favorite programs are like my favorite women

-> They look good
First impression counts. Nobody approaches the ugly girl unless serious amounts of beer are involved.

-> They are easy to talk to
If I don't understand the babe and she doesn't laugh when I'm making a joke... well - then I will click the "Next!!" button without second thoughts.

-> They tell me when and why I'm wrong
I hate "Fatal Error - and I'm not going to tell you why I'm mad! You may call me when you have figured it out!"

Posted by Oliver Marx at Mon Apr 11 2005 22:16

[Improvement]

-> They tell me when and why I'm wrong
I hate "Fatal Error - and I'm not going to tell you why I'm mad! You may call *my Mom* when you have figured it out!"

Posted by Martijn Faassen at Tue Apr 12 2005 00:48

Carlos de la Guardia writes:

I think a lot of Plone's popularity has to do with the
attractive design, but another factor that Plone has in its
favor is the user friendly setup executable that allows
aspiring content managers to have a fully working (and also
clean looking) site in a matter of minutes

That's a very good point. Note that I consider such "out of the box gratification" as more part of marketing than a technical feature. After all, when someone going to set up a real production Plone or Silva site, people are less
likely to use an installer.

Ruben Decrop writes:

For small web applications it is just overkill. The
reason for not choosing Zope had nothing to do with the
marketing, but with its technical shortcomings.

I think you're right at that too. Still, I believe marketing plays a part here, too. I do not actually consider the Zope 3 learning curve that terrible (though it can be much improved). Perhaps that a few simple, low-time-investment tutorials would help in making the curve flatter some more even without changing the code, though.

That wouldn't go all the way, but if we let developer marketing drive the technology a bit more for a while, we can get further. That means a focus on flattening the learning curve, ease of installation, instant gratification. Marketing can play a part in the direction a technology takes, too.

Thanks by the way for the criticisms of Zope 3. I agree on some of this, disagree on other parts. If you want to take it up, you might want to move to the Zope3-dev or -users mailing list and we can flesh it out some more.

Posted by Andreas Elvers at Tue Apr 12 2005 11:22

I'm working with Zope 2.x for 4 years now. I completed two bigger projects of which both are intranet systems. When I started using Zope there was no python script or page template available, but there was DTML. I did not know any python and was very exited about Zope. Too bad for me it was a bad mistake not to learn python in parallel of learning Zope programming. So I tried to find my way through TTW programming, which was very very hard.

Eventually I found my way and tried to convince my co-workers to adopt zope as our main technology.

I failed. There was no Zope CMS available that could fit our needs. Our needs are: Speed of development (programming and design implementation), total freedom in design since most of our money is done by producing web presences for mid-sized companies.

So what was the outcome ? Typo3. Written in PHP it is the most horrible thing I ever worked with. It is a nightmare for a programmer. But our (web/screen)-designers could use the interface. They could 'understand' it. The can even code typo script ( a textual description that is windows registry-like). And it delivers features out of the box that plone can not deliver.

If Typo3 would have been written in python, ruby or what ever ? It would not matter. If you can deliver a program to the masses, the language is of no concern if everybody is happy. Everybody is not quite true. I'm really unhappy.

Since it wasn't my decision it's not my problem typo3 lacks transactional logic and some decent error reporting. It does not have unit tests. It does not have page templates. It is so cheap and still so powerfull. People just don't conceive good design. But people are the masses and that's where Zope should be heading very soon before there is no need for it any more.

And Zope can do it. I know.

Posted by Scott Pierce at Tue Apr 12 2005 16:08

To me, the defining element is ZPT. I have yet to find anything close. Plone is sweet and Zope 3 is still an unknown to me, which says a lot as I have been building Zope products for several years doing virtually no work TTW. I'm a little hesitant to dive into Zope 3. I just don't feel up to breaching another paradigm at the moment and I think the point of the blog is valid. However, it is a framework and there will be products such as plone (if not plone itself) that will ease me into Zope 3. For someone new to Zope 3? I guess it will have to be that next killer application. I don't think Zope 3 in and of itself is sexy enough regardless of a glossy website. Having said that, it really should be reworked. It ain't pretty.

Posted by Peter Bengtsson at Thu Apr 14 2005 01:03

Let me through in a wild point amongst you more clever people...

When comparing www.rubyonrails.com with www.zope.org from web design point of view I can imagine that a lot peoples naive conclusion is that rubyonrails is new, fresh, immature, for mac users; whereas for zope.org people will naively think it's mature, boring, geeky.

Heck, looking your blog makes me think you're a oldfashioned unix expert in line with Greenspun, ESR and those people.

Isn't there value in that? First you appeal to the geeky developers and then the thick-walletted decision makers will follow. Google adopted this pattern and seems to be doing very well.

Posted by Martijn Faassen at Thu Apr 14 2005 13:30

Peter, that's a useful point.

Zope needs to appeal to an energetic, fresh set of developers if it wants to grow in the open source realm. Zope might indeed need to present another face to the decision makers. Whether zope.org is the right thing for either is another question.

Note that I'm not sure I want to be alongside Greenspun and ESR. :) I'm not in fact an old-fashioned unix expert, anyway.

Posted by Erin at Thu Apr 28 2005 01:57

I have a few years experience with a few scripting languages, and when faced with a large project recently I landed on Zope and started the learning curve.

After a solid month of banging my head against the wall I barely had a single page of my project up. I was frustrated that every peice of Zope looked different and acted different and required it's own steep learning curve. I asked my Zope expert (has worked with Zope for 4 years now) friend to lunch so I could pick his brain to solve a few specifc mysteries - and his advice - don't use Zope - move over to Ruby on Rails.

I did so and had, in a single morning, done everything I managed to do with Zope in an entire month.

I am very comfortable in the completely object oriented language Ruby, and am doing some moderately complex things for my project with very little code so far.

Zope 3 may be a different story - but I would have to have some pretty compelling reasons to ever try Zope again.