Is Zope…

• an application?
• a platform?
• a set of libraries?

Different audiences

• Python developers
• Content managers
• Site managers
• Casual developers

• Zope2 identity
  Mixed

• application (ZMI, “active” content)
• platform (Products
• not library (dependencies)

Audience mixed

• Content managers
• “Scripters”
• Application developers

Zope 3 identity

• Audience: experienced developers
• Eventually evolve Z3 to replace Z2

• “forward-compatibility” goal

• Zope 2, like Marxist state, “withers away”

Zope3 is now “old” tech

• Initial ZC sprint, November 2001
• Initial community sprint, January 2002
• Zope3X released Nov. 2004
• Five 1.0, ZopeX3 integrated into Zope 2.8, Apr. 2005

Two visions

• Jim’s list post, Feb. 2006
• Vision 1: “gradualism”
• Vision 2: “Zope 5″

• App server configured to support either Z2 or Z3-style apps
• “Zope3 explodes”

Competing alternatives

• Ruby on Rails
• Other Python frameworks

• Django
• TurboGears
• Pylons
• Twisted
• WSGI
• Paste

Lessons from Competition

• Lower barriers to entry – RoR has attracted frustrated Java developers
• Interoperability matters
• Slick marketing pays off

Disruptive Technologies

• Component architecture
• Egg-based distribution
• Buildout-driven deployment
• Grok

Component architecture

• Replaceable components

• Good for reuse of software
• Problematic for identity

• Configuration
• Risk: brand dilution / displacement – fuzzy about what Zope really is

Egg-Based Distribution

• Eggs as analogs to Java’s .jar files or Ruby .gem files
• Explicit dependency management
• Entry points
• Easy installation – easy_install (similar to Perl’s CPAN)
• Controlled environments

• workingenv
• virtual_python

• Risk: increased release management burden
• Risk: complex dependency relationships
• Need a mechanism for specifying “known-good” assemblies / configurations

Buildout-driven Deployment

• Scripted creation of an application instance / stack

• Specific versions / branches for components
• Repeatable, cross-platform

• Technology agnostic

• eggs
• checkouts
• tarball + CMMI

Grok

• Tackles “barrier to entry” problem for Zope3 application development
• Avoids ZMI
• Applications can be served outside Zope

• See Phillip’s Nudge talk

Decision, decisions, decisions!

• Monty asks: (see the Monty Hall problem game theory)

• Do you want what’s in the Box, or what’s behind the Curtain?
• What about what’s behind Door #3

• Let’s make a deal!

Behind door #3

• Drop the “application” part of the Zope brand

• Plone largely owns it

• Emphasize “platform” role for “Zope”

• Provide “known good” assembly of packaged components

• “Library” is main role for current Zope 3 code

• Satellite projects are where the real work gets

• “Pluggable app” stays Zope2′s role

• support Plone, Silva, etc.

Why trade?

• Improved branding story
• Focused audiences
• Improved intake models for community

• Grok for developers
• Paste / WSGI as evangelism
• Content managers / scripts not swamped with details

Prognostications

• In two years, Zope3 will no longer be installable as an application
• Zope2 / Plone will still be the dominant “application”, in terms of production deployments
• WSGI / Paste will bring Z3 components much wider use outside Zope

Technorati Tags: conference, dzug, natea, plone, sprint, zope, zope3

ok, there’s still one failing test regarding ZClasses, but the same test is failing on the regular 2.10 branch. the only difference is, that there it’s only failing when run seperately (and passing when run together with all other tests), and with zodb 3.8 it’s failing in any case… :) however, since ZClasses aren’t used in plone at all this issue is not too important at the moment.

apart from the good news is that all tests for “CMFPlone” continue to pass with the new flavour of zope 2.10 (and the ones for “plone” break in the same way ;)). on the other hand that’s not really so surprising, since plone doesn’t make use of the new blob support after all. at least not yet. so tomorrow’s more interesting question will be what happens when atcontenttypes’ file starts using it…

ps: oh, and another thing worth mentioning is that andreas jung did the same thing for zope2 trunk (think “2.11″), so now we’ve got working branches of zope 2.9, 2.10 and 2.11 with blob support

One of the problems that is holding back the adoption of Plone, is that it is very difficult to evaluate Plone with add-on products. Of course, you can easily install Plone using the point-n-click installers for Windows and MacOSX, but these just give you the stock Plone site with only the default functionality. While Plone does a lot out-of-the-box
Where Plone really shines is in the rich library of 3rd party add-on products. But if you aren’t familiar with Zope/Plone, it can be problematic to know which products to try out (i.e. which blog tool is the best?) and once you’ve downloaded the product, where do I put it and how to I install and configure it?

Plone needs a better out-of-the-box experience targeted at particular audiences. We can learn from Ubuntu which has a Edubuntu distribution targeted at young students in schools. The Drupal CMS also has distribution profiles to make it easy to set up a Drupal site with a pre-configured profile. DrupalEd is an example of a Drupal distribution whose purpose is to create informal learning environments.

At the PIKtipi sprint, we are using the buildout tool created by Jim Fulton of Zope Corp, and the sample Plone 2.5 ploneout script created by Lennart Regebro to create a Plone4Artists buildout script that will install Plone + Plone4Artists add-on products with two commands.

The purpose of doing this is to make it easier for:

1. Developers to get a development environment with Plone + Plone4Artists products already installed and configured.
2. Evaluators to get a testing environment with minimal effort. They don’t need to know anything about Zope/Plone in order to download the Plone4Artists package and try it out.
3. Integrators to see how to create a distribution for their own project or customer deployment.

There are several parts to setting this up:

1. Create a Plone4Artists buildout [DONE] – checkout the buildout
2. Make a buildout recipe to create a Plone instance and apply a GenericSetup profile [IN PROGRESS]
3. Create a GenericSetup profile that installs the products and configures the site [IN PROGRESS]
4. Use gsxml to export sample content and load this content during the GenericSetup import step [WAITING ON STEPHAN]
5. Create an executable AppleScript to provide a point-n-click interface to installing Plone4Artists on MacOSX. The AppleScript will execute the buildout commands in the background and provide feedback to the user through a nice Mac GUI. This is for those users who are intimidated by the terminal command line. [TIME PERMITTING]

More updates will be posted here throughout the next few days to let you know our progress!

Technorati Tags: natea, plone, plone4artists, sprint

Well, the best kind of bugs are those that you don’t even produce in the first place, of course. Meaning that if a new developer has some ‘best practices’ to guide him, he or she can spend more time debugging the business logic of his or her application and less time banging his or her head against obscure implementation details of Zope 2, Zope 3, Archetypes, CMF, Five and uh… oh, yeah… Plone.

The problem is, though, that the collective wisdom of the community on how to deal with many of these issues isn’t really documented much. This is especially true for the new ‘bleeding edge’ technologies such as Zope 3 in general, Five and formlib. And who can really claim to know exactly what kind of many useful gems are hidden in the numerous z3 related repositiories (z3c, lovely, zc et. al.). For Zope 3 there’s of course the ‘new’ zope3-wiki that was created specifically to address the issue of lack of centralized documentation on zope 3, but I haven’t found it very helpful or accessible so far … however, mainly due to the fact, that it’s (of course) entirely Plone agnostic, so one of the difficult bits is to figure out, which of the information is even applicable.

This sprint is a wonderful opportunity to add some documentation to address some of the basics for Plone (Product) Developers, especially, since many of the authors of the aforementioned technologies are present at the sprint. We’re going to start with a how-to on using Viewlets … let’s see how that goes…

Who’s here:

• Martin – grok
• Peter
• Christof
• Phillip – grok
• Nate, pet project – Plone4Artists, multimedia (blob support, buildout, zope 3 in plone using five)
• David – environmental and science organizations to collaborate and share information
• Florian – working with Plone Solutions. Viewlets and CacheFu
• Katja
• Pelle – from Copenhagen
• Andi – from Berlin, sprint organizer
• Hanno – Google Summer of Code student, OpenOffice transforms into Plone
• Daniel – make plone faster!
• Christian – from Freiburg, Germany
• Armen – database applications
• Andrew – from Melbourne, Australia – engagemedia.org
• Tom – from Berlin, sprint organizer, Plone 3 and viewlets, Caching, buildout

Technorati Tags: natea, plone, plone4artists, sprint, zope

Being the first sprint we’ve organized, we were quite naturally a bit apprehensive, as to whether everything would work out. But so far everything worked out just fine. The network is up and running, the tents have been set up and the tap beer installation is fully functional – let the sprint begin!

Technorati Tags: tomster