Forum .LRN Q&A: A clarification

Collapse
81: A clarification (response to 1)
Posted by Ben Adida on 08/08/02 07:49 PM
I think there is some confusion as to what problem I was trying to solve when Al asked me to put together a governance document, and therefore some belief that I'm trying to exclude users of dotLRN who are not programmers. This is not the case by any means. First, I want to clarify that it is MIT's role to determine future direction and Al has the final call on this. I will clarify where I'm coming from so that omissions in my proposal are not misinterpreted.

The question I was trying to answer is "how do we get non-OF people involved in dotLRN as soon as possible while maintaining a coherent direction?" - you'll note that the proposal is called "dotLRN *Technical* Governance." This is why my proposal is minimalist - to get things off the ground ASAP. However, I'm *not* excluding the later formation of other groups. I'm only saying that the formation of such groups should probably be organic, led by early adopters (users!) of dotLRN once they have some experience working together with dotLRN.

Some in this thread have compared this to the Apache project. Putting aside the fact that the Apache Board is generally not credited for Apache's success, dotLRN is very different from Apache because dotLRN serves non-technical end-users directly. This is Michael's point and I agree with him on this. In fact, I agree with this point so much that I'm loathe to dictate too much process in an area where *no one* has any real experience: open-source vertical apps. This is why I'm sticking to a minimalist, well-known structure, fully hoping that MIT, as the owner of the dotLRN brand, will coordinate user discussions and conferences to truly tap the educational community.

I simply don't think that it is beneficial to predicate additional developer participation on these ambitious goals. I fear that it would stifle the enthusiasm that many developers have clearly shown about dotLRN.

Lars raises some interesting questions, which I'll try to answer:

  • dotWRK is totally separate from dotLRN. Common code should be modularized out so as to form as strong a common base as possible.
  • yes, new-portal and the portal wrappers belong in OpenACS (and in fact, we're in the process of rolling them back in the next few days).
  • in my proposal, the TAB is accountable to the community and to the organizations they represent. The gatekeeper is accountable to the TAB.
  • the dotLRN kernel is not very big, but it is fairly crucial to keeping a solid architecture. It includes the applet API contract and implementation, the group management tie-ins to portal management, the specific role definitions and management, and a handful of other small details. In the proposal I put up, I mentioned the "portal architecture." I will revise this right now as per my discussion with Don.
  • one formation of the TAB that I envisioned (although, again, Al has final say over this): lead engineer from each of the big initial users of dotLRN (Sloan, Berklee, Heidelberg). As for gatekeeper, I proposed playing that role for the first 6-9 months, depending on speed at which the TAB can define a new process.