Evaluating specific CMS options

We took a closer look at seven options:

APC ActionApps: The distributed network model is central to the design of ActionApps, which lets users share “slices” of content with other ActionApps sites. The limitation of the slice model is that it is a content distribution scheme that is specific to ActionApps, so any telecentre network sites running on other systems would not be able to participate in the content-sharing scheme. While there is some RSS support it is not the primary mechanism for content-sharing, and both blogging and wiki functionality are still under development. We were also concerned that the small developer community for ActionApps did not promise significant growth on the platform.

Mambo: The user and administrative interface for Mambo was one of the best-designed options on our shortlist. We were also interested to note the emergence of Soapbox, a Mambo toolset geared towards the nonprofit community. The Soapbox toolset is however limited (at this point) to integration with the Democracy in Action CRM, and to single sign-on among sites. The information architecture of Mambo itself proved incompatible with the telecentre.org project, since it is structured around categorization (rather than tagging), which in practice imposes such limitations as precluding multiple categorization of inbound RSS feeds. Since much of the telecentre.org network’s content will need to be distributed to multiple categories (e.g. a story on a Bolivian wifi project needs to be tagged “wifi” and “Latin America”), the categorization structure was a deal-breaker.

Plone: As a CMS based on the Zope platform, Plone offers much greater programming extensibility than other CMS options we considered. The flip side of this virtue is that Plone’s relative advantages are much less compelling for a project that (like telecentre.org) specifically wants to limit its custom programming commitments. Ultimately our biggest concern was that Plone’s RSS aggregation capacity was not part of its standard install; while adding an aggregation module is a trivial technical challenge, the lack of native aggregation support spoke to the platform’s orientation towards single-site content management rather than distributed community.

SocialText: We used SocialText as a platform for circulating our requirements, which gave us an opportunity to try out the software in action. SocialText was appealing primarily as an EIAB option, and once we decided to focus on choosing a single platform for both EIAB and SNIAB, SocialText made little sense. In particular we found that its pricing model – based on per-user or per-day pricing – made little sense for our purposes, and reflected the fact that it is really a collaboration platform rather than a content platform.

Userland Manila: As a CMS that began as a blogging platform, Manila seemed like a promising option for a community-oriented web platform. However it lacked many key features we required, including wiki support and flexible, native RSS support. While it would be possible to extend Userland with scripts that allowed (for example) aggregation of different RSS feeds to different areas of a site, the extent of custom-scripting needed to effect the kinds of RSS control we’d like indicated that Userland was oriented to single-site CSS rather than distributed network community.

TIG (Taking it Global): Taking It Global is an NGO that runs both its own TIG community on a homegrown platform, and offers that platform to other users (such as the Digital Divide Network). The platform is specifically oriented toward supporting multiple sub-sites, but its model for supporting multiple sites is based on storing all sites on a single server (and in a single database) rather than as a truly distributed network; this would make it difficult to integrate non-TIG sites into a TIG-based telecentre.org network. While we were confident in TIG’s ability to quickly and efficiently deliver additional programming as needed, the relatively long list of features that would require custom programming for our purposes (site-wide tagging support, separate aggregation pages, wikis) again suggested that the TIG platform was not fundamentally oriented towards an RSS-based distributed network.