Hi Maciej!
I'll try to answer the questions from my point of view. I wouldn't take it for the general truth, just my opinion. :)
At my company we've had, and still have, a student (Jonas) writing a master thesis about company clusters and how to increase cooperation, knowledge and awareness (of other companies) by the help of a community portal. The site is online but still a prototype and awaiting evaluation. We are using OpenACS as you might have already guessed.
It was, by no means, obvious to use OpenACS for this, which leads me to answering your first question.
1. Jonas studied and evaluated 6 different systems (being open source was a requirement), Drupal, Mambo, PHP Website, Xaraya, Zope/Plone, Xoops and OpenACS. (Not sure about spelling of all the names here.) Most of the systems he tested failed on grouping, permissions and scalability. Most of the systems had "better looks" than OpenACS, OACS was the last one we tested, since I figured it needed too much programming to change to what we wanted.
Mambo had a feature that could be bought, where permissions and ease of creating additional communities were supposed to be easy (not tested). The original way to create additional sub sites and communities required a doubling of the amount of tables in the database for each new community and since it was supposed to be open source, Mambo failed.
Jonas failed to install Zope so we discarded it.
Xaraya couldn't create additional communities and didn't have a good permissioning system.
It seems the general similarity is that he looked at great looking web publishing systems when what we needed was a community system. I would look at the other systems as not direct competitors, in our case at least, but as systems that could become competitors in the future.
2. CON 1: The drawback of OpenACS was really the looks of the system from a user point of view. There is no simple way to change the look and feel of the system by just changing a template. We had to write our own templating system (not to mix up with the existing ACS templating system). It was not hard but takes a lot of effort to change all the pages to work in a way that lets you change the overall template in a simple way. We would like to help bring back the templating system to the community if the community is interested? :)
CON 2: There is a rather steep learning curve to install and understand the inner workings of OpenACS. But once you know it it's really good, fast and useful.
PROS: The system is very scalable. The community is very friendly. The documentation is sometimes outdated and hard to find but it is generally good (much better than for other systems). The most important parts for us are the permissioning system, the availability of grouping and last but not least, it's community oriented. It is very easy to create a new community and rather easy to create separate spaces for groups and communities.
For the system we built, we spent like 2 months full time, where I was able to help a beginner with technical questions. In these 2 months there is also the major job of planning, negotiations with other companies, testing and configuration, where the small part is actual programming. We made the prototype user friendly with very few and obvious choices for the user. We also did usability testing. OACS is not programmer friendly for a beginner, but I guess any complex system would be like that.
3. I would call it an online community. Not sure if there is a good name for this yet. :)
4. Open ACS in itself is a developer's toolkit. It has a lot of services and applications that can be put together to a complete solution for you or your organization. I would like to put it like this: Open ACS has a set of applications like a portal system, project manager, calendar, etc. Open ACS also contains a set of platform services like content repository, events and permissions, that are used by the applications. Put together in a clever way they make up vertical applications like .WRK, .LRN and Business Community Networks.
I hope this helps,
Hakan
