Forum OpenACS Q&A: Response to Article on ACS x Zope
am a little concerned in general about not being able to see the
forest through the trees. Since this thread was started, the
OpenACS project has clearly been evolved from an effort to take
an existing system built by ArsDigita, keep up-to-date with it, and
fix what's broken in it to an effort that's about envisioning,
designing, and building the system that the community wants.
Now that the community is truly charting it's own destiny, I think
it's a good time to think back to earlier conversations (like this
thread) that forced us to articulate what we liked and what we
wanted at the time and see if we're still on-target, if we're
off-target, or if the target has moved.
One of the themes of this thread, as I understand it, is that some
of the ACS partisans felt (at the time) that it was better to have a
relatively simple core architecture that is easily understood by
newbies than a complex core architecture that may accomplish
more but is much harder to learn. At least on this specific
philosophical issue, OpenACS 4.x seems to take one or several
steps away from this philosophy and closer to the Zope
philosophy. So the question I'm raising now is not so much
about specific architectural differences between Zope and
OpenACS as it is about general trade-offs between learnability
and the benefits of a relatively complex core.
I am certainly the last person to effectively evaluate this question.
However it is an important one that is closely related to the
branding and marketing issues the community is currently
discussing. Who is this toolkit for? What would be the most
useful to them? Which parts of the architecture need to be easily
learnable, and which parts are OK to make more complex in
exchange for more power or flexibility? Is the best trade-off to
make the core architecture complex but keep the APIs necessary
to create modules simple? Are there parts of the core
architecture that need to be easier to learn than others? Are any
parts of the core architecture in danger of becoming too hard to
learn? These questions are critical to answer if we want to
increase the adoption rate by developers and convince clients
that OpenACS will make it cost-effective for them to train their
staff to maintain and improve a web app built with it.