O3spaces, icloud, hosted apps and collaboration

Part of the email outsourcing carrot is that if you outsource to Microsoft and Google your client base also gets access to the vendor's online applications suite. As I've written elsewhere , this is a plus for either third world universities unable to provide enough resources for their students and the overwhelmed public universities in parts of Europe that have grappled to provide enough facilities and reliable email to students leading students to vote with their feet and go elsewhere.

The value of this carrot in a university with good infrastructure where all students have easy access to a competent office suite is somewhat less. Providing remote printing , document upload to central filestore via webdav provides much of the required functionality. Add access to something like open office via a thin client style solution, and a sakai powered collaboration service to allow people to upload documents to sites, and we can have editing and review and all the rest of it. We could even graft on access to a blog server and submission into the LMS

The only thing it is it's not seamless, but it does ensure that the intellectual capital stays in one place.

Google, to name but one, gives seamless integration with blogs, apps, mail, calendar making sahring and collaboration that wee bit easier, that wee bit more seamless. What we are looking for is to put everything behind a front end, perhaps a webtop like icloud that fronts all the services.

The trouble, of course, is that icloud is proprietary and one can't simply run up one's own implementation.

O3spaces , the collaboration service based around open office may be a more valid solution with the ability to push documents and share documents from inside of OpenOffice. One, of course has to ensure that every potential user of the service has OpenOffice installed with the appropriate extensions.

Providing one had control over the machines, this is no great deal, but if we're expecting colaaborees to increasingly use their own machines we cannot reliably second guess their operating system, or cpu architecture. All we could probably mandate are a range of supported browsers, which pushes us back towards hosting the solution in a thin client environment of some sort that will play nice with XP, Vista, OS X (10.4 ppc, 10.4, 10.5 intel) Ubuntu i386 and Suse. Support for other linux distros, ed red Hat, Fedora, Debian, would be nice but not essential as would support for Linux on non i386 architecture cpu's. (I feel the same way about Open Solaris).

But of course, as we're using the thin client environent as an easy access platform there would be nothing to stop users gaining access to the collaboration backend by installing and configuring Open Office and the extensions themselves if they find the thin client environment didn't work for them. Being Machiavellian, limiting the number of concurrent logins to the thin client service might actually be a sensible strategy, as it will force heavy users to the system to configure up their own hosts appropriately to guarantee access - occasional users will be happy with the thin client system - and also help move the infrastructure costs out into the user space ...