[Framework-Team] Re: random thought: identify the components that lack owners
hannosch at hannosch.eu
Sat Sep 27 10:08:58 UTC 2008
Martin Aspeli wrote:
> Tres Seaver wrote:
>> It seems to me that not having continuity of architectural vision across
>> releases, including the ability to remove broken / abandoned components,
>> is a really dangerous place for Plone to be.
> I think there is architectural vision in Plone, but it tends to be
> established through a process of discourse and consensus building, more
> so than through one man's iron fist.
The problem I have with the current state is that we have been
exceedingly bad at looking at maintenance cost of new technology we use
and features we include. Consensus building so far has most of the time
meant, that we do include new features all the time. There's no clear
voice that says STOP.
The other problem I see is that we have an insanely complex set of
dependencies and code base. Few people are able to understand large
parts of it. Our learning curve is insane. There's a reason why Plone
developers aren't available anywhere on the market and the training cost
to get them up to speed is huge.
If we don't get a roadmap that is able to reduce the complexity of the
system from a developers point of view by a huge factor, Plone will not
be able to survive. We are eight years old by now, where do we need to
be in another two to four years?
I know that various people in the community tend to think in the same
direction, but we need clear visible steps to get there.
For example we took a huge risk to embrace Zope 3 technologies via Five.
After the explosion of Zope 3 into separate packages it has become
obvious that only a few core packages like zope.component and zope.i18n
are actually maintained. Large parts of zope.app do not have any
community to support them, neither has Five itself. What do we make of
that? We used zope.formlib but most other people ditched it by now. Can
we get a consensus on discouraging its use and making sure we don't use
it in the core anymore?
> That's not to say we shouldn't rip out a bunch of code. In fact, I'm
> going to lend my voice (and hopefully a little bit of authority) to that
> argument in two weeks' time. :-)
Yes! How many components do we have that are completely unmaintained?
For example stuff like different storage layers in Archetypes, wicked,
NuPlone, ExternalEditor, iterate, ... to name a random number. We cannot
simply remove everything that is unmaintained, but I think we need to
make some of those hard decisions about what to remove from the core
P.S. Maybe my perspective from a bug tracker manager is always a bit
more depressing than for other people ;)
More information about the Framework-Team