Don, I'm not really sure what you're claiming would still be missing with the level of integration I propose. I can make sure that my students see the content I want within the main course environment, and I can see their progress (or lack thereof) in the gradebook. What else do I need that importing the content into my datamodel would give me?
Now that portal technology and SOIs have finally matured, they really change things. For example, up until now at SUNY, when we've needed new functionality in our LMS it's generally been easiest to build it from scratch in Lotus rather than find an existing tool and integrate it. Too much work, as you say. But in a uPortal/Sakai world, the integration points are much better defined and easier to handle. As we think about adding, say, chat, we're not thinking about substituting a third-party package for the short-term and then developing a "Sakai-native" package, whatever that would mean. Why waste the energy when we have so many other things we want to build? We're looking to find an "NIH" package that will do the job permanently.
The whole purpose of Sakai is to enable and support this sort of behavior. It's to prevent tool lock-in, to make mix-and-match a more feasible long-term option. The core developers hammer home the message that it's a framework; the applications that happen to come with it are just icing on the cake. So I don't think .LRN components would necessarily be viewed as a short-term crutch. It would be by some and not by others. But one of the main marketing messages behind Sakai is, "If you think the discussion board sucks, then swap in another one. No big deal." Here at SUNY, where we have to serve 64 very different campuses with one platform, and where maintaining a quick pace of innovation is important to us strategically, that's a message that resonates. We don't care what LOR we use as long as (a) it's the best one available for our constituents and (b) it plays nice with the rest of our components. Hell, we've been using Lotusscript and Domino for the past 10 years. You think Tcl and AOLServer are going to scare us?
As for the supposed implication that .LRN has "lost the battle," I am not implying any such thing. I wouldn't waste my energy posting here if I thought that were true. To begin with, there's certainly room in the market for more than one quality system. Ultimately, .LRN will likely occupy the space between Moodle, which is ideal for small schools with few development resources and lots of grassroots energy, and Sakai, which will theoretically be ideal for very large schools with significant development resources and a need for a tool that plays well with lots of other pieces of their enterprise pie. While there will be some overlap, I see Sakai, Moodle, and .LRN systems generally serving different market segments. Nothing wrong with that. Now, Sakai will probably be bigger that .LRN. Way bigger. Nothing wrong with that, either. While it's nice to be Hertz, Avis and Enterprise do just fine.
All that said, I am suggesting that .LRN and OACS can both benefit by demonstrating that they play well with other software. ACS was originally designed as a world unto itself back when there wasn't a whole lot else out there worth connecting with. It's an integrated application suite. But the world is different now. In higher ed, for example, universities want their LMS systems to integrate with their Student Information Systems (i.e., their electronic registrar software) and their university portals. You don't want to them to get the impression that .LRN/OACS are best used for either everything or nothing. Yet that's essentially the message they get when they hear "well, you're better off rebuilding from scratch rather than integrating." Of course, sometimes it happens to be true that they are better off building than integrating, and there's nothing wrong with being responsible and telling them so. But that answer should be a considered judgment based on a concrete use case and not a reflexive reply.
Integration with uPortal and Sakai are important for two reasons, one tactical and one strategic. The tactical reason is that there's a sales opportunity at the moment--a need that .LRN could fill by being first to market with tools that integrate with Sakai. But the strategic reason is to establish that OACS and .LRN don't promote lock-in. That they play well with others. It's not so different a reason than Talli's reason for wanting a better Apache message. The installer is a different story; that's a strategy that makes it easier to sell at the low end, where demonstrating that dealing with .LRN isn't going to suck up significant support resources is more critical. If you want to get into the larger organizations, having an integration story to tell is the way to go.
