CMS selected: Plone

Ok, let's go for Plone. I think we could reach our wgo goals with
Midgard as well but there are some reasons that probably make Plone a
better choice here and now. These reasons, detailed above, are based
more on human factors than the tools themselves.

To me this is the end of the CMS selection process. If you have anything
to discuss, let's discuss it. But Ramon can already start the work, to
be coordinated via gnome-web-list -



One aspect that has pushed the Midgard option since the very beginning
is their use of GNOME libraries - . From a technical
point of view this might open ways of integration between the GNOME
website and desktop. I'm sure that a dinner with Henrius or Tuomas would
throw thousand interesting ideas. Also, from an "institutional" point of
view makes sense betting in projects that have bet in GNOME to support
each other mutually. My conclusion about this is that it would be still
interesting to experiment with the Midgard-GNOMEdesktop integration, but
wgo is probably not the best place to do so. I think this essay would
make more sense in something like a - which is a slightly
different battle than wgo 2.18.

Let's compare Plone and Midgard.

- Localization: 

We could probably fulfill the whole i18n requirements with both tools
and some hacking. I can even imagine the Midgard developers willing to
make an investment on this since the working solution could be pretty
interesting to potential clients with intensive L10n needs. That would
be a best case scenario. However, this humble wgo revamp coordinator
needs to think in worst case scenarios: the Midgard developers busy in
other projects, Henrius lost in the Antarctica with a moped... and our
PHP guys around saying it is complex to get into the Midgard thing and
"we told you Quim it was better to go for [your favorite PHP CMS here]".
As a result, the i18n team, upset, decides it's not worth to waste the
time with us.

With Plone technically we could reach the same features than with
Midgard (and viceversa), but the human context is very different.
Perhaps Ramon & co don't want to invest the time needed to fulfill all
the i18n requirements, but the already existing Plone tools can offer
the minimum requirements to deliver to the i18n the minimum they need to
work: XML, versioning, diffs (same as Midgard). From that point if the
i18n team says "we got A, B, C which is fine but ideally we would want
to have E, F, G as well" our answer can be "no problem, go hack

Why this answer with Plone and not with Midgard? Well, Danilo knows
Python, he is developing (Python based)
and as far as I know is working in (Plone
based). Same for Jordi Mallach of GNOME i18n fame and even Carlos
Perelló (former GNOME i18n tools maintainer). No idea if there is more
Python knowledge in the i18n team, could be.  In this context the worst
case scenario wouldn't be assumed alone by the wgo team, we would share
responsibilities with the i18n team who would have more skills than us
to develop their own solution at their own will. A perfect integration
can be achieved if someone within the GNOME community is willing to code

- Look&feel: no problem with Plone or Midgard.

- Learning curve: let's have a look to the three levels of users needing
to learn how the wgo CMS works. Editors and translators would need to
deal with forms and little more, a simple 2 pages tutorial would
probably do. Web admins would have probably a similar learning curve
with both tools, that allow the administration of most tasks via web
interface (although it might be possible that Midgard relies more on the
command line). About CMS hackers, the ones implementing new features,
customizing stuff... in a typical PHP savvy web development environment
Midgard could have an advantage here, but due to the special context of
GNOME I think we have more good & intermediate Python hackers around.

About documentation, both tools have the basic that is needed, but the
Plone environment has a lot more, including a whole free book and
screencasts for several levels. People like these things when they have
to learn something.

- Security and upgrades: both tools are solid and seem to be careful
about the upgrade process.

- User management: apparently both provide what we need.

- Contributors around: as said, even if normally in web projects based
on volunteers it is easier to find PHP hackers, I think in our context
there is more Python knowledge. If the use of Drupal in and has brought some Drupal supporters on board, I think
the use of Plone will have the same effect with this CMS. We have
already some names of people interested in having wgo based in Plone - -
and we will probably find more through the Planet and other channels. 

In any case I trust the capability of Ramon leading the implementation
of the wgo CMS within the 2.18 timeline (same as I do with Henrius, no
differences here). This has been an important element in the decision as


Thanks to all the people that invested time willing to find the most
appropriate CMS for Even if the process wasn't as good as
it was planned, I hope the result will be as good as expected.

And now, let's build a great

Quim Gil ///

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]