Choosing Tools

OpenACS began as a sophisticated data model for community web sites, along with a large number of web/database templates written in Tcl. Over time, it has grown into a much larger project with a number of facets: independent packages that can upgrade both programs and the data model, the ability to work seamlessly with either Oracle or PostgreSQL and a sophisticated templating system that separates programs from the HTML output. And, OpenACS comes with a huge number of prebuilt applications that do about everything you would want for a community web site, from weblogs to fora and FAQs to an ecommerce store. With nothing more than your web browser, you can create a site in very little time.

And indeed, I find myself recommending OpenACS again and again to nonprofits that want to create on-line communities, reach out to their constituents, conduct discussions among the members or publicize information easily, without needing to know much in the way of technology.

That said, OpenACS has a number of issues. First and foremost is the learning curve. Zope's learning curve is difficult because there are so many technologies to understand. OpenACS has a much simpler model, but it stores absolutely everything in a relational database. This means the data is all in one place, but relational databases are notoriously bad at dealing with hierarchies, and all of the clever OpenACS developers in the world cannot mask that.

Thus, learning to work with OpenACS requires that you learn how to implement a simple object inheritance system and the extensive API that allows you to do it. If you haven't ever written stored procedures or worked with databases containing dozens or hundreds of tables, then you may be overwhelmed by the knowledge necessary to work with OpenACS.

OpenACS also suffers from little documentation for developers and none for end users. OpenACS is admittedly a complex system that can be difficult to describe to nontechnical people, but it can be maddening to find nothing to help with that. To their credit, the main openacs.org site was recently remodeled and rewritten shortly before I wrote this article and seems to have made some positive headway in this direction.

Finally, I find it somewhat ironic that OpenACS has become increasingly sluggish over time. Granted, this is because the latest version (4.x, as of this writing) is far more clever about users, groups and permissions than its predecessors, and checking these things with each HTTP request takes time. In addition, the developers know many optimizations still can be made, such that each request doesn't require quite so many database queries.

Several days before I wrote this article, a new report appeared on the Web describing how Yahoo has settled on PHP as a web programming environment. I personally prefer to work in other languages and wouldn't relish the idea of rewriting all of Yahoo in a new language. But for Yahoo's particular needs, it seems like PHP is indeed a good choice. I give them credit for considering all of the options, weighing the pluses and minuses and coming to a conclusion that fit their needs.

As I said at the beginning of this article, I am a firm believer in finding a technology that meets the needs of the problem at hand. As a developer, this means I'm constantly forced to learn new languages, technologies and techniques. At the same time, this means my clients can get a solution that's appropriate for their problems, and I gain broader skills and depth as a software engineer.

The fact that these systems are available free of charge via the Internet means that the only thing stopping you from trying them is time and some effort. I strongly encourage you to find the time to work with them; you and the people you work with will undoubtedly enjoy the results.

Resources