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.



Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to