OSPI 2005: The pitfalls, the pluses

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? ;)