In last week’s Web@Work column I took on a bit of an apples and oranges comparison: One of the challenges of working with open source software is dealing with the variations that exist from product to product. osCommerce and Mambo, two of my favourite open source products, provide a classic example of variations in standards and fundamental approaches to software development. I started on a new osCommerce project a couple of weeks ago and once again find myself struggling with the customisation of the system. osCommerce, while a powerful and full-featured ecommerce package, is a real beast to customise. In contrast, the newest version of the Mambo content management system is a breeze to use and customise. Both products are open source, but show widely divergent approaches to open architecture. Working with open source applications is a mixed bag for programmers. While you may love the open architecture, you are unlikely to love some of the other aspects. Insufficient documentation is the common complaint, with inconsistent coding standards coming in a close second. Both Mambo and osCommerce are mature, successful products. They have a similar technical base, both being written in PHP and running off the mySQL database system. Both have dedicated teams and a well-structured administration process, yet they exhibit a wide divergence in their approach to code. Why the big differences? The first difference lies in the relative intricacy of the two systems. osCommerce is a very complex catalogue and ecommerce system. It handles products, order processing, shipment and payment systems. It also has a back office component that enables the issuance of invoices and shipping labels and provides the site owners with data concerning their inventory and stock levels. It is an ecommerce application and that means it must be able to deal with the necessary security precautions that go hand in hand with transacting online. Mambo, in contrast, is a content management system and a web site framework. That is, it provides a foundation upon which you can build what you want by adding in additional modules and components with increased functionality. While it is complex, it does not exhibit the same level of intricacy as osCommerce and does not have to be as concerned with security issues. So, on the surface at least, it seems logical that Mambo is easier to open up and modify. However, a close look at the code, the file structures, and the database structure reveals a different story. The Mambo team’s approach to architecture is logical, modular, and more consistent with current coding practices. Mambo divorces much of the component functionality from the core, so it is possible to modify individual components and modules extensively without having a negative impact on core functions. Mambo code is also well-commented and consistent. The system also relies heavily on CSS to achieve formatting goals. In contrast, osCommerce employs less modularity and exhibits a less transparent coding style. Module functionality is often integrated with core functions, requiring a programmer to tread lightly lest they create unintended results. Comments are sparse and not presented consistently. Formatting in osCommerce is dependent on a multitude of tables and spacer gifs, making the code bulky and slow to load. One of the first things I do with any osCommerce site is strip out as many of the spacer gifs and nested tables as possible. This frequently decreases the overall code length for any particular page by 40% and reduces significantly the number of HTTP requests, thereby improving performance of the site. Substitution of an expanded CSS handles the formatting. In fairness, there are some common problems that plague both systems. Both systems probably have too many features by default, creating unnecessary lines of code and increasing the risk attendant with modifying the code. Both systems lack excellent developer documentation, though both are supported very well by forums and community sites. Neither system is standards compliant nor very accessible for the handicapped. They do not produce XHTML compliant pages and their usage of CSS is inconsistent. Moreover, while one of the benefits of using Mambo or osCommerce is access to the large number of components that have been developed for the systems by third parties, the quality of components tends to vary widely and standards are often not respected in those bits of code. Integrating those components into a highly customised core can be a challenge. The Mambo development team claims that the next version of Mambo will provide better XHTML and XML support and that some of the shortcomings in accessibility will be addressed. I can only hope that the next version of osCommerce brings improvements as well. Still, at the end of the day and despite their various shortcomings, these two systems are good examples of the bazaar approach to software development, that is, as you walk through the bazaar it all looks to be a bit of a mess, a bit chaotic, but if you look at the large picture, the bazaar is very efficient at meeting the varying needs of a wide number of consumers. They are also living proof that robust, reliable open systems can be built in very different fashions and still achieve their users’ goals. Originally published in Bangkok Post, 9 Feb 2005