Overview

In common with everybody else who has a stake in The Plone, I've got opinions about what would help, going forward. Unlike what seems to be most of them, I'm not writing a blog entry about them: lots of folks have done that, and it would be fair to say that I agree with several of the things people have written.

Instead, I would like to offer some terminological groundwork which may help the discussion among those who are there.

A short aside: I spend most of a week at one of the earliest Zope3 sprints (the workflow sprint in Saarbruecken, February 2002) finding out that the other folks in the room meant something entirely different than I did when they used the term "workflow." As a result, the sprint did not deliver much of anything in the way of working software, although we did clarify the terms ("activity-based" workflow was what they had in mind, a la WFMC; I was thinking of "entity-based" or "document-based" workflow, which is what the CMF provides by default).

With that in mind, I'd like to propose a couple of terms for use in the discussion this weekend: I know that there is already confusion about them, because folks are already arguing about definitions in blog posts.

The "Framework" versus "Product" Debate

First, I'd like to say that Plone as we know it today is really neither a framework or a product. It is closer to a "stack" or a "platform", on the one hand, or an "application" on the other.

A framework is a term-of-art in software development: it implies a component or package which provides services, on one side, and defines slots / plug-in interfaces on the other which are intended to be filled with objects supplying application-specific implementations / policies.

In this sense, the CMF is not a framework either, but many of the tools which it defines are: the types tool, the skins tool, the actions tool, the workflow tool, etc., are all frameworks. Likewise, the QuickInstaller, the Plone Control Panel, etc. are frameworks. The closest that Plone itself comes to being a framework is the "templating contract" it defines (METAL slot names, CSS classes, etc.)

In any case, the key thing about a framework is that it defers policy choices to the application, which is responsible for plugging the right components into the slots it provides.

A product defines a deliverable whose feature set is bounded; users choose to use a product becuase it provides that set of features, rather than because it lets them build something else. So, for instance, you can point to MSWord, or Halo, or the Google Search Appliance as a product, but not any of Zope, CMF, or Plone. Products are conceptually shippable in boxes, and what the users get from a product is what is there when they take it out of the box. (Another aside: there was, back in the boom days, a mockup of a "Zope 2.3" product box, floating around ZC headquarters: I can't think of anything less like a product than Zope, then or now.)

Another litmus test for a product: if the (notional, in Plone's case) company selling it routinely sells "customization" services for it, as part of the standard package / deal, it isn't a product. In the case of Plone, the entire market is a services market, which makes the point even clearer.

It would be possible to deliver a "Plonish" product, which might even look like the default Plone skin, but it would need to be preconfigured such that most customers would be happy using it without doing any customization, beyond whatever information they supplied during product installation. I don't know of anybody who uses Plone-as-of-today this way.

A stack (or platform) is a set of components which provided the basis for deploying applications. I prefer "stack", because it makes clear the layered nature of the beast: the Plone "stack" starts with Python at the bottom, and layers on Zope, the CMF, PAS, Archetypes, etc., with the top layer being the Plone skin "framework." Plone is wildly successful as a platform: people are building applications on top of it everywhere you look.

One defining feature of a stack is the "layer cake" diagram you can draw of it: each "layer" depends on the services / interfaces of the layer(s) beneath it, and offers services / interfaces to the layer(s) above. To make the "stacK" work, it is crucial to be able to do the layering cleanly: there cannot be any cycles or inversions in the dependency graph. Here, Plone is not quite so successful: the dependencies are more than a bit messy, particularly in the layers above those which Plone consumes from "the outside" (CMF, Zope). Cleaning up the "organic" / "just grew" dependencies should be a key task in making Plone a sustainable "stack" over the long term.

As with frameworks, stacks try to defer as much policy / configuration as possible to the applications they support: to the extent which a component imposes policy, its usability is limited. Here, the key tradeoff is flexibility / reuse versus convenience: a site manager who doesn't care about the "policy baggage" of a component can get away with not configuring anything.

An application, in these terms, is the "topmost" layer of a given stack: it wires together the services provided by the lower layers, supplying policies and plugins to create a single, usable whole. In the world of The Plone, applications are sites, complete with all the tool configurations, property settings, etc. which go into making up a Plone site. Note that each application defines a certain required stack (the components which it uses), and that different applications may need different stacks. Imagine, for instance, implementing Wikipedia on top of Plone: many of the components we take for granted today might be unneeded (workflow, for instance, or even membership). Certainly that application would require some additional components which don't ship as part of the current Plone.

I think the key to recongnizing an application in this sense is to ask the following question: "Given the existence of the appropriate stack, can I install this application by selecting its baseline profile at installation time?" To repeat: an application is the combination of a given stack, with the configuration data needed to create the site on top of that stack. Today, in this sense, there is only one Plonish application: the "community site" application is the only one installable, because the ZMI add form for a Plone site does not expose any choice among baseline profiles (it does expose extension profiles, on which more later).

I think it would be healthy to have several such applications recognized as "first-class" citizens, each installable by selecting their baseline profile (or with their own ZMI add menu entry):

• Plone Community Collaboration Site (the current default)
• Plone4Artists
• Plone Intranet Site (disables ad hoc membership, configures a different default workflow, etc.)
• Plone Wiki Site (maybe not quite as ambitious as Wikipedia ;)

Given sufficient polish, it is even conceivable that one or more of these applications could turn out to be true products, which wouldn't hurt at all.

Note that there are many more applications which are never shipped (redistributed) at all: most of the folks who use Plone today are building one or more sites / applications for themselves, or their employers, and don't want or need to publish it as a reusable application. If we recognize that they are making applications, rather than add-ons to a standard application, we can make their lives easier.

The Add-on Story

The Plone stack has succeeded in attracting the talents of a large group of folks: those who are developers often want to share the cool things they have developed for their Plone applications. The large number of these add-ons is one of the reasons many folks think of Plone as a "framework", to which the add ons "plug in." In fact, the add-ons end up supplying plugins (content types, skin layers, workflows, etc.) to any number of the actual frameworks which make up the Plone stack.

The standard mechanism for such sharing is to ship a component which registers itself for one of the "plug in" frameworks available for Zope / Plone (the ZMI add menu, the old-school QuickInstaller dance, the new-style GenericSetup extension profiles). In the case of the latter, it is best to think of an extension profile as something which gets merged into the existing application's baseline profile: after that point, the application has a new profile (you can see that profile, for instance, by creating a "snapshot" in the setup tool, and even diff it against earlier snapshots).

It turns out that writing an add-on is hard, especially in the presence of an arbitrarily large number of other add-ons: the careful add-on writer must be vigilant against stepping on any configuration beyond the scope of the add-on. Furthermore, we have taught folks who are really writing applications that they need to jump through the add-on dance, which is much more work than they need: the application writer should focus on capturing the "aggregate" state in a baseline profile, rather than sweating to reduce that profile to the narrower (and more error-prone) confinews of an extension profile.

Conclusion

I hope that the definitions I have offered can help to inform the no-doubt lively discussions which will ensue at the Summit this weekend. As the rest of the community of The Plone, I am eager to hear the outcome of that discussion, and look forward to helping improve the stack / applications / ecosystem from which we all benefit.