[Framework-Team] Re: random thought: identify the components that lack owners
optilude at gmx.net
Sat Sep 27 10:58:02 UTC 2008
Hanno Schlichting wrote:
> 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.
Who would lend that voice?
I don't see how anyone other than that consensus-built community could
have that voice. The release manager can have veto powers, but cannot
overrule the will of the community.
> 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 think that's a rather bleak assessment. I've just trained two people
up to be competent Plone developers in about 3 months whilst delivering
a project. By most measures, Plone still appears to be growing.
However, you're absolutely right.
> I know that various people in the community tend to think in the same
> direction, but we need clear visible steps to get there.
Right, those steps are:
There is a fundamental problem with seeking "management" in the
traditional top-down sense. No matter what hat you may have gotten
yourself, you won't be able to make me do any work on Plone that I don't
want to do. That's been the case since Plone was born. We rely almost
exclusively on volunteer action.
If that sounds scary, then think about what motivates people to
contribute. For me, it is things like recognition, friendship, and a
kind of instinctive self-preservation drive. I want Plone to succeed. I
want people to be happy with it.
This is visible nowhere more so than in you, Hanno. I suspect you fix
the amount of bugs you do because of similar motivation.
If we were a startup, we'd have a VC that provided money. That'd give
him the right to tell us what to do. We don't have anyone paying us to
do anything, really. Of course, I'd argue Plone is better for it. We
scratch a lot of itches that exist out there, for real people and real
customers, as opposed to itches that are hypothesised by a small group
So, as far as I'm concerned, architectural vision is emergent. It comes
from building a consensus about where the problems are and what we can
do to fix it. Find me one core developer today who doesn't say that we
need to simplify things? I don't think there are any. But there are
dozens who have ideas about how that can be done. We need to tap that
momentum. The framework team and release manager are the gatekeepers to
make sure the pieces fit together somehow.
> 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?
I hope so. It'll take a bit of time, but that's actually a good thing.
However, we wouldn't have been able to make this happen "top-down".
z3c.form only came onto the map when Daniel and Malthe built
plone.z3cform and did the necessary experimentation and bottom-up
innovation to prove that it was better.
We have large "top-down" mantras that exist out there. They often came
from Limi and ended up in broad trac tickets. Things like "fix WebDAV",
or "Build a better selection widget". Unfortunately, no-one feels
obliged to pick that stuff up.
>> 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
> very soon.
There are a lot of factors to consider here, such as the importance of
not breaking people's existing sites and the perception of Plone's
feature set to be improving, not shrinking. However, we've definitely
learned a lot about "in-core" vs. "out-of-core" recently. If I'm allowed
to do a few things in the core to bring Plone up to date with CMF trunk,
I'd be happy for Dexterity to live outside the core for a long time or
forever. The same goes for a lot of other things.
That said, not all things need equal amounts of maintenance. Iterate,
for example, is maintained in the sense that bugs in it do get fixed and
someone does release it. Beyond that, it's quite simple. Wicked scares
me a bit more, since it does strange things. Maintainability has as much
to do with patterns and architectural fit as it does with the undying
commitment of a few people. Then again, that may've been your point. :)
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
More information about the Framework-Team