This roadmap outlines the direction of Zope development in the near to mid term. Note that some of the most important things that we want to accomplish have nothing to do with writing code, so the roadmap is structured as a set of high-level goals (which are the really important part) that will guide work on the platform going forward. The idea is that the projects going on in DevHome will work in support of these high level goals.

High level goals

• Opening the Zope development process

There is a lot of untapped potential in the Zope community. There are many developers out there who are able and willing to actively contribute to core development, but we at DC have not yet put in place the needed technical and process infrastructure required to allow the community to contribute effectively.

There are many aspects to this, and they will not be solved all at once. We are now poised to make progress in this area, and I want to take an iterative approach to opening the process. The first steps will involve:

• establishing a Zope development-centric area on Zope.org to make the above information available (the moral equivalent of what mozilla.org does for mozilla) for now
• beginning to use that area to plan, coordinate and execute further zope development (roadmap, projects, status reports, design, planning, etc.)
• identifying our process for allowing checkin priveleges and an initial group who should be given those privileges
• identify and capture the absolute key elements of process that we will follow (config mgmt, how projects work, who owns what, who should you clear checkins with, etc.)
• establishing some good process examples in the developer area
• getting cvs infrastructure set up (cvs armegeddon)

This will give us the core things needed for the community to begin expressing its potential. Over time this core will certainly evolve; the pains we'll have with experience will help us set priorities for improving the fishbowl environment. I expect to work closely with Ethan to integrate this intelligently with our overall Web presence.

• Define Zope as a platform and its audience

  We have heard very clearly lately that complexity is a problem in Zope, and that it is not just a documentation problem. Zope does a lot of things, and we are at a point where we will have to be very careful about what Zope is and what it isn't. This is particularly true once we truly work in a fishbowl. More people will mean more opinions. If there is not a general agreement on what Zope is as a platform and what does and doesn't belong in that core a lot of energy will be wasted arguing this point over every proposal.

  Drawing distinct lines around the platform and defining the audience of that platform will be key to making the right strategic decisions going forward. If we can't agree on what it is and who it is for, we cannot possibly make good decisions on related things like documentation and training and we will never be able to measure whether we are doing a good job or not.

• Simplifying the Zope experience

  This is not so much a specific project as an ongoing philosophy. There has been quite a bit of discussion about this lately, and there are several themes that come through totally clear:

  • simple tasks should be simple!
  • flatten the curve for productivity
  • couch our story in familiar terms
  • reduce Pycentrism (index_html, et. al.)
  • less magic, even at the expense of more typing!

I think that the increased involvement of the community will be indispensible to helping us comply with these themes. We need to give ourselves an attitude adjustment and make simplicity and familiarity a priority going forward (even at the expense of elegance!). Many people have taken the time to tell us what is wrong, and we ignore that at our peril. We can do a much better job of making complexity an option rather than a necessity without compromising our core ideas. This jihad extends beyond the core software - documentation, training materials and web site content can contribute greatly by changing how we go about introducing complexity to the audience.

• Simplify the developer experience

  Like the through-the-web experience, creating add-on products is more difficult for developers than it should be. The decisions that we made in the past were appropriate for the situation at the time, but we need to change with the environment. It was ok for us to sacrifice clarity for magic and expediency when we were the only ones who had to puzzle it out, but we have to stop that now. We need to give developers a clear roadmap, clear interfaces to work with and clear guidelines for product development. This applies both to Python and through-the-web products.

  We have been making some progress in this area with things like the SecurityManager interface and explicit product initialization calls that remove some of the black magic that was there before. We need to make our future architectural decisions reflect this progess. We should also work with the developer community to identify the biggest current problem areas and work to address them.

• Continue working on scalability and reliability

  While some progress has been made on things like mountable databases, this work is very preliminary and we will increasingly need to think about our architecture with an eye toward large scale distributed systems. Some of our existing ideas (like the control panel object) probably need to be rethought to provide better through-the-web system information and management for a much more ambitious deployment model. Packaging of the Zope core and add-on products probably also need to evolve to support scalability.

  We need to get the initial release of ZEO "finished", meaning hardened, documented and packaged. Related to that, we should get PythonMethods finished to make it easier for developers to take full advantage of the 3-tier distribution story that ZEO represents.

  The "big folders" problem should be solved to give developers a little more headroom for in-ZODB applications.

• I18N support and Python 2.0

  Probably a little longer term goal, but there will be a number of things to think hard about once Python 2.0 is finalized. We will need to assess the impact of 2.0 on Zope and plan to support it, particularly the unicode aspects.

  With Python 2.0, the core infrastructure will be finally be there to begin defining and architecting I18N support for Zope. Community involvement will obviously be key in this.