His notion might have backgrounds in only looking at the projects listed on OpenSourceCMS.com, which only lists lightweight, mainly PHP-based content management systems, not any of the heavier-duty ones.
However, it is true that most Open Source CMSs are not that good. A major cause for that is duplication of effort. Everybody wants to build their own CMS and not improve the projects started by others, and so the wheel has been invented a huge amount of times. OSCOM seeks us to improve that by advocating collaboration and usage of common standards.
Let's take a look at how the improvement recommendations apply to Midgard CMS:
Make it easy to install. Your tool will see better adoption if you stop to consider the out-of-the-box experience before you ship it.
This has traditionally been the weak point in Midgard. There have been many dependencies to solve and packages to compile. However, Midgard 1.6.0 is a big improvement to this.
The Debian packages made by Piotras and Daniel's packages for most RPM based distributions made with Build Buddy will make the actual installation very easy and having MidCOM environment available out-of-the-box helps too.
Make it easy to get started. Give first-time users a series of quick wins that become increasingly complex. When I first log in, I want to create a Web page.
Even after installation it has been difficult to figure out how to get started. Now MidCOM and Aegir are bundled in the midgard-data package and so the Getting Started guide should be easy to follow. Midgard 1.6.0 also provides a friendly Welcome Page.
On a longer term there will also be the Midgard Site Creation Wizard.
Write task-based documentation first. Most systems have installation instructions that are quite good: "First do this, then do this, this, and this." But when it comes to actually using the CMS, they revert to feature-based docs, carefully outlining what each feature does, and typically from a back-end perspective.
Separate the administration of the CMS from the editing and managing of content.
Midgard does this already. MidCOM Authoring Interface System (AIS) is the end-users' content management interface that is provided as part of the website itself. For site developers and administrators there is the Aegir interface which provides access to users, templates and code.
Users of a public web site should never - never - be presented with a way to log into the CMS.
This really depends of preferences. Maintainers of small business websites like to have the login link handy so they don't have to remember or bookmark it, whereas bigger organizations usually want to hide it, and potentially disable access to the editing interface from public network completely.
In MidCOM Site Template there are three possibilities here, depending on site settings (/midcom-admin/settings):
- Login link is always displayed (default)
- Login link is never displayed
- Login link is displayed only for specific port (internal staging port, SSL etc)
Stop it with the jargon already. I don't know what a portlet is. Or a component, module, block, or snippet.
Good point. Being mostly techies themselves, CMS developers usually fall into using jargon. And since there is no standardized vocabulary for content management, the jargon may vary greatly between projects. Jargon should not be allowed in marketing descriptions for the CMSs, and even elsewhere it should be documented or accompanied with a description.
Why do you insist Web sites have "columns"? I've used quite a few systems now that have the notion of a 3-column layout. They give me the ability to turn columns off and on, and put "portlets" into "content-slots". Where does this assumption come from?
The three-column layout is a very typical convention in blog engines, community CMSs and portal systems modeled after Slashdot. Most real CMSs provide a less cookie-cutter like approach.