What is Plone?
The meta is hurting my head!
There's been a lot of blogging lately about what Plone is and isn't and whether that is a framework or a platform or a product or what. This is great - it's exactly what we hoped would happen in conjunction with the Plone Strategic Planning Summit - and that's not even happened yet!
However, I think we're going round in circles a little bit. There are some very important outcomes here, such as what terms we should use to market Plone and whether we should badge some of our more "framework-like" efforts as something not quite "Plone", using the titles of the lower-level elements of the stack. But let's not throw the baby out the bathwater. Plone is good. It's successful. It works for a lot of people. Whatever label you put on it, we're doing some things right (and some things wrong, for sure). I think it's important to focus on those too.
So what is Plone?
- It's a fantastic open source community and a mature project
- It's a good user experience
- It's a powerful out-of-the-box solution for managing content-like things (pages of text, files, images)
- It's a generic, good UI to perform those tasks
- It's a collection of common services, such as user management or search, integrated into a single package
- It's an extensible system which allows people to plug in different schemata of content
- It's an exposure of different APIs and resources that can be used by other software that need to manipulate Plone's state or get information out of it
And probably more ... but notice I didn't use the words "platform", "framework" or "product" there. If we tried to shut any of those things off - stop people significantly customising Plone, say, or drop the expectation that it should be a good solution out of the box, we'd lose our sweet spot.
We should definitely make some of the "framework" side of the equation easier, we should move more tasks (such as designing new content schemata) from being "framework" tasks to being "product" tasks, and we should consider putting the "framework" and the "product" functionality under different banners. We should possibly also modularise more, thus making it more of a "platform". But in the end, it is still going to be us, the Plone community, and Plone, the prolatformwork that we develop.
I also think it's interesting that people are making a noises about not wanting a framework at all. Frameworks are complex, they get in the way. The framework part of Plone means you have many things to learn and much to grapple with. Well, yeah, but ... you can write anything in assembler, right? Or plain-Python maybe. The truth is that Plone, in addition to giving users a great product, gives integrators and developers a starting point. From day one, they have a useful application. Their customers have a tangle product to understand and critique. Unless Plone is completely inappropriate as a prolatformwork for this project (which clearly happens), there is value almost immediately. Believers in "agile" will rejoice in this.
I too find frameworks frustrating, largely because I often don't already know them and I know there's no way I could learn them all. I kind of wish that all programming could be done without having to learn anything more than just Python's syntax. But I don't think we live in world where applications are like that anymore.
There are definitely frameworks that easier to learn than Plone's frameworkness part, as are there more complex ones. But there are few that give you so much out of the box to customise and build upon. Sometimes it makes sense starting bottom-up and sometimes there's more value in starting from the top and breaking things down when you need to, taking away almost as much as you add to arrive at a final solution. If you can't use Plone completely out of the box, then this may be a good second-best rather than trying to invent user management and search and a decent UI (often the hardest part) all again, either from scratch or by assembling pieces that you don't know for sure will work well together.