Purposes of SEPP Organisation

I'm not sure how best to put this, so I may make frequent use of the edit button to refine the point, but I think a fundamental task of SEPP will be to provide for "community support" (I know, I'll keep looking for a better phrase). This includes:

• good documentation
• infrastructure for communication/collaboration
• and other areas I haven't the wit to recognize this morning

I think that a narrow focus on the code and its development alone is unbalanced, and ultimately under-serves a guiding motivation to engage educators more directly in the development of their pedagogical and collaborative tools. SEPP must also devote attention and resources to supporting structures and processes. It might be argued that this is implicitly subsumed under "infrastructure resources" or "ongoing access" above, but I think it's important to make it explicit.

Actually, I have a more specific concern in mind, which I should come clean with. I've been hearing a lot from smaller schools about concerns over staffing resources and the in-house talent required to pull Sakai off. The quickstart has been a great accommodation, and I'd hope to see more of these measures to minimize the effort to get up to speed with the technologies and implement them locally. And again, I think this is important enough to deserve explicit mention in any stated goals.

I'm also mindful of a possible tension with commercial partners - one of the services they provide is to consult on these sorts of matters, and perhaps this may be an argument against putting this sort of burden on SEPP. I could respect that argument.

But I think there is a general point here about where open-source solutions have struggled to date. They are more difficult for "outsiders" to pick up, less friendly for the uninitiated end-user (the end-user in our case being the adopting institution), harder to find the requisite skills for, and harder to find sound, reliable information for. I think there's a danger of SEPP becoming a clique only for a certain sort of school (i.e. a school with a certain sort of IT department), and I don't think that will ultimately serve our interests.

I think you are making a good point Clay, but how about if I turn it around. The bigger schools with an IT department develop innovative teaching tools and the framework and donate the code for the public good (theirs and others). This process will require the sustenance of a community as you rightly point out. But then the commercial companies step in and (without the costs or risks of a major development) are able to offer a low-cost service to the smaller schools without an IT department. This seems like an attractive future to me, especially as the low barrier to entry for commercial players should ensure a high level of competition among suppliers.

Clay's tasks added to list

How about (tried to "steal" every idea above and add a few more):

*To provide a world class Collaborative Learning Environment (a.k.a. CMS) software package to the higher education community
*To own and maintain the core Sakai code and provide appropriate mechanisms by which additional code can be donated from the community.
*To ensure the highest quality, standards based code in the Sakai core packages as well as an on-going architecture roadmap for development
*To exercise prudent and efficient management of the project's core resources (staff, money and intrellectual property)
*To provide core documentation and information about the code and the project for the community
*To foster a community of users and developers in appropriate physical (e.g. conferences and workshops) as well as virtual (e.g. collaborative tools) environments
*To serve as a focal point for the community's interaction with other projects and endeavors as well as a broker for appropriate partnerships with other commerical and non-commercial entities.

On the general question of "community", and the specifics of producing a quality open source product, what are example projects/products and communities we can learn from? What are their theoretical and actual governance models? How do they build and sustain their communities? How do they resolve conflicts?

Positive and negative examples are useful.

I'm not sure if it's positive or negative, but I think Sakai is running counter to the governance approaches of the more popular open source projects - that being a sort of "Just-In-Time" governance. Linux is the prime exemplar. Governance structures are adopted only where and when it becomes too painful to do without. The advantage is that organic growth we're all supposed to value so much. The disadvantage is that many problems were easily foreseeable and avoidable.

But every time I try to make analogies with other open source projects (at least the ones I know, which I admit is very few in number), I butt my head against a fundamental, irreducible difference: they deal only with communities of independent, individual developers. I don't mean to say that this presents a simpler problem, but I think it is a more homogeneous one.

We, on the other hand, have to throw institutional incentives and structures into the mix at every level as well. Of course there are numerous open source projects where corporations have weighed in, but they still seem to do it largely by having their developers treated like everyone else. It isn't really a consortium model where institutional representation is front and center.

We also have to cope with a more diverse set of constituents and idiosyncratic needs. That may be the main reason that we have to apply a little more rational forethought to the governance question.

Anyway, yes, I want to hear more from other open source success stories on the governance question (though it may start to sound like I don't), and it seems silly to try and invent this for ourselves in a vacuum, but at the same time I wonder how much of these other experiences is going to be pertinent.