Ian Dolphin 2008 Thoughts

With the advantage of having read other Board members statements, where I find huge amounts to agree with, and rather than attempt a fully-fledged "imagined future", I'd like to focus and riff on a couple of points made by John and Clay, and on the general relationship of Sakai to the world outside the Sakai community. This is pretty stream-of-consciousness, for which apologies.

Clay is, I feel, absolutely on the money in rejecting a "feature footrace" with competitors in LMS space; our focus should be on ensuring the tools we have, or which are on the outer edges of the community are tested, integrated and made more consistent and intuitive for users. We should recognise also, I feel, that this consistency is a necessary element in the "co-option of strengths of other communities" Clay references, and a very significant challenge. Interoperability with tools from external communities will undoubtedly in the main part be driven by demand from within our own community, but it might be worthwhile further advancing a vision of Sakai as a natural coordinating/integration point in an ecology of tools both within and without the Sakai community itself. This has an aspect concerned with John's "hidden" technology & the framework, APIs etc, and critically on documenting them, but also requires a strong focus on a coherent UX. Perhaps, medium term, FLUID will offer some methods of easing the cognitive load on users of external tools integration. There's a further element involved in this integration, however, which is might almost be described as being more concerned with a philosophical approach to community. Whilst making the Sakai Foundation as hospitable as possible to the integration of external communities, this clearly isn't a requirement of collaborative work, and may frequently take time to accomplish. Equally, whilst much of the value of such collaboration will be generated "from below", we might also want, as we move forward, to place a little more emphasis on such collaborations at a Board level, at least in the sense of sharing a common understanding of what is happening "from below" and communicating it clearly to our own community. This relates to a potential larger agenda I'll indicate below.

Work with other communities requires some sensitivity. As an aside, whilst it's clearly to our advantage to emphasise the ability of the Sakai environment to serve the needs of both Research and Teaching and Learning communities, there's also a point in emphasising that original goal, in this context, of supporting the mode change of many staff who are both research and teaching active.

Whilst we don't have time for fully-fledged scenario planning, it's perhaps worthwhile stretching a couple of extrapolations of current tendencies to help inform how we locate Sakai in likely futures. I'd like to pick two broad tendencies that are likely to operate on us here; the first concerns architecture, the second economics. It seems likely that ICT development is headed in the general direction of more granular, loosely coupled services & that over-used and applied term, service orientation. (I don't want to get into an angels-on-the-heads-of-pins discussion of SOA here, btw, simply to observe a general tendency). The impact of this is already noticeable in the communities which surround us, and indeed, in our own. JASIG, for example, is broadly shifting from a perspective of portal as application provider to portal as architectural element, and separating out elements previously bundled with uP, such as Groups and Permissions, into separate services. In repository space there is a similar detectable shift (albeit not as large) from repository-as-application to repository-as-potential-architectural-element. John's comments on Kuali student offer a further reflection of this, as does the sharing of third party Pluto code in uP3 and Sakai.

It strikes me that there are two concomitants of this tendency. The first is that the overlap between existing communities, which already overlap considerably in terms of personnel in some cases, is likely to grow, and the boundaries become greyer. There will be as many cultural issues to face here as technical. The second is that there is likely to be a consequential need for more potential "joins" between communities; from formal and informal requirements gathering processes to establishing work around common interfaces.

The second broad tendency I would want to emphasise here I would term economic. Essentially, I believe that there are both limits to how many OSS/CS communities can be viably supported by the edu community, and that we do not make the most of opportunities we've discussed in the past to share infrastructure. A focus on some small steps in this space in the short-term might prove beneficial in the larger context I've imperfectly attempted to sketch above. I'm happy devoting some time from my next six months on the Board to that, beginning with working it up a little more. The larger medium-term question, however, remains our attitude to the possibility of a meta-community. Notwithstanding my comments above, I don't feel that this can happen overnight or in the short-term, but the questions do remain - do we want this, does it produce benefits, and is it viable? Is it best happening from below, led by organisations like Sakai, Kuali, JASIG, DSpace and Fedora, or from above, or even conceivably both? I suspect the formation of any such coordinating point/meta-community will be a slow process, but if it is desirable, one small element of our work should be to prepare the ground, despite our many more pressing immediate concerns.