Mambo Core Development Team and the Mambo Steering Committee released a Policy Statement outlining the plans for the future development of the Mambo Open Source Content Management System.

The statement outlines the new team's philosophy and approach and provides details on both short and long term goals. If you are interested in Mambo development, or how Team Mambo is addressing the challenges they face, we encourage you to take the time to read this article.

Bringing ideas to fruition

Establishing stability

The Mambo Core Development Team is almost entirely new to the Mambo code and as a result, brings fresh eyes with new views on the state of the project. The released code is feature rich, but the new team feels a need to review a number of the core mechanisms in order to make them robust enough for further long term development. The code that was under development at the time of the fork was incomplete and not fully tested, so without the knowledge that departed with its developers, is considered to be of limited value.

In this situation, the core team's first priority is to deal with the recorded bugs in 4.5.2.3 in order of significance and to tackle all known security weaknesses. The factors that cause these problems are generally well known and it is essential that the security issues be addressed quickly and effectively.

Historically releases of Mambo tended to involve a very high proportion of the total code and sometimes came with disruptive frequency. Goals for future stability include: efforts to implement development and release control procedures that will reduce the frequency of bugs and remedial releases; and, progressive design, with particular emphasis on encapsulation inside sound and documented interfaces.

While bugs are being fixed and security loopholes eliminated, improvements are being made, mostly in small ways, and the team is gaining familiarity with the code.

On minor housekeeping issues:

• The core development team has agreed to use only a standard three digit release numbering system, with the first release to be 4.5.3.


• There will also be efforts to resist feature creep through practices such as last minute addition of functionality. In the case of 4.5.3 no new features are being added apart from the previous work on a simplified user interface, demonstrated in the 4.5.3 beta.


• However hard we try, some bugs are inevitable. Provided these are non-critical, the team will make regular bug fix releases that can be implemented by Mambo site administrators without particular urgency.


• Notification procedures are also being implemented for key partners and third party developers in an effort to improve communication and transparency.

Current Mambo Development Projects

Dates are given for guidance only. Reasonable efforts will be made to keep to them, but in the nature of a complex project that relies on volunteer workers, none can be guaranteed.

• Internationalization is strongly demanded and is considered to be a top priority. Work is currently in progress to decide on the best technical solution. It is expected that decisions will be made on the approach to be adopted by mid November 2005, at which time development will commence. Once standards have been established for data formats, work on translation can commence. This should be under way from the beginning of December 2005.


• The second priority project is to establish a viable Role Based Access Control system throughout Mambo. The ACL facility presently in Mambo 4.5.2.3 is considered excessively large and complex and is being replaced by a lightweight, flexible system designed in the light of recent thinking on OO RBAC mechanisms. It will provide comprehensive access mechanisms that can be used both within Mambo and by third party developers for their solutions.


• Priority is also being given to work on templates, although this is presently at an early stage. However, the goal is to provide a highly flexible facility that will combine two important factors. One is to make some reduction in the freedom of templates so as to reduce the likelihood of security issues through template installation. The other is to retain the ease and flexibility of template development that has been one of the critical factors in Mambo's success.

Mambo Development Goals

Much of Mambo consists of plugins – components, modules or mambots – sometimes known collectively as CMTs. (This part of Mambo is also being called the “outer core.”) The plugins are automatically installed as part of the Mambo installation, unlike third party plugins. In order for plugins to be possible, Mambo requires an inner core.

• A guiding principle for development is to aim at a small, efficient, fast inner core. Code here includes such things as session management, plugin management, core access control mechanisms and database interface layers. One medium term goal is to have more reliable and efficient mechanisms for managing the loading of code on demand. The ability to fully implement this is currently constrained by the lack of availability of PHP5 in the web hosting market, but some steps can be taken.


• Another principle is reduced reliance on large libraries of code. Pulling in libraries is a quick way to create new functionality. There is no intention to cease consideration of good solutions of this kind. However, many of the libraries currently in use are cumbersome. They create difficulties in maintenance that are greater than for internally developed code, and can often place design constraints on future development.


• Vital to improved code is the implementation of encapsulated objects that have defined interfaces. The vast majority of Mambo (including third party plugins) ought to be in the form of groups of classes. Globals should be substantially eliminated as should reliance on properties of objects. There needs to be a clear definition of which classes and methods are intended to be available to three classes of use: within the class, within the Mambo core, and generally by anyone. Documentation should match the type of use. Soundly designed classes reduce the dependencies that arise through a lack of clearly defined interfaces, allowing more rapid development and reduced risk of faults.


• Enhanced security is a significant goal. Basic principles for secure coding are well known and must be consistently applied throughout Mambo. In addition, the team will be looking for ways to increase the security of Mambo systems through features such as code signing and greater database security.


• Backwards compatibility remains a firm goal, although there will be times when this is sacrificed. It is not an absolute commitment, since design changes are needed and will certainly affect interfaces. However, the aim will be to make efforts to sustain existing interfaces at least long enough to give third party developers adequate notice of deprecated interfaces and sound information about alternatives and how to use them.

Policies for Development

In order to achieve the goals stated above, and other significant goals, the following policies are being adopted by the core development team.

• Overriding all other considerations, Mambo's development must be user driven, and attention will be given to requirements gathering. Arrangements have been made with the forum moderators to try to capture the numerous ideas and comments that are not always channelled into the wish list area. The Documentation Team has agreed to be responsible for analysing ideas and organising them into a usable form. When considering the user driven character of Mambo, it is useful to take account of the four constituencies that are most relevant: Those who build sites using Mambo (the web developers), those who manage sites on Mambo (the webmasters), those who visit sites using Mambo (the visitors), and those who develop components, modules and other features for Mambo (the 3PDs).


• It is helpful to adopt a broader concept of “content”. This will help to simplify Mambo for its users, both webmasters and site visitors. Currently, Mambo uses the term “content” only to refer to published articles. However, it is better applied to most kinds of material, such as forum pages or contents of file repositories.
• Well designed and published interfaces are a core policy. Provided they are soundly designed, published interfaces should be capable of being held constant over a sizeable period, even though the implementation behind the interfaces may have changed considerably. Everyone involved in development, both on the Mambo outer core and on third party products, is entitled to have up to date documentation that relates to reliable and predictable functionality.


• In the area of interfaces and elsewhere, it is highly desirable that documentation be delivered simultaneously with code. In the case of documents such as user manuals (more than one may be required, allowing for the different kinds of users) it is highly beneficial if the manual is a part of the development and QA process, and they are thus prerequisites for the completion of developments.


• Maybe it should go without saying, but it is the policy of the development team to create sound and efficient code. The development team will aim to use modern techniques to maintain high quality output.

Hosting Policies

A few simple points will illustrate the current intentions with regard to hosting. A good many practical problems arise with hosting, and efforts will be made to provide better documentation on these.

• The base requirement for Mambo will be raised to PHP 4.3 and MySQL 4 at the next release after 4.5.3.


• A general direction of reducing reliance on the file system will be pursued.


• There will be correspondingly greater use of the database.

Near future development projects

• There will be continued efforts to establish adherence to current web standards such as XHTML. In addition, a project will be started to deal with questions of accessibility.


• New capabilities for making Mambo “Search Engine Friendly” will be introduced in an early project.


• Mambo will be provided with flexible nested folders to any depth, to replace the current two level system of sections and categories.

Longer term projects

• Database portability is an important goal, but is treated as long term because it is highly likely to break plugins. The development policy has been provisionally established as the building of dedicated Mambo interfaces to established database products. PostgreSQL will be an early implementation because of its high level of ANSI compliance, which will test the flexibility of database use by Mambo and third party programs.


• Multi-site administration is in great demand from some quarters, and is clearly needed by people running large numbers of sites. It has to be a longer term project because of its complexity and security vulnerabilities.


• In the long term, the development team expects to see XML become much more central to CMS content. It already has clear advantages for multi-purpose material. However, it is not a short term goal because of the lack of sufficient adequate tools, such as XML editors.