[Zope-dev] Open Letter to zope-dev

Robert Rottermann robert@redcor.ch
Sat, 1 Dec 2001 19:23:18 +0100


Clark,
where is the problem??
Yes ZC ties to make money out of Zope. And I hope they are successful.
Don't you know that only those that have can give?
If ZC does not make the money to cover their cost how can they give us
Zope??

Open source is not only for fun. Also to make money!

Robert

----- Original Message -----
From: "Clark O'Brien" <clark_obrien@yahoo.com>
To: "Joachim Werner" <joe@iuveno-net.de>; "Andy Dawkins" <andyd@nipltd.com>;
<zope-dev@zope.org>
Sent: Saturday, December 01, 2001 6:47 PM
Subject: Re: [Zope-dev] Open Letter to zope-dev


>
> If anyone has seen how open source works, there is
> usually a strong core team - like the ZC folks- who
> provide direction to the project. There are also
> dozens if not hundreds of enthusiastic folks who are
> less involved but contribute features, patches, bug
> fixes, documentation ...
>
> Despite the fact that Zope is one of the most
> attractive open source project around today there is
> no
> mass appeal to the project. The ZC folks are now
> struggling with issues that should be handled by folks
> less knowledgeable.
>
> In my humble opinion if the open source process had
> been allowed to progress unfettered by corporate greed
> Zope would even now have a state of maturity
> that it is not likely to reach even in 10 years of
> development at the current rate.
>
>
>
> --- Joachim Werner <joe@iuveno-net.de> wrote:
> > Hi!
> >
> > > To be honest i would be happy for Zope 3 not to be
> > backwards
> > > compatible.  Tidy it up, delete the unless code,
> > dare i say it -
> > > refactor.  Yes so my products will break, well
> > half a days refactoring
> > > myself and i have a tidier more understandable
> > project anyway.
> >
> > YES, we need a new start. Building on what we have
> > now, of course, but doing
> > things better without having to think about all the
> > legacy stuff. When I see
> > long-time Zope users like Tom Schwaller (who is a
> > Linux legend in Germany)
> > move on to something new like Webware for Python,
> > that makes me wonder if
> > Zope is starting to loose some of its momentum.
> >
> > Zope is a great product. And it becomes easier to
> > sell it every day. But it
> > could be so much better and more easy to use with
> > just a little effort. Just
> > to mention a few points: What we really need is
> >
> > >>> A true vision of what Zope 3.0 is going to be
> > <<<
> >
> > Zope 2.x, together with the CMF, was "sold" bei
> > DC/ZC as a content
> > management product, which it isn't really. It is a
> > good start for building
> > one, but so many things that are mandatory for a CMS
> > are missing in the
> > out-of-the-box installation.
> >
> > Zope is a nearly perfect document storage, except
> > for its server
> > implementations for FTP (and partly also
> > HTTP/Web-DAV) will not be too
> > useful with major system load.
> >
> > Zope + Python are a dream team for web-based
> > applications.
> >
> > I think that a single product can't be good at all
> > these things. But I also
> > think that Zope could emerge into a suite of
> > near-perfect products for
> > web-based internet and extranet solutions.
> >
> > I think Zope should be split up into components as
> > soon as possible:
> >
> > - a database layer that includes alternatives to the
> > ZODB (using products
> > like DBObjects or the new stuff from 7x
> >
> > - a document management frontend to the database
> > layer that can be used to
> > manage all kinds of docs. Together with add-on
> > products like the document
> > library, Zope already does much of this, but it is
> > not optimized for high
> > loads yet, and products like Microsoft's Sharepoint
> > Server are really coming
> > close now. I wonder why people in the open source
> > community seem to ignore
> > what Microsoft is doing. I don't ask you to USE
> > their software, but we
> > should at least try to get inspired by the good
> > ideas they have (or have
> > collected from others who had them first). What we
> > need in that part of Zope
> > is high-performance real-time cataloging and
> > searching, interoperability
> > with FTP, WebDAV, maybe even SAMBA and NFS,
> > automatic document conversion
> > from Word/PDF to HTML etc.
> >
> > - an application development framework. Here, we
> > need some more work done
> > towards a real IDE (for Python and Zope). A lot of
> > work has been done
> > already by people like Riaan (who maintains Boa
> > Constructor). Most of DTML
> > (if not all) should go, and Python as the main
> > programming language for Zope
> > should be in the focus of documentation and training
> > efforts. I spent more
> > than a year with getting good at DMTL, just to find
> > out in the end that
> > ZClasses/DTML are really limiting and that
> > developing in Python is almost as
> > fast and much more effective. We need full
> > integration between ZODB-code and
> > filesystem code for that. We need ways of doing
> > ZClass-like things with real
> > Python code, and we need CVS-compatibility or
> > something better within Zope.
> > XML-RPC/SOAP/Webservices could be a strong part of
> > this.
> >
> > - a real, complete, out-of-the-box CMS, based on the
> > other three components.
> > I know that there are at least a dozen good CMS
> > BASED on Zope, but this
> > seems to me to be a waste of resources. We only need
> > one good system that
> > can be maintained by many people. It needs a
> > high-level plug-in
> > architecture, so that people can contribute modules
> > that can interact with
> > each other. Currently, most Zope products other than
> > the database adapters
> > and user folder implementations are standalone
> > products. Let's take
> > Squishdot as an example. It is cool, yes. But it is
> > not compatible with
> > anything but itself. The CMF was a first try to
> > build a standard Zope CMS,
> > but it still far from being a good solution. It
> > solves problems you don't
> > have and takes away solutions plain Zope can offer,
> > like being able to build
> > hierarchically structured sites (as it has a flat
> > member paradigm). What we
> > need for the CMS level is:
> >
> >   - easy-to-use (partly WYSIWYG) editor tools
> >
> >   - a chroming/skinning mechanism that is used by
> > all components
> >
> >   - workflow
> >
> >   - ...
> >
> > - on top of all that, I see really sophisticated
> > systems like (real) portal
> > toolkits or groupware software.
> >
> > - one of the remaining questions is: Does Zope need
> > a stronger XML story?
> >
> > I think that Zope Corporation doesn't want to
> > maintain all of that, and that
> > they actually wouldn't be able to do so. So it is
> > really important to make
> > sure what will be part of Zope 3 and what not. And
> > who is going to be in
> > charge of what.
> >
> > Wow, this has gotten rather lengthy (and still
> > incomplete). But maybe I'll
> > get some feedback on this ...
> >
> > Joachim
> >
> >
> > _______________________________________________
> > Zope-Dev maillist  -  Zope-Dev@zope.org
> > http://lists.zope.org/mailman/listinfo/zope-dev
> > **  No cross posts or HTML encoding!  **
> > (Related lists -
> >
> > http://lists.zope.org/mailman/listinfo/zope-announce
> >  http://lists.zope.org/mailman/listinfo/zope )
>
>
> __________________________________________________
> Do You Yahoo!?
> Buy the perfect holiday gifts at Yahoo! Shopping.
> http://shopping.yahoo.com
>
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists -
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope )
>