Jeff Waugh recently announce that GNOME.org now use WordPress MU for blogs. What looks like a smart move is indeed not very smart. Why? It was decided to use a new CMS for gnome.org – if Drupal would have chosen it would have been a matter of minutes to create a subdomain will blog functionality. And there still is the GNOME planet. GNOME has not solved the main problem the site has for years now, which is:
- Content is outdated.
- Many new are not present on the main page
People are working for years now on this front page. The way one should have done it from my perspective is:
- Use Drupal as a good base
- Start with the main page www.gnome.org and link to old content.
- Replace content to be part of Drupal slowly one by one.
- Focus on new stuff like news – integrate Planet and Blogs – so make a selection of most interesting blog posts – seperate content into user, developer and general public.
- Enable projects to make their own pages (replace /projects)
- Focus on user logins. So if you log in – you can comment in blogs, participate in projects, access hidden parts and get more rights to add content.
With a given layout and some work one would have been able to replace the main page in less than a week. One could have started in trying to move that page 1:1 into a CMS (an so have a theme which represents the current status).
It is unfortunate that the switch to a new CMS has taken so long. My help for guadec.org was not accepted (but it looks good) and also shows Drupals great flexibility. In may not be the greatest CMS – where Drupal is to get things done – and that I think is most important. I am tired of outdated sites or sites that never get done.
In the WGO (www.gnome.org) decision cycle one of the errors that have been made is that everybody could add some requirements – and that then after that a specification was set up. Drupal was dismissed by Quim Gil because of the following reasons:
- 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
- not convincing the i18n team and/or
- 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.
Here are the reasons to choose Plone in the end.
if one looks back i think the most underestimated thing is the learning curve and Quim did not see that from my perspective Plone sure has the highest learning curve of all CMSes that I have looked at. And I know many projects who say the same. And as we did not have a new CMS on 2.18.0 , 2.18.1 and still not at 2.18.2 one can and should say that people where not able to move quickly enough to a new CMS with Plone. So to choose Plone was clearly the wrong decision as the goal to have a new CMS ready not later than 2.18.0 release. may experience is that Drupal does not do everything perfectly but it provides all important tools and one can quickly start to put content in. Abut the lack of really good localisation – if I look at the situation right now – we still do not have localized pages – and are far from new pages. And Drupal also moves forward and gets better – so i guess at the point that localisation would have been a real issue Drupal would have supported it better – and also one could have won some people working on it to help GNOME.org. Its more easy to fix one module as to fix a whole CMS concept (Plone will never be easy to use!). Its sad to say that GNOME.org is stuck now and to see that exactly happened what i feared – and even worse.
Personally i would welcome to see more self criticism in that sense. its not a bad thing – everybody makes errors – but if people ignore their own errors they will repeat them. I fear most of the people who made this decision will not admit that this was not the right decision. Actually it turned away some people from participating.