[Fwd: eZ and Drupal to be dismissed]



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.
--- Begin Message ---
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

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

-- 
marketing-list mailing list
marketing-list gnome org
http://mail.gnome.org/mailman/listinfo/marketing-list

--- End Message ---

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]