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