Sakai and Information Systems and Services

The Sakai Project is a major open-source development, which aims to produce a robust, scalable collaborative learning environment for higher education.

An article by Stephen Downes in the latest issue of Innovate! provides a good overview of the Sakai project website and helpfully steers newcomers towards the best content and resources.

This is one of those Really Useful articles that the open-source community needs to do more - a lot more - of. Downes is right: the Sakai site is confusing to navigate and, in many sections, is dominated by technical language. This can be highly off-putting to non-developer stakeholders who choose to visit.

And this is precisely where many open source projects fall down: in terms of communications and outreach towards those who are located "outside" the developer community. The problem is that an open-source project website is (normally) both the public and the private face of the community. The website has to serve a dual purpose, looking "outward" towards casual visitors and end users, and "inward" towards its own members. You can't solve this problem by shutting the developers' mud-wrestling, sorry, complex and interesting discussions, off into password-protected areas of the site; because that usually means that the information left  within the "visitor/user" sections of the site is far too thin to be useful.

So, OSPI 2005. I could talk about the weather: hot and humid. Or the numbers: 145 people, 8 countries, 2 days. Or the people: including Darren Cambridge (George Mason U), Chris Coppola and Janice Smith (r-smart), Jeff Haywood (U of Edinburgh) and Susan Kahn (IUPUI). So...what's next, what's new...?

With OSPI 2.0 unveiled, we learned that its future is now pretty much bound up with that of Sakai. This is not just a question of architecture and admin underpinnings, it's also to do with the way the project will be managed in future. Word is, the OSPI board may disappear altogether; the project may be managed via an Apache-style foundation. This could be a real turning point for the OSP development. For the moment, I'm reserving overall judgment as to the costs/benefits of this apparent convergence. I do have questions about the financing aspect, and I also wonder how OSPI plans to balance "collaborative" development with development that is driven by lead institutional partners.

Most interesting "user" development, from my perspective, is the portfolio matrix tool - looks great, and is flexible enough to support a range of activities. IUPUI has invested time/energy in developing a pedagogy of "matrix thinking", drawing on Stanford's Helen Chen's work on "folio thinking". This is something to watch.

Some immediate thoughts/reactions:

1. We need to think hard about what constitutes "success" for the open source development model. More obviously: does "success" mean simply that we held the conference, and the people came? Or that the OSP is financed sustainably, develops in a coherent way, and is being used by multiple institutions in 3 years' time?
2. We need to keep the diversity. OSPI 2005 attracted academic teaching staff, educational technologists, faculty liaison, software developers, and vendors. This diversity is a major strength of the OSPI community. I have to say it stands in marked contrast to the Sakai conference - held in the same venue, immediately prior to OSPI 2005 - which is much more developer-centric. To this end, I floated the idea of starting up an evaluation group as a way of keeping faculty involved and making sure the OSP fits their diverse needs. This may be coordinated through EPICC (European Portfolio Initiatives Coordination Committee) - watch this space for details.
3. We need less architectural change, and more tools. This one kind of follows on from the second point. If you're showing a faculty member a VLE/CMS, it's hard for them to see the benefits of an "empty box": they want tools and content. But unless we slow down the number of releases and the number of major changes to the "plumbing", in Brad Wheeler's phrase, we'll never get to the tool-making stage. (I believe this point applies regardless of whether we conceive of e-portfolios as a "tool", a "practice", or a "community").

So my holy trinity is: focus on sustainability, talk to the end users, and work on creating the tools they need... (So, that's all? Nothing more, then? ;)

Looking forward to OSPI 2005 in Baltimore. Not exactly looking forward to the long flight from Heathrow...!

I've been a member of the EPAC VCOP for about a year now, and am hoping finally to meet some of the people I've been communicating with online over this period.

My institution, University of Cambridge, expects to pilot OSPI 2 for the next academic year. This will be plugged into Sakai, which we are currently trialling with various academics and subject communities, and which we expect to use as a campus-wide VLE for 2005-2006. My main aim/hope is to get a more detailed, high-level overview of OSPI than I've been able to access to date, with a view to deciding exactly which features and tools we would like to use at Cambridge. On the plane, I'll be scanning the detailed matrix of e-portfolio affordances in the JISC e-portfolio review.

I won't be attending the SEPP meeting (immediately before OSPI), but two CARET-eers will be there, John Norman and Ian Boston. John will be co-chairing the meeting, with Chuck Powell.

I'll try to blog while at the conference, but failing that, I'll report here afterwards.