Wednesday, October 18, 2006
A Modest Proposal
I have often said that the software that the Sakai project ultimately produces is not as important as the opportunity to forge an entirely new way for institutions of higher education to collaborate, to build something together that is greater than the sum of its parts. This new way is an exciting alternative to the old buy vs. build dichotomy.
The basic problem right now is that we have a requirements gathering process, but no organized (or better yet, self-organizing) system for getting the work done. Even though the Sakai Foundation oversees the project, they’re not “the boss.” They can’t force anyone to work on anything, because we’re a coalition of volunteers. That’s good, in the sense that we are the masters of our own destinies, but it’s bad because if no one drives the boat, it just sort of drifts. There is no shortage of resources: institutions have people and money, and they’re ready to use it to get software that helps them fulfill their missions. Among all the institutions in the Sakai community, there amounts to rather a lot of people and money.
There is a gap between what we want and what we get. It’s nobody’s fault; This is a hard problem. We need a (metaphorical) machine that takes people and money as inputs and emits world-class software. At select organizations, this is achieved by world-class software teams. To take it to the next level, we need a means of spawning meta-organizations — purpose-built working groups that swarm to a specific problem and produce great work. This happens now by dint of tremendous effort, currently embodied by the recent Resources work by Jim Eng, Clay Fenlason, and the folks at Unisa. We’ve got to find a way to bottle this up. Wouldn’t it be better if our best people had the mandate and the money to solve community problems full-time, instead of heroically squeezing it in between dinner and Conan O’Brien (I’m looking at you, Aaron Zeckoski)? I personally get frustrated that I can only put in a couple of hours a week to help make Sakai’s data interchange first rate.
I worry that we think this is going to iron itself out. The fact is, crossing institutional boundaries is fairly unnatural, and it’s going to take an intelligent template and a force of will to make it work as well as it should. Our problems are not technical, they’re organizational. Solving them is worth it because we stand a chance of closing the gap and getting what we need and want out of our systems, on our terms. Anybody interested?
It seems to me that one of our greatest problems is to make software which supports the local needs of institutions (and schools within the wider institution) without being reliant on an ongoing process of local patches. Our institutions vary wildly in their understandings of many of the fundamental issues that Sakai is designed to address (is a class a group of 3 students, or of 600, for example?). But perhaps this is a result of building software which, at the moment, focuses heavily on the administration side of teaching. Administration does vary from place to place - in a way that teaching and learning doesn't. Perhaps building more pedagogical tools will enable more cross institutional sharing?
Harriet Truscott - University of Cambridge
MooseTrout BrainDrain: "A Modest Proposal -- One Response"
And yes: more attention within the community to pedagogy and pedagogical tools is really, really needed. Did you know that we (NL, Sweden, Norway) are working on a paper on this subject. And that we want to present this in Amsterdam???
And maybe we need an "Chief Pedagogy Officer" or a "Educational Director" for the community..
What do you think?
At some level we have three choices:
a) Become a new life form where we figure out how to do this in a distributed collaborative fashion allowing each member of the community to gently manage their time between the common and local needs
b) Collapse down to be a pure Apache project where people pretty much volunteer their time and progressis very sporadic
c) Become a centrally managed non-profit company which happens to release its source.
I prefer (a) - but we need to give it time to develop. The right model is to get to the point where local needs are satisfied and people have time during the workday to work on the commons. Effectively their boos tells them to "work 50% time on the commons".
This will work better when our basic software is more solid and feature complete at some basic level. Because once the software is complete at a basic feature level, then we won't be rushing all the time and can handle momentary the ebb and flow of a mostly volunteer workforce.
The problem is that we still have a lot of incomplete stuff that is REALLY basic! Like a solid testing engine and the ability to export materials from a site under the control of the end user. The problem is that when we have these "open wounds", we feel the need to rush and then the "common need" cries out loudly and we all feel bad if we don't respond.
My feeling is that once the basic common needs are well in hand - this will be a very stable approach.
But there is that small problem of getting from where we are at to where we need to go while remaining intact.