'The problem with OpenACS or OACS is that they both still look too much like "ACS," which is exactly the confusion we're trying to
avoid' (Michael Feldstein).
I agree that as OpenACS evolves away from ACS, there will be a need to differentiate more clearly between the systems. Is OACS ready to make that distinction?
At this point, most of the work is still porting software and critical documentation--not new modules.
thoughts on changing name:
weaknesses:
- changing names can be a sign of whimsical support --lacking dedication to objectives etc.
- changing name away from ACS reduces message that OpenACS is alternative to ACS
- Loss of ACS as a keyword for finding OpenACS as a viable alternative.
- the greater the distinction between the two systems, the less likely we can use (now) proprietary (copyrighted) documentation to support the project.
strengths:
- creates new distinct identity for project
- helps everyone differentiate between the OpenACS and ACS
- gatekeepers can write their own OpenACS books...
I offer the following words to the creative pot:
- phronesis - evolving community-centric knowledge (origin Greek?)
- Cadre or Cader - Means "framework". Essentially, OpenACS strives to be machine/OS/DB/other software independent... leaving a power framework at the core. Seems a nice acronym could be made from it as an alternative to the other great choices.
holiday cheers
