This is probably the most astute comments on Plone I've read.

Plone does have a marketing value proposition problems. It should either admit its an ECM/consultantware/framework (which is more or less how we at Pretaweb market it now), or ... well I don't think are many other niches left for it. With marketing as an ECM Plone has lost its opportunity with Alfresco getting traction with it's "The open source ECM" slogan. Plone is possibly the only openly developed high bus number ECM but that's harder to market. Either way plone doesn't market itself like this so any individual effort isn't very effective.

In terms of making plone approachable to developers I've been being trying my best to muddle through ways to get some of this done in the last year. With documentation, I've agitated on teh documentation list and individuals the conference and managed to piss some people off but at the same time with pushing from plenty of others I think the direction is better with a focus on manuals being the only "official" documentation. The single understandable developer manual is still too daunting however for the doc team to consider and I agree it shouldn't come from the doc team but the developers. Myself and Rok Garbas have been trying to get buyin for a sphnix based way of publishing plone developer documentation, with the idea that if plone documentation in svn is visible then it will get written better (or at all). There are political problems there too. but perhaps your monetarism idea is what is needed. Perhaps developer documentation needs to officially taken away from teh docteam and given to core developers.

All I can think of saying is we need more people like you saying these things

Also I'm working on a tool called hostout to make hosting more manageable for amateurs.

Making plone simple enough for amateurs is the only way to grow the community and survive I think.

Dylan Jay, Plone Solutions Manager

-----Original Message-----
[] On Behalf Of Chris Calloway
Sent: Thursday, 12 March 2009 12:07 PM
Subject: Re: [Evangelism] promoting WPD

On 3/11/2009 3:00 PM, Calvin Hendryx-Parker wrote:
I'd be interested in hearing as many of these stories as possible so we can help others not make the same mistakes. I bet that rarely Plone was the issue, but the people involved in the project just didn't know what
power they really had.  I could be wrong and would still love to
leverage this info if possible.

You'd like to hear about it on this list? With open archives?

I think you'd be asking for blog-fodder for our competitors.

Because they really aren't stories about people not knowing what power
they had.

And a lot of it was to do with Plone, its community, and its culture.

This is why I don't have a blog. :)

I'd be glad to give you private run downs. I'm sure I have given you
some already. :) I'm sure some are well know to you already because you
swim in these waters, Calvin.

The biggest horror story is one I'm not supposed to even talk about.
It's not like everybody around the Triangle doesn't know it. It's just
that it involved a couple million dollars of charitable funds and some
highly placed people lost their jobs over it. So all the observers have
been asked to have respect for the dead and shut up. By their bosses.
And it just gets talked about privately, usually by the bosses with the
checkbooks whenever someone brings up Plone because it is some damn
succulent gossip.

But I can *categorize* some of the main problems on this list, starting
with the aforementioned case and some others like it.

The number one problem has been great variability in the abilities and
ethics of consulting companies operating in the area. Not yours. Yours
and a couple of others have been the mop up people called in to clean up
some of the previous disasters. Most of the crap companies have been
outed and have left the area, leaving behind only their legacy of
don't-use-Plone in their wake. But we have at least one problem company still muddying the waters here. As you might see, there would liability
in telling enough of the story to identify that company.

Anyway, that problem is kind of taking care of itself. The bad companies have been identified and blacklisted. But not without leaving long term problems for Plone marketing in my locality. Plone got started in a big
way pretty early here. There were big ass Plone projects underway here
even before Plone 1.x was out. It took until sometime in Plone 2.x to
get the bad companies banished because it took awhile to really figure
out just how bad they were.

So this relates to the number two problem. Because you might think,
well, bad consulting companies are equal opportunity employers. You'd
think that the resulting Plone horror stories would be matched by equal
or greater number of Drupal and Joomla horror stories. But other than
the one instance you cleaned up here recently, there really aren't many Drupal or Joomla horror stories here. Just lots of successful and happy
Drupal and Joomla shops who cough loudly when Plone is mentioned.

Why? Because reason number two is something the Plone community
*promoted* vociferously in its early days. Plone's reputation here is if you use Plone, you'd better be prepared to hire a full time consultant.
And in the early days of Plone, it was repeated by the community every
day, if you need help with Plone or you need Plone documentation, hire a Plone consultant to help improve Plone and improve Plone documentation.

Seemed simple enough. Seems like an open source dictum. And that is what
people have had to do a lot, just to get even simple sites rolling in
any reasonable time and money frame.

Now, you might say, that's a case of not knowing how much power somebody had. But I'd say you are wrong if you did. Because the Plone culture has way too much of a blame the Plone victim mentality. We imagine everyone
who has Plone problems is someone who pops into IRC and asks, "Please
tell me how to Plone," or "I downloaded Plone and it doesn't work." The
truth is, there are huge numbers of very smart people with Plone
problems bigger than they can solve and who just move on. I get to talk to them every day. Or I used to more but I just started telling people,
look, I can't solve all your Plone problems and do my job, you need to
hire a Plone consultant. So a lot of people here have just stopped
asking and moved on. There aren't enough consultants AND there aren't
deep enough pockets compared to the expensive of putting up a Drupal or
Joomla site.

See, there's a pretty heavy cognitive dissonance with "hire a Plone
consultant" and several other Plone messages, both marketing and

One message is "Plone is a product" was chanted as a mantra for a long
time. It's been called into question, sure. But it was chanted long
enough to do a lot of damage that isn't any longer repairable.

So Linux is an open source product. Do you need a consultant to use
Linux for you? Is Linux not a lot more complex than Plone?

What other open source products do you use that you need consultants for?

Which brings us back to our local happy Drupal and Joomla shops. They
don't hire consultants. They use skills seemingly everybody has. They're
freaking ecstatic.

Now, you might say again, yes, but those happy Drupal and Joomla shops
don't realize the power they have in their hands with Plone, that Plone
operates in a different niche, in a different solution space, in a
different whatever buzzword you have for audience this week. That Plone
is For The Enterprise(tm) unlike those toy PHP CMSes.

But this runs into cognitive dissonance with a second Plone message. For
years the Plone message has been Plone is easy to customize.

To support this, I wanted to go back as I have many times for people
wanting to market Plone and point out all the sites from the
past and their parade of "easy-to" marketing messages on the front page.
But someone has now gone and blocked access to those:*/*/

But trust me, if you could still go back and look, you'd see year upon
year of claims about how Plone is great for web sites, intranets,
extranets, portals, content management systems, etc., etc.. Pretty much any use case you can think of without limitation. Along with the message
that it's easy. To use. To customize. To whatever.

And of course. It's a product, right? Who wants a product that isn't
easy? Or isn't versatile?

Now, of course we know Plone isn't free as in free from cost. We rolled
out that ToTaL CoSt oF OwNeRsHiP slide at the last WPD showing how
Plone's lack of licensing fees puts you way ahead of the game from those
other expensive ECMs.

But if we say it's a case of too much power, that Plone is an Enterprise
CMS, then we've got to make the choice to stop saying that it's in any
way easy. Plone is not both an ECM product and an easy product. It's one or the other or not a product at all. Ease isn't a product quality that
conjoins with needs-a-consultant.

Plone is not easy. It's just more affordable for those people who have
pockets deep enough for an ECM. It's more affordable for those people
who were going to hire a consultant anyway.

So, Plone is not so much a product. It's consultantware. Which doesn't
differentiate it that much from other ECMs. And doesn't provide enough
advantage from popular non-consulantware easy CMSes to make it worth the

This is a really dangerous place to be if you look at eliminating the
use cases which imply Plone is easy or inexpensive (and which are mostly
basic content management use cases that you *don't want* to eliminate
anyway). Most of the enterprise characteristics which come from a Plone
deployment done by consultants are bolt-on advantages that come from
other things like Squid, Pound, Varnish, Lucene, PostGres, LDAP, or some
other content generation or content delivery system and not Plone.
Plone's strong ECM use case is it's a good content management system for
non-English speaking people with disabilities.

That brings us to problem number three. Do not blame the victim for not
knowing how to handle Plone's power. Because Plone is not so much
powerful as it is complicated. Plone has some nice stuff, but the
complication is way out of proportion to the extra nice. The
complication is way out of proportion to some of the basic content
management functionality *left out* of Plone at the moment. Simple
changes get too complicated very fast with Plone.

Plone is not easy. Plone is complicated. Do not blame people for not
being able to handle complicated. Just stop it. That is Plone's problem,
not the problem of people who adopt Plone. Python is about the simple,
or at most the complex. Plone is complicated. Problem number three.

Plone is so complicated, it's even complicated for Plone consultants. I
talk to Plone consultants about my Plone problems and walk away with
more problems to solve than when I started. I walk away with more
problems to solve than I can afford to solve. I talk to Plone
consultants and they run into problems trying to help instead of
helping. Plone is so complicated that it contributes to bad Plone
consulting companies spreading Bad Plone Karma.

And I'm a friend of Plone. I can handle some degree of complicated and
consider Plone a challenge. It's complexity is kind of interesting to
me. But imagine what it's like for people who have no particular
allegiance to Plone, they just have a job to do. And Plone is getting in
their way. They ask questions. They start getting complicated answers
and the people answering start to realize how little they know about
what they are trying to answer. It only takes a couple of public
incidents of that in any locality for all the bystanders to decide
there's nothing going on worthwhile in the Plone community, so let's
move along.

Plone is so complicated, there's a lack of Plone consultants to handle
the demand for Plone here. Or at least a lack of affordable Plone
consultants that can get the job done without breaking the bank. My
local area has about half the decent Plone consulting firms in the
country doing business here. And it's not enough. People have a
preference for local Plone consultants and there's no one here I can
even recommend as a competent Plone consultant. I have to recommend
people halfway across the country. That has been a real strain on Plone
marketing here.

Plone is so complicated, we in the Triangle have tried to train new
consultants and Plonistas to keep up. We expend so much effort doing tis
that I'm sure it's going to be the death of me. And there's no keeping
up. For most people, it's just too darn complicated for more than the
simplest sites. And for simple sites, you don't need Plone. You could
just do Drupal or Joomla. We put people though a week of boot camp, and
they learn just enough to be dangerous to themselves and others. They
can't really take it home and start meeting real world requirements and that pisses off their bosses who spent their time and money on even low
cost training.

We put people through a second week of advanced boot camp and it just
makes them more dangerous. For those people whom we move onto "advanced"
(i.e., more than customizing a logo), we train them and then their
training is very quickly out of date because new complexity is being
created every day. That really pisses them off.

Out of hundreds of people we've used as training guinea pigs, we've
gotten less than a handful of people who one day might be able to
contribute to the core of Plone and none who don't have to fight the
framework for every end user requirement they are trying to fulfill. And for every dullard we end up putting through training because their boss bought into Plone and sent whatever random employee was available to the
training, we put one really smart and accomplished person through
training. It's not an intelligence problem. We've put some pretty
illustrious people with proven abilities to adapt through our trainings.
And it's not a training problem. I've never seen such incredible
technical trainings and I've seen many.

For those people whom we did train and to whom it stuck and was useful,
it was mainly because they now eat, live, and sleep Plone 24/7. It
wasn't, "OK now that they training is over you need to put this into
practice and get better at it." It's more like whatever it was they were doing before, they aren't doing it now. They're just doing Plone. Plone
has become an end unto itself instead of a means to an end.

Plone is so complicated, for those people whom we did train and to whom
it stuck and was useful and who mainly because they now eat, live, and
sleep Plone 24/7... they can't keep up. It changes too fast. New bugs
are created too fast. They make a site to requirements. There are
problems. To fix them they have to continually migrate because things
move on that fast and only security fixes get backported. And now they
have two problems, the original problem and what they have to do before
they can start to fix it.

Plone is so complicated, from time to time people who are on the cutting
edge of creating new bugs will say, enough of this bug creation! Let's
refactor! Let's simplify! Let's throw out cruft! Let's re-engineer the
framework! Let's take a new approach!

...Which damn near always results in a factoring out features and
backwards compatibility instead of complexity, giving still more new
problems to the legions of people who adopted Plone while making the
people on the cutting edge of creating new bugs very satisfied with what they did today for the legions of the unappreciative Plone welfare state.

Which brings us to problem number four. OK, so Plone is complicated.
That in itself is a complicated problem. It's complicated because we
need a compass to get through the maze. And there is no compass.

For all the talk of hire a consultant to make Plone documentation
better, and all the hiring of Plone consultants, the documentation is
just reshuffled, reindexed, retagged, and new complexities given a
recipe or two.

Because that is our culture. We come from Zope culture. Even worse, we
come from CMF culture. We come from some of the worst documented open
source cultures in history. We come from cultures that are avowedly
against documentation. Cultures who from all outward appearances
consider documentation a bad thing and belittle those who dare think it
necessary because Python is self-documenting. Those cultures keep
producing code not only without documentation, but in some very visible
instances, *removing it* because developers would not update it with
their changes. ("Zope Tutorial" still in your drop down? Try adding it.)

Dude, products have usable documentation. Python is self-documenting and
even it has usable documentation.

And don't tell me about how many Gagiggy-bytes of Plone documentation
there are, or how many Plone books there are. You already know Plone
documentation sucks. You know it. Don't act insulted. You. Know. This.
We've got low hanging fruit of end user documentation of what's already intuitively obvious for any user of Plone. Check. We've got the hive of
recipes. Check. We've got some outdated development books. Check. Book
compiling some of the more basic recipes soon to be outdated. Check.
Book coming out on Plone in Education. Check. Done. Oops, we don't have
ongoing dependable continually updated usable documentation on what
people actually need to do with Plone.

And that will not get better as long as Plone is consultantware. We keep
hiring consultants. And Plone consultants keep innovating and creating
new, undocumented, and under-reviewed code for an overheated codebase
nobody can keep up with. It's like Alan told us before the Plone
gathering in Indy last fall, "Plone is so big, nobody know it all anymore."

When people come into the Plone community, rarely do they become
contributors to Plone. Sometimes they become product developers to try
to work their way into becoming Plone developers, and that rarely
happens, because Plone is so complicated. But what happens to most
people coming into the Plone community is they are asked to contribute
documentation. This is kind of like asking the blind to lead the blind
(no offense to the blind, please). It's a chicken and egg problem. You
can't document what you don't know. So a lot of those people get tired
of that dead end and join the great wasteland of Plone marketers. We
can't contribute to it. We can't document it. But damn if we can't sell
ice to the Eskimos.

The idea that there are some people who get to do the fun part (code)
and the everybody else is a plebe who has to do the shit work of endless
reverse engineering for the purpose of documenting is just beyond

We know that everyone can't code. And that really there are only the few
who can do it well.

However, if someone is that logically intelligent to be the coder, then they can understand the error in logic from thinking it must follow that
documentation is therefore up to those who can't code.

At one time, I could read a lot of the Plone codebase and figure some
things out. Not so much anymore. There's just too much of it. It's not
an intelligence problem. There have been many psychologists who have
studied the problem of how much code can even brilliant programmers can
keep up with.

Now, it's not like there aren't other big codebases around. It's just
that these codebases have something we don't have. They have developers
who document what they do.

And I'm not talking about documentation by writing test cases which can be searched for and torn apart. I'm not talking about stacks of recipes
to search through for arcane use cases. I mean documentation like
there's Python documentation, where I can read it and then know
everything there is to know about Python.

So OK, four broad categories of ongoing obvious lessons to be learned:
bad consultants, consultantware product, complicated complexity, and bad
documentation. Some mixed messages for added cognitive dissonance:
hire/easy, refactor/cripple, train/fall behind.

"They" say you shouldn't propose problems without the hint of a
solution. And I'm not so crazy as to think I have or am the solution.
But I have a hint.


At the risk of offending many people whose opinions I value, I don't
think Plone is a meritocracy anymore.

And I think the marked decline in Plone metrics over the last few years
fully supports that possibly incendiary statement. Keep your awards.
Plone was once the "it girl" and now it can't get a date.

I think at one time Plone was a young meritocracy and it slowly devolved
through no one person's fault but through cultural drift into an
entrenched mediocracy which only full time consultants can even begin to
hope to penetrate.

I think it creates new problems faster than it solves old ones.

I think evolving from a benevolent dictatorship into an unofficial
consensus of a few who crown themselves meritorious by virtue of their
additions to the complicated complexity drove this.

I think that such was probably a natural evolutionary step, like from
tribalism to feudalism, and is subject to further evolution.

I think a new standard of merit is in order. A standard which values
current, comprehensive documentation over overheated innovation. A
standard which values ease of Plone adoption over marketing of Plone
adoption. A standard which accounts for meeting customer requirements
and ongoing maintenance with Plone in its evaluation of total cost of
ownership of Plone. A standard which values a customer's content instead of holding it hostage. A standard which grows new Plone consultants and grows the Plone community by eschewing consultantware. A standard which champions the Plone amateur instead of punishing the Plone professional.

I'm not talking about the merit criteria for the Plone Foundation,
either. One, the Plone Foundation is not the Plone community or Plone
development. Two, the Plone Foundation merit guidelines specifically
disregard consultantware. That is, contributions to Plone made in the
course of performing paid client work are not considered sufficiently
meritorious to the Plone Foundation. We publish that view in writing in
the PF merit guidelines. There's huge wisdom in that.

As much as I'd like to see TTW Ajaxy layout management and content type
generation right in Plone (and think they would have been there years
ago a better understood Plone codebase), I'd forgo those in an instant
if a code moratorium were to divert effort into improving Plone
documentation to a usable level. (The Apache Foundation did this for a
year and it was the best thing they ever did.)

I'd like to think both necessary innovation and re-documentation could
be done. But it would require a degree of cultural self-discipline that
I haven't ever witnessed in anything Zope-community-related.

There was in the last few months a thread on, I think, the framework
list where it was discussed requiring PLIP developers to account for
every place in the documentation where implementing their PLIP would
require a change in the documentation. It was decided that such a
requirement would be too onerous. I'm fully in favor of revoking the
commit privileges of anyone who thinks that way. So sue me. At some
point you just have to say that approach specifically detracts from
Plone's own merit.

For any such cultural change, there are those who justifiably ask, who
would make this effort? There's so much to do and so few doers. How
would we take on more?

I would say there is too much going on. I would say there are too many
doing too much to something that is supposed to be owned by more than a
few. Something that is a public trust. I would say the who is the who
already doing the doing. Just that they need to return to doing
something more meritorious for awhile than compounding problems. I think we need less innovation and more documentation for awhile. More hardcore

I think if that doesn't interest "innovators" and that this would cause
so-smart developers to desert the community, I say don't let the door
hit you on the way out. #php is right next door. Plone is damaged by
developers who don't usably document. I'm not talking about test cases.
I'm not talking about inline documentation in the code. I'm talking
about the documentation no developer likes to do, but which no really
usable code ever existed without.

I think the people who mangled the codebase now owe it to us to tell us
just what they've done to Plone in some way a bit more adult than a
changelog. I think Plone has been dragged down to the point where some
people are going to have to measurably reclaim their mantle of merit.

I don't think who is going to do this should be a problem. And if it is
a problem, it should be a nontransferable problem.

I think we need a benevolent dictator again. I think anarcho- syndicalism
is not working for Plone. It is working for a group of consultants who
have seized the means of production. But it is not working for Plone the
content management system and its community. Anarcho-syndicalism is
embarrassing Plone.

I think that benevolent dictator needs a more considered approach than
what is being applied to Plone through rigorless net meetings and chance
IRC exchanges. Something more like the process Python uses too great
effect and to the enormously huge benefit of its community.

I want it known that I am *not* in favor of a Plone community of
imposing "process" on Plone development. I think we all know that is a
dead end of the bureaucratic.

I am in favor of imposing more considered merit standards on Plone

Python would never make a release without a simultaneous release of
completely comprehensive and updated documentation. What gives Plone the idea that it would be right not to? The notion that we've always done it
that way and it would be too hard to change now?

That's neither merit nor innovation.

I wish I didn't have to jump in a car right now and drive 100 miles to
take care of a recently bereaved elderly relative, so I could edit this behemoth and possibly spare myself some future grief. But such is life.
You put me on the spot, Calvin, and this is what you get.


Chris Calloway
office: 332 Chapman Hall   phone: (919) 599-3530
mail: Campus Box #3300, UNC-CH, Chapel Hill, NC 27599

Evangelism mailing list

Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.557 / Virus Database: 270.11.7 - Release Date: 3/03/2009 12:00

Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.557 / Virus Database: 270.11.7 - Release Date: 3/03/2009 12:00

Evangelism mailing list

Reply via email to