JEvents

The ".0" suffix of "web 2.0" means that anything labeled "web 2.0" is absolutely the first, largely untested, untried, but "working well enough in the factory" version of whatever "it" is with the prefix number and name, in this case the "web 2" prefix.  Also the developers of ".0" web server code, in this case CMS code, feel confidant nothing, or only very tiny bits, of whatever "it" is will not "break" and cause major harm to end-user data or cause major frustrations for the end-users when in the case of CMS software they try to build and manage web sites with "it".  That also means "it' is not yet sufficiently refined and improved by the developers responding to end-users' complaints, remarks and suggestions to be called the next version, i.e. in this case, "web 2.1".

In general I say: beware of any software or hardware that is numbered ".0" (point zero).  It may work "ok", but it not has not been fully "field tested", i.e. tested in very many more real life situations than the software or hardware developers ever anticipated!  Hence there is a need for end users of new ".0" hardware or software to give feedback to developers to fix bugs, to add requested new features, and in the case of CMS software to otherwise improve the code, the functionality and performance of the web server code between the release of version "Point Zero" and "Point One" of it.  And the same applies for improving something that is ".1" to ".2" and so on.

Some advantages of any CMS:

The site administrators transfer much of the content creation and administration activities to the end-users of the site.

• The site administrators transfer much of the content organization and re-organization of the web site content to designated end-users called "publishers", "editors" or content "authors".  Once a web site is, say, 50-80% built and "working well enough" that end-users can begin adding content to the web site, this CMS ability to allow the delegation of some site-building and maintenance activities to the end-users gives the site-builders and administrators more time per day, per week, etc. to improve the web site without disturbing the on-going activities of these "early adopting" end-users.
• The end-users of the CMS can create their own web content, edit is, keep versions of it, delete it, and "llink it" within the CMS-powered web site to one or more different categories and sections of web content on the site.
• The site-builder can "add-on" new features and functions to the web site without shutting down the web site.  In the case of the Joomla CMS, the site-builder adds to the web server what are called extensions.  Extensions are additional special purpose PHP code which the "core Joomla system consisting of different 'operating environment' PHP code" immediately recognizes and executes appropriately when the next end-user makes a request for a web page that requires the execution of the new code to give the user the web page or parts of it.

Some problems others have found with "CMSes" not yet identified by name to me:

• They are "fat".  I think this means:
  
  1. The code that makes the web site work to present web pages and which makes the features and functions of the site more easily extendable takes up a great deal of hard disk storage space on the server computer.
  2. The database for the web site is very large compared to just creating and storing on the web server a number of much simpler, 1990s-style HTML (version 4) web pages and letting the web server present them to the end-user who is using a web browser program.
  3. A lot of web server code for the web server to "interpret" and execute during any single web request for a web pages, such as is in any CMS, means the web server will run slower when responding to an end-user request for a web page.
  4. A slower-running or responding web server means when there are lot of end-users trying to use the site at the same time, i.e. simultaneously, the server will respond even slower to all of them!  Also the web server may even "break" to the extent that it refuses to respond to some of the simultaneous web page requests forcing those end-users to wait several minutes to receive their requested web page.
• One CMS does not "work well" or "play well" with another CMS.  It is relatively hard to impossible in some cases to "export" database information from one CMS and "import" it into another different type of CMS.  This fact makes an otherwise "open source", easily extendable CMS a more "closed" system on which the owners or commissioners of the system must necessarily become more dependent!  In the computer business that is also called "creating job security"; i.e. they the web site owners will "always need us" once they have started using our system.

Some problems I have found in the Web 2.0 Joomla v1.5 CMS:

• It is also absolutely necessary for the site-builder to get to know well the database table schemas for the tables which each added-on extension (i.e. component, module, and/or plug-in parts of a given extension) adds to the system which creates the web site which displays a certain kind or type of web page to the end-user.
• It is very helpful to know fairly well what the extension's PHP code is doing with that table data, what the code does with any other data already on the web site (i.e. in other web site database tables controlled by the Joomla core code and/or by other unrelated extensions), and what the code does with data input by the system users.  And "system users come in two general types: (1) the so-called "front end" users, a.k.a. site visitor and logged-in site users (who have end-user interactions with the web site and it's data) and (2) the "back end" users, a.k.a. web site administrators who have administrative interactions with the extensions code and the web site data!
• It seems from comments I received from other techies who are more experienced in building web 2.0 web sites, usually a given extension -- or set of 2+ extensions -- only adds about 80% of the functionality that the site builder was led by the advertising and terse documentation would be inherent in the extension(s).  Improving the code and revising table schemas to "do more" to get to, say, 85% or 90% of what one originally wanted the web site to do takes A LOT OF ADDITIONAL WORK! That makes "better web sites" more expensive to build.  That in turn puts "better web sites" out of reach of the more poor clients and institutions who want or need to have one.
• Requiring the site-builder to sorting through and try out, say, 2 or 5 extensions with apparently similar functionality also takes a lot of time and effort to see which, if any, is better!  This fact in turn coerces new web site builders to turn to "contract site builders" for help.  The latter have already done the extension study and comparisons.  But their help will be expensive.