Forum OpenACS Q&A: Re: Reuse in the large is an unsolved problem !?
I read Lars's comment and agree with most of it _if_ you are trying to build a small-scale (in terms of functionality) website with forum discussions etc.
OpenACS is complex. But that's just part of a "maturity cycle" that all (successful) software packages go through: It starts lean & mean & incomplete, then it gets "improved" and finally it's getting too complex and being replaced by the next hyped architecture/toolkit/... Remember when client-server architectures were cool?
So, yes I agree with Lars that it may be quicker and cheaper to use a new lean & mean & incomplete architecture to build "yet another dynamic website" because of the lower overhead. No surprise until now.
However, many of the OpenACS websites, dotLrn and ]project-open[ share a background of organizational and technological complexity (distributed client organizations, not fully rational customer behavior, heterogeneous IT environment, etc.) that require a certain functional complexity (permissions, ...). I think that LDAP integration may be one of the best examples. Lars says it's largely irrelevant in his market. Perfectly possible. However, it's a major sales argument to our customers, because they have already Active Directory deployed in their organization.
Many say that the OpenACS data model or permissions are too complex. I guess that this is an indication that there is a mismatch between the application domain and the toolkit. In this case you should definitely look at RoR. Or SugarCRM. I just had a look at its data model and I was amazed by its simplicity. However, you'd never be able to run a reasonable report using these systems, because there is no referential integrity in the database and you'll probably never get your data right. That's a minor issue for a minor website, but there _are_ applications where it does matter. You are basically trading in the short-term advantage (simplified development of small systems) for a long-term disadvantage (increased complexity in complex applications) because you have to handle RI exceptions on the scripting side.
Having said all of this, I agree however that the OpenACS community is "basically dead". It's dead, because it's not growing as fast as the other ones. At least this is what "open-source economics" say. However, this may not be as bad as it sounds. OpenACS is condemned to be a system in a "niche market". But it may actually a very interesting niche market, comprised of the biggest online communities in the world. However, the "branding" of OpenACS doesn't fit this to this market position at all. But there seem to be already action in place to improve that.
Funnily, this "niche" situation is actually an advantage for us (]project-open[ is basically a small ERP system built on the OpenACS platform, http://www.project-open.org/). It creates a "barrier of entry" keeping potential competitors from copying us. It is actually comparable to having a proprietary platform. I know that this sounds a bit ugly, but I guess that this was also a consideration during the foundation of the dotLrn consortium. OpenACS service companies such as Solution Grove and Cognovis probably love the lock-in effect that keeps their customers coming back to them for support...
Finally Form Builder. What a nightmare of obscurity. We have actually resisted quite some time from using it, receiving bad Karma points from the community during years. Just like Lars said: Just hand-code the forms, it doesn't take much longer. However, this situation has changed since we have integrated a consistent SQL metadata system, thanks to input from Quest Computing (thanks a lot to Ciaran and Merv!). Now Form Builder allows us to automatically integrate metadata changes in our edit screens. So there is at least a real benefit benefit from using it...
To conclude: OpenACS is already a "niche" product, but I firmly believe that OpenACS is the right choice today to develop new complex web communities and ERP type applications such as dotLrn and ]project-open[. Let's try to spread this message in a more aggressive way.
Frank
mailto:frank.bergmann@project-open.com
http://www.project-open.com/
