Re: [Fwd: eZ and Drupal to be dismissed]

[Gergely Nagy <greg gnome hu>]

Hi all,

Sorry for disappearing for such a long time, I've been really busy with
thesis defense and a full time job, and also took me a while to catch up
with the progress that was made on the wgo front.

With my own investigations I came to similar conclusions like Quim.

It seems that all CMSs meet our goals to a certain extent. Therefore,
the critical issues boil down to:

- i18n
- maintenance (ease, enough people)
- scalability
- security

I think we still have enough time until release to leave the remaining
candidates in the race. We need a staging server for the final candidate
anyway, since we can only "go live" when the release is made, so I think
it is no problem to have several "beta" staging servers. Then the choice
can be made with better first hand experience with real new WGO content,
and more people's input.

Now, whether we leave 2 or 3 candidates (Plone, Midgard, Drupal?) in the
race is a management decision. Apparently Drupal has the most
supporters, and while it currently seems least "ready" from the 3, if
people want to work on it, and we think its not a waste of human
resources, why not?

So I propose to start staging on all the remaining candidates, as if
they were the "final", and eventually they will drop to just 1. I think
it will not be too much duplication of effort, content can (hopefully)
be more or less copy-pasted across. It can actually be an advantage to
see more ways to solve problems, or get ideas how to improve the "other"
CMS, or serve as healthy competition :)


Some more general thoughts:

The selection process is certainly taking a long time, however I think
it is not _too_ long. As I said before, there are more important issues
than "The CMS", for example the content or the policies. I'm glad to see
focus shifted to those aspects after the initial "obsession" with the
CMS :)

We should not depend too much on a single CMS. Now, I'm not suggesting
to change CMSs with every release, however our requirements will surely
change over time, e.g. a large enough user base might even warrant
something custom. Such independence is also important wrt
interoperability to other (gnome) sites. This was already covered in the
initial CMS reqs, I'm just stressing this point.

cheers,
Greg


On Fri, 2006-10-27 at 08:30 +0100, Lee Tambiah wrote:
> Fair enough, after playing with Drupal yesterday, I have also came to the same decisions as yourself, it's either PLONE or MidGuard. It seems you and Henri have addressed most points regarding Midgard. Also Ramon has added many points also, so we are all most there. Would you like me to cut down the CMS requirements Wiki Page down to PLONE and Midguard now?
> 
> Lee
> 
> > ----- Original Message -----
> > From: "Quim Gil" <qgil desdeamericaconamor org>
> > To: "gnome web" <gnome-web-list gnome org>
> > Subject: [Fwd: eZ and Drupal to be dismissed]
> > Date: Fri, 27 Oct 2006 00:53:13 +0200
> > 
> > 
> > Update on my previous request: eZ and Drupal are being dismissed,
> > opinions from a sysadmin point of view are now even more needed about
> > Midgard and Plone.
> > 
> > From: Quim Gil <qgil desdeamericaconamor org>
> > To: marketing list <marketing-list gnome org>
> > Subject: eZ and Drupal to be dismissed
> > Date: Fri, 27 Oct 2006 00:48:53 +0200
> > 
> > 
> > eZ and Drupal are the following candidates to be dismissed. I'm putting
> > them in a same row because they have complementary problems and virtues
> > from the wgo revamp perspective. eZ could be perhaps an appropriate tool
> > for wgo but we lack human resources. Drupal is backed by many potential
> > volunteers, but I think that making this tool matching the wgo
> > requirements (specially i18n) would be pretty complex.
> > 
> > For these reasons I think the final will be decided between Midgard and
> > Plone.
> > 
> > More in detail (DRUPAL FANS PLEASE READ UNTIL THE END)
> > 
> > About eZ Publish:
> > 
> > - Localization: many requirements are covered and I believe that someone
> > with good PHP skills and a lot of free time could create the missing
> > functionality at some point. Native XML content, CVS & diff and a lot of
> > code and thought already implemented in a tool that has been
> > multilingual since the beginning. See
> > http://ez.no/community/developer/specs/improved_multi_language_in_ez_publish_rev_2
> > 
> > - Look&Feel: probably no problem.
> > 
> > - Learning curve: apparently eZ is easy to install, setup and use, and
> > there is good documentation around. I'm not sure about the complexity of
> > customizing the tool and making it work as we wish. The problem here is
> > that most of the potential volunteers around would start from scratch.
> > But well, this would be a positive point as well.
> > 
> > - Security and upgrades: typical scenario of a decent coverage. Patches
> > and maintenance releases are published as soon as a vulnerability is
> > detected and the upgrading is done via scripts and requires some
> > tweaking.
> > 
> > - User management: provides what we need.
> > 
> > - Contributors around: I'm really concerned about who would be willing
> > to work on this, and learn to an advanced level to be a reliable
> > webmaster. Michael Maclean has been really helpful and I'm sure he would
> > assist us in the process. Same thing with the people from Igalia. But I
> > don't see many people using this CMS around and I wonder how cooperative
> > the PHP-friendly division would be considering that most of them are
> > playing around Drupal, and are happy with it. If we are having serious
> > trouble finding contributors for more broad tasks like wgo planning,
> > writing texts etc... please understand if as a coordinator of the wgo
> > revamp I fear we won't find enough resources to work well and fast on
> > the wgo CMS implementation. In this release and in the following.
> > 
> > The latter is the heaviest reason to dismiss eZ, since I see more
> > probabilities of ending up with a real website in place and decently
> > maintained via Drupal, Midgard or Plone. In other circumstances I think
> > it is a good CMS, and if we were a professional web development agency
> > with a budget I would seriously reconsider this option.
> > 
> > 
> > About Drupal:
> > 
> > - Localization: although the i18n module has done a lot of progress,
> > it's still miles away from our requirements. If wgo would be just in one
> > language I would probably bet on Drupal (as I have done consistently in
> > the past). But thinking in a scenario of wgo translated into +20
> > languages in one year I see a lot of risk around Drupal. Either we would
> > need to develop a lot of hacks and additional features or either we
> > should design a fragile workflow a) not convincing the i18n team and/or
> > b) with a high probability of ending up in a low quality mess and a lot
> > of improductive work. Drupal is conscious of its weakness in the
> > multilingual field and they are putting slowly a remedy (see the recent
> > thread at http://drupal.org/node/88417 ) but this process will take long
> > and we need a multilingual wgo before.
> > 
> > - Look&Feel. We would get what we want.
> > 
> > - Learning curve. It's easy to get from 0 to an editor level. It's not
> > difficult to get from intermediate admin/hacker level to advanced. It
> > would be appropriated to our needs, I think.
> > 
> > - Security and upgrades. Vulnerabilities are quickly found and generally
> > quickly fixes with maintenance releases. The upgrades are made with
> > scripts and currently it's a quite straightforward process. There are
> > not big problems with the core CMS, but the maintenance of the
> > contributed modules is another story (i.e. the diff module was abandoned
> > by the maintainers and now we would need to port it ourselves in order
> > to use it in the last versions, these kind of stories are not that
> > rare).
> > 
> > - User management. Permission levels are more fine grained than before
> > and there is an LDAP feature. It would do the work although I believe
> > other candidates are much more stronger in this field. But well, we
> > don't expect to have complex permissions policies in wgo either. It
> > would probably do the job.
> > 
> > - Contributors around. Definitely the best asset. Over the past months
> > many Drupal fans got interested in GNOME, and/or the other way round.
> > Many GNOME related sites are using Drupal and there is some expertise
> > around. However, we have also experienced difficulties getting real
> > commitment in our Drupal sites when we have needed them and I have to
> > say that the level of complexity of these websites is not extremely high
> > either. These are two reasons that make me think that although we might
> > have many potential volunteers around, at the end I'm not sure if we
> > would find the resources needed to hack a Drupal installation to the
> > levels we want to achieve.
> > 
> > 
> > This is why I think Drupal is another candidate to be dismissed for
> > wgo... while keeping thinking that is a very good option for GNOME
> > subsites without complex i18n requirements i.e. guadec.org,
> > gnomedesktop.org and the many GNOME groups that are using it.
> > 
> > For this reason I ask to the Drupal webmasters and hackers with GNOME
> > love to stay with us, subscribe to
> > http://mail.gnome.org/mailman/listinfo/gnome-web-list and give a hand
> > with the current installations - they need it. For instance, precisely
> > these days Thomas Wood (GUADEC 2007 coordinator) is crying for Drupal
> > help. See
> > http://mail.gnome.org/archives/guadec-list/2006-October/msg00000.html
> > 
> > --
> > Quim Gil /// http://desdeamericaconamor.org
> > << signature.asc >>
> > 
> > --
> > marketing-list mailing list
> > marketing-list gnome org
> > http://mail.gnome.org/mailman/listinfo/marketing-list
> > << signature.asc >>
> > 
> > _______________________________________________
> > gnome-web-list mailing list
> > gnome-web-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-web-list
> 
> >
> 
> 
> 
> Regards
> 
> L. Tambiah
> 
> GNU/Linux Enthusiast
> 
> /**************************
>  * "Having the source code 
>  * means that we are not 
>  * held hostage by anyone's 
>  * support department." 
>  *              --R. Nelson.
>  **************************/
> 
>