promoting WPD
|
|
| 1 2 |
Roberto Allende
|
Hello
I'm working with a local government to organize our local WPD. They've experts on communication stuff and they asked me if we've an alternative name to promote WPD. The point they mention is that for someone who has not knowledge about what Plone is, a World Plone Day could have no sense. By the other hand, i've seen a scrum event called Agile instead of Scrum. Then... considering what the communication people say, do you think that if we use Content Management Event or Day, instead of Plone could be better in terms of communication ?. Do you have any other suggestion instead ?, i repeat, the goal is to use a title that someone who doesn't know what Plone is, can get an idea about what the event is. I'm asking and considering this to make the experiment at a local level. This is not a proposal to change the name. Kind Regards r. -- http://robertoallende.com _______________________________________________ Evangelism mailing list [hidden email] http://lists.plone.org/mailman/listinfo/evangelism |
||||||||||||||||
Jan Ulrich Hasecke-2
|
Hi Roberto,
Am 11.03.2009 um 14:49 schrieb Roberto Allende: > Then... considering what the communication people say, do you think > that if we use Content Management Event or Day, instead of Plone > could be better in terms of communication ?. > Do you have any other suggestion instead ?, i repeat, the goal is to > use a title that someone who doesn't know what Plone is, can get an > idea about what the event is. > > I'm asking and considering this to make the experiment at a local > level. This is not a proposal to change the name. I won't change the name to indicate that this is a Plone event. I don't like to camouflage this. But in Germany we are going to have a motto for our WPDs "Wir bringen Schulen ans Netz" what means that we are planning to make a school website during the WPD for one school in each town. At the end of the day the result is presented to the audience. This idea came up to have a broader audience but I think that a motto might help to clarify what you are going to de. juh http://muenchen.worldploneday.de _______________________________________________ Evangelism mailing list [hidden email] http://lists.plone.org/mailman/listinfo/evangelism |
||||||||||||||||
smime.p7s (4K)
Chris Calloway
|
In reply to this post
by Roberto Allende
On 3/11/2009 9:49 AM, Roberto Allende wrote:
> Then... considering what the communication people say, do you think that > if we use Content Management Event or Day, instead of Plone could be > better in terms of communication ?. People who don't know what Plone is also don't know what content management is. And if you've heard of content management, you've probably heard of Plone. At least, that's my experience. So I don't know that an alternative name change leaving out the Plone brand helps those people who don't know what content management is, or those who do. WPD might need a secondary slogan to communicate what Plone is to those people who don't know what Plone *or* content management is, though. In simplest terms, what a CMS does is help people get their content on the web quickly. The word "content," however, is kind of jargon-y for most people. When I use the word "content" with people who don't know what Content Management is, their eyes just glaze over. And that's most people. Who need content management. And don't know it yet. Additionally, content is a means to and ends. Content is something you want to communicate to people. And that's what a CMS really does. It *communicates* content. On the web. And people understand what the words "communicate" and "web" mean without having to understand the context of what content management is. So I would just suggest the title, with a secondary slogan like: World Plone Day: Communicate on the Web or World Plone Day: Quick Web Communications (I like the first one because it manages expectations. I find it really important to manage expectations up front when doing a marketing event.) You could incorporate that into your logo as well. Just put "Communicate on the Web" below the logo in smaller type. Or encircle the logo with that secondary slogan. I'm not really good with that part. I'm sure somebody can figure that out. It tells people, hey, I'm going to an event that will help me communicate on the web. (Possibly quickly.) And that's really what people want Plone for. And it tells people what Plone is even better than an elevator speech. So, yes, I think explaining that Plone helps you communicate on the web is an good thing to communicate. On the web. :) -- 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 [hidden email] http://lists.plone.org/mailman/listinfo/evangelism |
spaley
|
Hey Chris,
Thinking more about this though, who does WPD target? Are we trying to target those who don't have any idea what a CMS is? Scott On Wed, Mar 11, 2009 at 12:04 PM, Chris Calloway <[hidden email]> wrote:
-- Scott Paley | ABSTRACT EDGE Office: 212.352.9311 Direct: 212.352.1470 Fax: 212.352.9498 Website: http://www.abstractedge.com Blog: http://www.brandinteractivism.com _______________________________________________ Evangelism mailing list [hidden email] http://lists.plone.org/mailman/listinfo/evangelism |
||||||||||||||||
|
Chris Calloway
|
On 3/11/2009 1:35 PM, Scott Paley wrote:
> Thinking more about this though, who does WPD target? Are we trying to > target those who don't have any idea what a CMS is? That's a good question, Scott. I was just trying to help Roberto clarify what he wants from suggesting we rename WPD. I will say, that the WPD event my user group held last year only attracted people who already knew what a CMS is, already knew what Plone is, and, well, were already using Plone. I don't think that was a good use of our time. It was fun seeing everybody. But it wasn't a good use of department time during business hours on a work day. Part of that was, Plone is already marketed to death in my area. It's been very visible since the beginning here and we've trained just about everybody who is a candidate for Plone training here. There are commercials for Plone on the local public radio station here, ferpetessake. There was also non-profit here that was making free Plone sites for just about any other local non-profit that wanted one right from the beginning of Plone. So everybody here has had a Plone site at one time or another and they're mostly kind of over it now. There have also been some monumental Plone and Zope project failures and unmet expectations due to Plone over-marketing in my neck of the woods that have given Plone a bad name in many quarters around where I live. It's very hard to market Plone here to anyone who knows what content management is because they have X number of Plone horror stories to draw upon already as their main knowledge of what content management is. So I can't really say what would be good for your area. But in my area, about the only people left to market Plone to are people who don't know what a CMS is yet, but who may need one. And I'm not sure if I'm ready to manage the expectations of people in that category, given past experience. -- 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 [hidden email] http://lists.plone.org/mailman/listinfo/evangelism |
||||||||||||||||
Calvin Hendryx-Parker
|
On Mar 11, 2009, at 2:52 PM, Chris Calloway wrote: > There have also been some monumental Plone and Zope project failures > and unmet expectations due to Plone over-marketing in my neck of the > woods that have given Plone a bad name in many quarters around where > I live. It's very hard to market Plone here to anyone who knows what > content management is because they have X number of Plone horror > stories to draw upon already as their main knowledge of what content > management is. 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. Cal -- S i x F e e t U p , I n c . | http://www.sixfeetup.com Phone: +1 (317) 861-5948 x602 [hidden email] ANNOUNCING the first Plone Immersive Training Experience | Sept. 10-11-12, 2009 http://sixfeetup.com/immerse _______________________________________________ Evangelism mailing list [hidden email] http://lists.plone.org/mailman/listinfo/evangelism S i x F e e t U p , I n c . | "Nowhere to go but open source"
Midwest: +1 (317) 861-5948 x602 Toll-Free: 1-866-SIX-FEET mailto:calvin@sixfeetup.com http://www.sixfeetup.com | Zope/Plone Custom Development |
||||||||||||||||
|
Chris Calloway
|
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 [hidden email] http://lists.plone.org/mailman/listinfo/evangelism |
||||||||||||||||
|
Jan Ulrich Hasecke-2
|
Am 12.03.2009 um 02:06 schrieb Chris Calloway: > > This is why I don't have a blog. :) This is all so true. I cannot add anything. All said! I hope that these who are concerned read this list. juh _______________________________________________ Evangelism mailing list [hidden email] http://lists.plone.org/mailman/listinfo/evangelism |
||||||||||||||||
Dylan Jay
|
In reply to this post
by Roberto Allende
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: [hidden email] > [mailto:[hidden email]] On Behalf Of Chris > Calloway > Sent: Thursday, 12 March 2009 12:07 PM > To: [hidden email] > 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 > [hidden email] > 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 > > _______________________________________________ Evangelism mailing list [hidden email] http://lists.plone.org/mailman/listinfo/evangelism |
||||||||||||||||
Alexander Limi
|
In reply to this post
by Chris Calloway
On Wed, 11 Mar 2009 18:06:57 -0700, Chris Calloway
<[hidden email]> wrote: > But I can *categorize* some of the main problems on this list, starting > with the aforementioned case and some others like it. Thanks for the email, Chris! We're hearing you loud and clear, let me make that absolutely clear. I'll try to keep it short instead of addressing every single point in your email: - The problem of bad consulting companies is a complex one, and we are acutely aware of it. We are doing something about it, but since it's a sensitive issue, we have to keep it somewhat confidential. Posting "avoid company X, Y and Z" on the Plone front page is not how we operate. ;) - I agree 110% that Plone is too big, too complex, and with too many ways to do things. That's why the main goal of Plone 4 is approachability, simplification, and getting rid of code. That's why Plone 4 is "done when it's done", and Plone 3 development continues in parallel, so we can get it right. That's why instead of documenting every insane nook and cranny, we're getting rid of most of them and simplifying everything. - I agree, you shouldn't have to hire a company/consultant to do any of the following: - Create new types - Create a new theme - Do sophisticated layout - Deal with rich media content …etc. We hear you loud and clear, and Plone 4 *is* a revolution. It's not evolving what's currently there. It's getting rid of as much of the insanity as possible, and optimize for the things people want to do during day 1, week 1 and month 1 of their Plone experience. On the upside, I do think people have become better at saying "use Django" or even "use Drupal/Joomla" when the use case doesn't fit what Plone does well out-of-the-box. The community is much more mature these days, and really doesn't want people to use Plone come hell or high water. It's a natural evolution of any open source project — in the beginning, it wants to be all things to all people. Plone now knows exactly what it wants, but that means we have to shift the focus a bit, and get rid of some baggage and simplify. Finally, let me commend you all in TriZPUG for your excellent work in everything related to Plone. You all do amazing work, and don't get nearly enough recognition for what you do. PS: Shoot me an email if you want to do a phone call, I'm happy to speak about the more sensitive details on the phone, but I think it's inappropriate to do so here on the list. :) -- Alexander Limi · http://limi.net _______________________________________________ Evangelism mailing list [hidden email] http://lists.plone.org/mailman/listinfo/evangelism |
||||||||||||||||
Karl Horak
|
In reply to this post
by Chris Calloway
In Albuquerque, we've never had more than a Plone Users luncheon or happy hour. We took a baby step last year by using WPD to hold a Python/Zope/Plone open house. Our corporate daily newsletter gave us a paragraph to explain that we were discussing content management and web solutions to a variety of problems. Our attendees were most of the local Python community and many from the corporate web group. Only when someone arrived did they then learn that the event was a WPD one.
This year we're going to expand our outreach into the broader community, involve other Plone shops, and see how it goes. I like the idea that Plone is "quick web communication." I also think we'll emphasize the intersection of web content management, social software & collaboration, and enterprise portal capabilities. If you explicitly promote WPD, I think you must be prepared to immediately follow that up by answering the question, "What the heck is a Plone and why should I care?" We dodged that by calling the event one thing and using WPD as the motivation, rationale, and the international "glue." -- Karl
|
||||||||||||||||
|
Dylan Jay
|
In reply to this post
by Alexander Limi
Hi,
One thing highlighted in Chris's recent post was about positioning. This is a problem we've personally faced in our company. We promote plone as an enterprise solution but the plone community itself doesn't. It's all very well us promoting plone but unless we have a clear message of what we are promoting plone as, people don't remember it. This was highlighted at a recent CMS smackdown event at a local users group that we presented plone at [1] There is a local proprietary system called communitymanager and it compares favourably to plone from the demo we saw. They had an interesting slide with a graph of CMSs and where they are positioned relative to cost and "enterprise-ness". (I think it's slide 7 from [2] but it doesn't open so well on open office). What's interesting is that Plone is completely missing and Alfresco is labelled as costing nothing and enterprise. We all know that's rubbish but their slogan is "THE open source enterprise CMS" (clever people, they saw the gap and took it). You can see in our presentation how we try to present Plone [3] My question is, where would you put Plone on that graph? And should we accept we need to position plone more clearly? [1] http://sbtug.com/2009/03/presentations-from-our-25-feb-2009-cms-smackdown-now-available/ [2] http://cid-6085fcdbc00a4c4f.skydrive.live.com/self.aspx/Public/SBTUG/2009-February/CMS-Smackdown-Elcom.pptx [3] http://cid-6085fcdbc00a4c4f.skydrive.live.com/self.aspx/Public/SBTUG/2009-February/Plone%20the%20open%20development%20enterprise%20CMS.ppt --- Dylan Jay, Plone Solutions Manager www.pretaweb.com tel:+61299552830 mob:+61421477460 skype:dylan_jay _______________________________________________ Evangelism mailing list [hidden email] http://lists.plone.org/mailman/listinfo/evangelism |
||||||||||||||||
|
Karl Horak
|
Dylan,
I think the subway map has the right of it: Plone is at the confluence of open source, enterprise CMS, social & community CMS, and web publishing CMS. Plone is the only one occupying those three subway lines (four counting OSS). At my day-job, we have a very small web team handling dozens of sites for a center with 280+ staff. We can't be experts at WordPress, SharePoint, Plone, Drupal, Joomla!, CommunityManager, and whatever soup of the day hits some manager's fancy. We need to have a generalized toolset that's very, very customizable so that we can use that toolset very effectively to solve a huge host of problems. Plone-Zope-Python with a heavy dose of CSS is that toolset. Plone leverages our investment in training and experience by letting our web team produce community collaboration sites, multi-language sites, embedded blogs, wikis, & discussion areas, and just plain static websites. Reducing the webmaster/developer role as much as practical lets content owners really own their content. Top that with a security and workflow model that PHP-based systems can't approach and you can see why we use Plone in our particular environment. What I see then is Plone wearing several hats. In my situation, I need lots of hats but I don't have time, staff, and funds to become expert at an entire hat rack full of different styles. I need secure, flexible, reliable, open source CMS technology that is based on a limited but powerful toolset. -- Karl
|
||||||||||||||||
Ross Patterson-2
|
In reply to this post
by Dylan Jay
It seems that a lot of the things we can improve on in our community can
trace their origins back to messaging. Witness Chris Calloway's observations regarding damage to our reputation from consultants trying to solve any and every problem with Plone and poor expectations regarding how much adopters should expect to have to engage the services of consultants. Witness the confusion regarding whether Plone's sweet spot is an enterprise CMS or a small organization CMS (I think it may be both, but we're not good a communicating how that is). Witness the oft cited expectations problems with the 2.5 release and the pain I now feel about the surrendering already established expectations about the 4.0 release. Witness the framework vs product debate. We're now targeting the notion of Plone Base and Plone the Product and a Plone API but are we going to do enough to communicate what that means to the far reaches of Plone communities? I know that I and others appreciate the openness, democracy, and introspection in Plone communities that allows us to be honest about how the glass is half empty but regret that more isn't done to share and express how the glass is half full. It also seems that our marketing story could be significantly improved with a better shared understanding of the various different messages we'd like to get out there. To be sure, I like the decentralized and democratic character of Plone communities and I don't in any way suggest we sacrifice that. I do think, however, that there's a lot we can do in the way of instilling sufficient messaging discipline without sacrificing those qualities. Bringing good release discipline by canonizing a release manager, for example, has been a huge win for Plone user experience without sacrificing the openness of Plone development. I think appointing a "Messaging manager" would be a bad idea, I only cite that as an example of how discipline can be improved without sacrificing openness. I know the PSPS did a lot to address messaging in the Plone world. I wonder, however, if recently we're not once more drifting too far from sufficient messaging discipline. It seems likely such drift is bound to recur without some sort of somewhat central institution concerned with discipline. I don't think control is necessary here. This is one of the great things about Plone communities. We respond well to a sense of shared mission. The value here would not be in policing, but rather in ensuring that we have a continuous dedication of resources to the matter of messaging. The mission might be merely to start the discussions that need to happen but aren't and to take the messages that come out of all relevant discussions and ensure their wide dissemination to the far reaches of Plone communities. It would also have to be a broad, rather than narrow, team with strong technical, marketing, and user voices to ensure integral messaging. Messaging like this can have a subtle effect that may become very powerful when compounded through shared understanding and repetition. So could a team be formed or delegated with the responsibility of reviewing Plone messaging? Would such an institution be a slippery slope to too much dogma or other stifling restriction? What might be some other ways to improve messaging in Plone communities? Is this an issue we're already addressing sufficiently and we just need to give it time? Is there a value to enshrining this process even if it's already happening? Is this not an issue? :) Ross _______________________________________________ Evangelism mailing list [hidden email] http://lists.plone.org/mailman/listinfo/evangelism |
||||||||||||||||
JoAnna Springsteen
|
> So could a team be formed or delegated with the responsibility of
> reviewing Plone messaging? Would such an institution be a slippery > slope to too much dogma or other stifling restriction? What might be > some other ways to improve messaging in Plone communities? Is this an > issue we're already addressing sufficiently and we just need to give it > time? Is there a value to enshrining this process even if it's already > happening? Is this not an issue? :) I believe that this is already being addressed with the work Gabrielle, Mark, et. al. have been doing. It's slowly becoming more and more visible (15 Questions, organized representation at events like NTEN & World Internet Expo, etc). While I'm not sure exactly who all is involved on the team, from what I've heard, there is a plan taking shape. I'm sure, like most of our teams, they probably need more help. Personally, I think one of the things that would help is a formal PR/Marketing/Evangelism contact so that any journalists looking to write about Plone or any press releases put out always have a representative to go to. Establishing a relationship with the such people can be very valuable when it comes to promoting events like World Plone Day or the Conference. Telling people to contact a mailing list just isn't enough (tho I think it should still be done so we have a record of such messages/inquiries). Establishing a leadership team for the doc team has helped us get organized and we operate much like the framework team. Having a recognized leadership for all of Plone's working groups might benefit from a guiding team? _______________________________________________ Evangelism mailing list [hidden email] http://lists.plone.org/mailman/listinfo/evangelism |
||||||||||||||||
|
Ross Patterson-2
|
JoAnna Springsteen <[hidden email]>
writes: >> So could a team be formed or delegated with the responsibility of >> reviewing Plone messaging? Would such an institution be a slippery >> slope to too much dogma or other stifling restriction? What might be >> some other ways to improve messaging in Plone communities? Is this an >> issue we're already addressing sufficiently and we just need to give it >> time? Is there a value to enshrining this process even if it's already >> happening? Is this not an issue? :) > > I believe that this is already being addressed with the work > Gabrielle, Mark, et. al. have been doing. It's slowly becoming more > and more visible (15 Questions, organized representation at events > like NTEN & World Internet Expo, etc). While I'm not sure exactly who > all is involved on the team, from what I've heard, there is a plan > taking shape. I'm sure, like most of our teams, they probably need > more help. > > Personally, I think one of the things that would help is a formal > PR/Marketing/Evangelism contact so that any journalists looking to > write about Plone or any press releases put out always have a > representative to go to. Establishing a relationship with the such > people can be very valuable when it comes to promoting events like > World Plone Day or the Conference. Telling people to contact a mailing > list just isn't enough (tho I think it should still be done so we have > a record of such messages/inquiries). > Establishing a leadership team for the doc team has helped us get > organized and we operate much like the framework team. Having a > recognized leadership for all of Plone's working groups might benefit > from a guiding team? I meant messaging in a sense larger than just marketing. I think we need to better communicate with and educate our communities of consultants, developers, and users regarding subjects other than just marketing and press. For example, what expectations should consultants communicate to technically minded clients about features in the next release? When a sysadmin and sometimes hacker at a non-profit gets excited about Plone and starts advocating for its usage internally, what will she have read that helped her set expectations that will guide her towards success? What will a consultant have read by the time they decide to start taking on Plone jobs to help guide ethical and successful consulting? If any of these people started or joined discussions on IRC, on the mailing lists, or at a conference, will the community members participating in those discussions have encountered enough queues about appropriate messaging? These kind of messages are not largely or exclusively technically, marketing, or user oriented. They require a cohesion of all concerns. Maybe I'm trying to be structural about something that shouldn't be addressed that way. It does seem, however, that this is a significant challenge for our communities. No? Ross _______________________________________________ Evangelism mailing list [hidden email] http://lists.plone.org/mailman/listinfo/evangelism |
||||||||||||||||
Matt Hamilton
|
On 6 May 2009, at 01:44, Ross Patterson wrote: > I meant messaging in a sense larger than just marketing. I think we > need to better communicate with and educate our communities of > consultants, developers, and users regarding subjects other than just > marketing and press. > > For example, what expectations should consultants communicate to > technically minded clients about features in the next release? When a > sysadmin and sometimes hacker at a non-profit gets excited about Plone > and starts advocating for its usage internally, what will she have > read > that helped her set expectations that will guide her towards success? > What will a consultant have read by the time they decide to start > taking > on Plone jobs to help guide ethical and successful consulting? If any > of these people started or joined discussions on IRC, on the mailing > lists, or at a conference, will the community members participating in > those discussions have encountered enough queues about appropriate > messaging? > > These kind of messages are not largely or exclusively technically, > marketing, or user oriented. They require a cohesion of all concerns. > > Maybe I'm trying to be structural about something that shouldn't be > addressed that way. It does seem, however, that this is a significant > challenge for our communities. No? I see what you are getting at here. I think one event that does do a lot for this is the Plone Conference keynote by Alan and Alex. Or the 'what coming up in release X' talks that Alex usually does. These generally focus on what is coming up feature-wise and I think do a lot to set expectations of what is coming up. Now I know that Alex is often (and I hope you don't mind me saying this Alex) quite ambitious in his visions for Plone in some of these talks, but I think that is a good thing. How that will now relate to the release manager type role I'm not sure. Ie. I think Hanno would be in a much better position to say what is or isn't upcoming. But I think Alex does a very good spokesperson (dare I say BDFL?) type role. Alex is doing something at the Plone Symposium East for this: http://weblion.psu.edu/news/alexander-limi-to-open-plone-symposium-east-2009 I think this is a great avenue for communicating the message to the community on where Plone is going. As for how we can do more of this and a more cohesive message across other mediums and forums... good question ;) -Matt -- Matt Hamilton [hidden email] Netsight Internet Solutions, Ltd. Understand. Develop. Deliver http://www.netsight.co.uk +44 (0)117 9090901 Web Design | Zope/Plone Development & Consulting | Co-location | Hosting _______________________________________________ Evangelism mailing list [hidden email] http://lists.plone.org/mailman/listinfo/evangelism |
||||||||||||||||
Hanno Schlichting-3
|
Matt Hamilton wrote:
> On 6 May 2009, at 01:44, Ross Patterson wrote: >> These kind of messages are not largely or exclusively technically, >> marketing, or user oriented. They require a cohesion of all concerns. >> >> Maybe I'm trying to be structural about something that shouldn't be >> addressed that way. It does seem, however, that this is a significant >> challenge for our communities. No? > > I see what you are getting at here. I think one event that does do a > lot for this is the Plone Conference keynote by Alan and Alex. Or the > 'what coming up in release X' talks that Alex usually does. These > generally focus on what is coming up feature-wise and I think do a lot > to set expectations of what is coming up. Now I know that Alex is often > (and I hope you don't mind me saying this Alex) quite ambitious in his > visions for Plone in some of these talks, but I think that is a good > thing. I have been sitting with a big smile in my face in all keynotes I attended, knowing that half of what our founders where talking about was not to be taken too seriously ;) I think we do have two types of messaging going on here. One is the real marketing messaging to our customers. These better only promise features and directions that are based on some good ground, as in whatever is actually released or in late beta / release candidates. The other one is part of the community conversation about where we are headed. It's trying to build consensus or set expectations on where we should go. The keynotes do have a bit of both, but a talk from Alexander about the Future of the Plone UI is pretty much completely in the later scope. Another aspect of these internal conversations is also to attract people to the idea. If you have an idea that you cannot technically or time-wise implement, you need to market the idea to the community, so it is on the one side accepted as something we should do but on the other hand you also need to attract someone who wants to do it for you. Thanks to our open discussion nature we do have the conversation about what to do next in the same open way as everything else. If an outsider mistakes these as factual promises on some deliverables he has a bit more to learn about Open Source. What you can count on is what is released in a final version. This holds true for commercial vendors in the same way, which might remove a feature from a late beta release. The added value you get in Open Source is that you can see the debates about the future direction, which in many commercial solutions will be hidden behind the doors of some meetings. And you can even engage and try to change these directions. The abstraction-loving German in me sometimes wants to structure these things and appoint people, get clear responsibilities. But so far I failed to see any way that could be done or would be useful for this particular challenge. Hanno _______________________________________________ Evangelism mailing list [hidden email] http://lists.plone.org/mailman/listinfo/evangelism |
||||||||||||||||
|
Dylan Jay
|
On 06/05/2009, at 7:18 PM, Hanno Schlichting wrote:
> Matt Hamilton wrote: >> On 6 May 2009, at 01:44, Ross Patterson wrote: >>> These kind of messages are not largely or exclusively technically, >>> marketing, or user oriented. They require a cohesion of all >>> concerns. >>> >>> Maybe I'm trying to be structural about something that shouldn't be >>> addressed that way. It does seem, however, that this is a >>> significant >>> challenge for our communities. No? >> >> I see what you are getting at here. I think one event that does do a >> lot for this is the Plone Conference keynote by Alan and Alex. Or the >> 'what coming up in release X' talks that Alex usually does. These >> generally focus on what is coming up feature-wise and I think do a >> lot >> to set expectations of what is coming up. Now I know that Alex is >> often >> (and I hope you don't mind me saying this Alex) quite ambitious in >> his >> visions for Plone in some of these talks, but I think that is a good >> thing. > > I have been sitting with a big smile in my face in all keynotes I > attended, knowing that half of what our founders where talking about > was > not to be taken too seriously ;) > > I think we do have two types of messaging going on here. One is the > real > marketing messaging to our customers. These better only promise > features > and directions that are based on some good ground, as in whatever is > actually released or in late beta / release candidates. > > The other one is part of the community conversation about where we are > headed. It's trying to build consensus or set expectations on where we > should go. The keynotes do have a bit of both, but a talk from > Alexander > about the Future of the Plone UI is pretty much completely in the > later > scope. Another aspect of these internal conversations is also to > attract > people to the idea. If you have an idea that you cannot technically or > time-wise implement, you need to market the idea to the community, > so it > is on the one side accepted as something we should do but on the other > hand you also need to attract someone who wants to do it for you. > > Thanks to our open discussion nature we do have the conversation about > what to do next in the same open way as everything else. If an > outsider > mistakes these as factual promises on some deliverables he has a bit > more to learn about Open Source. What you can count on is what is > released in a final version. This holds true for commercial vendors in > the same way, which might remove a feature from a late beta release. Persoanly I think that there isn't an issue with the messages about future features of Plone. There's some fantastic ideas going into the new version and some great people working on it, as well as many leasson learned. I think perhaps what isn't working well and what Ross means by messaging is communicating what Plone is now. We all understand it because we're Plone experts but others wanting to engage with Plone don't have that advantage. The hardest message to get out is what Plone is to people who don't know its details. For instance to developers who haven't used a CMS, or who are familar to other CMSs. To explain it business managers, or goverment strategists, or NGO CTO's. These people typically don't have much time but need to make decisions to take further steps toward Plone or toward a competitor. Perhaps we need single, simple, effective yet truth messages about Plone. Messages that are repeated in marketting material, web content, documentation etc. But thats really hard to do, even by paid professionals. Its also hard to do when picking one message might upset members who see Plone differently. Unfortunatly many messages and opinions make for a confused message which is just too hard work for outsiders to decipher. But it's important for us to try right? _______________________________________________ Evangelism mailing list [hidden email] http://lists.plone.org/mailman/listinfo/evangelism |
||||||||||||||||
|
Alexander Limi
|
In reply to this post
by Matt Hamilton
On Tue, 05 May 2009 23:41:55 -0700, Matt Hamilton
<[hidden email]> wrote: > Now I know that Alex is often (and I hope you don't mind me saying this > Alex) quite ambitious in his visions for Plone in some of these talks, > but I think that is a good thing. :) That's spot on, my role isn't always to be correct, it's to show what potential we can realize if we do certain things, and why we want to do it. I know very well that a lot of the stuff we talk about ends up landing in a later release — but I have stopped worrying about scheduling. We've been at this for 8+ years, we have some of the best people in the business working on our product, and a healthy, fun community. That's what counts, and why I'm not worried. > How that will now relate to the release manager type role I'm not sure. > Ie. I think Hanno would be in a much better position to say what is or > isn't upcoming. But I think Alex does a very good spokesperson (dare I > say BDFL?) type role. I'm probably the de facto BDFL these days, backed up by Hanno, Martin, Laurence et al on the technical front, which I think is a good solution too. The vision for the product and the user experience is something that lends itself to a small group, technical leadership within a certain domain is easier to distribute. And I certainly think the structure we have now with release manager (with veto powers ;) + framework team is a really good solution. Even Mozilla is interested in how we do these things, and whether there's something they can learn from it. > Alex is doing something at the Plone Symposium East for this: > http://weblion.psu.edu/news/alexander-limi-to-open-plone-symposium-east-2009 And Geir is doing a similar talk at the European Symposium. It will also be the main focus of the Plone Conference 2009 talk, so it's good that we have these events a few months earlier to refine and update the message. > I think this is a great avenue for communicating the message to the > community on where Plone is going. One thing we could probably do better is to communicate this outwards. There's been a resurgence of interest from the press in Plone lately, so I'm hoping to get this stuff published in publications outside of just the Ploniverse too. -- Alexander Limi · http://limi.net _______________________________________________ Evangelism mailing list [hidden email] http://lists.plone.org/mailman/listinfo/evangelism |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
