Plone: Application or Framework? Should We Care?
For a bunch of years now I have heard a debate within the Plone community, most notably from Paul Everitt, about whether Plone is an application or a framework. While I can't honestly say I've given the issue a ton of my time, nor am I sure I fully understand why this is a particularly important distinction, I did have one thought on the matter I wanted to share.
To me, Plone is an application.
Plone is also a framework.
Yes, that's right - it's both!
I wonder if this question is akin to asking if light is a particle or a wave. So, which is it? Well, it depends on what kind of experiment you run. This Wikipedia article explains this issue better than I could, but in the end it's all about context. Or maybe it's about the inadequacy of trying to use simplistic mental models for complex things. In either case, Plone is a framework when you need to use a framework, and it's an application when you need to use a CMS application.
I suspect this is really more of a marketing issue in Paul's view (Paul - am I right about this?) which I suppose does make it less academic. Marketing 101 tells us that you want to pick something where you (or your product or your service) are the best in the marketplace, point to that, and sell, sell, sell. You shouldn't try to be everything to everybody.
As far as this particular issue goes, it is clearly in some people's best interests to position Plone as a framework, and in other people's best interests to position Plone as an application.
So, let the public debate begin!
- Why is this important?
- Why should Plone be positioned as an application? What does that even mean?
- Why should Plone be positioned as a framework? What does that even mean?
- Is there any reason not to speak of Plone as one or the other?
- Is this discussion worth having?








Yep, I mostly meant it as a marketing, e.g. positioning, statement. Is Plone something in a particular segment (upper mid-tier) of some particular market (CMS) that has people reviewing it, analysts recommending products in that market, purchasers writing RFPs for the market, etc.?
Or, is it used to build things with different brands/expectations that are themselves in such markets?
Thus, it is a lot about positioning and expectation management. However, it's also about product vs. platform planning. Do we always ensure that the needs of the product's users come ahead of the needs of the developers that want freedom to change anything/everything, take it in new directions, etc.?
Zope, for example, started as a product named Principia. Back in 1997, we tried really hard to *hide* Python (believe it or not) and let people assemble websites using our product. Transitioning to Zope, we gained a bunch of people that wanted to write new and unexpected things for it, making it a platform. And those people eventually rebelled against the product part of the software (ZMI, TTW site building, ZClasses, restricted Python, etc.)
Ultimately Zope 3 shed any concept of having an out-of-the-box product. In fact, the only reason there is still a ZMI (Rotterdam) is that they can't easily disable it. [wink]
Thus, not knowing if you are a product or a platform can have some negative consequences, IMO.
Posted by: Paul Everitt | November 07, 2007 at 01:50 PM