Forum OpenACS Development: Re: Apache support critical
Sorry to jump in and muddy the waters even more, but it's possible that, from a .LRN perspective, uPortal integration and some kind of a Sakai interoperability toolkit (like Java OKI bridge?) are more important than either Apache support or an easier installer. That's because the current state of Sakai creates an enormous opportunity.
Sakai is a tsunami. The amount of attention it is getting, both from universities and from vendors, is enormous. Major publishers are in discussions with Sakai schools about creating course cartridges. At least one synchronous platform vendor that I spoke to recently is giving serious consideration to integrating with Sakai in addition to Blackboard and WebCT. It is getting huge amounts of attention.
The trouble is that its feature set for end users is fairly weak still. I'm told that the plumbing is very good but a number of applications are either missing or just weak. If .LRN could "integrate" with Sakai (more about what that means in a minute), and were strongly marketed as having that capability, then I think you'd be able to get some real traction.
To start with, if the uPortal interoperability isn't already done, then I'd recommend finishing it. That by itself would allow you to claim some level of interoperability, since you could put .LRN tools into the students learning environment next to Sakai's through uPortal channels. Once you've done that, you could work selectively on adding back-end interoperability. It doesn't need to be full, everything, super-deluxe interoperability; it just needs to be enough to show that the community has both a strategy for and a commitment to making Sakai interoperability feasible. Intitutions who are attracted to adopt Sakai but are also concerned about lowering their risk of backlash from putting out a tool that isn't as polished as it should be will have an incentive to look at anything that can lower that risk by allowing them to plug in battle-tested functionality from a system like .LRN. So they'll be inclined to help finish Sakai interoperability work if it's already been started and appears to be a manageable project.
Once they are using .LRN for anything, you have an opportunity to compete directly with Sakai tools for pretty much everything. It's quite possible that some institutions will find themselves using .LRN for the lion's share of their environment and end up throwing out Sakai altogether. Others may take a mix-and-match approach long-term. Still others may rely on .LRN only as a short-term transition. But even in that latter case, you will have spread the good word about the toolkit and lowered resistance to taking it up for other purposes in those institutions.
Two caveats. First of all, taking on Sakai integration will do nothing to directly promote non-.LRN use of OACS in the short term, while Apache support and better installers both would. Second, I have little grasp of how difficult interoperability beyond uPortal integration would be and can only assume that it would be significant work. That said, one of the options that SUNY is seriously considering is running many of its legacy Lotus-based LMS tools through uPortal side-by-side with Sakai tools and swapping them out incrementally, so I know that mix-and-match is considered to be a feasible option for us. And in some ways, the marketing challenge of describing OACS interoperability with Apache may be roughly analogous to the marketing challenge of describing .LRN's potential interoperability levels with Sakai.
