Carl and others, My post was Socratic because I wanted to get a feeling for what others thought in the community. The consensus, with which I wholeheartedly agree, is that there should be a single process for releases, installations, etc.
If we continue to distinguish between OpenACS and .LRN, I would like the community to agree to the following:
.LRN should not be viewed as something built on top of OpenACS. Instead, .LRN should be a subset of OpenACS. I realize that this is currently not the case, but we should move quickly in this direction.
Secondly, I would like to gain acceptance within the community on how to demarcate .LRN from OpenACS. The current way of driving the distinction is to say something like: "it's the OpenACS-based application for eLearning". I would like to get away from this way of thinking. .LRN should become the OpenACS core + any component "certified" by the community as enterprise class and enterprise quality, irrespective of its use. If the Events module or Project module become enterprise ready, then we should designate theme as .LRN and make it available as part of the .LRN release.
Thirdly, .LRN consortium should become a funding arm for ongoing OpenACS infrastructure enhancements. But if that's going to be the case we need to encourage all OpenACS users to join the consortium, whether or not they use .LRN.
This means that statements such as the following would soon be non sequitir: "We use OpenACS, not .LRN". I am proposing a re-think of OpenACS / .LRN relationship. Every user of OpenACS is ipso facto a .LRN user and should join the consortium. Again, .LRN would be a subset of OpenACS components that meet or exceed an enterprise quality threshold.
