[Evangelism] promoting WPD

Chris Calloway cbc at unc.edu
Thu Mar 12 01:06:57 UTC 2009


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 
experiential.

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 plone.org 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:

http://web.archive.org/web/*/plone.org
http://web.archive.org/web/*/http://www.plone.org

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 
expense.

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. 
Complicated.

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 
brain-dead.

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.

Revolution.

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 
documentation.

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 
development.

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.

-- 
Sincerely,

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







More information about the Evangelism mailing list