Skip to main content

Zope Foundation accepted in the Summer of Code

The Zope Foundation is happy to announce it was accepted in Google's Summer of Code program in 2008!

Students interested in a Zope (or Grok) related project, please sign up to our summer of code mailing list and introduce yourself and the projects you're interested in. We only have a few days to hash them out before Google starts accepting student applications:

http://mail.zope.org/mailman/listinfo/gsoc

Mentors, I hope you all already on that mailing list.

Grokkerdam sprint!

It was planned for a long time, but at last we are going to hold a Grok sprint in the Netherlands. To be more precise, in Rotterdam. Rotterdam will be "Grokkerdam" for the duration of the sprint!

Where: Rotterdam, the Netherlands

When: 30 april - 5 may 2008

Who: hopefully, you!

A number of experienced Grokkers will be attending. People of all experience levels are welcome, as long as you're interested in helping us improve Grok. Tasks could be anything Grok related. Some possible topics:

  • improving the Grok introspector UI
  • relational database integration for Grok
  • Polishing Grok's KSS integration
  • Preparing for Grok's 1.0 release
  • Documentation

... or whatever you want to work on!

Sign up for the sprint on our wiki page, here:

http://wiki.zope.org/grok/GrokkerdamSprint

If you have any comments or questions, please mail me!

Our generous host for this sprint is The Health Agency (http://www.thehealthagency.com/), a company that uses Grok for its own web applications here in Rotterdam.

Note: this sprint is back-to-back with the Plone 3 sprint in Paris (25-27 april), hosted by Ingeniweb. Rotterdam is 3 hours away from Paris by train. You could participate in both sprints and enjoy a few days of Paris (or Rotterdam) in between.

Please don't break library compatibility in Python 3

Update: Guido appears to share my opinion on this.

I've heard murmurs from a bunch of projects over time concerning their transition plans to Python 3.0. These transition plans are naturally vague at this stage. There's one theme I've heard a few times in these murmurs that worries me enough to speak out on it.

People sometimes reason that since Python 3 is going to break people's code anyway, now is a good time to make backwards compatible changes in their libraries too. The reasoning is understandable: people are facing a big change anyway with Python 3, so why break backwards compatibility for them once then, and then another time for your library? Better do it at the same time and make people suffer only once.

There are other reasons that drive projects to break backwards compatibility at this point. As far as I understand, the Python C API will change with Python 3, so that means projects that bind to C libraries need to be adjusted anyway. This might tempt people to make larger scale changes.

I just heard that the current WSGI spec isn't entirely compatible with Python 3. If that is so, and a new version of the spec is needed, then that might give some frameworks that use WSGI an opportunity to clean up some things and break backwards compatibility.

While very understandable, the negative consequence of all this is that the Python 2 to 3 conversion script strategy stops working for code that depends on these libraries and frameworks. This official transition strategy aims to make the transition between Python 2 and Python 3 easier by offering a script that convert your Python 2 code to Python 3 code automatically.

If lots of important libraries and frameworks however also break backwards compatibility in their Python 3 versions, this means that any converted code that depends on them has no chance of working. Instead the developer would need to track all the API changes and make adjustments there too before the code would work again: a much harder task.

So my advice to library and framework maintainers would be: please do not use this opportunity to break backwards compatibility in your library or framework too. I'd like to ask you to resist this temptation. The language changes already make this a major transition for everybody, and you'd make it that much harder by taking away people's ability to automatically convert their Python codebases.

Summer of Code for Zope

Last year the Zope Foundation participated in the Google Summer of Code. We had four students, all of whom are still active in the Zope community, so we can declare this a success. We hope to participate in 2008 again, and we're looking for mentors and project ideas.

We need to show a list of mentors to Google soon, and the bigger that list the better, so if you do want to mentor, please sign up here:

http://wiki.zope.org/gsoc/SummerOfCode2008

Being a mentor can be very rewarding, but it does require regular contact with your student and with the mentor coordinator (myself).

We really hope to be able to participate in the Google Summer of Code again this year! Project ideas are very welcome. We're looking for ideas surrounding Zope 2, Zope 3 and the ZODB. I've already supplied a lot of ideas that surround Grok, but more ideas of course wouldn't hurt.

By the way, Plone is also participating (they're an old hat at this by now), so if your project is more Plone related, see here.

Going to FOSDEM

This weekend I'm off to FOSDEM, a large free software/open source event in Brussels. For years I intended to go but for years I didn't make it. But this weekend I'll be there, taking the train later today!

This year there unfortunately seem to be precious few Python (or Zope, or Plone) related events at FOSDEM. Lots of other languages and web frameworks are there, so what's wrong with us? If this FOSDEM is a success, perhaps next year I can help organize some of those.

If you're going to be there and you'd like to say "Hi", please drop me an email (faassen at startifact.com) and we can see whether we can arrange to meet!

Python 3.0 is incompatible with Python 2.0

Jesse Noller wrote:

I hate slashdot: Python 3000 is incompatible?!!!

and then says:

A sensationalist title, summary and normal slashdot commenters: "Python 3.0 To Be Backwards Incompatible"

I don't see how the title is sensationalist. Python 3.0 is backwards incompatible with Python 2.0. Conversion scripts are supplied, but that fundamental reality stands. The summary on Slashdot is this:

Organizations using Python will be affected in a major way by changes in store for the language over the course of the next twelve months, Linux.conf.au attendees were told this morning. The Python development community is working towards a new, backwards-incompatible version of the language, version 3.0, which is slated for release in early 2009. Anthony Baxter, the release manager for Python and a senior software engineer at Google Australia, said "We are going to break pretty much all the code. Pretty much every program will need changes." Baxter also added another tidbit for attendees, saying that Python accounts for around 15 percent of Google's code base."

I don't see anything sensationalist in this either. It's true: organizations and communities using Python are going to be impacted in a major way by the release of Python 3.0, and the reason they are going to be impacted is the non-backwards incompatibility. There are significant consequences for organizations that need to deal with this transition - for the organizations that go ahead and make it, and also for the organizations that wait and see and continue to use the Python 2.x version.

I haven't read any of the Slashdot comments. I'm sure some of them are very wrong, and very annoying; that's normal. It's just that I object to spreading the idea that this message is sensationalist or somehow wrong. It's not. It's the reality that one way or another the Python community will have to deal with. Objecting to an expression of this reality spreads the wrong message.

Recognizing that Python 3.0 is backwards incompatible makes us aware that we are heading for something we will have to deal with one way or another. It's a useful wakeup call for people who might not be aware of this.

The language developers are working on a migration script and are adjusting the Python 2.x line of Python so that we can prepare our code bases. By all means, spread that news too in addition to the backwards incompatibility news. But don't object if news sources forgo such subtleties in spreading the main message to take home about Python 3.0: without special action on your part, your code will break when you try to run it with the new interpreter. Adopting Python 3.0 as a community will mean an awful lot of code to transition. It'll be a process of years, and it won't be easy.

(as an aside: I think I wrote a reasonable posting about Python 3.0 just now. Of course that's what I thought when I posted about this last time, and then I had people land on my head like a ton of bricks. It left a very unpleasant taste in my mouth. Let's hope this time will be better. I think having an open discourse about this is important.)

Allowing Zope 2 applications to contain Zope 3 content

Five, the system to use Zope 3 within Zope 2, is a pain sometimes. Five is full of hacks to ensure backwards compatibility with Zope 2. This stops developers from using full-fledged Zope 3 strategies in places.

How could we make this pain go away?

The main reason these hacks in Five are necessary is acquisition. Acquisition in turn is necessary to support the construction of URLs, and most importantly, to look up security information. There has been long-standing work on a branch of Zope 2 to make acquisition also inspect the __parent__ attribute. This should help make some of the hacks go away.

Five so far is about everything Zope 3 except content objects. You can do just about anything Zope 3 can with Zope 2, except store plain, simple, Zope 3 content objects. I think if we added the ability to store Zope 3 content objects to Zope 2, we could take a leap forward in merging the two platforms. Suddenly just about any Zope 3 application could be hosted in Zope 2. Existing Zope 2 applications (such as Plone) could be extended with pure Zope 3 code. You'd be able to use things like Grok more or less out of the box, say. You can start thinking about gradual content migrations over multiple releases of your applications towards a pure Zope 3 platform.

I'll sketch out what I think would need to be done to make this possible. It's likely I'm missing some complexities, and perhaps I overestimate some other complexities. My hope is that some of the readers of this post will be stimulated into doing some experiments...

What would be required to let Zope 2 host Zope 3 content objects? Let's first catalog what we already have (so no work is needed):

  • code: we're shipping the Zope 3 codebase with Zope 2, so that's all already there.
  • zodb: Zope 3 and Zope 2 content objects can share the same ZODB.

Now let's look at what's almost there:

  • no more acquisition: we can look up Zope 2's security infrastructure using __parent__ references, without acquisition (the branch I mentioned).

What needs to be done?

  • storage: we need to extend Zope's folder so you can store a Zope 3 content object in it without any harm. Mixing it with Zope 2 objects would be nicest, but if that isn't available, two separate pools of objects would do for now.
  • publishing: we need to make sure that as soon as someone traverses to a Zope 3 object, the Zope 3 publisher kicks in. We'd leave the Zope 2 publisher completely behind. Initializing the Zope 3 publisher into the right state is going to be tricky. It's likely we need to amend Zope 2's request object so the Zope 3 publisher has everything it needs.
  • security: we likely need a custom Zope 3 publisher so it can do view-level security checks, much like Grok does. We probably need some mix of Zope 2 security information and Zope 3 security information to determine whether someone has access. That's going to require some thought. Trying to make the whole Zope 3 security proxy machinery work would be more trouble, so I'd recommend skipping that step for now. I expect the combining of security systems would be the trickiest parts. Perhaps there are good ways to sidestep this issue.
  • directives: Five works in part by reimplementing some of Zope 3's directives to make them work for Zope 2. Unfortunately the original version of the directives would need to be used to support pure Zope 3 content. Possibly both sets of directives can be supported by migrating Five's registrations to a new namespace. It's going to break all existing Five-based ZCML. That ZCML should however be easily fixable by using the Five-specific namespace (http://namespaces.zope.org/browser_five, say) where needed. This namespace would have all registrations for http://namespaces.zope.org/browser, with special Five versions for those directives that need it.

Again, I hope these thoughts will set some people thinking...

On Revolution and Evolution

Malthe started an interesting discussion on the possibility to rewrite Plone from scratch. I have some thoughts on the topic of rewrites, evolution and revolution. Here are some of my scattered observations.

While at Infrae, I led the development of Silva for many years. I also initiated the Five project. The creation of Five was driven by two concerns:

  • Silva needed the customization and flexibility potential of Zope 3 technology.
  • I realized that a complete rewrite of Silva based on Zope 3 was going to be unlikely.

I participated early on and enthusiastically in the development of Zope 3. I'm still a big fan of the project. At the time it was generally assumed that this was the next-generation platform that in time would replace Zope 2. The stories about how we were going to port Zope 2 code over were always vague. Luckily Silva can almost completely export its state as XML. I therefore assumed for quite a while that soon enough we'd end up rewriting Silva on the Zope 3 platform, and even without a way to port any code, we'd at least be able to carry over the content.

As time progressed, it became clearer and clearer that the rewrite of Silva was not going to be happen. Of course not! Would any customer would pay for it? What would you tell a customer? Give us lots of money and we'll give you a new version with initially less features and more bugs? Infrae has wonderful, quite enlightened customers who care about Silva, but telling them that was unlikely to solicit very positive responses, and for good reason!

Now Plone has the benefit of having a much larger community than Silva does, and it's full of all kinds of energy. But telling community members that you are going to rewrite Plone is going to be almost as hard a sell, and will give rise to inevitable confusion.

Given the experience we had with the confusion surrounding Zope 3, I wouldn't announce you're rewriting Plone. Don't call it Plone, at least. You might get away with it if you are the sole dictator of a project. Apple could more or less do it with Macs, transitioning to Mac OS X. Microsoft could do it with Windows 95 and Windows NT. But even these use the same brand name and name the individual things differently - note how they use names that are not much like a version number.

There is no Plone dictator. A rewrite project named Plone will certainly give rise to confusion in the community. You'll get questions like "sould I use Plone X or Plone Y?", ages before Plone Y is even ready. "Hey, why can't I run PloneAmazingProduct on top of Plone Y?"

It's easy to avoid such confusion. If you want to create a new thing, give the thing a new identity. I even gave Five an identity by itself, and it wasn't really a new thing at all - it's whole idea was to combine existing things! I also learned the best way to make a new thing is to base it off some existing thing: Zope 2 and Zope 3 for Five. libxml2 and elementtree for lxml. Zope 3 for Grok.

If you want to get a lift from Plone's community, by all means try. Closely ally it with Plone somehow. Make it easy for the two systems to work together, perhaps. That's the relationship we're aiming for between Grok and Zope 3. But naming it the same is a bad idea. We have namespaces in code for a reason; without namespaces confusion and bugs are more likely. I think the same applies to projects.

It's true that reimplementing software is very attractive to software developers (it is to me). It's also true it's frequently not a good idea. I disagree with the position that rewrites from scratch are always a bad idea. I do agree that any idea to rewrite should be scrutinized aggressively. It's good that it's happening. This needs to be done, as rewrites have huge costs. Even backwards incompatible changes have a severe cost, especially where they are done low-down in the stack. Rewrites are like backwards incompatible changes with a lot more confusion to the community. If one would change the name for the new effort, is it a good idea for Plone? I think it could lead to useful things, but it could as well lead to nowhere. I don't know.

When I was pushing Five, I used the phrase "evolution, not revolution". After a while I started hearing this back from others, so the meme was spreading. I still think this is a good idea for the position Plone is in - the same position Silva is in.

So was the Zope 3 project, a near-complete rewrite, a bad idea? It's hard to say. I certainly like much about how it's turned out. It's one of the most advanced pieces of web technology out there. There's so much mostly untapped potential in it. The Grok project is now happily in the process of tapping it. So is the Zope 2 project! I believe we can go very, very, far with Zope 3 technologies. I think we'll surprise a few people with that...

On the other hand, Zope 3 was incredibly disruptive to our community. False impressions as strong as promises were given, and much of what was generally expected never became a reality. We needed to do a lot of work to reforge the community in the aftermath of these disruptions.

Then again, Zope 3 is also serving as a unifying force to our communities. Silva, Plone, and Zope 2 itself, have a more or less clear direction: toward the adoption of Zope 3 technologies. This saved the Zope community from breaking up into separate splinter groups. I think this is a great thing. Could a project more closely allied to Zope 2, a less disruptive project, reached the same thing? I don't know. I do think that by being independent from Zope 2, Zope 3 could make braver choices and helped us set a clear course.

So Zope 3 was a curse to our community, and it's a blessing. It hurt us and reinvigorated us.

Where will the evolution end up? Can Plone or Silva ever evolve to a purer Zope 3 base, using Five? That, after all, was also the idea behind Five. Can we slowly reengineer our applications so in the end they run on a pure Zope 3 core? I don't know. It remains to be seen. Certainly it appears quite distant in the future right now. Certainly also people are making great strides forward with every release. No matter whether we'll reach the end goal soon, later, or perhaps never: I am convinced that the direction we're going in, as a unified community, is a good one overall.

Paradoxically, these days, I'm more in a revolution mood. I'm pretty free in what I can do now. I feel I paid my dues to Zope 2. So I'm aiming to change the world with Grok. Grok is purely Zope 3 based. It's Pythonic. It lets go of the past. No need to worry about Zope 2 cruft anywhere. A revolution!

But note that Grok is pretty conservative in its revolutionary plans - Grok is Zope 3 in a different coat. Grok is not a rewrite but based on Zope 3 technology in development since 2001. It's revolutionary for me, as instead of combining two existing things I'm just building on one! It's hopefully revolutionary to others as we're putting a lot of power into the hands of many.

We will end up going full circle. People keep asking me about supporting Grok technology in Zope 2. I think this will eventually happen; it's not hard, and so many people are asking about it one day someone will actually get up and do the work. Unless someone pays me a lot of money, I'm not going to do it myself. I'll support it though! Grok needs Zope 2. Grok needs Plone. We can count on many of our best contributors to come from those communities.

Perhaps the Zope community evolves by punctuated equilibrium. Long periods of seeming stability with intermittent fast spurts of new developments based on evolutionary innovations that took place almost in the hidden. Or perhaps that is just another metaphor that doesn't quite fit.

We are about 10 years into a fascinating experiment. Can Zope continue evolve forward? Can we continue to be at the forefront of development? Will we continue to innovate? Can we reinvent ourselves while keeping our community whole? (and what a community! What other Python web framework has two foundations and a business partner network?) Can Zope continue to be relevant in the future?

Yes, I believe it can, and very much so.

Snowsprint report

This year, like last year, will be a year of Grok for me. Grok has given me real hope that Zope technologies can compete, and compete well, with other Python-based web frameworks. In the Zope community, as well as outside it, we are well aware of Zope's flaws, both technology and community-wise. We sometimes think too little about Zope's assets, which are huge. Zope 3 is great technology, years ahead of the competition in the pluggability department, and Zope's community is well established. One of those things in the Zope community is the yearly Snow Sprint. This year was the first time I attended.

The Snow Sprint is organized by Lovely systems. Lovely systems is an interesting company with very strong experience in building scalable Zope 3 applications. The Snow Sprint is not just about Zope 3 though: like every year, there were a lot of assorted Zope and Plone developers present. Much programming, learning, discussing, discovering and partying took place. We were 2000 meters high up in Austria, in the middle of nowhere surrounded by gorgeous snow-covered mountains. This was a bit problematic when I developed an acute toothache in the weekend after I arrived. Ouch! Ouch! Luckily I was able to descend the mountain on monday and an Austrian dentist fixed me up.

My personal mission at the Snow Sprint was to work on Grok, and hopefully get some other people to get involved as well. Luckily it turned out quite a few people were interested - my talk on Grok was well-attended and many people explored Grok. A bunch of sprinters started the development of a new CMS system with some conceptual rethinks called vudo. It's based on, among other things, Grok. What will happen with vudo remains to be seen, but at the very least it was an interesting topic to discuss and a good learning experience.

I saw many familiar people again at the sprint, and also met many new people. In particular I met a few nice people from the Open Plans project. Whit Morris I had in fact already met at a previous sprint in Austria (in a castle). New Open Plans people I met were Robert Marianski, Ethan Jucovy and Jeff Hammel. We had quite a bit of fun hanging out, and we also worked on Grok-related tasks. Jeff focused on trying to build a KSS driven commenting application in Grok. Meanwhile myself, Robert and Ethan started work on z3c.autoinclude.

z3c.autoinclude is a package that should make it easier to reuse packages with Grok. I had noticed that reusing a Zope 3 or Grok-based package takes mentioning this package three or four times:

  • you start importing from it in your Python code
  • you list it in your setup.py's install_requires
  • you need to include its ZCML using a ZCML include directive
  • you probably need to pin down its version in buildout.cfg

This a clear DRY violation; we're repeating ourselves in four places! Reducing this amount is not easy, but we could at least tackle the ZCML issue. If a package is listed in setup.py has a configure.zcml or a meta.zcml, we should be able to figure out to include this automatically from the information in setup.py.

Making this work was a challenge in test-driven development. We used setuptools APIs and zc.buildout's easy_install module to set up packages in a doctest. Robert and Ethan hadn't done very much test-first programming yet, and several times I had to apologize for it not being that complicated normally. Luckily we stimulated each other in not giving up on writing the tests, and in the end we benefited from them. We were able to refactor working bug ugly code towards a much cleaner API in a very short time; something we wouldn't have dared without tests.

So now, if z3c.autoinclude is installed and you use the autoinclude directive in your package, you don't have to remember including ZCML manually anymore if you already list those packages as setup.py dependencies. I hope we will roll this functionality into Grok soon.

Monday, Tim Terlegård arrived on the scene. I know Tim from grok-dev but hadn't seen him at the sprint yet. He was immediately eager to go ahead and work on things. Tim had the great idea to finish up Grok viewlet support, something that Kevin Smith had worked on in the past but never got reviewed and finished. Unfortunately on monday I was recovering from my dentistry and toothache induced lack of sleep, so it took me to tuesday to really get involved.

Viewlets are a system in Zope 3 that allows the very flexible inclusion of page elements into pages based on:

  • what the page is viewing (its context)
  • the view itself
  • the skin that view may be in
  • the particular collection of viewlets we want to display (viewlet manager)

I always had trouble getting the concept of viewlets to stick in my mind, not helped by the copious amounts of ZCML configuration that they required, but I think it finally did at the last sprint.

Tim, Robert and myself started freshening up the viewlet branch and adding tests. We also thought of ways to make configuring viewlets as easy as possible. No more ZCML, just Python, to configure viewlets!

It took the rest of the sprint to clean things up and bring the implementation on a solid footing. I believe the viewlet work is now close to ready for merging and I can already see many uses for it in my own code bases.

Along the way we refactored Grok's configuration code a bit, and I got a few more ideas on how to make progress in this area and make Grok's configuration system more declarative, helped by a discussion that started on grok-dev to make sure that Grok contains as little magic as possible.

Another notable Grok-related event happened last week, though independently of the sprint. We opened up the new grok.zope.org! The new grok website is based on Plone 3. The goal was to refresh the layout, which as you can see has succeeded, and to make it easier for people to contribute documentation on Grok. Even before the site officially opened this flow of contribution started to happen; Grok's documentation section is already filled with many useful documents. I hope many more documents will be added in the future!

A lot of people worked hard to make the new grok.zope.org a reality. Thank you all! In particular I'd like to thank Kevin Teague who pushed and pushed again to get the website to this point.

At the Dawn of the Fourth Age of Zope

Some years ago, in 2004, I came up with the following quote to promote the Five project, which was the first step towards the inclusion of Zope 3 technologies in Zope 2. Zope 3 technologies are now heavily used in Zope 2 projects, and Zope 3 code has been part of Zope 2 for a while now, but back then we were just at the start of this process. The quote itself was creatively adapted from the first season intro of Babylon 5, a 90s scifi TV show:

"It was the dawn of the third age of Zope. The Five project was a dream given form. Its goal: to use Zope 3 technologies in Zope 2.x by creating a Zope 2 product where Zope 3 and Zope 2 could work out their differences peacefully."

I realized today we are now at the dawn of a new age of Zope: the fourth age.

What are the ages of Zope? A community needs its mythology, its history and storytelling, so let's tell them to each other and everybody else.

Zope's First Age: The Age of Through-the-web Development. (1998-2001)

In 1998, Digital Creations (now Zope Corporation) open sourced their Principia web application platform, renaming it to Zope. This open sourcing was a rather unprecedented move for the times and drew much attention from the press. The web was hot, and the Zope community grew quickly.

It was an age of discovery and exploration. Much of Zope development was done using the Zope Management Interface (ZMI) and through the web. People would write DTML templates, ZSQL expressions, later ZPT templates and Python Scripts in a web browser to put together web applications. You could also install so called "Products" to extend Zope with new features, but how exactly to do this remained a mystery to most members of the community.

Zope's Second Age: The Age of Product Development (2001-2004)

Slowly the Zope community started to figure out how to do Product development. A Zope "Product" is basically a special kind of Python package you can install in a special place to have Zope pick it up. A Product can register new content types with Zope. These could be used to extend the ZMI development platform's abilities. This age saw the rise of the CMF, the Content Management Framework, which worked this way.

More and more also we saw the creation of whole new applications in Product form. The major CMS projects of Zope, such as Plone and Silva, started somewhere in this age.

The second age also saw the start of the Zope 3 project, an undertaking to rewrite the Zope platform taking into account the lessons learned from Zope 2. At this time we did not yet know what shape Zope 3 would eventually take. "Zope 3" shows we were still expecting a pattern of replacement: Zope 3 would be a successor that would replace our Zope 2, and we'd somehow move our code over to the new platform. It didn't happen that way.

The second age was an age of building. It was in many ways an age of diversification and parting of the ways. Different projects building on Zope would move in quite different directions and the community started breaking apart into different sub-communities with their related but slightly different ways of doing things.

Zope's Third Age: The Age of Zope 3 Technologies. (2004-2007)

The Zope 3 platform developed and matured, and the first applications started to be developed on this platform. It was realized that it would not be a clean successor to Zope 2. Zope 2 was there to stay. Instead, the community started integrating the Zope 3 technologies within Zope 2 itself, starting with the Five project.

This was an age of a coming together of ways. The different sub-communities started sharing more again. The main way this was done was through the increased use of Zope 3 technology: the Plone, Silva projects, and Zope 2 and CMF themselves, started integrating Zope 3 technologies heavily into their codebases.

Zope's Fourth Age: the Age of the Rebirth of Zope (2007-)

During the third age, outside the Zope world, other web technologies had started to become more and more popular. Projects like Ruby on Rails, Django, TurboGears and Pylons started gathering significant mindshare.

Zope would have to adapt, reinvent itself, or be consigned to irrelevance. This process of adaptation had been long underway with the Zope 3 project. The previous ages have shown that the Zope community has a magnificent ability to adapt itself.

It was now time to apply the lessons from the competition: start to actively reach out to the outside world. Communicate better. Accomplish the goal we set out to reach long ago with Zope 3: to work with the broader Python community instead of being isolated in our own community.

This is the age we find ourselves in today. It is the age of the eggification of Zope 3, and slowly also Zope 2: the splitting up of Zope technologies into more independently reusable and evolvable packages, using common Python technologies such as setuptools and the Python package index. It is the age of WSGI, allowing Zope to be integrated with other Python web technologies more easily.

The Grok project set out to make Zope 3 technologies more easy to use for beginners and experts alike. The Repoze project set out to bring Zope 2 kicking and screaming into the modern egg and WSGI age. We are taking a fresh new look at ourselves.

We are just at the dawn of this new fourth age. We still need to drastically improve both the quality and quantity of our communication with the rest of the world. We need to reach out to the world and say "Zope is back. It is new again, reforged, but forged within it are hard-earned lessons of the past. Please come and join us."

I hope the effort of the fourth age will be successful, and that many newcomers will join the Zope community in the next years. Who knows what the fifth age will bring us? In a large part, it will be up to the newcomers.