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.
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.
