What is Plone?

by Martin Aspeli — last modified Feb 07, 2008 09:45 AM

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.

Document Actions

One word

Posted by http://reinout.myopenid.com/ at Feb 07, 2008 10:45 PM

Amen.

Uh-oh, here we go again...

Posted by http://emyr.myopenid.com/ at Feb 08, 2008 01:30 PM

Sorry, I know this debate is rather long-in-the-tooth, but it is important we steer Plone in the right direction going forward, so here's my take on the whole issue...

Installing Plone, as it stands today, you have a very capable CMS product up and running in no time at all, which you can (to an extent) customize through the web with very little programming knowledge. Look a little deeper and underneath the polished UI there's a very flexible framework that you could use to modify and extend Plone to do things it doesn't already do for you. Or you can look at it slightly differently. You're a developer looking to build a project (with content management at its core) so you install Plone. What you've just installed has a loosely coupled component architecture, a fine grained security model, workflows, multilingual capabilities and a load of other cool stuff. While it's true that some of these things are available in other frameworks, many of them aren't. The fact that you have a working CMS sitting on top that showing how all these things fit together drastically reduces develpoment time (assuming as I said that managing content is the main purpose of your project). That's a really good middle ground, and is what makes Plone so popular.

I think where we need to be looking to change things is how we direct people coming to us for information. I think we should break plone.org into 2 sites. plone.org stays, but is significantly trimmed down into a brochure-ware site (yes, you heard me right) promoting Plone as a fully functioning CMS product, playing on its out of the box strengths. We should definately keep a small documentation section on there, but limit it to short, easy to follow how-to's that walk you through the things you can change through-the-web via the control panel. Things like:

* Creating collections
* Managing portlets
* How to version/stage content
* Managing permissions
* Maybe even adding a new product (like Ploneboard or something)

By limiting the documentation like this, it becomes less of a burden on the documentation team, and we can make sure that every piece of documentation on plone.org is bang up to date and 100% correct, so that both Plone itself and plone.org are seen as being very polished and easy to use - promoting the Plone brand. Ideally, every piece of documentation that goes up there needs to go through a formal review process to check for accuracy and readability. Yes, this is more work per item, but there will be less items to review, so the workload shouldn't differ that much. And remember, these are all supposed to be short, easy to follow docs, involving no coding at all, so it won't take core developers to review them.

We then have a very clear and easy to reach page on plone.org, a "Where do I go from here" type page that talks about some of the more complex customizations you can do to Plone. This should point people to 1 of 2 resources:

1. plone.net for those wishing to hire someone to customize plone for them, and
2. developer.plone.org for those wishing to learn how to customize Plone themselves.

developer.plone.org should be where we discuss Plone more from a framework point of view. The audience will know what an out of the box Plone is capable of, and they know how to change setting using the control panels in the UI. What they want to know is where they can hook into the code to make Plone work the way they want it to. They need more in-depth tutorials like:

* Integrating with a relational database
* Creating a totally new skin/theme
* Single sign-on in a Windows environment

While we should of course still be aiming to keep this documentation as up to date as possible, and suggesting best prectices, this area should be open to more community contributed documentation. Documentation written by core Plone developers could be automatically flagged as best practice ways of doing something, but next to that you may have an article written by an integrator saying "this is how I got Plone to do XXX and it works!" A rating system for documentation would be extremely helpful here.

So, the way I see it there's only "one true Plone". Plone the platform and a Plone the framework are two different views on the same project.

Sorry for the rather long comment!

--Emyr

Previous: Is Plone too hard? Next: Plone Strategic Planning Summit Debrief Right arrow

Plone Book: I have written a book called Professional Plone Development. You can read more about it here.