#1 - Help me, help my customers.

Like many people who might read this blog, I do Python programming for a living. I mentioned in a prior blog entry that I now very rarely ever get a web programming lead that was not generated in some way by Plone. That's utterly fantastic and a testament to the folks who help to market Plone. The Plone brand is very strong.

Often the potential customers are attracted to Plone for the same reason that highly risk-averse people tend to be attracted to Microsoft products ("there's safety in numbers, and I've heard of it before"). Plone, due to its superior marketing and its strong feature set is considered a "safe" option. This is an amazing feat. Very, very few open source projects gain this status.

One of the downsides to this, however, is that the potential customers whom contact us.. well.. they all want to use Plone. And it's often (heresy!) just the wrong platform on which to build software that would meet their actual requirements. These potential customers tend to have requirements that can be expressed summarily as "I want it to be Plone, except I need it to work nothing whatsoever like Plone".

Several related things make this a problem. All of them are highly personal and some are highly selfish.

1. Using Plone is a near-mandate by some customers, even if building on top of it is not actually objectively in their best interest.
2. I have a tough time recommending Plone for projects that don't fit its out-of-the-box profile.
3. Customers who have the "I want it to be Plone except it should act nothing like Plone" won't be happy with the outcome if we do use Plone (it doesn't scale terribly well, it's too complicated a stack for a lot of problem sets, some of its core assumptions aren't a fit, and so on)
4. I need to make a living, and change is pretty hard. I don't want to need to become a Rails programmer or something.
5. People hire consultants at least partly to have someone to blame. It isn't in any way beneficial for a customer to remember that the consultant recommended against using Plone at the beginning of a project when a project turns out badly due to, say, Plone-imposed scaling issues. At the end of a project-gone-bad, it's always going to be the consultant that takes the blame rather than the customer (and rightly so, that's what we're paid for). "I-told-you-so" is an absolutely unacceptable conclusion to a project.
6. I hate, hate, hate having unhappy customers. I will go to lengths to keep customers happy. Often that equates to digging into Archetypes internals when I'm made to use Plone. ;-)

While it'd be useful to be able to turn Plone into something that is something good enough to solve every web programming problem, that would be a lifetime of work. I can't afford it. So Plone is what it is, and I can probably help improve it continually over time, but I'm not going to be able to (by myself, anyway) morph it into something more generally suitable in a timeframe that it would matter.

So I have two pleas. One is to folks doing Plone marketing. The other is to folks doing Plone core development.

Marketing folks: Please try to listen carefully to the core programming folks if they object to some characterizations of Plone in marketing plans. Sometimes it just wasn't meant to do that. For example, one of the best and worst things that has happened to Plone is that it has been branded a "content management system." Plone, out of the box, is absolutely not a content management system (at least as most of the people who use the term are concerned), however. This is dangerously close to being a lie. Plone is much closer to being an intranet system. It requires a good deal of programming to turn Plone into a content management system, because when people say "content management system", they usually mean something that has some customized, performant retail content delivery system that is largely separate from the system used to enter the content. But Plone doesn't have one of these out of the box. This is "good" for consultants, because it means there's half the work to do all over again for every job, but it's not great for customers, and it makes me a little uncomfortable. Content delivery is a hard problem and can't be generalized completely, either. But at least if customers understood that it wasn't a CMS, they'd be able to make reasonable decisions about whether to use it or not. Marketing terms are fuzzy while customer's needs are concrete, and their collisions are often spectacular. Often these collisions are not in the best interest of the brand, the consultant, nor the customer.

Core developers: Keeping concerns separated is important. Be judicious about what you let into "the core". It would be ideal to have something that bore the Plone brand that didn't have Archetypes, KSS, ExtendedPathIndex, wicked, and so on. This isn't because any of these things is at all bad for the intranet application that Plone is out of the box, but often it's fatal to Plone's usability as a framework. It's pointless to argue whether Plone is or isn't a framework. Defacto, it is, because people ask other people to build stuff on top of it, and the stuff that you build on top of it has to fit into it. I believe it's possible to solve this almost entirely through packagaging, by the way. If we were able to post-facto inject some reasonable layering, it would be possible to use as a framework without buying in to the entire stack, which would help a lot of people. It would be ideal if there was some layer that could be recognized as "Plone" but left out 90% of the stuff that the Intranet-application-which-is-Plone-right-now.