Magnolia 3.5 Enterprise
ABSTRACT
Magnolia is one of the first of a new generation of open source Java WCM projects designed for simplicity and usability. Magnolia's vision is governed by its tag line and motto "Simple is Beautiful." The page editing interface gives the author the experience of "editing the web site" by laying out structured content elements as they would appear on the rendered page. Content is easy to find within the management interface, which is organized according to the navigational hierarchy of the published web site. Many potential customers compare OpenCMS and Magnolia. When ease of use is a primary selection criteria, Magnolia is generally favored. While tight binding between the authoring and delivery views makes finding and editing content more intuitive to users, it comes at the cost of making content less re-usable. Content elements exist only as components of a page and are not easily shared between pages. It is less intuitive to build query driven sites with placeless content in Magnolia. Magnolia's architecture of running different instances of the application for authoring and public access provides a sandbox to preview the full site before it is published. This design also supports clustered environments with multiple autonomous instances of the content delivery servers. Magnolia's caching functionality makes it suitable for high traffic sites such as the Magnolia powered amgentourofcalifornia.com that has served up to 8 million hits per hour. France24 uses Magnolia with the help of Akamai distribution. Like other products in this report, Magnolia offers a free Community Edition and a commercially licensed Enterprise Edition. Unlike Alfresco and Jahia, there is actually a community using and developing the Community Edition. While Magnolia will not offer support for the Community Edition, it is the same code base as the core of Enterprise Edition. Much to the frustration of Magnolia, several very large sites (including France24) run on the Community Edition. In addition to the option to buy support, the Enterprise Edition has a more robust feature set aimed at enterprise customers and is certified to work with different application servers and an alternative repository.

HISTORY
Obinary, now Magnolia International, was founded as a services firm in 2000 - the peak of the Internet bubble. Founders Boris Kraft and Pascal Mangold were experts in WebObjects and built a sizeable practice implementing the Icelandic WebObjects-based CMS Soloweb. Given the amount of integration work required to implement a solution, Kraft and Mangold looked for alternative foundations that would bring down the cost of the offering while maintaining services revenues. After a disappointing survey of the existing open source Java WCM options available, Obinary started to build their own platform. At that time, JackRabbit - Apache's reference implementation of the Java Content Repository - was still in its unnamed infancy and lived its life as a subproject of Slide. However, Obinary was convinced that this project could eventually bring significant business benefits and choose it to provide the core functionality for the new product. Although incumbent Java WCM projects criticized Magnolia for being just a thin shim on top of JackRabbit, Magnolia was able to provide the simplicity and usability which had eluded the more engineering focused products. Magnolia was released under the open source LGPL in November 2003, and was able to shield its users from many of the changes that JSR-170 would go through before it was finally released in June 2005. While the product gained attention, particularly in Europe, Obinary looked for different business models. A donation based revenue model failed. Obinary decided on a tiered product approach with an unsupported, open source Community Edition and a supported, commercially licensed Enterprise Edition which includes some value added features, as well. The Enterprise Edition requires an annual subscription of 10k USD per server. Obinary had aspirations in the DMS market and built document management capabilities into the Enterprise product. But the emergence of the well funded and highly visible Alfresco discouraged their hopes of being the open source Java ECM product. While the document management capabilities remain, they are not the focus of the offering. In 2006, Obinary changed its name to Magnolia International. Currently at 12 employees, Magnolia is experiencing growth and is expanding its team. It has signed more than 30 customers since releasing the first Enterprise Edition in November 2006.

ARCHITECTURE
Like other products in this category, Magnolia is an end-to-end web content management system. To use Magnolia requires adopting it for both your management tier and you web delivery platform. There are many benefits to this architecture including ease of use and development efficiency, but some architects will feel boxed in having to rely so much on the Magnolia architecture - especially if they have invested heavily on an alternative web application framework such as Struts, MyFaces, Tapestry, or Spring. It is conceivable to use an alternative presentation tier (and customers have experimented with many) because of the standards based repository. However, doing so would probably make the product more difficult to use since the editing environment is so closely tied to the delivery tier. Magnolia's original claim to fame was that it was the first CMS built from the ground up to work on the Java Content Repository (See Glossary for JCR). The JCR is a relatively new Java standard (JSR 170) that defines a repository for managing content. The JCR is well suited for semi structured content that is hierarchical in nature. Unlike relational databases, JCR's native support content management-specific functions like versioning, workspaces, and content deployment. The JCR specification has not yet enjoyed widespread adoption. The biggest proponent is Day Software, whose CTO David Nüscheler is the specification lead. Day also has a number of its own developers working on the reference implementation: Apache JackRabbit. Day also sells a commercial JCR implementation called CRX and JCR adaptors for other repositories such as Documentum, FileNet, Lotus Notes, TeamSite, Sharepoint, OpenText Livelink, and Vignette. Outside of Day, however, use of the JCR has been limited. Few CMS companies, such as Alfresco, support the JCR standard with their own repositories but now Oracle 11 supports the JCR natively. Other products, like Percussion, support the spec at level one (Read Only access) and support the query language for finding assets. There is more JCR interest within internal corporate software engineering departments that are building custom systems and want to reduce their risk by sticking to standards. If the JCR is to become a truly successful standard, it will require corporate architects putting pressure on more software vendors to support the specification. The JCR specification is in the process of being upgraded with a new Java Community Process (JCP) Java Specification Request (JSR) called JSR 283. JackRabbit will serve as a reference implementation for JSR 283, as well. Magnolia did a good job of keeping up with the evolving JSR 170 spec and improvements proposed in 283 are not expected to pose too much disruption. That is, certainly not like the the original 170 specification. Architects that are new to using the JCR sometimes have the tendency to want to use it for everything. On the developer mailing list, you occasionally see architects getting "talked down" from using the JCR for inherently tabular data like e-commerce catalogs and order history. By default, Magnolia's content repository is Apache JackRabbit. JackRabbit has a pluggable persistence manager with the default being a file system, which is also the slowest. Other options include relational databases such as Oracle and MySQL. The

binary install of Magnolia comes bundled and configured to use JackRabbit with the Java relational database Derby for persistence. Derby is better than the other commonly embedded database Hypersonic but high end implementations will probably want to use MySQL. JackRabbit has a WebDAV interface; however, WebDAV support in Magnolia is slated for a future release. The Enterprise Edition comes with the option to use Day Software's commercial CRX JCR product. The Magnolia administrative interface contains a JCR repository browser that lets you view and edit the content tree as one would with a database administration tool. There is a free JCR browser plugin for Eclipse, as well. For relational data, Magnolia implementations can use the embedded Derby database or connect to any other JDBC compliant relational database. Magnolia does not use the relational database for much but Derby can be replaced with MySQL if a more powerful relational database management system is needed. This configuration is done at the application server level by specifying a data provider. Magnolia is certified to work on Tomcat as well as full JEE Java application Servers JBoss, WebLogic, and Websphere. Magnolia was one of the first open source WCM systems with a multi-tier design. In a basic configuration, two instances of the web application are deployed: one is designated as the authoring server and another as the presentation server. The distinction is made with an attribute setting made in the management interface. Content is authored and edited on the authoring server and then deployed to one or more presentation server instances. Each instance of the application is called a "stage." Communication between stages is done over http/https.

Figure 1. Magnolia Screenshot: Configure Subscribers

In the authoring server, an administrator configures subscribers that the authoring server will publish content into.

Developers wishing to extend or customize Magnolia can do so by writing add-on modules. The best practice is to write all customizations in modules so that a new instance can easily be brought online by installing the base system, deploying the modules, and then deploying content and template code. There is a Subversion repository for sharing modules, and a couple have been added, but there is no module forge like other projects have. The newly released version 3.5 introduced a more pluggable architecture that may facilitate the sharing of modules. Right now module sharing is limited to the mailing list. Future releases will likely introduce the Spring Aspect Oriented framework. This will enable code to be more easily shared across custom components.

CONTENT CONTRIBUTION
Magnolia provides two main interfaces that content contributors can use to navigate the web site. The primary user interface is "AdminCentral" that is used for all site administration, configuration, and development tasks. The "web site" section shows a clean view of the hierarchical site tree. Color coding is used to express workflow in three states: red for unpublished, green for published, and yellow means that the asset has changed since it was last published. Context sensitive right-click menus show what actions are available to the user based on his security permissions.

Figure 2. Magnolia Screenshot: Browsing in AdminCentral

The main "AdminCentral" user interface is the primary way to navigate to edit content.

The second method of navigating the web site is through preview mode. Content contributors can browse around the authoring instance in preview mode, which shows editable regions as well as buttons for editing. This interface is also used to edit page metadata and move paragraphs around on the page.

Content contributors can browse around the authoring instance in preview mode and edit paragraphs by clicking the edit buttons. This interface is also used to edit page metadata and move paragraphs around on the page. Source: Magnolia documentation site.

Magnolia is closely tied to the hierarchical model of the JCR. The primary content type is a generic "page" that is composed of "paragraphs" and metadata. Although pages are not "typed" into content types or classes, a page is defined by a template that determines the structure of the page by creating regions that can hold paragraphs. For example, a template might have a three column layout with the center column containing the main page content and a right column containing sidebar content components. In this example, the user would be able to add paragraphs to the center and right column. The template would also control the display of the paragraphs in the page. Paragraphs are structured content types in their own right and can have their own metadata. Paragraphs are defined by and edited with pop-up "dialogs" that can have multiple tabs. In addition to paragraphs that accept content, there are also paragraphs that hold dynamic page components. The default Magnolia Enterprise installation comes with paragraph types for: Text and image, File download, Link, Anchor, Documents: List, Search by topics, RSS link, RSS icon, Movie Player, Code example, Navigation, Breadcrumb, Mail form, iFrame, 2 Columns, Javascript, Full text search input field, Full text search result, MP3 Player, and Text scroller. New paragraph types are defined by creating custom dialogs through the administrative user interface.

Each paragraph type has its own edit dialog. Clicking the edit button launches an edit dialog that contains form fields for the structured elements of the paragraph. Paragraphs can also have their own metadata. Image source: Magnolia documentation site.

This model is different than most web content management system designs that create semantically meaningful content types at the page level. In Magnolia, rather than creating a new "event" asset, one would create a page and put in a custom "event info" paragraph that contained elements for information like date, time, location, and description. To create an event calendar page that listed events chronologically, a dynamic template would need to look for all "event info" paragraphs and display them. The design of Magnolia is not conducive to sharing content across pages but there are work arounds. A common strategy is to create a non-navigable collection of pages that are just containers for global assets. Then paragraph templates can be programmed to pull in paragraphs from these pages. While the strategy works fine, it is a break from the overall browse-to-edit metaphor. Localization, new in version 3.5, is done at the paragraph level. In the Magnolia localization strategy, a language neutral page has a collection of paragraphs. Each paragraph has

its own language specific elements that, in the edit dialog, are organized into tabs. For example, if a paragraph is translatable into English and German, there may be English Title and German Title fields that are on different tabs. When the page is rendered, a locale identifier in the URL path tells Magnolia what language specific paragraph fields to show. It is easy to see how this model would break down in sites that are published in many different languages but it seems adequate for sites that are translated into up to three or four languages. Perhaps companies that work in many languages group the localizations into multiple independent Magnolia instances. However, this design would not effectively enable content sharing between the sites. Another limitation is that the URLs would only be in the primary language that the page was in. For a first attempt, the localization system is not too bad. However, the plan is for a major improvement in release 4.0.

Figure 5. Magnolia Screenshot: Localized Edit Dialog

In Magnolia's new localization scheme, content is localized at the paragraph level. Each paragraph is given a set of fields for each language supported.

Rich text editing services are provided by FCKeditor. By default, users are not able to embed images directly into the text area using an image button. Instead, they need to go to an image tab of the paragraph dialog to upload an image that will be placed by the display template. The image tab of the paragraph dialog may present the user with options such as alignment, text wrapping, and fields for attributes such as caption. This is generally a good strategy because it allows the CMS to be aware of images and give it more control to manage their display. The FCKEditor can be configured to allow other ways of dealing with images, if so desired. Magnolia has no special link management functionality. Internal links are constructed through a path but internally the relationship is maintained through the unique identifier of the asset (UUID). This means that if the target asset is moved or renamed, the link will still work. If the target page is deleted and then replaced with another page with the same name, the linking mechanism will fall back and use the URI to link to

the new page. However, Magnolia does not manage links and is not able to warn a user when deleting an asset will create a broken link. There is also no view of what pages link to a page like in Daisy, Lenya, and OpenCms. Using a third party link checking software is advised. Not all authors like to think of their pages collections of paragraph components. It makes it hard to re-factor text heavy pages when you have to open different pop up dialogs to move text from one paragraph to another. Authors who write text heavy pages will have a tendency to put in hard returns to create multiple paragraph-looking text blocks within a single paragraph component. This is probably not a bad thing. Still, this component page model is a nice compromise between structure and user control over layout. Structuring content in this way allows a template developer to re-organize the layout of the pages by editing the template rather than editing content. However, because page components are not easily re-used across pages, the benefit of the structure is somewhat reduced. Since release 3.0, Magnolia has used the open source Java workflow engine OpenWFE to manage workflow. Magnolia's CTO Boris Kraft is a committer on the OpenWFE project. Like most workflow engines, OpenWFE uses an XML syntax to create "process definitions," although OpenWFE does not use a standards based process definition language, such as BPEL. In the configuration area of the administration interface, there is a place to paste in a process definition. The workflow definition references "commands" which are mapped to classes in the administration interface. The default definition that comes with the basic installation, "activation," has commented-out sections for functions like email notification.

SYSTEM MANAGEMENT AND CONFIGURATION
Magnolia's access control list system is based on the Unix model. Users and groups are granted privileges of read, write, or deny. Access is granted hierarchically on the site tree. Privileges are bundled into "roles." Typically, access is denied at the root of the content tree and then granted at lower branches of the tree. All security management is done through the administrative user interface. The recommended configuration is to assign a base role to all users have that provide a minimal level of read access on the repository. Then users get additional roles that either restrict or allow more specific access. The LDAP integration supported in the Enterprise Edition is only for authentication purposes, although Magnolia does provide an abstract class that can be extended to use information in the LDAP directory for authorization logic. Several Community Edition users have built their own implementation of the LDAP connection module. Importing content would be done through the JCR API for which Magnolia provides a method in its GUI. JackRabbit, for example, has a method called Workspace.importXML() that accepts an XML document as a String. The Enterprise Edition comes with some useful features for enterprise deployments. A packager module can export and import entire instances of Magnolia as packages. This is useful for back-up and recovery, replication, and also for managing developer sandboxes. JackRabbit also has a "systemview" method that exports the whole repository as an XML document. On the Wiki, there are some scripts and Ant tasks that can synchronize content and templates between Magnolia instances. These scripts also handle the JSP template code that is stored in the file system. There are a number of tools available for editing the JCR repository directly. Day offers a free Eclipse plugin that can browse and edit content in both JackRabbit and its CRX repository. However, these tools fall short of the familiarity and power of SQL database management tools. The JCR is a new standard; expect better tool support as the standard matures. Magnolia's multi-site hosting capabilities are limited. The most common approach is to have root elements for each of the sites and then use virtual hosts and URL rewriting to map different domains to specific branches of the content tree. The hierarchical permissioning system can be used to restrict authoring access to specific "subsites." Features like cache clearing are global across the application, so one site clearing its cache will have a performance impact across other sites. That said, many Magnolia users run multiple sites on the platform. They just create a separate instance for each site. With the improved deployment mechanism introduced in version 3.5, system back-up has improved. Regular deployments can back up to other instances of the repository. Companies needing a more robust back-up system may consider upgrading the repository for the default JackRabbit JCR implementation to Day's CRX that provides hot back-up functionality. Otherwise, the best approach is to take the system down and do a dump of the database being used as the persistence layer.

PRESENTATION
Magnolia has a "frying" style presentation system where pages are generated at request time rather than pre-compiled into HTML to be served by a simple web server. Caching is done at the page level using a custom cache implementation or optionally the popular open source caching framework ehcache. Cache is invalidated when new content is published and (now with 3.5) when template code is changed. The main issue here is that cache clearing is global, so high traffic sites should publish at regular intervals to limit the number of cache clearing events. The centralized caching mechanism is one of the key issues that limit Magnolia's suitability for multi-site hosting. Magnolia does power some fairly high traffic sites, such as France24 [http:// www.france24.com/]. High throughput is achieved through clustering presentation servers and there is support of session federation. In this configuration, the presentation tier is read-only. Interestingly, France24 is using the Community Edition so they must have developed their own version of the clustering mechanism that comes with the Enterprise Edition. One common strategy is to publish different sections of the site to different delivery servers. For example, a highly interactive section may be put on another delivery server so that the computational complexity of those pages does not degrade the performance of the entire site. A future version of Magnolia will introduce a "baking" style model where static HTML files are deployed to a web server farm. As previously mentioned, pages are rendered at request time. Magnolia has its own modelview-controller implementation. URLs reflect the organizational hierarchy of the site. Magnolia does support virtual URLs or URL aliases. On the mailing list, some developers have reported success in integrating Magnolia with a Struts based delivery tier although this would probably make more sense when using the unsupported Community Edition rather than wasting money on the Enterprise Edition by making it unsupportable. Content presentation templates have traditionally been written in JSP with the help of the Java Standard Tag Library (JSTL) and custom Magnolia tags that are provided under the namespace "cms". The third party add-on MagTags distributed by Noodle Open Source under the LGPL provides convenient helper tags. Velocity and Freemarker JARS ship with the product but are not, by default, available for use as an alternative templating language. However, it is possible to build alternative "renderers" that leverage these technologies. There is discussion within the Magnolia community for adopting Java Server Faces, or potentially an AJAX based framework (such as Google's GWT-Ext) as a delivery framework. But for now, the officially sanctioned front end of Magnolia is JSP with Magnolia's tag library. The JSP code files are stored in the file system under the "webapp" directory and pointed to by nodes in the repository. The Enterprise version comes with a module called "Sitedesigner" that allows templates to be developed and modified through a design environment within the admin interface. This is a convenient feature for companies that do not have web designers at the ready to respond to template change requests. Sitedesigner consists of a generalized parameterized template that allows a business user to edit properties to control the layout. There are no WYSIWYG, drag-and-drop graphical features that a DreamWeaver user may be

accustomed to. Instead, Magnolia uses the dialog model with bunch of property fields. The edit buttons appear right next to the buttons used to edit content. Sitedesigner template updates are stored at the page level and can be inherited down the tree structure or overridden by child pages.

Figure 6. Magnolia Screenshot: Site Designer

Sitedesigner consists of a parameterized template that allows a user to control the look and behavior of pages by setting properties.

Although Magnolia has a dynamic delivery tier, the separation of the authoring environment and the delivery environment makes it less suitable for visitor contribution functionality. However, there is a strategy to store visitor submitted content in a different workspace within the JCR and replicate that workspace back to the authoring environment. Magnolia does maintain some add-on modules to deliver community oriented functionality (such as forums and polls) but they are extremely simplistic and not well documented. They should, at best, be considered as a starting point on which to build custom functionality. Modules can be downloaded from the Magnolia Subversion repository which organizes them into Community and Enterprise modules. The Enterprise section of the source code repository is password protected. Module support is relatively new for Magnolia, so users can expect more development in this area. Also in the future, Magnolia plans to introduce more visitor facing interactive features. They are currently working on a marketing module that will have functionality like A/B testing and SEO optimization tools like a Google sitemap. Another option for presentation is through a third party JSR 168 (See Glossary JSR 168) compliant portal product. A Magnolia instance can be wrapped in a JSR 168 portlet and subscribe to updates from the authoring instance. Sold separately, there is a Web Services for Remote Portlets (See Glossary WSRP) module that publishes content out to this standard. The WSRP module is new and has not yet been aggressively sold as a product.

Caching configuration is done at the page level based on URL rules. By default, all pages are cached in the delivery tier. Caching is then turned off on a page by page basis for pages that have dynamic or personalized behavior. The Magnolia architecture now tolerates co-existence with other security and cache filters. However, setup has been reported to be tricky. Large, high traffic Magnolia implementations tend to deploy across multiple delivery servers which, although expensive from a hardware prospective, is simple enough to do using Magnolia's publish/subscribe model.

Figure 7. Magnolia Screenshot: Configure Cache

Cache is configured at the page level through AdminCentral by editing URI nodes.

DELIVERY AND SUPPORT
As with many commercial open source projects, you must buy the Enterprise Edition in order to get support for the product. However, unlike other commercial open source projects in this report, there is actually a community behind the community version. The Community Edition and the core of the Enterprise Edition share the same code base. In other words, the Magnolia core carries a dual license: GPL and the commercial Magnolia Network Agreement (MNA). The Enterprise Edition uses the MNA licensed core and adds some MNA licensed code. There are five committers on the Magnolia core who are not employed by Magnolia. The Enterprise Edition costs $12,000 per year per server. Non production servers are half that cost. If you are running WebSphere, your license cost is nearly double that ($22,000 per year for a production server). It would seem the rationale is that if a customer is willing to overpay for their application servers, they can pay more for CMS licensing. This pricing system is new and it will be interesting to see if it works out. Because of the way the Magnolia project is organized, using the Community Edition is actually viable. Some of the largest Magnolia sites (including France24) are running the Community Edition. Some of Magnolia's 30 paying customers that license the Enterprise Edition are really running on the Community Edition. They bought Enterprise for support but do not use the Enterprise Edition features. The Community Edition usually comes out a couple of weeks before the Enterprise Edition. This time is used to certify the platform on the various supported application servers and to ensure compatibility with the extended feature set. When bugs are fixed, they are fixed in the common code base. Magnolia is a small company committed to being a dedicated software company rather than a software and services hybrid. The challenge for them is to build the Enterprise Edition license base to increase revenue on licensing and support fees. But it is not easy for the company to convert Community Edition implementations into Enterprise customers because the Community Edition gives most users what they want. Magnolia is actively growing its partner program. Most of the official integration parters are in Europe but there is a growing number of North American systems integrators that do Magnolia implementations. However, there is only one official U.S. based partner. The monetary hurdle to be listed as an official partner is minimal ($1,250) but there is a requirement to buy a high tier support package. Consultancies that make this commitment get a 25% commission on sales. The mailing list for Magnolia is active for a community of its size and it is your best resource for information other than paid Magnolia support. The documentation is very thin, especially for the 3.x releases. The Community wiki (http://www.magnolia.info/wiki/ - recently ported over to Confluence) is frequently better than the official documentation (http://documentation.magnolia.info). There are some Javadoc comments in the code base and the code is relatively well named and easy to follow. From a social perspective. Most of the action happens in Magnolia's home territory in Switzerland where there are social gatherings. Magnolia has opened an office in New York

CONCLUSION
Table 2. Magnolia 3.5 Enterprise Summary
Category Contributor Navigation Score Explanation The tree-based AdminCentral interface is the content contributor's starting place, but from there he can launch into the preview view for an in-context editing experience. The content entry model is very page oriented, which has the advantage of being intuitive for most uses, but is weak for semantically meaningful content types such as an "event." WebDAV would help with uploading binary files. Spell check would be helpful too. Magnolia is the only product in this category without a strong link management system that discourages users from actions that break links. Full versioning support with new version created with every save. The page oriented editing model does not naturally lend itself to high levels of content reuse. While many customers use Magnolia to run multiple language sites, parallel localization is new to Magnolia and this first attempt is rough. The standards based JCR repository is well designed for integrating Magnolia content in other applications. Java developers will be familiar with writing JSP/Java code to interact with any relational data source. A basic approval workflow comes out-of-the-box. More complex workflows are supported by pre-integrated OpenWFE workflow engine. The JSP based delivery templates are easy for a Java developer to work with and the paragraph model can be easily translated into page components for building flexible pages. The Sitedesigner tool enables nonprogrammers to control the look of the site. The main question is where to put user submitted content since the publishing model is based on a uni-directional flow between the back-end authoring server and the front end delivery servers.

Explanation XML orientation tends to output clean XHTML. User friendly, human readable URLs are supported. None The new documentation site (http:// documentation.magnolia.info) is extremely thin and does not cover any of the new features introduced in 3.5. The developer and user mailing are fairly active as the community version of Magnolia is widely used.

Books Online Documentation

User Forums

Key:

Nonexistent;

Below Average;

Average;

Above Average;

Exceptional.

Magnolia hit the market at precisely the right time: when buyers were looking for a simple, easy to use Java based WCM product and when the JCR was beginning to emerge as a stable platform to build on. As a result, Magnolia International has been able to rapidly build a compelling product without the need of venture funding. While Magnolia CMS has enjoyed widespread adoption, the company has been trying to figure out a business model that will turn the success of the product into corporate growth. From a business perspective, Magnolia International is somewhat between Alkacon and Alfresco. Like Alkacon, the free version is, in itself, a useful product that large companies can deploy. Like Alfresco, Magnolia asks their customers to buy the Enterprise Edition to be eligible for support packages. However, Magnolia is not as forceful in pushing users to the Enterprise version... probably because they don't have the same venture capital revenue pressures that Alfresco does. Although Magnolia (the company) is small, it seems stable and solid and gets high remarks from their customers. As an open source project, Magnolia appears to be a safe technology to adopt because of the install base and the development energy behind the underlying technology: the Apache JackRabbit JCR.