I've been continually (in the sense of "on and off") working on a customer project now since mid-2004. In terms of manpower, it's a tiny project, as it's primarily only me and another developer at the customer site, plus occasional fly-ins from contractors.

In terms of code, it's not mind-bogglingly enormous, but it's substantial. sloccount gives me about 50K lines of Python (11.18 person-years, ha, not quite, although it feels like it sometimes!). For comparison's sake, sloccount weighs the entirety of Zope 2.8 at 238K lines of Python, so it's about 20% the size of Zope 2 itself. Not that counting code by lines is a great measurement, but it's the only one I have. Anyway, it's pretty big, at least divided by the number of people who've contributed to it.

The project is a Zope+CMF project. CMF is providing almost zero value except for types and skins, neither of which we use much as most of the type stuff could now be handled by interfaces, and we've transitioned away from skins to Five views for almost everything. I even keep my own types registry separate from the types tool. We use Postgres to do most of the data storage except for blobs, and the occasional XML file. On this project, Zope is providing exactly the value that the union of ZServer + ZPublisher + ZODB + Zope security + the Zope DAV implementation (which implies, for better or worse, OFS and propertysheets) provides.

It dawns on me though that much of the code in this project actually subverts features of the components I'm using. Speed and scalability requirements foil the stock implementations. For example, I need to encrypt files as they get uploaded to avoid needing to encrypt them in a "big bang" when they make it into the publisher. To do this, I utterly rape ZServer. Avert your eyes. I need to actively subvert silliness in CMF (opaqueItems.. really? really?). I use PluggableAuthService, but I'm not sure why: my plugin is the only one. I use the ZCatalog, but only for two indexes, and these could be replaced with relational indexes if really necessary. I use security declarations, but oh my lord, do I beat them like redheaded stepchildren (I roll permissions up into "grants"). It would have been easier to do it another way. The DAV stuff: if you saw what I had to do to make it behave, you'd back away very, very slowly. I can't even really use the stock Folder or File implementations in Zope or CMF; Shane's BTree folder code is too slow for my particular purpose, so I had to roll my own and the File implementation needs to deal with encryption.

Frankly, lots of frameworky implementations (not just Zope's) are not very good for any particular purpose. This is not because they're written badly but because they are fantastically too general for any specific purpose, and using them wholesale results in speed and code-comprehension problems ("wiggling the wires"). On the other hand, if you didn't start out with some set of tools, and you wrote everything from scratch, you'd be a moron, because there is value in the framework. As a result, I believe you should start off on a project using some "framework" (even if it's just a collection of libraries) but its best to to use good judgment about when to subvert the framework's features. And have the good sense to ditch the pieces of the framework (or the entire framework) when the day comes that it's just apparent that the amount of value it's providing is outweighed by the amount of value it's subtracting as you write code.

But in order to reach this point, you need to understand the intent of the pieces of the framework. Frankly it drives me utterly bananas to see, for example, some poor guy trying to make Archetypes/Zope3 Schema/ToscaWidgets/whatever show some complicated widget on his form when it's clear he could have just ditched the framework and made a form much more easily. I usually say of this that he "didn't get the joke" or that he's producing "add only code". The joke is that he just spent six hours fucking with Archetypes when it would have taken him two to make the form and handlers. Even worse, his code is utterly tied up with a framework that may or may not work for him later, depending on his scaling requirements. He might have made a perfectly workable widget that might work forever and might help a lot of people with similar requirements as himself, but it's just as likely that he might need to just go make the form later because he didn't really understand the requirements in the first place.

The next time you're "fighting the framework", stop. Breathe. Consider. Are you sure the framework you're using is appropriate for the task? If not, throw it out. Use something simpler. It will be faster and smaller. If you're basing your code on the framework solely because you believe that the framework helps you so much that you'll never need to understand how it all works, you're fooling yourself. I guarantee that once you find out what pdb is, you're going to be in it for days later on. There's absolutely nothing wrong with writing application-specific code. Your code doesn't need to plug in to any framework, or play by anybody else's rules. All that matters is that it works.

I'm hoping we can move Zope in a direction where we can pull off pieces of it to use as necessary for projects, if only so people can understand the intent of those pieces. Otherwise, we're forever going to be in the ghetto. Most people who complain about frameworks complain about them because they don't understand the intent of the pieces that comprise the framework. They don't even know there is a division between those components, they just see one big gray blob. Zope is too big to be one thing and shouldn't be treated as such.