juillet 24th, 2009
Why I am leaving Plone
After a long long time working (and beeing very happy to) with Plone, I’ve decided a few months ago to leave the boat. Why? Here’s the whole story.
The rise of Plone
I started working with Zope in 2000, and I was immediately impressed by its strengh. Dude, that was nine years ago. I even wrote some books about it, as it lacked documentation by this time. Plone was brought to my eyes in mid-2002 by my old-time friend Kamon Ayeva. Then I began working heavily with Plone as a developper and contributed a few modules.
Plone 1.0 came out in 2003 and had a tremedous effect on the rising sun of CMSes in Planet Earth. Wow. Such a wonderful package, and as was said by Mike Sugarbaker in OSCON 2002 :
I won’t do the complete rundown of all the « competing » open source content management frameworks. I’ll cut to the chase : the winner is Plone. The package with the most tools, the most professionalism, the most traction, and above all, the most buzz.
Then went great times. Big companies joined the boat, small companies arised (especially here in France) and started to organize. Pilot Systems and Ingeniweb were the two major competitors in France for Plone, but many other small businesses joined in. Pilot and Ingeniweb both had prestigious customers, such as large industrial companies, banks, etc. Plone was a success for, IMHO, the following reasons :
- Open-source : openness was becoming a strong trend back in 2003 ; as such, many companies started to turn to open source software providing a professionnal service.
- Technology advance : Plone was one of the rare serious (open-source) CMSes by these times and provided in an integrated package some powerful features it was difficult to find somewhere else : MS-Office indexing, LDAP integration, components architecture, SEO, Cache efficiency.
- The big CMS time : by this time, there were not so many widely used CMS software. My grandmother wasn’t aware of Internet Power (well, in fact she was dead). Blogs were run by techies and were not as popular as in 2006. We were in year 2 before S.B…
We gained marketshare over big CMS companies such as Documentum. Even CA showed a strong interest in Plone and contributed to the Plone Foundation creation.
Then we missed something.
2006/2007 : Maturity
By 2006 I stopped developping with Plone and became more into python teams management and commercial activites. Plone was easy to sell for us at Ingeniweb : we had a tremendous experience on what customers needed as an added value from the « out-of-the-box » product. In fact, most customers always wanted the same things over the out-of-the-box product :
- Plone essentially as an intranet ;
- LDAP integration ;
- Nice user interface / skin design ;
- Powerful search engine indexing MSWord / PDF documents ;
- Workgroups ;
- Large file storage (which required additional products because it was inefficient in ZODB).
That’s the time I should have noticed something were becoming wrong. Although we had a great experience of those custom installation, and although customers needs were often the same, we always had to do custom installations each and every time, which involved a lot and a lot code to do.
Plone was there a mature product we had very good time working with, but my teams started complaining about the refactoring maniacs in Plone and the updates-that-break-everything trend. I didn’t pay too much attention.
Oh, and by the way, the last sign of life we get from CA’s Plone-based Brightstor Document Management is somewhere in 2005. But we had great successes in deploying large intranets. Wow.
Plone’s future was promising : it was said by those times that Plone would gain an enormous benefit from using Zope 3 instead if Zope 2 (Zope 3 was talked about since at least 2002). Performance was also something to improve.
2008 : Missing the step
In 2008 I started to think we should find alternatives to Plone. We began loosing some contracts, and with time I think the reasons were simple.
CMS were widely spread in 2008. In 2003 it was a niche market but in 2008 many companies, small or big, offered those services, and the price-to-pay for a CMS decreased dramatically. That’s something we didn’t figure out at this time.
Plone was state-of-the art back in 2003, and as it was then widely accepted that it was based on a not-well-known language and ran on a less-than-well-known platform (Zope). I won’t argue about the strengh of Python (which I love) and Zope 2 (which is now too anti-MVC for me to keep it as a viable solution for my projects). But, hell, we were in 2008 and LAMP solutions were widely accepted even by large organizations. Although it was an advantage 5 years before, edge technology made Plone harder to sell. Many people involved in Plone didn’t understand that and there were some big fights in my company against PHP. PHP was shit. PHP was brainfuck. PHP was hell. Python was THE rule, Python was for Internet what C’s been for Unix. Yeah… but sometimes, to sell to the masses, you have to listen to them just a tiny bit – and we missed that. Which major hoster provided a Zope / Plone hosting service ? None. Which hoster provided a PHP hosting offer ? All of them (even at Ingeniweb we had some PHP stuff running ! But, hush, that’s a secret).
One of the major inconvenience of using an edge technology was that it was difficult to find developpers. Plus, when you’d find a Python programmer, you’d have to train him to Zope, then train him to Plone. And it is impossible for people with average developpment skills to program Plone. The learn curve is tedious (have you noticed how the Plone Conf 2009 logo looks like a Plone learning curve, by the way ? even the falldown is there !). But it’s difficult having people who masterize both programming and HTML/CSS integration. Hence the failure : we had a lot of programmers, writing PROGRAMS instead of WEB SITES. And when you look at Plone as it is today, you notice it’s really the major error for it : Plone people are programmers, not web people. Remember the early success of Plone ? Limi was an UI guy, not a programmer. We’ve lost that. Now, Plone people code because they love to code. In my company, doing a roll-down menu was a pain for all the guys. No one seemed to be able to build a site that was working with IE6.
Also, using an edge platform, Plone was very dependant of it. The future of Zope became at one point linked to the future of Plone (Paul Everitt saying that Plone was the « killer app » of Zope). But when you look at the Zope history, you cry… Zope 3 was full of promises, it was Zope 2 advantages without Zope 2′s defaults. And Zope 3.0 came out in fall 2004. In late 2009, Plone is still using Zope 2.x ! When I think about Five, things become more funny. Five is Zope 2 + Zope 3 : a way to use Zope 3 features with Zope 2 architecture. Plone architecture is a layer cake, with criptic pathes everywhere. It’s so layered that there are so many ways to do just one thing… Wait, that reminds me of a language Python programmers love to hate ! So, when you think about our programmer, he has to master :
- Python (of course)
- Zope 2
- The concepts of Zope 3
- Five’s way of integrating Zope 2 into Zope 3
- Plone 3.x
- Plone 2.x because many things are still done the Plone 2 way instead of the Plone 3 way
Now, do you understand the learning curve ? And do you understand that there’s not too much room for HTML/CSS advanced skills ? How much time must a newbee spend to become a Plone 3 master ? Plone’s architecture evolution is the exact contrary of Python’s way of evolving. Well, hopefully, some people understood that and started adding a new layer (once more) to integrate great Python concepts : eggs and so on. So you have now to master one more layer, distutils, to install a simple product into Plone. Nuxeo understood this back in 2006 when they decided rewriting their ECM suite from Zope to Java. We laughed at them by this time, thinking they would never succeed, but they did – and they did it well. We though Zope was the ultimate web framework. Instead, Zope was becoming older and older. Zope 3 promises remain unfulfilled by this day.
When I started writing this article, I drawed a simple timeline to explain why I were leaving Plone. Here it is. I didn’t invent anything, it comes from the official release timeline.
Ok, now do you notice something special ? Yes : no major feature added since mid-2007 (that is, the prehistoric times). By no means people stopped working on Plone core ! They did. They refactored some code, leading developpers to learn new layers as well as old layers. Then they refactored more, developpers had more to learn. Then they refactored more, loosing interest from everybody. Developpers are now fed up with this refactormania.
Then, last but maybe most important thing : as a specific designed product, with a nearly underground framework, Plone ignored competition. Both « buzz » and features became more important with other products such as Drupal, Joomla! or eZ-Publish. Yeaaaah, I know, those products are full of defaults and Plone is nearly perfect – no kidding, I was considered as a fucking bastard when I tried to introduce Plone alternatives in my company. But still. Look at cruel, raw facts. See this drawing there :
Can you see this blue line hitting the ground? That’s Plone’s popularity. And, if you wonder, yes : Plone’s popularity is decreasing.
Wait ! There’s even more fun stuff. See that ? Plone is now as (un)popular as SPIP. What a shame.
Today : thank you and goodbye, guys !
As of today, Plone is seen by many as a black box with magic inside. Sometimes the magic works and it’s nice, sometimes it doesn’t and you have to spend several years in Harry Zopper’s sorcerer school to understand why it doesn’t work and how to fix it.
Plone is full of « proprietary » (I mean, not widely spread nor supported) software. Zope. ZODB. Even Kupu, the visual editor, is poorly spread (plus has a stupid name). Python is the only great thing about Plone as of today.
No matter how you put it, Zope is slow. Can’t believe me ? Click this and have a coffee.
Plone’s future is pityful. Look at this great news item from Pilot Systems. Want to know what’s the future of Plone ?
- Refactoring, refactoring, refactoring ;
- Getting rid of the past errors (Kupu => TinyMCE – at last !)
- Getting the modernity train (new skin, blob support – at last)
- Some more stuff to learn (tiles / deco, dexterity vs. archetypes, Chameleon, Queryplan, …)
Were are the new features ? Hidden.
Where are the solutions to the learning curve problem ? Hidden, as well ;)
For all there reasons, I’m not part of the game anymore.
I’ve used Drupal, eZ and Joomla! and I’ve found that those communities were well-organized. I’ve also found that :
- Installing a product could be as simple as untaring a file ;
- Deploying a site didn’t require to know 8 frameworks ;
- Designing a skin was as simple as integrating HTML+CSS into a set of files (Delivrance is such a big joke by the way) ;
- There was ONE WAY to do things well, and this way was obivous ;
- There were many quality extensions to those products.
I’ll miss Plone for edge Intranet projects with important security requirements.
I’ll still be using Python for other projects – you can’t quit Python as easily :)
I’ll still keep in touch with Plone companies such as Ingeniwebalterwaysolutions or Pilot Systems with respect. Those two last years, Pilot did a far better job than Ingeniweb at promoting Plone – and it’s important they did it. But it’s funny to see that both companies are now moving towards different directions beyond Plone. Just like, back in 2006, Nuxeo waved away from Zope.
I’ll miss 2006′s Plone strength, but you can’t always rely on the past. Many CMSs has been (and are still) moving fast, but Plone stayed immobile, just re-re-re-painting blinds.
I think you make some good points, particularly about Plone’s complexity, which is something that I believe the Plone developers are very well aware of.
While I am not a contributor to Plone, I am in part to blame for this (indirectly) as I originally came up with the Five technology. Applying this tremendously increased the complexity of Plone as now there are multiple ways to do things. On the other hand, it’s hard to imagine another route for Plone to take that would’ve been easier – it has to be developed incrementally and that’s going to mean rough spots. Evolving a complicated application like Plone is very very difficult, and it’s to the credit of the Plone developers that they can keep it moving forward like they are.
But there are also some cheap shots in your article. Pointing to http://www.zope.org‘s products page to demonstrate that « Zope is slow » is a very silly example to take, as you should know very well. The zope.org site is outdated and practically unmaintained. That’s the Zope community’s shame, of course, and would be a legitimate criticism, but a slow web page hardly demonstrates that Zope is slow. It’s as easy to write an unscalable application with Zope as with any other technology.
Another cheap shot is your criticism of the presentation you reference. You say Zope is slow, and you seem to ignore all the slides that talk about increasing Plone’s performance. You say there are no attempts to decrease the learning curve, and I see a whole section about simplicity, reducing the size of the codebase, and a tiling based UI, and a section on approachability which describes dexterity. From this, I’d say one of the major goals for Plone 5 is to decrease the learning curve! Making it easier (again) to customize and develop with Plone sounds to me like a major feature in itself…
It’s fine to disagree with the specifics of those directions, of course.
I realize that you are fed up with Plone and you need to distance yourself with it. That’s fine. But that doesn’t mean you have to fire off cheap shots at what you leave behind.
>> I am in part to blame for this (indirectly) as I originally came up with the Five technology.
Well I don’t think that five is stupid « per se ». I’m just blaming the fact that Zope 3 never really came close to reality. Five is not such a bad idea, it’s the fact that it had to be written that should be noted.
>> Pointing to http://www.zope.org’s products page to demonstrate that “Zope is slow”
>> is a very silly example to take, as you should know very well.
You’re 100% right :) It was quite provocative :) But for the same architecture and the same needs, I think Zope is slower than Ruby or WordPress for example. In the other hand, Zope is more scalable – that’s true.
>> Another cheap shot is your criticism of the presentation you reference.
>> You say Zope is slow, and you seem to ignore all the slides that talk about increasing
>> Plone’s performance. You say there are no attempts to decrease the learning curve,
>> and I see a whole section about simplicity, reducing the size of the codebase,
>> and a tiling based UI, and a section on approachability which describes dexterity.
>> From this, I’d say one of the major goals for Plone 5 is to decrease the learning curve!
>> Making it easier (again) to customize and develop with Plone sounds to me like a major feature in itself…
You’re absolutely right, BUT…
- http://plone.org/events/conferences/2008-washington-dc => Martin’s talk was already focused about code simplification
- http://www.coactivate.org/projects/plone-conference-2007/presentations/adding-super-powers-to-plone.pdf => Already mentionned performance problems – in fact, performance is a recurring matter since several years.
That’s what I want to point out: the issues that arised a few years ago lead to many changes in architecture, but were not (for many) really solved as of today.
Ruby’s a language, not a web framework, and WordPress is not a web framework but a blogging system. I think comparing performance between a web framework (albeit a very odd one like Zope 2) with either of those is not really very useful. Python’s not slower than Ruby, for instance, and there’s no reason a Zope-based blogging system would necessarily be slower than WordPress.
As to the slow progress the Plone developers are making: I think that’s not because they’re lack of will or lack of activity (Martin I know has certainly been working on it for a while now). I think it’s because the extreme complexity of the task. It’s hard to move a platform forward at the same time juggling backwards compatibility and platforms. That’s not to say the Plone developers don’t make mistakes; I’m sure they’ll be the first to admit that they do.
Finally, performance and scalability is a battle that never ends. I’m sure they were talking about it in 2001 and they’ll be talking about it until the indefinite future.
Another note: Zope 3 didn’t quite become what people expected of it, but I’ve been using Zope 3 productively for years now and I know plenty of people beside me who do as well. Perhaps in its guise of Grok. But for successful existing software like Plone it’s risky, and difficult, to make such a transition – it’s easier when you write new code.
> In the other hand, Zope is more scalable – that’s true.
Could you elaborate on that?
The scaling bottleneck for most webapps is the database. I don’t see how Zope is any different.
I like how in the screenshot plone gets the red squiggly underline and the others don’t. Cute, that.
It’s clear that the best engineered solution is not often the winner. Joomla! I’ve myself been fiddling with drupal a lot lately, and that’s mess enough. But I also have at long last, with great sadness, pretty much given up on plone. Reasons are similar, though i’ve never used it as extensively. I think plone is still a really great solution for some people, and there are sill brave souls out there doing really cool projects around it. I really hope they catch on, and plone is elevated through them. But I haven’t got the time or energy anymore to support things at such low levels with so small a community.
I think the graph above underlines Zope’s (and plone’s) focus on zodb has not helped it triumph over systems that rely on the additional layer of an sql database. I might even argue that these php hack jobs which are so popular actually consider sql db integration as a selling feature… there’s more of a sense of data independence, and interoperability. Zope didn’t realize until it was pretty much too late the dangers of becoming a monolithic walled garden. Yet they still gather all their pretty egges around the central monolith of zodb.
@Tim
Well, let me put just one thing clear about popularity: I know Plone is less popular than some mainstream PHP stuff – there’s nothing much to do about it and it’s not a real problem.
No, the problem is Plone is loosing both relative and _absolute_ popularity: Plone is becoming less popular than before. Another hint: My Zope and Plone books sold well a few years ago, but sales plumetted in 2007.
You can’t juge a solution with it’s popularity, but the fact that people are loosing interest in it is something Plone team should really worry about.
So let me get this right. You wrote a book on Zope in 2003 in French and 6 years later you are not selling as many copies? Is that really a surprise?
I think you raise some good points here about complexity, but as you also point out the community is aware of the issues and is actively working on them. Geir’s presentation is basically the answer to your points.
-Matt
@Martijn Faassen
Then, maybe it’s about time to think about a whole Zope 3 Plone re-writing – just as Nuxeo did with their Java rewriting ? Such a decision would really, positively, impress me: instead of replacing layers by other layers, you would really start from a clean code base.
@Pierre-Julien Grizel
time to jump ship ? build the next plone on top of that : http://www.cubicweb.org/ and keep going with Python
FWIW, I’ve developped intranets, ECMS, around Plone, and now, using this, and it feels like that http://xkcd.com/353/
The zope/plone combo is so soul-crushing.
The sheer weight of Plone condemns it. Its reliance on Zope is the most embarassing thing and precludes any sane refactoring. (Zope developpers seem to think zope 2 was wrong because it was not correctly done … they do not agree on the fundamental mistake that is the object database). They could have rebuild it on top of django, pylons, whatever in less time it took them to not advance the framework in the past two years.
[...] This post was Twitted by emencia [...]
Have you looked at any of the Repoze stuff? BFG may perhaps be closer to what you’re looking for.
Sure refactoring a legacy system is hard. Drupal suffers from that too. Sure we could do it faster. Sure the learning curve for professionals using Plone has been hard. No one wants to go from being proficient and learn to do things in new ways. We’ve all been through that pain. Drupal also went through that.
Plone has lost some developers in this transition and php CMSes have gained new ones more easily due to barrier to entry for hosting and general greater ground swell and evangelical attitude. We’re working on that too.
But Plone still has a great UI, good model and features that still put it out ahead. Exactly which features do you think are missing?
Using the same tool, you could conclude that PHP and Java are becoming less and less popular
http://www.google.com/trends?q=python%2C++php%2C+ruby%2C+java&ctab=0&geo=all&date=all&sort=0
Time for them to jump off ship?
> My Zope and Plone books sold well a few years ago, but sales plumetted in 2007.
Maybe it stopped being relevant for developers when Plone3 came out.
Martin’s book was published in september 2007 and was the first to cover Plone3.
>Plone’s architecture evolution is the exact contrary of Python’s way of evolving. >… eggs and so on. So you have now to master one more layer, distutils,
This seems like a contradiction.
> Using the same tool, you could conclude that PHP and Java are becoming less and less popular
Yes, you’re right. PHP is becoming less popular. Frameworks (or CMS, for that matter) based on PHP are, however, becoming more popular. People don’t want to code bare naked PHP anymore. Is it a real surprise ?
> My Zope and Plone books sold well a few years ago, but sales plumetted in 2007.
My editor refused to have another version of the book, because they anticipated the fact that it wouldn’t sell well. They may be wrong, and maybe it’s just a french trend, but I’d be very curious to see sales figures on the other books.
> Plone’s architecture evolution is the exact contrary of Python’s way of evolving. [...] This seems like a contradiction.
What I meant is that Python core devs try to keep things simple. That’s not the feeling you have when you try to follow Plone evolution.
I do hope Plone 4 will go towards the right way : simplicity, efficiency (both for performance and extensibility). From what I’ve understood from the various feedbacks I had, that seems to be the way Plone wants to go – and that would be a very good thing. So I’m just going to wait ’till it happens.
Your points and criticism are constructive and useful in improving Plone… if it were 2006.
CHANGE VS. LEVERAGING EXPERTISE:
I think that all IT integrators have the eternal, internal struggle between wanting to leverage existing expertise as billable consulting services versus wanting to improve the platform being used. If you want to be able to continue to propose solid solutions to your clients, then the platform or software of choice needs to evolve and improve, as Plone has and is doing.
I feel your pain of having to learn new things to keep pace with the technology, rather than resting on what I know and being able to make a living from that knowledge alone, but alas, this is the world of technology. As others have said, the other platforms have run into the same issues.
PLONE IS A VERY WELL-RUN PROJECT:
One of the draws to Plone is that there is a migration/upgrade path from one release to another. The community is not about to ‘give the finger’ to the current install base (thousands of organizations) by doing a complete rewrite with no migration path and leave them in the cold without ongoing support options. Sure, with a complete rewrite you eliminate backward compatibility worries/code, but you also then eliminate your install base and community from which to draw development help.
HEALTHY INTEGRATORS MARKET:
You mentioned Nuxeo, and while I’m sure the software they’ve rewritten is probably great, but what are your options to hire an integrator? I see fewer than 10 integrators/partners listed on their site (only 2 of which I’m familiar with as being in North America), whereas Plone has 150+ integrators in dozens of different countries around the world.
Our team has been doing Plone implementations since pre-1.0 and we’re busier now than we have ever been, which is saying something.
If Plone were to be rewritten entirely, that might clean up the code base, but would surely eliminate some integrators who, like you, would rather leverage existing expertise than keep having to learn the new APIs, way of installing and configuring, etc.
And speaking of a Plone rewrite, hey, didn’t you already say you were frustrated merely by the Five library. What would your effort and frustration level be with a complete rewrite, and for a tool that would launch without any books on Amazon, etc.? There’s an abundance of nice software projects you could start using if lack of documentation and a support system/community is no worry for you.
Plone probably has more published documentation than any of the other open source or commercial CMS tools out there – for the content manager, the site admin, the add-on product developer, the sys admin, you name it.
PLONE IS SLOW?:
Well, a lot of things are slow ‘out-of-the-box’, and I’d agree that Plone is too, if you leave it without any tuning. The same is true of MySQL, for that matter. If you don’t care to leverage one of the alternative configuration files that ship with MySQL for larger databases, then have fun ;) Ask some of the commercial CMS vendors how your site would respond if you just launched it with all the configuration options you have when it’s first installed. I’ve worked with these tools as well. It would not be pretty, and by the way, you’ll usually be paying more in license fees if you need to cluster them to multiple Java app server instances and/or physical servers. You didn’t want fail-over, scalability, and redundancy did you? Oh, well that’s another $300K, thanks. RedDot by the way requires a Windows server for its .Net-based CMS and then runs on a Java app server for its portal/site delivery engine (which can run on Windows or *nix.) They all have their configuration issues that must be sorted out properly by someone who knows what they’re doing; Plone is no different there.
I think the main reason Plone does more churning than many other open source CMS tools upon a typical page request is due to a trade-off whose other side is very attractive to most of our clients – fine-grained permission checks and flexible, enforced workflow. When you hit a typical page in Plone, it dynamically determines which navigation, portlet, and other elements to present to your user account, as you probably well know. This comes at a cost.
Besides implementing squid or other front-end proxy/caching mechanisms that are widely mentioned for large Plone deployments, we’ve found that a very simple way to make Plone perform better is to create your public-facing site skin from scratch, rather than leveraging all the CMS-related widgets, such as the built-in navigation portlet, stack of CSS files, etc. Plone was built to be a CMS at and that’s true of the site skin as well. It just happened that the CMS skin/theme was nice enough to also be used on the site delivery side. Nobody says you MUST extend the default site skin as your site skin.
We have sites for motocross racing that appear on the CBS network in the U.S. each weekend during the winter and that get millions of requests/hour. We have 2-3 Zope instances in a cluster and simply have Apache with memory-based caching and load-balancing enabled, and this handles the load. Nothing all that fancy, really. And this is on Windows servers!
IN DEFENSE OF THE ZODB:
While some clients may want their content data stored in a relational/SQL database, simply because it ‘feels better’ and more decoupled (not true), or because they use Crystal Reports, Jasper Reports, or some other reporting tool they’d still like to use (valid), this doesn’t mean that an object-oriented database isn’t a good choice for a CMS.
I’d argue that it’s the best choice for a CMS and would point to Documentum (probably the most successful ‘Enterprise’ with a big ‘E’ DMS out there) as a pretty strong example. And following the Documentum model of using a OODB for operational CMS storage, while offering a (‘data pump’, I believe they call it) way of pushing the operational content/data out to a relational database for reporting.
For a Plone site, this option of pushing data out of the ZODB and to relational storage has always been possible, but now, you don’t even really need to write your own scripts to do it. Just install Content Mirror and go! There are only a half dozen conference presentations on using this approach, though.
THE BEAUTY OF OPEN SOURCE:
If you want to head up a Plone rewrite project, providing all the functionality that Plone and Zope provide, but base it upon some, more mainstream language such as Java or .Net, please be my guest. You’ll be able to hopefully learn from the experiences of the dozens to have tried. (See magnolia, daisy, opencms, lenya, uportal, phpnuke, and many more that still cannot offer close to what Plone does.)
INTERNAL CONFLICT:
You state that Plone/Zope is slow and that it’s difficult to develop for the platform, yet criticize the efforts that have come out of similar feedback over the past couple of years and you specifically criticize things such as deco and dexterity which aim to address such concerns. You can’t have it both ways. You either need to accept change and improvements, or the status quo. And nobody is preventing you from continuing to roll out Plone 2.5 sites, if you prefer to walk in place on a platform you’re familiar with and to not learn anything new, but of course you will miss out on new features that come to be, as with any software.
SILLY ANALYTICS EXAMPLE:
As for Plone’s popularity, simply typing terms into Google Trends is quite a misguided approach. I hope that you don’t consult your clients based upon such skimming-the-surface analysis. (For instance, in your search, did you consider that ‘ez’ is contained in completely unrelated products and topics, such as the ‘EZ Pass’ electronic tollway booths in the U.S., and the like?)
To play the same game, try comparing Plone’s popularity to other established commercial CMS tools on the commercial side, such as « RedDot, Ektron, Interwoven » or to « Vignette, Fatwire, Tridion ». I’m quite happy that Plone falls right inline with other established, yet still wildly popular CMS tools that can handle ‘enterprise’ type content management needs.
I understand that the Google Trends analysis gives equal weighting to pages related to $5-10/month hosting projects as it does to large organization/project requirements and needs, and that since the thrifty hosting shops include the option to install Drupal, Joomla, or WordPress, with the flip of a checkbox, but I don’t think that indicates which CMS tools are on the short list for organizations doing serious evaluation of things such as workflow, permissions, version control / audit trail /rollback, taxonomy management, standards/accessibility compliance, etc.
MARKETING OF PLONE:
I’m sorry to hear that Plone consulting business seems to have dissipated for you in your region.
I know that our firm was able to rest on its laurels for a few years and not do ANY advertising and just wait for projects to find us by word-of-mouth. Sadly, this lazy business model actually worked, and I believe is at the root of the lack of marketing of Plone (since it was true for any other Plone integrator I know of.) If you have more work than you know what to do with, what good is advertising and getting more, right?
Well, unfortunately, that isn’t a good business model for our firm nor for the Plone ‘brand’, and I think that’s more at the crux of what you’re trying to get at (with your Google Trends analysis.)
More recently been trying to be more active about marketing, not just of our firm, but of Plone, because I do agree that we, as the professional Plone integrators community, need to build up the buzz, reputation, and profile of Plone as a software tool, project, and community.
I think it’s true that Plone at-large has followed the same model in recent years (figuring that a quality product or service would stand on its own), but over the past year or so, the Plone Foundation has begun being more active in marketing, making sure Plone is represented at expos and conferences, etc. Let’s give this a little time to pay off dividends.
We were recently at a CMS Expo in Chicago, IL, USA, and this conference started out originally as a Joomla expo, so it has a strong Joomla following. As we demonstrated Plone at our booth, the Joomla folks watched in amazement and I have some Joomla-to-Plone converts (and projects) as a result. So, while Joomla is wildly popular, so is Internet Explorer, yet I wouldn’t call IE a superior browser. Joomla is just more available (through the cheap hosting plans, just as IE ships with Windows computers), and very easy to get into, and Plone *should* learn this lesson and I believe has/is.
So, I do agree with you that more marketing of Plone needs to be done, but I can’t agree that Plone needs a rewrite (for Zope3 or otherwise), that it shouldn’t address the approachability for site designers and should instead stand still, so people don’t have to learn new techniques, nor that Plone isn’t a healthy project with great market demand.
A RECOMMENDATION:
If you’re leaving Plone, because you’re frustrated by change, then I don’t think you’ll be happy in IT. Just ask the Joomla folks who used to work on/with Mambo, before the company that open-sourced the software had second thoughts and commercialized it again. Or ask the tcl programmers from Vignette of 10 years ago, before it was rewritten for Java. Or, just ask the Drupal folks who find it impossible to migrate all the little configuration tweaks they do through the web browser for their development/staging site and then need to promote those configurations to their live/public site (and who lack the portal_setup/Generic Setup tool that Plone provides to export such things as nice and neat little XML config files as well as who lack Zope’s handy-as-hell export-to-zexp feature to export content.) Someday, these Drupal programmers will need to learn some new technique that allows them to do the things we can already to in Plone.
This is a blog on the Internet and thus far, you’re still able to say just about whatever you want on it. But at the same time, when you basically just rant about many issues that have been or are being addressed, there are going to be people such as myself who feel inclined to defend what we believe to be a very in-demand, high-quality project and software tool, so I hope you’ll take to heart our comments as much as we’ve tried to do the same with yours.
Thanks for the opportunity to comment!
Ken
As someone who is new to Plone and is evaluating it for our CMS websites, i do recognize a lot of your emotions. There seems to be a clear decline in activity in the add-ons and documentation updates after 2006/2007, there are way to many different ways of doing the same thing, and it’s not clear at all what way to pick from all the possibilities. Also it seems that Zope/Plone is currently technology/framework driven, and not so much from a ease-of-use or development-speed point of view.
On the other hand, i must say that Plone is VERY easy to use for end-users, it has a very good UI. Much much better than the big PHP alternatives like Drupal, Typo3, EZPublish. In the end this is one of the most important aspects of a CMS system, you can have all the speed of development, power, MVC framework etc, but if the end-result isn’t easy to use for the end-users, you are nowhere.
Currently we’re still undecided to jump into Plone, or go the Java/J2EE way with Magnolia, which also is very powerfull and has good usability.
Anyway, thanks for your thoughts, maybe some Plone-time-off helps :)
Olaf
@Ken Wasetis
Well, many many thanks for your reply, one of the most argumented I’ve had so far. It’s nice to see somebody else’s point of view without too much of an emotional reaction.
Here are some random thoughts I had reading your reply:
CHANGE VS. LEVERAGING EXPERTISE: You’re right, but my feeling is that it’s more difficult with Plone to stay in line. It’s just a feeling – I know – but from what I’ve understood I’m not the only one to feel that :)
PLONE IS A VERY WELL-RUN PROJECT: About the rewrite (which is not a must-do in my eyes) : Why wouldn’t a complete rewrite make an upgrade path impossible? It’s just a matter of exporting content and importing it back – that would issue 90% of the migration? Anyway, has any real Plone integrator already had the feeling that migrating from Plone x to Plone x+1 was a smooth and peaceful thing? I mean, really? Isn’t that the reason why in the recent Plone changes we now can rean « non-invasive upgrades » ?
HEALTHY INTEGRATORS MARKET: It’s the only point on which I totally disagree with you, especially about Nuxeo. Look at this: http://www.nuxeo.com/nuxeo/partenaires/integrator/ => Logical, Cap Gemini, Thales and Steria are the 4 of the 5 leading IT companies in France (the last one beeing Atos) – look at the figures, they’re stunning, and they are all quoted in the main french stock market. And none of these IT companies provide Plone support, nor any company of this size.
However, about this point, it’s more of a marketing problem that a pure technical problem, but I really regret the fact that Plone has not too much acceptance among big integrators. That’s something the Fundation should work on – especially since CA left.
PLONE IS SLOW?: At last, somebody really going deeply into what I said :) I do agree with you: you can (and must) fine-tune Plone to make it run faster, we’ve done that every time and it was successful. What I regret is that this fine-tuning doesn’t come out of the box. You have either to spend time (or to pay somebody who knows) to tune your Plone installation everytime. And when you compare a bare-naked install, usually, PHP CMSes run faster prior to any tuning than Plone. It’s not an unsolvable issue, it’s just taking time and/or money.
THE BEAUTY OF OPEN SOURCE: I should build a functionnalty matrix of what other Open-Source CMS offer. Things are evolving pretty quickly, and now I know that for 90% of my projects I could find an alternative to Plone. It would be interesting to spot those remaining 10% because that could really make the difference – and Plone team has to « market » those 10% if it wants to grow.
INTERNAL CONFLICT: Well, I didn’t criticized Deco or Dexterity :) But, please consider a newcomer. Will he has to learn Dexterity or Archetypes? Delivrance? Deco? What is the future? What is the right way to do the right thing? This is that complexity that makes Plone look like a squid. Maybe stopping naming things would be a good way to stop loosing people into too much complexity :)
SILLY ANALYTICS EXAMPLE: On the detail you’re right (especially for EZ;)) but on the « gross weight » it does say something; And I was just mentionning that for popularity, not features of the CMS, of course.
Anyway, I didn’t invent anything, please have a look at this: http://www.waterandstone.com/downloads/2008OpenSourceCMSMarketSurvey.pdf and at CMS Watch reports (they’re not free, but they really worth the look).
Right, some of those CMSes don’t provide as much as functionnalty as Plone does. But if they are more popular than Plone, doesn’t that mean that people don’t really care about those extra functionnalities?
Maybe the Plone foundation should perform a deep audit of what is really necessary and what is not. And should ask Plone users and integrator what works for them and what doesn’t. For example… is anybody here 100% happy with Linguaplone?
MARKETING OF PLONE: Well, I left Ingeniweb for a while now, so I won’t talk about their marketing decisions (or lack of, for that matter). But I agree with what you say here: Plone has to be sexy for newcomers and decision-makers. The rewrite is not a real matter as long as simplicity comes back – I really feel like Plone can be 3x simpler (and then accessible) by removing old stuff and focusing on what is really promising.
A RECOMMENDATION: Well, thanks for the recommandation – reading some comments gave me hope :) I say again that you are one of the few people to really adress some points I raised and I thank you for that.
I’m not a technical guy anymore, so my point of view is more a crude, business-oriented one. And the fact is that for 90% of what we do, hiring and training somebody to make it with Plone is more expensive than doing the same with some other open-source CMSes.
I’d really like to do a faithful comparison between those CMS, so that people can choose more easily.
Plone has really some interesting points and some additional feature over the others. But others may have also additionnal features over Plone :)
@Martijn Faassen
« Pointing to http://www.zope.org’s products page to demonstrate that “Zope is slow” is a very silly example to take, as you should know very well. The zope.org site is outdated and practically unmaintained. That’s the Zope community’s shame, of course, and would be a legitimate criticism, but a slow web page hardly demonstrates that Zope is slow. It’s as easy to write an unscalable application with Zope as with any other technology. »
How you scale? At least, on other software, you untar the new version and you’re done. In zope.org there’s an old version of CMF who nobody knows how to touch, having binary (!) data inside. At least sql gives me the opprtunity to do a query, what about a zodb file? It doesn’t still have a query language!!!
Said that, I’m a Plone fan and I like it for rapid application developing with few clicks, which others can’t do. So, it is the right tool for me and not for the « web sites » guy :)
Yuri
> My Zope and Plone books sold well a few years ago, but sales plumetted in 2007.
Well, but it still works!! If you buy a 2003 book about Joomla or Drupal, does it still work?
Hi PJ,
Your article is interesting, but it comes too late for two reasons :
* If you were writing it when you were always working at Ingeniweb, i mean when you were always using and selling Plone, the credibility of your intends would have been more clear. Today you are working in a place where you do not sell CMS solutions, it reminds me of a child choosing his new Christmas gifts.
* If you were writing this article when we (developpers and integrators which were working under your decisions) were suffering with new Plone3 concepts and technologies, when we were doubting about these new technologies, in 2007/2008, some of us would have approved you at least for your temerity to talk about the elephant in the room, but at this period of time you didn’t say nothing and you were letting us down with our learning curve ( http://macadames.wordpress.com/2007/12/24/plone-usine-a-gaz/ ). Today, we are really cool with these concepts because some people have been writing good books telling how to play with it. So don’t bite the hand that feeds you, be honest with yourself, your ticket is not …
I’m right with you about Plone’s learning curve and Plone’s popularity, the first has been increasing as the second has been decreasing, and for a cause and effect reason no doubt. But i believe that Plone4 and Plone5 will inverse the curves and i think your appreciation of Plone’s future is not right : did you read something about dexterity and deco ? we are waiting for that impatiently.
After all, denigrating Plone, and by the way, denigrating your old colleagues’ work close to our clients, especially in this period of crisis is not very worthy of you. I’m asking myself about your reasons behind.
I hope you will reply to my approximative english, friendly ;-)
Plone has it’s place and can be complicated, but it also allows for customization that most of the other CMS systems don’t allow for.
I don’t think it’s the right tool for all cases, but it does put the control to the developer which also means the responsibility of system.
I am sticking with it, but still investigating other options for cases when I don’t need to add functionality.
@jean-mat Grimaldi
@Jean-Mat :
Hi,
My article may come too late, but I’ve been talking with many people involved with Plone – and I’m not the first one to leave it – so I wanted to tell why and have some feedback from the community. I don’t think I’ll contribute to the crisis with this post, however.
I’ll answer your two points :
1/
I’m impressed that you seem to know more about my own work than I do ;)
But I’m still (heavily) using CMSes, Plone beeing one of them. I’m still using, recommanding and selling CMS solutions. Should I feel sorry for that ?
Even if I didn’t want to _write_ this while at was at Ingeniweb, that was something I was worried about (see next point).
2/
I remember asking _you_ to try something else for a minor project and you refused. So you can’t say I didn’t do anything – even if I did not do it well in your eyes.
What you call « The hand that feeds me » is the knowledge of content management in general, not any particular tool. Would you trust a seller that would only know ONE brand of a product ? It would be very dishonest to promote Plone « blindly ». For example, in general, Plone as a blog sucks. WordPress is better at this. (note to py-flamers : « in general », I said).
The funniest part of your comment is that… you agree with me (as many others do after one or two beers) : Plone’s getting more complicated and less popular.
Yeah, sure, Plone 4 (and even 5, and even 6 and 7 as well) is full of promises. But what if I need a CMS RIGHT NOW ? Except for fine-grained content security projects I’ll choose another CMS.
I’ll consider Plone again as a mainstream CMS for my projects when a n+1 Plone version will REMOVE more concepts than it adds (it’s not only about code reduction but overall framework simplification).
Anyway, I don’t pretend I’m right. I know this is an emotional post and that’s why I put a personal title to it (« Why I’m leaving Plone » is not « Why everybody should leave Plone », as far as I know !). Many people who answered me said :
- Your figures are wrong, eZ/Drupal/Joomla is less popular than it seems (maybe… but, still, they’re more popular).
- It’s not because something is popular that it is good (right… but what is widespread is cheaper ; and, most important, I’m not complaining about the fact that Plone is not popular, but about the fact that its popularity is DECREASING ; nobody gave me an explanation for this).
- Plone is not slow at all provided you spend time tuning it (right… but out of the box, most PHP CMS will be faster than Plone prior to any tuning… so in that way they’re cheaper to implement).
- Plone is getting simpler (right… show me an official simpler version and I’ll trust you – I’ve never read anywhere that people would remove ZPT or Achetypes… I’ve read they’ll build other stuff on the top of it… once again if I’m wrong just tell me so).
- You’re bitter, you’re mean, you denigrate (oh, yeah, right… and you ?)
So, Jean-Mat, ask yourself those questions :
- Amongst the people who quitted your company, how many of them are still working on Plone ?
- How many new Plone projects are you hearing about every month ?
- How many Plone developpers have their personnal blog built with Plone ?
- How easy is it to hire a skilled Plone developper ?
- Was Plone used to build your company’s website ?
Then maybe you’ll share a tiny bit of my feelings :)
[...] I won’t discuss yet another time about some CMS’ popularity. I’ve been told that using Google Trends to evaluate the popularity of something wasn’t [...]
This is exactly what I think about Plone! Few time ago I was calling to fork Plone 2 and burn everything made using Zope 3, but time is gone and we can’t do anymore… :-(
Here z3 base cms/cmf http://www.zope.org/Members/fafhrd/z3ext-1_0_0_released
just in time :)
On the end it really doesnt matter what u are doing. What matters is how passionate u are about it
[...] just read a splendid article about why Pierre-Julien Grizeli is leaving Plone. The article is from 2009, but the points [...]
Hi,
I’ve just come across this site, and the core developers of Plone should be forced to print it out and eat it – maybe then they would start listening to some of their users. Leaving the complexity issues aside for the moment, the single thing they need to do is to provide a consistent API between versions that doesn’t break applications already developed. They could then change the internals as much as they liked, and it wouldn’t matter.
I have made this suggestiopn to them on a couple of occassions, and it is as if I am talking a foreign language to them. Their reply is always along the lines that it would « restrict » adding new features/capabilities.
This is total bullshit – you are right, they just like coding for coding’s sake. Could you image how long Oracle would last if each new release broke every application built on top of it ?
I was attracted to Plone because of the capability of building the application model in a UML tool, then automatically generating the code, which I did for a music history project (www.franktraynors.au.com).
It is still running on Plone 2.5 as the very same UML model would not generate to Plone 3 using Joel Burtons public site. Some of the 3rd party applications also break on Plone 3, although I eventually have it all working on a test machine after wasting more time doing so than it took to get the original site functional.
I am dreading even thinking about getting it to run on Plone 4, as NONE of the 3rd party apps are available for Plone 3, due I suspect, to the reasons you give above.
Regards,