Why I stopped doing Plone
Last week I headed down to Seattle for Django Seattle and had a good time and some good beer.
One question I got asked is "why did you stop using Plone?". I've been asked this a few times and having a quick look back through posts, don't think I've blogged on this. So with a deep breath and the hope I don't offend everyone, here goes.
Rescuing sites
For many years I did a lot of Plone sites. This was doing consulting directly or through Enfold. For many years we had quite a few different sites. At the time we had three kinds of sites: 1) the Plone project started by someone else that got abandoned by the consultant, or the main developer left or they just couldn't get it done 2) the Plone project that isn't really a CMS but Plone's a development platform 3) a CMS site that is a perfect.
There was very little of 3) and lots of 1) and 2). Partly this is because as developers we weren't needed on sites that didn't have problems. The result was that we got a lot of problem sites. As a young developer keen to make a reputation, I was keen to have every site in the world be a Plone site. I remember chats on #plone many, many years ago trying to make Plone do site X or site Y. These days people would be crazy to try those in Plone.
The result was a negative situation. I started projects in bad situations and mostly they got better, but it was a struggle.
The bits I couldn't solve
One of the advantages of being old is that I know there a things I can't fix. I now know how brilliant the ZODB is. I now know I never want to use it again. But I know this isn't going to be replaced in Plone without a heck of a lot of work. Or for example: I faced a Franken Plone 2.x site that was slow and couldn't be upgraded or made faster for many reasons.
Stuck with these bits and knowing they aren't going to change, you either learn to love them or not. In the end this (and other parts of Plone) felt like they were continual weights. This added to the negative situation.
The monster hiding behind the cupboard
Like an system or framework there are bits that are sample to change and bits that aren't. Some things are so damn simple to change to configure. Some are like scaling your way up the north face of the Eiger with a broken arm.
So you'd discuss things with a client and there would be 20 things that need to be done and there'd be 15 things that are easy, 4 things that are hard and 1 that is the lurking monster. You do it and then it spawns problem after problem. The monster runs around wrecking bit after bit of your site and project. It's not predictable. Your timelines are shot, your project runs over and before you know it everyones annoyed. Things don't get better.
With Django
It's not perfect, it's got warts and some odd stuff in there (later posts I'm sure). But it provides what I need. What I don't have I can add. Sites are not started by non-developers and then abandoned, because of the underlying requirement to know the basics before starting a site. There are no monsters hiding that I've found. It's clear and transparent, so far.
The overall situation has been positive and that's the key difference. When building sites with Plone it became "oh another screwed up site" or "oh another site that wants 20 non-working collective products installed" or "no Plone can't do recurring events" and so on. This is a very personal thing, but it became more negative than positive.
This is a very personal interaction with Plone however and how I interacted with it. The irony here is that Plone is a very productive platform around for end users. Create a Plone site and end users can be up creating content so fast, it's a very enabling system. I just didn't see or feel that.
Will the same happen to Django? Perhaps. Perhaps I just did too much on Plone, perhaps the year or so away from Plone just when zope 3 came along hit me too hard. But I do feel happier doing projects in Django and that's important to me.