This is the first in a series of posts where I contemplate Sakai Strategic stuff - after all I am a Sakai Board member for the next few years. I think that it is incumbent on board members to gather input from the community and share ideas being discussed at the board level (subject to privacy needs) with the community.
This is a message I wrote back in December during a discussion on the management list of whether Sakai should become part of an umbrella organization or become an umbrella organization itself - all brainstorming stuff - no real plans here - just thinking strategically.
December 14, 2009
I think that it is an oversimplification to assume that we need some number of umbrella organizations similar to the list Brad includes in his blog post:
- Teaching and Research: Sakai
- Administrative Systems: Kuali
- Infrastructure: JASIG
- Scholarly Repositories/Libraries: ??”
Going from a single project to being an umbrella organization requires a lot of thought and perhaps even could include a new brand and new non-profit organization being formed with a very clear mission and purpose. As Chris says, Kuali has been structured from the beginning as a collection of projects, each self-governing and has a clear differentiation between the top-level Kuali organization and its collection of projects. JA-Sig and Apache are also collections of projects.
It would seem that Duraspace is more of a merger rather than an "umbrella organization". In a sense Duraspace is more like the Sakai-OSP blending where there is a goal to get project roadmaps to gently begin to align.
A Duraspace-like merger for Sakai would be something like Sakai-ATutor or Sakai-OLAT, or even Sakai-Moodle throwing their lots into one organization. I only use these as examples because I think that none of the listed "LMS-mergers" make sense because the projects are doing fine on their own and by staying independent they do not suffer from "who will be the #1 product that the overall org pushes". In a merger situation or buyout situation - it is very rare for it to be symmetric.
At the same time Python Foundation has a single product and happily takes care of that product - so the single-foundation-single product is a completely sustainable pattern. Would it make sense to make the Python-Ruby Foundation? I think not.
One thing in my mind that helps clarify these kinds of things is to "follow the money". I think that we should look at the 990's from Kuali, Duraspace, Python Foundation, Apache Foundation, JA-Sig, and the Sakai Foundation and work backwards to understand how much money is typically available to support umbrella-organziations, projects-within-umbrella organizations and single-project organizations. We can also see how the money is spent to see the nature of these organizations as well.
I think that if we are intending to build a new umbrella organization, we should ask ourselves how our organization would be fundamentally different from other umbrella organizations like Apache, Kuali, and JA-Sig? I can see potential value in a new umbrella organization that is clearly distinct from the existing organizations - but I would like to see a rationale as to how a new project might weigh alternatives and then pick amongst affiliating itself with Apache, Kuali, JA-Sig, or our new ubmrella.org.
I don't think that every vertical market needs its own umbrella organization as proposed above. I think that the difference between Kuali and JA-Sig is not the kind of software which is being created - but instead the basic mission of the non-profit, how it interacts with its community, what it takes from the community, how it supports the community, and how funds are raised, and how funds are dispersed.... many issues - far away from the notion of "what kind of software are we making?"
For me this comes down to doing a good job defining a mission statement for a new organization.
Posted by csev at January 19, 2010 03:17 PM