I want to thank John for his comments (they are always "spot on), but also tease them out a bit in a series of posts.
During one of our conversations several years ago over coffee in Cambridge (US), I recall John saying:
"Hey, Al, you guys really need to focus on an easy installer and make .LRN a configuration option for OpenACS."
John reminds me of a physics professor that I had in college. His statements even at face value were valuable but the real insight was something deeper: take this thought, develop it, and you will be rewarded. Let me take the John installer thought a bit further, even if John ultimately might disagree with where I am taking it.
The starting point is that there should be an identical installer for OpenACS and .LRN. It can be implemented using switches or whatever, The deeper point here is that we should not be view OpenACS and .LRN as separate products and processes. As John indicates, "The impression that .LRN is another layer on top of OpenACS with different developers having different agendas does not help."
If OpenACS and .LRN are equivalent in terms of code base, how are they different? First, .LRN would always be a subset of OpenACS and not an "additional layer" on top of OpenACS. Secondly, ".LRN certified" components would need to pass an additional set of QA to receive the designation. Third, in addition to a higher level of quality code of individual components, the ".LRN-certification" would also provide assurance of integration among the certified components. Fourth, .LRN-certified components would also be tested for scalability. Finally, there would be a commitment from the consortium members and the community to always keep the focus on quality for the already certified components. We would also always provide an easy upgrade path for the latest release.
In short, .LRN would be that integrated subset of OpenACS which is enterprise ready.
I believe that it benefits neither OpenACS nor .LRN to think of .LRN as software for the educational community. I come back to another point that John keeps reminding us of, namely that a course should be viewed as just a "special case" of a community. Now, this is the reason why we (MIT Sloan) went down this path. We were not interested in building a course management system to compete with Blackboard of WebCT. What we wanted and needed was a platform that would support knowledge communities of all kinds, whether it's a student organization, a research community, or a project community.
Again, here is a one line sales/marketing pitch for OpenACS /.LRN:
"We have a product that you can install quickly, upgrade easily, and is enterprise ready out-of-the-box."
The pitch to be an educational instutions (K-12 to ., a non-profit, a corporation, any organization that has a need for collaboration and online communities.
"And, by the way, the software is backed by the .LRN Consortium, which consists of these organizations...."
The list of organizations should be deeper than educational institutions and ideally include everyone who is using the certified components.
In short, we should begin to view ourselves as a single community that produces the highest quality software to support online communities of every sort.
