One possible way to reframe some of the ideas in Al's most recent post in the context of Open Source philosophy is to consider the possibility that the "source" which is intended to be Open in dotLRN is more than just software code. There are methods in teaching--pedagogical API's. Those API's are still largely undocumented, particularly in the context of online learning.
What excites me about the idea of dotLRN is that it potentially enables me to explore and share best teaching practices using the software code as a medium for that sharing. If I learn a new, better way to teach online, and that way can be supported by the software (or, as Don Norman would put it, the software offers the proper affordances), then others will find it easier to pick up on the same technique, extend it, and give it back.
Framed that way, it becomes clear that the software is only part of the code that needs to be maintained. It is entirely consistent with current Open Source methods that the people who know the code and write the code should have stewardship over that code. Under this more expansive view of what constitutes source code, it becomes clear that technologists should be the stewards of some pieces while educators (i.e., the people from MIT, Berklee, Heidelberg, and elsewhere who will be using dotLRN to teach) should be the stewards of other pieces. Multiple gatekeepers with multiple backgrounds are required to get the job done.
The view that I just described does not capture the fact that the users are also the customers here, which Al articulates so clearly and which is an idea that is completely absent in the Open Source story in general. However, the two views are complimentary. Business processes (or, in this case, pedagogical processes) are code. They are a part of the system in equal measure with the software that supports those processes. From a production perspective, therefore, the people who know these processes are developers every bit as much as the technologists are. If you look at major software project management methods like MSF (and RUP too, I think), you'll find that embedded into their role structure is this very idea. They embed the customer in the development process itself, from beginning to end. Open Source needs to get that concept in order for it to leap the gulf between writing applications for developers and writing applications for others.
