A recent post from Michael Feldstein regarding the lack of an course export feature in Moodle got me thinking. In his post Michael mentions that:
...universities should insist on support for some standard export capability in any platform they adopt.
I know that he is most likely commenting on the decision making process that occurs before an organization elects to adopt a platform. However, when I first read it I wondered, "Insist on that support from whom?"
For schools that deploy proprietary solutions, this is a pretty easy question to answer. You would go to the vendor with all of your support questions, feature requests, complaints and feedback. You usually don't get a lot of options and most of us IT folks feel comfortable with this long standing "one stop shopping" model.
When you decide to use open source software, that same question can be (and has been) answered in a number of different ways. The strategy that your IT group decides to pursue in answering this question can have a lot to say about how vested you are in the "open source" idea of freedom, local control of "your IT destiny", "shared risk" and long term viability of your solution. The institutions involved in the Sakai and OSP communities have approached these questions from a few different directions.
Dipping your toe
Some open source software (notably Moodle in the LMS space) are very easy to setup and configure. It is so easy to do and takes up so few resources that the ROI on the 10 minutes it takes to set up make it really easy to just say, "Wow! This is great" and just run courses with it as it is. I've heard of teachers setting a Moodle server up in their classroom on a desktop computer just because they can. This is frequently the first phase of a pilot deployment of Sakai.
Sakai is substantially more difficult to set up than Moodle. However, there are a few vendors that make running a pilot quite easy via their ASP models for hosting. An institution could simply accept the community released or vendor supported offering and focus on the training and use of the system to support their own processes.
I have a hard time believing that this really leverages the benefits of the open source community. In some ways, this is pretty much the same boat as using a proprietary solution. I believe that an institution needs to engage in the upstream discussion about the design of the software in order to really extract the additional value that a community created software solution can offer.
Hoe your own row
At the other extreme of the spectrum are those institutions that design, build and support their own custom version of the software. Indiana University, Stanford, Berkeley, University of Michigan, Cambridge and the University of South Africa are institutions that have dove in the deep end of the pool and contributed a lot of resources to the discussion and development of Sakai. In many ways, these institutions have the ability and the mandate to change the way that the software works in order to meet their local needs.
In the past there have been some concerns that the direction that these schools were taking Sakai were not always in the interest of the community. They were (and often still are) scratching their own itches by developing new tools or modifying existing tools. Furthermore, it has been somewhat difficult for a school that hasn't decided to pursue this strategy to engage in the often highly technical discussions that accompany the development of these new ideas.
Developer for hire
To bridge the gap between the frequently chaotic world of bleeding edge development and the pragmatic needs of faculty and students some institutions contract with a freelance developer or vendor to span the gap and act as their proxy to deliver the functionality that they need. This make a lot of sense, particularly if the developer/vendor is able to negotiate the community process, build community consensus around an ideas and get other institutions to climb on board with the idea long term. Ultimately, you don't want your idea to be so unique that you need to support it yourself forever. If there is such a need, the vendor needs to build a long term relationship with their client to ensure that the "one off" feature is maintained (with a great cost to the sponsoring university) over the long term.
My gut tells me that this approach makes sense for a few "proof of concept" projects, but if the idea has value to teaching and learning communities, it will be better off for everyone if the project is vetted by the community at some point and rolled into a community release.
Upstream consensus building
Many open source projects have multiple distributions to serve different needs. A notable example is the multiple flavors of Linux distributions, which are amalgamations of a number of other projects that are going on around the world. The Enterprise distributions of Linux typically draw from well vetted and supported versions of it's component projects.
I don't see much in the way of an upstream community from which Sakai/OSP can be derived from. This is part because of the relatively young age of the project. Over the next couple years I hope that Sakai is able to stretch out a bit. I think that the real strength of the vendor supported solutions will come when there is sufficient room in the community to engage the untapped resources of faculty, instructional designers and local developers to discuss and build consensus around pieces of functionality that meet a wide swath of needs.
I think about the current answers to Michael Feldstein's question. What do we do if we want to insist that a piece of functionality exists in Sakai? If you are one of the heavy hitters in Sakai, you can easily engage in discussion and get to developing quickly. If you are school that is currently "dipping its toe" in the Sakai water, that move may seem daunting. It may be far easier to ask a developer/vendor to proxy for you in that discussion. While pushing off the heavy lifting onto a vendor sounds like a good idea at first, we have to acknowledge that vendors take on a lot of risk developing solutions that do not have broad appeal. They also take on a lot of additional transaction costs by negotiating the community consensus building process.
Perhaps the best thing that a vendor can do is to engage a potential client in "process based" consulting to help them get their own voice heard, to make the connections with the right community connections and get that upstream discussion happening way before they invest their own resources in the development of new processes.