I work on projects using Plone, and I love working with its framework. I just worked an hour for my current project, and once again I enjoyed the fact that I can write stuff in a clean way. I can expose logic or behavior where and how I want it, using interfaces and components mechanisms provided by Zope libraries under the hood. It's got even better now that we have an elegant API.
I see Plone as one of the best Open Source CMS' out there, when you are delivering big projects. Of course I am biased, because I prefer Python to PHP. A PHP developer could say the same for Drupal if he uses it every day, and it fits his brain.
Now, I do not define myself based on the tools I use, and this is not a post about Python vs. PHP. Please read on!
While working with Plone stuff for people, I have come to understand that Plone itself is well thought, stable enough, and does a great job. But there can be frustrating times, with managing complexity in projects, such as many dependencies to track and maintain.
The problem is what we try to do with the tools
Another example is trying to implement all your use cases in Plone, when you could do these 10 to 20% of the hard stuff
using external tools, services or APIs built and optimized for the job.
Even if you succeed in getting your implementation right, you have already failed!
Why? Because you will end up having to maintain too much, and there is a long-term cost you are not seeing. We should all accept that maintaining software is not easy and, integrate it in the long term cost of what we are building.
Our social conventions and cultural bias train us to believe that we are strong and have unlimited resources and time. I believe there is a flaw there. Among other things, we are limited by the clock. Time should not be wasted. You also want to spend your time on aspects of your life as important as your work (if not more), such as family, leisure (for rejuvenating purpose), and the world. The same applies to the people working for you. The same applies to your clients.
A manifesto for simplicity
One thing I can take from it today is: Think more about inessential complexity, and always look for ways to avoid it.
I am already doing this in the area of websites: Building all sites that do not require a CMS, using the static approach. I recommend this to others, and I have been giving training and support to those who are already sold to the idea.