Forum OpenACS Development: Re: FYI: My Vision and priorities for OpenACS
I think we should explicitly avoid being labeled as "groupware", "CMS" or whatever because we will always be behind the ball. This is because in a buzzword laden world there's not choice but to differentiate an application every few years, and we'll never keep up.
For example, "groupware" was adopted as the industry term after "community" ran its course. Now, "social networking" is replacing "groupware". Whatever they mean, it's all crap because the software stayed the same - just the VC money went different places.
Furthermore, the OACS is being used by many different people than just groupware/community/whatever developers. For instance, Andrew's use of the OACS is for a hedge fund application. Bart is working for a company using it for a semiconductor modeling application.
The reason they chose OACS is because it provides a foundation for generic services like user registration, notification, permissioning, etc. In other words, they are using it as a platform for web-enabled database applications.
Furthermore, the development tools are quickly moving in that direction. The OACS is finally fulfilling its promise (thanks to all of our hard work) as a services based platform in which a sophisticated application can be quickly cobbled together because of tools like ad_form and listbuilder and APIs for the CR and portals.
What this suggests to me is that we ought to market the OACS as a platform and use examples of vertical applications (another promise that was long ago made and now being fulfilled.) We can point to things like .LRN and Project/Open as examples.
Ultimately, we should have things like this:
OpenACS - Platform
Groupware
.LRN
Project/Open
CMS
XCMS
CRM
Cyber-advocacy systems
This is what the J2EE and the .NET folks are trying to do = build the infrastructure and let specific markets and developers decide what to do.
I think ultimately this will be a more beneficial approach as the OpenACS community can be more honest with itself. We are not marketeers, but a community of software geeks trying to do as good a job as possible developing the OpeACS.
Which brings me to Apache... I think this is important to make our next big step. I disagree with Barry that mod_tcl will do the trick, although I could be wrong. I think John's approach will ultimately be easier because it models AOLserver a lot closer and because it uses FastCGI, once it works we get every other FastCGI enabled server for free (namely IIS).
I also think that Apache+Portable.nsd will never be equal in stature to AOLserver, but it lower the barrier to entry massively. People (and I am less interested in the geek who disregards AOLserver out of hand than I am in the IT department with policies about which apps can be deployed) are not too afraid of Tcl once they understand the OpenACS. Almost all servers in large institutions or enterprises are running Tcl in one form or another so that really isn't too big of a deal.
Sysadmins are a big fan of downloading and giving things a run, though, and if they can do so by setting up FastCGI, Portable.NSD and PG, they would be happy to do so. I know this from at least three conversations I had with IT staff from universities at Linux World last week.
After they run OACS, and they are inevitably impressed, they will go the extra distance to try out AOLserver. This I'm quite sure of. Particularly if they are considering deploying the application for 40K users.
The other benefit of course, is in integration. Providing an Apache front end (either with Portable.nsd or even some kind of interface to AOLserver using mod_proxy or native FastCGI tool) would be a big help as we would have access to the full range of apache mod_*.
Anyway, those are a couple of extra thoughts.
talli
