Re: Open Source CRM - Options?

On Wed, 2008-05-28 at 10:46 +1200, Andrej Ricnik-Bay wrote:
> On 28/05/2008, Kevin Hunter <hunteke(at)earlham(dot)edu> wrote:
> > > And its python :)
> > That's actually a bigger plus than folks may realize because all three
> > communities (Django, Postgres, Python) share the
> > "do-it-the-right-way,-not-just-the-quickest/easiest-way" mentality. (At
> > least in my experience.) From an overall quality perspective, this is a
> > huge win for all involved. And if you're developing, you will
> > appreciate the chat rooms/mailing lists/community-in-general for all
> > three for just this reason.
>
> How does Zope/Plone fit in there as an alternative in your opinion? :)
>

I will offer my experience on this one. We were attempting to use
Zope/Plone for the GNOME.Asia summit website. In short, it was a
disaster for us. Starting with no experience in Plone the learning curve
was very very high.

I was able to make some initial theme changes, but when we started to
add custom objects, new "page types" to display things like speaker
profiles, abstracts, and adding new data to registered user objects the
framework itself really got in the way. We spent some time with the
Plone community but there were no clear answers on what the errors we
were seeing actually meant, several times the answer was "Well, you
have something wrong, but it looks like it should be working....".

Setting up the development environment on each persons system was non
trivial as well because the "preferred" method of using Plone/Zope is
with a "buildout", which is basically a magical script which can
download and set up everything. It sounds easy enough, but in practice
it can turn ugly. They offer pre-established Plone/Zope tarballs,
but when we used them and we had some issues trying to use some of the
extra modules, the first answer was always "are you using a buildout,
because then it would be easy for you".

Judging by the questions that were being asked on the Plone mailing
lists / IRC channel there are some things that need to be changed in the
default Plone configuration. I saw "Why doesn't my Plone start" as
many times as I have seen "Why is select count(*) from
my_super_blog_awesomesauce; so SLOW!!!!!" on the Postgresql mailing
list. The different being there were 10 different "common" answers for
the not start question.

Using version control on the customization "product" you create can be
hard too, because even though you commit your code, and the other
developers check it out, some of the changes your product make to
Plone's layout and display cannot be reverted without essentially
deleting and starting the database from scratch again. Not optimal.

Oh, and to top it all off, it really wants to use ZODB for its
datastore. Using an external data back-end is supported, but things can
break unexpectedly.

I will say that Zope/Plone has had a lot of time spent on it and the
developers that know it very well can do some very interesting things
with it pretty quickly.

Django, much much easier learning curve. It just doesn't get in your
way. Nice support for sqlite, postgresql, mysql. Django's ORM is very
easy to understand. The template system syntax is very straightforward
with excellent separation from the backend code. The web designer on the
team knows no python at all and has been able to work on the templates
with no problems.

Time spent with Zope/Plone: 4 weeks Result: base plone installation has
a new theme. website 15% complete. Eta completion: Infinity

Time spent now with Django: 1 week 2 days. Result: Website 90%
complete. Eta completion: 3 days.

I have no desire for this to escalate into a Django vs Zope/Plone
debate, so please no one turn it into one! I am sure that if we had
known more Zope/Plone or had more time to learn and figure out how to do
things in the "Plone way" we could have had more success with it.

Sincerely,

Will LaShell

>
> > Kevin
> Cheers,
> Andrej