3.1 Ruth sabean interview - part 1 - ucla selects open source  (Page 6/6)

I was struck by your comments, “After several years of cross-campus collaborative efforts to better link the variety of services, UCLA decided to join the Sakai Educational Partners Program,” and that UCLA wanted to, “remain engaged with the higher education community and the Sakai Foundation in order to work on interoperability of Moodle, Sakai, and other CMS/CLE solutions.” To be honest, at SUNY we found that Moodle was not designed with service integration and interoperability in mind, and the Moodle community was not interested in undertaking the development to make SOA possible (although we did feel Moodle was a better designed and developed application with a stronger community).

I am curious if the above considerations were part of the decision making process, how Moodle’s technology and architecture was assessed, and how the FCET felt Moodle’s architecture provided (or could provide) for the integration of services and interoperability?

Thanks Ruth, and best of luck, Patrick

7. rsabean - march 17th, 2007 at 5:15 pm

Hi Patrick, I think I touched on some of this in my response to your comment in the other section.

Regarding the assessment of Moodle — just a couple of observations.

• The FCET did not do an architecture assessment. Although some members might have that skill set, most of the faculty on that committee do not. If you’re interested in seeing the assessment task force report, I’d be happy to share it with you. Part of that assessment involved discussions with institutions with similar scale of operations who also seemed to be effectively working on these issues. We also spent quite a bit of time talking with people who had chosen the Sakai route to understand what we might be missing.
• Our sense, and I guess time will prove whether we’re right, is that Moodle seemed to be implementing standards fairly rapidly and more consistent with the definitions than Sakai at the time we compared them. So even though there were no philosophical statements being made about that, in practice there did seem to be attention being paid in terms of the work being produced.
• It was also our sense that the Moodle community was interested in the practical aspects of interoperability perhaps because so many campuses run Moodle AND something else, even though there was not a lot of discussion of that as a goal.
• We did observe even the 6 months or so that we were working on these choices that Moodle seemed to be learning faster from Sakai than the reserve. Hard to say if that was simply the maturity of the community or the faster pace of development because of various factors, or just that key requirements spread rapidly.

Cheers, Ruth

8. richardwyles - march 19th, 2007 at 5:47 am

Hi, I don’t want to spark any grand debate here but I feel it necessary to rebut Patrick’s comments - “at SUNY we found that Moodle was not designed with service integration and interoperability in mind, and the Moodle community was not interested in undertaking the development to make SOA possible”. That is quite an extraordinary statement on two front 1) given Moodle’s architecture which is fundamentally about application programming interfaces, and 2) the value judgement on what is a huge and diverse community of users. Firstly the architecture. The M in Moodle stands for Modular. It was most certainly built with interoperability in mind and it was this criteria that helped win the day back in 2004 when we selected it. Follow the link if you want to read our architecture assessment at the time (although being May 2004 it needs updating!) (External Link)

Since then we’ve done many integrations both at the application level and with dataflows, including many beastly student management systems. We’ve used a variety of web services with Moodle, just recently SRU/SRW creating an interface with the Fedora institutional repository system. Interoperability, open standards and web services is also explict with Moodle’s roadmap.

So I struggle to understand how your evaluation cam to these conclusions? I’m also a little curious how a SOA architecture sits with the selection of proprietary Angel?

regards, Richard Wyles

9. pmasson - march 19th, 2007 at 6:23 pm

Not sure how to respond to this. I don’t want to deflect this discussion either (I’m slated to contribute later on, maybe we can pick this up then).

Quickly in context to this discussion,

Our technical goal was to provide teaching and learning components independently of a system. Not really to pick a new LMS. We felt OSS was the best option for doing this. In fact uPortal was to be our “system” with disparate tools presenting depending on the user/course. We felt it would be easier to use Sakai’s tools–not Sakai, not Moodle–as independent components. In fact, we actually began with tools developed outside of “core” Sakai: the grade book and test engine, and even another project, the Bedework Calendar.

And how Angel fits into a SOA model (or at least what we were trying to do)? I don’t think SUNY cares about SOA (see (External Link) for the gruesome details). I had nothing to do with the selection of Angel. I would love to know how Angel became the “preferred platform” for SUNY. But I do know that this topic is much bigger than what could be explained here!

10. ken udas - march 21st, 2007 at 5:05 pm

Pat, Richard, Ruth, this seem to illustrate the importance of dialog. Different institutional needs will drive the selection of applications based on a variety of criteria. The methods of achieving interoperability will impact the usefulness of different applications given different requirements and intended uses. The impact here of OSS is the ability to really understand what is under the hood so we can make truly informed decisions that will influence the teaching, learning, and administrative experience. I know that due diligence, which was facilitated by code transparency, happened at the Open Polytechnic and at SUNY with different conclusions and results.

I think too that Richard struck at something with his final question, “I’m also a little curious how a SOA architecture sits with the selection of proprietary Angel?” The quick answer, as Pat indicates, is that it does not. Angel was not selected based on the requirements that guided our recommendations as outlined in the “SLN’s Request for Public Comment” document referenced above. So, considerations that lead the evaluation team to an SOA-based solution were taken off the table.

Sometimes all we can do is make recommendations.