Hi guys,
I don't really want to get into the details of this, because I don't
have strong opinions on the exact PLIPs, but I would like to offer my
point of view.
Basically, we have three issues at stake here:
1) Architecturally, having small and independent components makes
maintenance and evolution easier. Ergo, bundling too much stuff together
is a bad idea.
2) Resource-wise, maintaining less means we can improve the quality
and/or speed of releases. Ergo, anything we add that needs to be part of
our core distribution has a cost in terms of testing and getting bug
fixes done.
3) Feature wise, Plone needs to be able withstand scrutiny and provide
the tools people need to solve their everyday problems. Ergo, for things
that are "core" to our vision of what Plone needs to be, we should have
"core" package that solve these things in a well defined, well tested,
up-to-our-quality-standards sort of way.
Clearly, there's a balance to be struck between the first two and the
third of these.
Now, I wouldn't want the Framework Team to become over-stretched (a real
risk) or to try to control more than it's been given the legitimacy to
do (a very unlikely risk).
However, we need to be careful. It's all well and good to say Plone
should become smaller and simpler. To me that has more to do with
architectural cruft and the places where we have two solutions to the
same problem, than with actual end user features (although there are a
few we could possibly factor out).
However, our audience here is not necessarily the core developer who
knows how to evaluate a third party product, which developers of third
party products, to trust, and how to build something custom if there's
no decent solution as part of Plone. Our audience has to be the people
who use the installers and want to do something with Plone without
investing a huge amount of time becoming experts in our community and
our stack.
In other words: Plone is a framework to many people, but it's not *only*
a framework, and the "product nature" in terms of what you get when you
opt for Plone (not Plone-plus-some-vague-set-of-add-on-products) needs
to be compelling. Having just done a detailed CMS product evaluation and
seen what else is out there and how Plone gets written about, I cannot
overstate how important this is.
I suspect that's what Alex is talking about with Amberjack, for example.
And this is where installers are a convenient way out. The installers
can pull in additional eggs that are not dependencies of the 'Plone'
egg. These are still things we need to test and make sure work, of
course. But this approach allows us to at least deliver on (1) without
neglecting (3).
This still leaves the question of how we decide what's in and out of
scope, and thus what costs under (2) we're willing to accept. My
suggestion would be that we use the good old 80/20 rule:
- If we think a feature might be useful to 80% of those who use Plone,
we ship with it.
- If we think a feature is only going to be of value to 20% of our
users, we don't.
That's not necessarily a hard-and-fast rule always. Sometimes, the cost
may be so low and the "wow factory" may be so great in comparison that
shipping with a feature is a good idea. Sometimes we may want to ship
something to encourage a standard platform for certain things to aid
interoperability of third party propducts (I guess that's what the
jQuery Tools thing is about).
This approach has a few implications:
- We make some choices about how we think Plone should be used. To me,
our "core" proposition is around web content management. Basic services
like types, versioning, check-in/check-out staging, theming, and so on
are all core CMS features, and we would stand no chance without them as
part of the supported core product. Conversely, we wouldn't ship with a
shopping cart or a flight tracker (yep, that one was on uservoice...)
because those are not really core to web content management.
- We're allowed to have features that are "soft" dependencies, i.e.
they can ship in the installer without being mandatory dependencies of
the 'Plone' egg.
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See
http://martinaspeli.net/plone-book------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
