Interview with Ploners
Formulator makes life easy
Server side python
Resetting Zope's session timeout
Getting undo history
« Website of Bruno R. Preiss
» Canada launches WebPot
Huima has some excellent points on what makes it difficult to make people understand and support Zope. Readers have some excellent comments too. Personally, I believe, Zope Corporation needs to have a dedicated marketing team that can map solutions based on Zope to common customer needs. Not everyone gets the idea that it solves 80% of *almost any* problem right-away and 20% is for you to solve, very easily.
- Zope is different
- More than one way to do it
- Zope and Python have been relatively unknown
- What really makes the difference ?
- Learning is hard
- Knowledge is scattered around the world
- Setting up a good development enviroment
I’ve found my beef is only with #7. Rest of the things are not a big deal for me.
A person once exclaimed: “Zope is a really bad thing, because it is unlike anything I learned in school”. I think Zope is not the bad thing, but the learnability of this person. I studied 8086 architecture in Engineering college. By the time finished college and started work, no one was using 8086. The whole world was using 80286. Architecture is a bit different, but should I’ve stopped working or using it because I didn't learn it in school? No, I learned 80286. Technology changes. Fast. IT professionals need to have good learnability.
Actually, Zope Corp got rid of much of their marketing team around the same time I left the company. Zope Corp makes their money on consulting services, and it turns out that not much marketing needs to go into that, as enough customers have come approached ZC based on referalls or some other introduction to Zope (usually from someone in the company downloading it and using it).
It doesn't make sense to have a marketing department on payroll that isn't able to contribute substantially to sales. This is especially true in light of all of the other "open source app platform" companies that have gone bust in recent years (Lutris, makers of Enhydra; and Ars Digita (the skeletal remains of which are now owned by RedHat) are two prime examples).
I'm starting to sound like a broken record, but hopefully Zope 3 will make all of this easier, because Zope will be easier to explain in some common terms (components, etc). In some regards, it's similar to J2EE, at least in the general concepts area. I also hope this will bring a more uniform way of developing Zope sites. There's a big polarity difference right now between the script/template/sql way and the ZClass way and the Product way and the CMF way.
Marketing department - I'm just pained that I've to repeat myself to people/managers about how great Zope is, to solve typical problems. If I send them to Zope Corp's site, that is probably a sure way for a manager to get turned away :-(
Smart companies know they need to pick a solution that solves their problems; not problems advertised by the vendor. Such companies will have no problem choosing Zope. Problem is, there are quite a few "dumb" ones out there. Where preference is for latest IT buzz words. You need something "pretty" to show them.
Example: Show default CMF to a manager. See if you get favourable reaction. Show Plone with all its skinned glory. Actually, this is a real-life example. I conveniently forgot to mention that Plone is based on Zope and CMF - *sold* without any questions being asked.
Point is, in such firms, you need to show something for the people who sign checks. Which these folks can in turn show to their bosses to get applause. At that level, you need pretty stuff, unfortunately.
Hi Babu,
I'm one of the people who find Zope having a nearly vertical learning curve. I'm used to basically hacking away at most products to master them, but the API and learning DTML to make Zope work just dissuades me. Also the staggering 495 pg zope book doesn't lead to instant gratification either.
Any advice regarding how you overcame these problems?
Regards
Arun