Christian Scholz wrote:
[snip]
> I am not sure if this is really about product or platform. I'd think the
> decision which technology to use is not about whether Plone is this or
> that but what you want to do with it later on.
CMSWire apparently thinks Plone is content management specializing in
web publishing. They apparently got it wrong. :^) Whatever we decide
that Plone-the-product is supposed to be excellent at out-of-the-box,
people are going to want to do other things with it.
Having some understanding of the difference is what product/platform is
about. Read in this thread the reponse by Martin saying "content
management can mean lots of things", with the reply by Yves.
Some of us are interested in trying to make sense of what part is the
Plone UI for what Plone wants to do, and what parts are re-usable
outside of what Plone wants to do.
> Implementing it in CMF is probably not very useful as not too many
> things run on plain CMF.
I agree that some number of insiders have reached some level of
conclusiveness about that.
At the same time, that contradicts the consensus that Goldegg tried to
reach, so we could correctly collaborate with others in the stack. It
also contradicts the status quo going into Plone 2. And probably
contradicts Andy's book, though possibly not Martin's.
Making poor newbies figure this out by polling #plone for help sorting
out the accumulation is not a strategy. Getting "The Plone" to say "The
CMF is deprecated and we are no longer targeting that as our Content
Management Framework" would, at least, improve clarity.
> Using Zope 3 makes more sense these days as theoretically you can run it
> also outside Plone on a plain Zope3 instance.
I'm not 100% sure "The Plone" is ready to recommend that as the entry
point. I believe, and the person I replied to believed, that current
practice is to recommend Archetypes machinery.
It would be be an improvement in clarity to say that Archetypes, like
the CMF, is marked as deprecated. And that the way forward
is...errr....something else. :^) However, I don't yet know if we've
made that official.
As such, I worry that people are trying to figure it out for themselves
and possibly giving up.
> Using AT basically binds you to Plone in that you need probably the
> whole or most of the packages which ship with it.
I agree.
> But maybe I don't get the whole framework/product debate. What is the
> difference? What does Plone the Product actually mean? What Plone the
> framework.
Plone-the-product is a user interface and a set of features that works
together, out-of-the-box, for a certain defined market (e.g. scorecard.)
People looking for something in that market see Plone listed, compare
the scorecard of what they are looking for to what Plone provides, and
make a judgement.
Plone-the-framework is a blank slate. You dream up the product. The
framework isn't trying to attract end-users. It is attracting
developers that create something for end-users. The scorecard isn't
about features and pretty pixels, it is about developer experience.
*Very* different audience.
For you in particular, this is relevant. Plone-the-product, as it
stands going into 2007, is about content management. People in that
market weren't trying to do Facebook or LinkedIn. Once enough people
ask for it to get social networking on the scorecard, it gets on the
product's radar.
Frameworks don't care about radars, scorecards, brands, end-users, RFPs,
bids, tenders, etc. Because they don't choose a market.
This is strategy stuff. It's ok to say we don't care about strategy.
But I think we do care about strategy.
> You probably cannot dictate how people use it anyway. Guy Kawasaki once
> was talking about how Apple discovered that people were using their
> computers outside the intended market, e.g. for design and not for
> office apps. He said that many companies panic if they realize such
> things but he suggests "Just take the money".
I think you're over-paraphrasing. Industry segmentation is a big
difference than "are you a product or a framework?"
By you're analogy, you're saying Guy would be fine if Apple just sold
motherboard parts and had no strategy. As long as people bought the
motherboards, Apple could "take the money". I...uhhh...think Apple
cares a bit about the integrity of their packaging and branding. :^)
> So when I talk to clients they a) know Plone already and want it and
> thus there is no real discussion about what Plone actually is or b) they
> don't care how we implement it or c) they search for some CMS but don't
> know which yet.
>
> In the latter they probably search for a (customizable) product, not a
> platform. So maybe the general idea about what it is, it's a product.
> And compared to Django it certainly is more of a product because you can
> install it and you have a complete CMS running. With Django you cannot
> really do anything without programming something.
Exactly. Django doesn't try to have a product. It doesn't try to say
it is particularly ready-to-go, or even better, at one particular
function (e.g. content management.) Plone does not, not, not want to
relegate its out-of-the-box experience to being nothing more than
CMFDefault, does it?
"Plone is a (fill in the blank with whatever you're trying to do)" is an
unsatisfying marketing position for a product. It's great for a framework.
> Then of course people use it for completely different things than
> traditional content management, so for them it's maybe more of a
> framework. Or just a very flexible product?
>
>> IMO, using the word "Plone" to mean both product and framework gives us
>> (a). It leads to the bizarro axiom that "we encourage people to use
>> Plone to develop things that aren't Plone but shared outside Plone".
>
> Well, what we encourage people to do is different from what is possible
> to do. I think there should be at least one preferred way to implement
> components for Plone. Today this might be still AT, tomorrow this might
> be more Zope 3 based. But beside that you can also use these outside
> Plone (here the question actually is if that's really that easy to do)
> it maybe is more important that it offers you more flexibility inside
> Plone. Maybe simply because the core Plone components more and more go
> into that direction (and I doubt the reason is that it's then easily
> portable to another system).
If "The Plone" had a strategy on this, it would probably clear up some
confusion for people coming in.
>> There have been strong voices in various directions, as well as
>> recurring evidence of confusion. Consolidating these into a clear
>> statement (aka a strategy) from "The Plone" would set people's
>> expectations about Plone, the stack, re-use, and the preferred way to
>> develop.
>
> As said, I think there should be a preferred way to develop but not so
> much because of this debate but simply because it has other benefits
> like it's easier to point people to docs, help them or have a migration
> path for the future.
>
> For potential clients it's probably a product and for (some) developers
> it might be a framework.
Saying you develop Plone components for the Plone framework makes a
pretty heavy implication that the components are only for Plone.
--Paul
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
