[Evangelism] promoting WPD

[Dylan Jay]

Chris,

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
www.pretaweb.com
tel:+61299552830
mob:+61421477460
skype:dylan_jay

>
> -----Original Message-----
> From: evangelism-bounces at lists.plone.org
> [mailto:evangelism-bounces at lists.plone.org] On Behalf Of Chris  
> Calloway
> Sent: Thursday, 12 March 2009 12:07 PM
> To: evangelism at 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 at 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
>
>