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

Hanno Schlichting hannosch at hannosch.eu
Sat Sep 27 11:49:21 UTC 2008


I'd guess this makes a good candidate for an in-person discussion at the
conference :)

My main point is probably, that we all have been too busy and we need to
drive Plone forward now or it will never happen. I'm also extremely
scared by key people leaving the community all the time, without an
equal amount of people coming in again.

While the community at large seems to be growing, the core developers
seem to be getting less all the time. If we cannot stop that trend, we
we will soon reach a point where we cannot turn this trend around anymore.

Hanno

Martin Aspeli wrote:
> 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. :)
> 
> Cheers,
> Martin
> 





More information about the Framework-Team mailing list