-----Original Message-----
From: evangelism-boun...@lists.plone.org
[mailto:evangelism-boun...@lists.plone.org] On Behalf Of Chris
Calloway
Sent: Thursday, 12 March 2009 12:07 PM
To: evangelism@lists.plone.org
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
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
_______________________________________________
Evangelism mailing list
Evangelism@lists.plone.org
http://lists.plone.org/mailman/listinfo/evangelism
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
AM
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
AM
