[Zope-CMF] Re: Re: Plone participation in the CMF list

[Martin Aspeli]

> The general mindset of most Plone developers, as I perceive it from the  
> CMF side, seems to be one of "I'm in Plone code, and I know what to do  
> here, and I don't need to look beyond my world". Very few developers  
> have a broader view and even think of pushing generic functionality or  
> even specific improvements to core functionality that originates in the  
> CMF down to the CMF level. It seems easier for them to monkeypatch and  
> override directly inside Plone code.

I think you're right, at least as pertains to myself. It's not a concious  
decision, I have nothing against CMF and the developers I've met that are  
in CMF core I get on with well. However, I think this mentality resides in  
a lot (if not the majority) of Plone developers. Some speculations as to  
why this may be are:

  - There is no clear strategy or leadership on how this integration should  
work. What code is CMF worthy? What isn't? Plone gets stuff done  
principally because people yell at other people to help out. If person X  
in Plone could say "this looks like something that should be in CMF, send  
an email to person Y in CMF and get him to take a look", and then person Y  
could respond in a positive way immediately, then the poor programmer  
would be more likely to feel like he knew what he was doing. Currently,  
that happens rarely. Maybe because...

  - CMF is "infrastructure" and low-level. Such code tends to have more  
intertia, and the risk of making mistakes is higher, so one may presume  
the best thing to do is to "leave it to the professionals"

  - Plone still has a lot of "process" problems, but with the  
PloneHelpCenter, the PLIP process, the collector (sucky though it is) and  
the active leadership of people like limi and lurker, we have at least a  
fairly good idea of how new features get in, how bugs get tracked, and  
rough areas of responsibility that emerge. To an outside, at least, the  
CMF world seems to be more difficult to slot into. I'm sure it isn't, just  
that I don't know where to go to find out how to behave well in the  
community.

  - The CMF community feels less active (perhaps for obvious reasons - it's  
more of a stable technology; just reading the list intermittently, it  
feels like it's in maintenance-and-blue-skies-future mode, which may not  
be true, of course). There's always life and excitement on the plone-dev  
and plone-user lists, and in #plone on IRC, so our attention tends to be  
focused there. We get to know some other developers, we start helping out,  
and so our world becomes confined to that one. This is obviously a  
self-reinforcing process.

  - It's yet another contributor agreement and bureaucratic process to go  
through; in fact, it sounds even worse than Plone's. So, the marginal cost  
for a developer to do it "just for one little fix" is too high (of course  
over time, it may not be, but that's moot there and then).

  - The release cycles are not synced. We seem to work best to deadlines,  
so there's been a great push towards Plone 2.1 in the past couple of  
months. Hence, there may not be time to generalise, test, talk to CMF and  
CPS and other people and get something reusable into CMF. A lot (well,  
maybe not that much) of stuff in Plone is marked "XXX: Should probably  
move to CMF".

  - CMF is less sexy. Getting features into Plone typically mean higher  
visibility. For those of us who base custom CMS solutions on top of Plone,  
it also puts them closer to our own skillset and toolchain.

  - Plone is (probably) better documented and more widely understood than  
the CMF underpinnings. It's not that hard when you know Plone, so it's  
probably more of a psychological barrier, but it seems easier to get a  
grasp on Plone.

So, I guess my suggestions for what we can do to improve this situation  
may be (some of these may already be happening, but it doesn't hurt to  
spell it out)

  - Encourage Plone people to read the CMF list

  - Encourage CMF people to read the Plone dev list, and shoot in whenever  
something seems to be CMF material

  - Encourage CMF people to be in #plone, for the same reason

  - Have the senior Plone and CMF people work out some guidelines for how  
better to encourage cross-pollination of ideas and code, and follow  
through on it day-to-day.

  - Make the CMF contribution process as seamless as possible

  - Produce "how to be a good CMF contributor" documentation that's easy  
for a Plone developer to grasp without taking the whole weekend off  
reading logs, code and lengthy manuals (incidentally, we're working on a  
similar thing for Plone core. We should collaborate here too. I can give  
you access to the in-process document if you're interested in seeing where  
we are so far).

  - Work *transparently* and *openly* on the Z3/Five/ECM efforts, with  
Plone, CMF and non-Plone CMF users. Cross-post major discussions here to  
all relevant lists, and produce easy-to-follow documentation about the  
state of discussion and implementation, so that people can determine  
whether it's feasible to throw their efforts into an existing project when  
they need to get something done, either for Plone or for their own  
customers.

  - Set out some overarching guidelines in terms of management and coding  
standards for such Z3/Five/ECM efforts. Most Plone developers seems  
excited abot Five/ECM, and I think long term we do all want to end up on  
Z3, but that process is lengthy and needs both champions and careful  
communication and stakeholder management. Those who burn for this project  
should expect to have to do some kicking and yelling to get people in  
gear. Saying, "our code is great, join us" will give you a few interesting  
glances. Saying, "you're duplicating what we're doing, and we can promise  
you that if we work together this will work for you by the time you need  
it" will get you actual code.

I'm sure others will have much to add as well. However, I think the  
fundamental issue here is that there is some culutral separation between  
CMF and Plone (and I presume CMF and CPS, CMF and Silva, CMF and XYZ  
consumer of CMF). That separation is probably necessary (even useful) but  
it doesn't mean that you have to be in one camp or the other. To get  
people to be comfortable working at the CMF level, the CMF people need to  
make an effort. So do the Plone pople. And the CPS people. And the Silva  
people. And anyone else.

Martin

-- 
(muted)