Forum .LRN Q&A: Response to dotLRN on .NET - Heidelberg

Posted by Carl Robert Blesius on

First I would like to clarify that I am going to be posting twice. Once as a member of the Heidelberger E-Learning team and once as a member of the EB of dotLRN.

I start with the Heidelberger subjective view:

I am glad that Roberto finally brought this point up in the governance thread... this rumor has been bothering me for a while (I have been waiting to post because I did not feel it was my place or that I had enough background information). I think these rumors also had a lot to do with some of the tension in the governance discussion.

In Heidelberg we have spent a lot of time and energy looking at different eLearning platfroms and dotLRN has been at the top of our list for a while. Obviously before we could make our final decision in Heidelberg we had to clear up all the various questions that came up that we could not find answers to in the forums or the website. Even though we had contacted a lot of people we decided that it was imperative that we fly to Boston and talk with as many people in person as possible (there were just too many open questions).

The news of potential funding from the iCampus project was one of the things that came up shortly before our trip and was a shock. To be quite honest I immediately thought to myself... "bye bye dotLRN... would have been nice", yet we obviously had to take a much closer look before we could make any major decisions. So I invested time into getting a general overview of what .NET is about and then I tried to talk to people involved with the iCampus project.

After doing superficial research on .NET we have come to the preliminary conclusion that much of the Microsoft philosophy for Web development is focused on server-side controls (which makes it clear why .NET is so appealing to a company that sells server software and is looking for innovative ways to maintain its present income). What about Mono... the "Open Source" Unix version of .NET? Staying days, weeks, or even months behind .NET eventually wasting major time on reverse engineering unpublished features of the .NET framework does not sound like a wise decision (not to mention possible performance problems... which reminds me of the extreme fatigue that can be associated with infectious Mononucleosis). There are also rumors in the Mono realm that there may be legal protection in place that leave a (intentionally or unintentionally) "kill Mono" option open (wether it is acted upon or not). Finally how MS has treated web standards in the past, does not exactly build faith that they will respect standards in the future.

Our initial conclusion in Heidelberg is that it would be a MISTAKE to introduce dependencies on .NET into dotLRN (not to mention the fact that our main partner in this endeavor, the University Computer Center, is very resistant to having Microsoft products running as servers for security, business, support, and other reasons). We also feel that a rewrite of existing dotLRN functionality using .NET would be a waste of resources that could be used more wisely.

Next step... what is iCampus "A research alliance between MIT and Microsoft enhance university education through information technology [...] sponsoring innovative projects with significant, sustainable impact at MIT and elsewhere." (from the website). This does not sound too incompatible with dotLRN. So who do we talk with? To start with it seemed that the best person to talk with was Dave Mitchell at MIT from Microsoft Research who manages the MIT/Microsoft iCampus alliance. He gave me a feeling for what iCampus is and what the motivation behind the project is. Afterwards I asked some questions about dotLRN. It became clear to me that it was still very early (he could not give me any specific information on funding) and he did not yet know that much about dotLRN.

I then looked iCampus projects from the past and present to see which might be interesting for dotLRN. I focused on the iCampus framework, because it seems like an iCampus project that could coexist nicely with dotLRN. The focus of the project is to "illustrate the benefits of service architectures for university educational computing infrastructure". This specific project is going to be using Microsoft's .NET architecture to implement certain services, but for dotLRN what makes this framework interesting is that it will interoperate with Web service architectures that adhere to the World Wide Web Consortium's service standards based on SOAP (Simple Object Access Protocol) and WSDL (Web Service Definition Language). dotLRN being able to talk using SOAP and WSDL, would obviously be a very good thing (as Roberto mentions above). It is obvious that we need strong support of web services standards in OpenACS and dotLRN.

Our conclusion in Heidelberg: using the iCampus funding to get dotLRN to talk with web services enabled applications would be GOOD... introducing dependencies on Microsoft software or services or putting energy into creating a new version based on .NET tools would be BAD. dotLRN is based on OpenACS and like OpenACS it should remain OPEN. It does not look like the goals of the iCampus project necessitate the use of .NET.

Why do we feel that we can take the risk of going with dotLRN without knowing if there is going to be Microsoft funding and what it will be for? First of all MIT-Sloan gave us the feeling that they are interested in having the users of dotLRN have a very active role in the dotLRN decision making process. OF also gave us the feeling that, regardless of what happens, there will be a version of dotLRN that they and other vendors will support regardless of decisions MIT-Sloan makes in one to two years from now. The main reason that we are willing to take this risk is because we believe that the system fits our users needs much better than other systems, dotLRN is a system being actively used, with a very high acceptance, and most importantly we feel that the momentum that is building behind dotLRN (from very diverse sources) will make dotLRN based on OpenACS a sound platform, easily able to deal with this and other kinds of funding in the future.