Forum .LRN Q&A: On another note... Good News!

What is the good news?

After a meeting with the heads of both our medical school and the computer center in Heidelberg little stands in the way of dotLRN being the next platform at Ruprecht-Karls-Universität Heidelberg. I have approval on some funding to make OpenACS (and then dotLRN) international. After long and drawn out university wide user surveys and an extensive platform selection process (which also included flying to Boston and talking with the MIT group, OpenForce, the Berklee group, and others) initial funding will be coming from the Medical School and the Computer Center to do this if everything falls into place as we predict.

What are we going to start with?

We will attempt to coordinate and focus the resources of those who would like to contribute to making the OpenACS platform and the dotLRN application international. There will be parts of the internationalization of OpenACS that our university might not need for dotLRN, yet others might be interested in funding. For this process we will offer funding infrastructure, that is typically used by multiple institutions to bundle funding for ambitious research goals.

I will be posting more on this soon...

Why in the world are you posting this HERE?

We feel an initial general plan for dotLRN governance is a keystone that needs to be put in place before we can contribute AS AN INSTITUTION to the OpenACS community. After talking with many key players (in order to make an informed decision) Michael's and Al's fears, concerns, and argumentation above pretty much harmonize with ours.

Obviously the fact that we have two conflicting proposals creates a problem for us as we walk towards the starting block in Heidelberg, yet we understand that it is part of the process (as well as an indication of the freedom given to OF by Sloan... which is not what I would call stifling). I would like to emphasize that Al's proposal by no means indicates that technical decisions will be made by the Consortium. The structure Al proposes also introduces important checks and balances... and would give the consortium the opportunity to push the gatekeepers in a direction which echos the needs and wishes of not only the dotLRN user group, developer group, but also those of the greater OpenACS community when needed.

Don's post above that first mentions the Apache Foundation also echos a lot of what I wanted to say, yet I had to talk to Ben and Al on the phone before I could put it down in black and white.

After talking to both Al and Ben I can second Don's description of the fundamental philosophical differences in the two governance documents (it is bottom up tight vs. top down broad)

After meeting both Ben and Al personally, corresponding, and talking yesterday I think that they generally both want the same thing: the best thing for the community and for dotLRN.

We in Heidelberg also want the best thing for the community and for dotLRN and think a very broad and neutral Consortium (which could be seen as a contributing member of the OpenACS community) would work very well for both. The governance model presented by Al is what we are going to push for (it would make the platform a better bet for us in the long term and as Don correctly stated it will be much easier to get funding for). In contrast to OpenACS, in its present form dotLRN has a pretty clear function it is trying to fulfill based on ACES/SloanSpace. A specific function that we as a University are very interested in: sharing and LRNing built by the needs of a teaching institution. It is not a toolkit like OpenACS is, but an EDUCATION application based on this toolkit that has been built (in a nice general fashion) for a EDUCATIONAL customer (with very similar needs to our own).

What Ben proposal might lead to is a .LRN-OF, a .LRN-MIT, a .LRN-Berklee, a .LRN-Heidelberg... or even worse a dilution of the technical leadership within the OpenACS community (Malte please consider this). This would be a disaster for dotLRN (the prospect of having to support a distribution is something that my faculty can not sell to the computer center in Heidelberg). We have been talking to major players in the industry (WebCT, Blackboard, IBM, Sun, Cisco and others) and they all offer more or less boxed applications with secure futures and guaranteed updates and support (organize funding, install, and you are done). We host WebCT at our university and this is the path of least resistance, which is very appealing to institutions. An official .LRN package that mimics this will help it compete in this realm. Having additional "dotLRN compatible" applets (what Blackboard will offer with its "open-source" Buildingsblocks program and WebCT is planning with its SDK) and is not a problem, but there must be an official dotLRN group of applets. If a group wants to create a new distribution and apply the application to a totally different sphere... great, but it will have to be named something else (e.g. dotWRK). We want to avoid an uncoordinated free-for-all... we want to prevent a dilution of efforts... please do not forget that dotLRN is entering a specific market (open-source or not) and I can tell you that there are a lot of very interesting alternatives and movements. If we want dotLRN to succeed in the long term we feel there is a need for a broad governance that Al is moving towards that freely delegates to a strong technical leadership, that provides funding for the wishes and needs of the user community. There is a huge potential here and it is clear that we must proceed carefully if we want this to work.

The most important point I would like to emphasize is that we NOW see dotLRN as an MIT initiative, which for us means the final word on branding and governance at this point in time has to come from MIT. We want to enter the playing field as a partner with MIT interested in pushing dotLRN in the right direction. This must be clear... at the same time we want to promote the existing and developing fruitful relationships between MIT, Berklee, OF, Furfly, Musea, Collaboraid, Heidelberg, idividuals, and other members of the present and future community continue.

If we take an active part in this process our interest would be in acting as a member of this consortium... consolidating funding for good ideas that push the platform in the direction the community (users and developers of OpenACS and dotLRN) wants it to go... NOT forcing a technical direction. This little grain of structure must be put into place for dotLRN if the OpenACS community wants to benefit from our contributions.

We see the main advantages of choosing dotLRN not only in its functionality and/or architecture, but the fact that design can be driven by the needs and views of both the users and developers. One of the most important reason we want to change platforms now is to allow for us to respond to our user's needs quickly and remove our dependence on a single vendor. If we see a single party (or person) taking control of what dotLRN is then the risk and energy expenditure would be too great to warrant Heidelberg taking the "road less traveled by".

At this early stage (before the existence of the Consortium) the platform needs leadership with good intentions, a high level of trust, and a good track-record. After meeting with the MIT-Sloan group (and talking to a lot of people in the OpenACS community) we are sure that governance defined by MIT-Sloan will give all parties a voice and representation. I believe it will include our concerns, developer concerns, and those of the broader OpenACS community. As I mentioned above we want this to be a shared team effort... and we are ready and willing to play our part (next to the community building around dotLRN and the existing OpenACS community).