[Framework-Team] Re: random thought: identify the components that lack owners

Martin Aspeli 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:

  1. Discuss
  2. Build
  3. Release


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

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 mailing list