Forum .LRN Q&A: Response to Request for Comment: dotLRN Technology Governance
I think the first thing to remember is that dotLRN did not have to be an Open Source project at all; it could have remained a work-for-hire paid for by MIT and kept for MIT's private use. The fact that Al has chosen to make it Open Source, and that we are having this discussion at all, ought to make it reasonably clear that his motives are good.
(obviously Ben's motives are good too, but they don't seem to be under question here so I don't need to defend them)
As to why Al is doing this, it has been my impression that he wants to see dotLRN be adopted as widely as possible by other educational institutions. This is one way of getting value out of a piece of distributed software. Selling it is the other - let's be thankful that Al chose the Open Source route, eh? And if wide adoption is the goal, Al *has* to set up a structure that the potential adoptees will be comfortable with. I think Michael and Carl have done an excellent job of explaining why the model Al has proposed is the right fit for the educational software space.
As for the comparison with Apache goes, although there are many similarities, as others have pointed out, there are differences as well. The main difference being that dotLRN was commissioned and paid for, and has therefore sprung forth fully formed. It has not, up to now, been the product of volunteer developers. That gives it a certain appeal in places that are slightly suspicious of the percieved anarchy of Open Source, and I think MIT should do all they can to preserve that. I believe that the proposed Governance structure will help in that regard.
I think Tracy had a good point about the ability of the proposed Consortium to hire folks to do things like QA testing, writing documentation - tasks which benefit the entire community. It's a great way for institutions to pool their resources and end up with enough funding to really get things done.
I can understand why people are concerned about future changes to dotLRN forcing changes to OpenACS. However, I think one can see how dotLRN was built and see that this is not necessary. For example, the existing Portals package was considered to be inadequate. Instead of rewriting the OpenACS package and forcing the project to adopt the new one, OF wrote New Portal. Now, it happens that New Portal will probably make it back into OpenACS proper, because there seems to be general agreement that it's better. But that doesn't have to happen; changes made for dotLRN that the OpenACS gatekeepers really don't like can remain in dotLRN.
Having said that, I think it would make people feel better if Al added something to his document to the effect that the dotLRN project can never *require* the OpenACS project to implement a change. They can ask, but they can't require it. And maybe also that dotLRN should be kept compatible with the latest (from CVS) version of OpenACS.
And lastly, I agree with Malte that a similar governance structure might work for OpenACS, but I think that's premature at this point. IMHO that idea should be set aside until the dotLRN governance issues have been worked out and a structure that works well for all stakeholders has been achieved. Then we as a community can take the lessons learned from that and decide if the process is appropriate to OpenACS or not.
