First a quick introduction. I'm Paul Everitt, co-founder of Digital
Creations, the people that make Zope. I just came across this thread and
would like to make some observations and offer help, if that's appropriate.
Some background. I'm the Mozilla fanatic here. We started a project called
Zope Studio to design a next-generation management screen for Zope based on
Mozilla. As I told Mitchell Baker in a note recently, unfortunately that
project didn't make it. We went way over budget before Mozilla got stable
enough for development, and at the same time Komodo from ActiveState taught
us that we're not a client-side tools company. :^)
Regarding some things from this thread:
1) It's true that Zope doesn't come out of the box ready to solve the
problem. Rather, it's a platform for solving the problem. It's a little
like the relationship between Gecko and a Mozilla browser. Fortunately
there are a lot of components for Zope that can add value, one of which I'll
mention in a moment.
2) Regarding James' comment about the hassle of the add-on product for
hosting, he's correct. Fortunately Zope 2.3 (a2 came out this week, final
release planned this month) includes this functionality, along with a lot of
other long-overdue stuff).
3) Regarding Gerv's comment about "perhaps getting a Zope guru will pitch
in", we're willing to go a little further and significantly pitch in.
4) One thing this thread has shown is that mozilla.org and the documentation
folks have what is known as a content management problem. This requires,
IMO, a content management system. I feel that mozilla.org shouldn't write a
CMS, since that's not the mission of the company. Rather, they should
partner with a CMS, preferably an Open Source CMS. We happen to have a
content management framework we'll be releasing that's Open Source. I
realize this logic is self-serving, but I feel it's also sound.
5) At a glance, here are some of the things that you'll need for a new
mozilla.org that are things we have experience in and software for:
o Membership. You need a system where people can sign up for accounts,
remember lost passwords, get expired after inactivity, get low-privilege
roles that can be expanded by higher ups, etc.
o Approval. For some areas of the site you need simple workflows.
o Navigation (searching, site maps, what's new, glossaries, categories,
etc.) This is one of the most important parts of the site. You need
efficient, effective ways to organize a huge mound of diverse, heterogeneous
content. This organization needs to then be presented to people in an
effective way for browsing, searching, and navigating the site.
o Content objects. There are different flavors of content on the site.
(In Zope, we treat all three tiers as content, so presentation, logic, and
data all get the same business rules.) These content objects might have
multiple input formats and multiple output formats. You might have business
rules to enforce on them (such as the document can't be updated if it isn't
well-formed with a valid category included). We have a LOT to say on this
subject, but also give a platform for mozilla.org to extend our basics.
o Security. When you start talking about a site with thousands of
contributors...I'll just leave it at that. :^)
o Site-wide style. This might be the second biggest challenge for
mozilla.org, after organization/navigation/structure. How do you
efficiently impose one or a few consistent presentations on a whole pile of
content, while leaving room for context-sensitivity?
o Dynamic components. One thing shared by all content management systems
is that, to some extent, pages are rendered dynamically. Thus logic can be
used at run-time. Even better, you can tap into pre-defined logic
(components) such as polls, threaded discussions, Bugzilla, etc.
o Low admin burden. How do you do all this with essentially a volunteer
staff? The system should promote safe delegation of control.
Ultimately we're interested in contributing in a substantial way. However,
as mentioned a few times, the first step for any of the various directions
mozilla.org might choose is to line up the prototypes.
I've been in the Python community a LONG time, and now in the Zope
community. One thing I've learned is there's a big difference between what
*might* be and what *is*. Thus I'm willing to get Digital Creations to help
on producing a pilot site.
However, we're bandwidth constrained, getting ready for LinuxWorld Expo at
the end of the month. (If anybody is going to be there and would like to
see a killer demo of what mozilla.org could be, drop by the booth :^) Thus
I'd like to just work with a small group of people in private email
exchanges, then let them present the work back to the group.
For what it's worth, as an example of how a content management system
*might* work, I posted this exact text in a "page at
Zope.org":http://www.zope.org/Members/paul/MozillaDotOrgProposal. We have a
text format called "structured text" that can be rendered into HTML,
DocBook, and soon PDF. Zope.org is running an old version of our content
management story.
--Paul
