2008 Sakai Foundation Goals

Purpose of this Document (an MS Word Version is available)

The purpose of this document is to set out some of the things I've been thinking about as I begin to establish a set of goals and a budget for the Sakai Foundation. I've framed this around a number of questions that I think should be asked, if not necessarily answered, about Sakai.

One note of caution: This is not intended to be "rules" for what people in the Sakai community can or can't do. It's community source and those who have resources ultimately decide where we're headed. It's simply a statement of what types of activities the Foundation intends to spend it's resources and influence on. Please keep this in mind during any ensuing discussion.

Use sfgoals2008 label to be included

Table of Contents

Sakai Foundation By-Laws...

I thought it would also be useful to provide a very relevant section of the Sakai Foundation's by-laws before digging in.

ARTICLE III Purposes and Mission
3.1 Purpose. The Sakai Foundation is dedicated to the design and development of collaborative, open source code, software efforts that are targeted at supporting education, research and related scholarly activities.

3.2 Mission. The mission of Sakai is:
a) To deliver an application framework and associated collaboration, research, and teaching and learning environment tools and components that are designed to work together for education course management, research support and various forms of collaboration;
b) To support research, collaboration and community building around the Sakai application framework and associated research and learning environment tools and components that are designed to work together for education course management, research support and various forms of collaboration;
c) To solicit grants and other funding to permit the development and refinement of the Sakai application framework and associated research and learning environment tools and components that are designed to work together for education course management, research support and various forms of collaboration;
d) To promote economic efficiencies for IT in education and research settings through cooperation, leverage of shared investments and innovation.
e) To engage in the development, adoption and propagation of open standards for IT, data and information in education and research settings through cooperation with similar efforts across the globe.
f) To engage in such activities permitted under the Michigan Nonprofit Corporation Act incident or beneficial to the foregoing purposes;
g) To serve as an effective voice for open and community source software for research, collaboration, and teaching and learning environment efforts in education.

The Questions

Should we articulate a product strategy/direction?

The first may seem like a silly question...of course we should. But there is a rational argument to say, simply, that this is community source and the product will head in the direction the community takes it. I think of this question often because I'm starting to give (and have already given) presentations to institutions considering Sakai. To the CIO at these institutions you would say: Look around at the community members, what they are working on and how they are using the product. If you like what you see, you should be comfortable with where the Sakai CLE is headed and join us.

This is an unsatisfactory answer for me, personally, primarily because I would like to see significant additional adoption of Sakai (see separate question addressing this assumption and what I mean by "significant") and we limit the number of institutions willing to adopt if we can't at least tell them where we are intending to go.

On the one hand, a less specific articulation of the product direction potentially makes the appeal broader (although too general can become vacuous). On the other, more focus could potentially get us somewhere faster (although only if it is somewhere enough people want to go).

I think the answer to this question is informed by how important you think adoption is. The more important you think adoption is, the more important it is to define a product strategy and to make it somewhat specific. This is because I believe that the "next wave" of Sakai adopters are going to care as much about the Sakai product as the Sakai community and will want more specific answers. If we don't give them more specificity, they are less likely to join. I already hear this from current Sakai Foundation member institutions.

How specific should this product strategy be?

We should be able to credibly answer questions from interested institutions about where Sakai is headed and, as importantly, where it is not headed. The generic "wherever you take it" answer needs to be coupled with something of the form:

Of course, this product vision should be coupled with the "wherever we take it together" answer. And we should emphasize that, as an open source project, other surprising and beneficial uses will emerge.

The downside of a more specific message about the Sakai CLE is, among other things, the credibility hit that would come with not delivering on our product vision. There is a distinction, I think, between a product vision and a roadmap with timelines (although it can be a slippery slope). So we have to treat this very carefully.

Where should we be on the continuum from "code libraries" to "product"?

We have a choice to make here in terms of how "off the shelf" the Sakai release should be. A more productized release doesn't exclude using the source code as set of libraries to be used as the basis for an (essentially) home-grown system, but if we view our project as delivering code libraries it won't usable as an off the shelf product. Today, Sakai is further towards the "code library" end of the spectrum than I would like. Again, because I think additional adoption is desirable and we won't get there without a more product-like approach.

If, in fact, we aren't trying to be a product then we need to change our communication and even our release practices.

If we are trying to be a product then we need to improve the quality of our releases as well as our installation and administrative tools.

The middle ground is to rely on commercial partners to provide the productized version of Sakai. Again, a change in our messaging would be required here.

What does this mean we won't be doing?

A few things we shouldn't actively pursue at this stage of the game:

• Building SIS-type functionality (Kuali Student, Oracle, Banner), although we should be working closely with these groups to make sure we're each doing "what we should be."
• Driving K-12 related functionality into Sakai, although we'll certainly help out if someone (IBM?) wants to provide resources to do that.
• Building courseware authoring tools, although Sakai should serve as a conduit for publishing open courseware.
• Making Sakai run well on a "desktop" machine, although we should certainly make it easier to install and administer.

Who should we be trying to attract into the development community?

We should be trying to recruit a few more development-capable schools into the community. The current set of schools may be "enough" but we could benefit from the addition of a few more significant centers of development resource.

This should be a higher priority for the Sakai Foundation that adoption in general (despite the relative lack of space dedicated to this topic) and should be a significant focus for the ED and the Board of Directors.

Who is the Sakai CLE for? The institutional answer...

I would actually break this question down a bit more, as follows:

• What use cases/institution types are ideal candidates for Sakai today?
• Who should we be trying to optimize the software for?
• Who else will find value in the software?
• Who shouldn't try to use the software?

My thoughts:

We are an excellent choice for higher education institutions with a need for a system that manages both collaboration and courses and want to have access to source code. Their specific reasons for wanting to have access to the source code are less important, and could include a combination of the following:

1. They want a platform for innovating/customizing
2. They want to manage the risks associated with proprietary software
3. They do not want to pay licensing fees to a vendor

These are in priority order, that is, if a school's interest is skewed to #1 then Sakai is a relatively better bet than if their primary interest is #3. I, personally, would like to see us make each of these sufficient reasons for choosing Sakai.

I'm reminded of Geoffrey Moore's "bowling pin" metaphor for approaching "markets", where you succeed in an initial target and then proceed to addressing adjacent "markets" (in quotes because I would say we're taking about groups of institutions, which are not really large enough to be what I would consider a "market").

Here's a sample picture of what this might look like for Sakai:

The area of focus would be the use cases surrounded by the blue diamond. This is clearly not well thought out at this point, but I think this type of analysis is important in trying to articulate who should be using Sakai and, perhaps more importantly, who we should be trying to recruit to the Sakai community (because they will naturally help get us there).

The basic goal here is to be successful one step at a time, only reaching further when we've established enough success to move on.

Who is the Sakai CLE for? Another way of segmenting the world...

Another way of looking at this is, which is more focused on the individual rather than the institution, is based on the kind of flexibility people want in their CMS (forgive the fashion metaphor):

• Off the rack: These folks are happy with a standard CMS and worry about the costs and time associated with customization.
• Tailored: These folks aren't quite happy with a standard CMS and are willing to invest, at least on a one-time basis, for significant changes to meet their campus needs.
• Bespoke: This group thinks it is important to have a unified, centrally supported platform, but they want it to be their vision of what the platform should be. They'll customize the CMS and use it for a platform for meeting local requirements, evolving it over time as needs change.
• Suit? I'm wearing jeans today and dress tomorrow: This group, which is a small but growing faction, believe that enterprise CMSs are too restrictive and want the freedom of choice that the open internet provides. Sure, they miss the central support and the benefits of integrated systems, but if they have to choose between the benefits of integration and the benefits of freedom, they choose freedom. (This, by the way, is my person view on how, in the long run, we should be thinking about the student interface to Sakai. See the next section for more.)

It is an interesting question as to whether, by trying to meet all of these use cases, you to fail to be the best at any one. The risk of trying to address all of these and failing to be the best at any one is that the platform will be adopted (as a compromise solution) only when a campus can't come to agreement on a strategy. Or, put more positively, you are chosen as the platform that provides the most ability to choose and/or change paths as time marches on.

Sakai could become a solution that addresses all of these segments. The service-oriented architecture, modular tool approach and open/community source model could provide the best of both worlds. We aren't there today, of course, and perhaps the best path for getting there is to focus on one or two of these groups first while ensuring the architectural decisions don't disallow any of the others.

(Thanks to Michael Feldstein for the starting point for this segmentation)

Whence the learner?

Oh, yes, the learner. Where do they fit into this mix?

Creating a great experience for learners should certainly be a goal of the Sakai community. My personal view about this is that, eventually, learners may seldom log into Sakai, per se. I can see a future with Sakai as a provider of data/services that get assembled in a Personal Learning Environment that is chosen by the student rather than the institution. Especially as you move out of the world of 4-year colleges into a world of K-80 learning, the notion of the student experience being centered at the university makes less sense. Furthermore, you can control your IT and academic computing resources. You can hope to dictate to your faculty how they use technology on campus. It's a much more difficulty proposition to tell students what they can and can't use as part of their learning experience. They will be using other tools and these other tools are like to form the center of their online experience, rather than a CMS. We should relax and embrace this, instead of fighting it. This is a long-term view, however, and we do need to address the question of learners in the short and medium term.

This document has focused on the instructors and administration because, for better or for worse, those constituencies seem to be the driving forces in CMS decisions on campus. While student retention and satisfaction is certainly important to many institutions, the CMS is not seen as a major differentiating factor in terms of student recruitment, retention or satisfaction.

One could argue that this is an opportunity for Sakai to really differentiate itself. I agree, in the long run. We should show our vision with a few key examples, like a Facebook integration or an "important event" feed that can be aggregated. Chuck's recent functionality mash-ups also come to mind, of course. In the short run, though, our efforts should focus should be on the needs instructor, researcher and members of the technology services organizations (IT, Academic Computing, whatever).

But, again, this partly depends on how much and what kind of adoption you think is important.

How much adoption is desirable/necessary?

Enough to sustain community development is necessary. We've achieved this already.
Enough to attract external development is desirable.

A piece of my recent blog post on this topic is relevant here:

...But is wider adoption a good thing? While it may seem to be inherently beneficial, wide adoption isn't valuable in and of itself. The current Sakai community isn't necessarily helped if institutions adopt but don't contribute, either directly or via membership in the Sakai Foundation. That's true, as far as it goes, but I think this misses a crucial point. There is a critical mass (tipping point?) of adoption that brings useful resources to bear. If, for example, commercial enterprises see enough schools using Sakai, they will devote resources to integrating their technology or content with the platform. And that should benefit everyone-you never know when your school is going to need a commercial tool that, thank you very much, has already been integrated with the platform...

If you accept this, the question then becomes two-fold: How much adoption is enough? Are we ready for it?

The answer to the first of these follow-on questions is more than we have now. The good news is that we are already seeing 3rd parties show interest in working with Sakai (Wimba and Elluminate are both showing off integrations at Newport Beach). But I think we need about 15% market share in any particular market to ensure that we are attracting 3rd party development. (Maybe 10% is enough, certainly 20% should do.)

There are different ways of measuring market share (% of institutions? % of enrollments? Across which schools in which geographies?), and I'm not going to try to analyze that in this document. The point is that we'll know when folks are coming to us saying "We did this cool integration with Sakai, wanna see it?" rather than saying "We're thinking about integrating with Sakai, what can you tell us about adoption?"

The answer to the question of whether we are ready is: I sure hope so (or, perhaps, We'd better be). It seems clear that many institutions are considering replacing their CMSs in the next few years, in large part because of dissatisfaction with Blackboard/WebCT and the emergence of viable alternatives like Sakai, Moodle, Angel and D2L.There's a mass re-evaluation of campus strategy for these systems happening and I think there is a 2-3 year window of opportunity to bring these schools into the Sakai community. Once a decision is made, especially a decision that involves switching from one CMS to another which is painful and expensive, the opportunity won't come around again for another 5-10 years (in most cases).

Should there be a geographical focus to our efforts?

Trying to address the whole world at once would be biting off more than we can chew (although partners are more than welcome to take us places the Foundation can't concentrate on). Clearly we should be focused on the English-speaking world where we are already successful. That's North America, the UK, Australia and South Africa. We should also continue to try to strengthen our presence in Western Europe. I especially like Spain, France and Portugal because they speak languages that allow Sakai to spread to many other places in the world (Central/South America, Africa). And the momentum we've built in the Netherlands shouldn't be squandered either.

I would propose we concentrate on those areas we already have good traction and explore, at most, two other geographies for potential expansion. China is promising but a very long-term proposition. India could be a good source of development resources and Russia looks interesting as well.

In any case, the main message here is for Foundation resources not to get spread too thin.

What does any of this have to do with the Sakai Foundation?

The first question we should ask about any actions that may be implied by this is: Can we get the community to do it? First and foremost we shouldn't be trying to consolidate control into the foundation. The SF should remain primarily focused on coordinating activities that the community is able to do, only stepping in directly when needed.

In general, I think the foundation should take a more active role in driving the product. I don't think it should become a dominant player in development, however, rather it should use its position at "the center" to turn conversations about needs into active development projects run by the community.

It should have some budget for doing coding/design work (either by a staff member or by hiring external developers) but its main product development activities should be requirements gathering, best practices development and dissemination (e.g. coding standards and UX standards), release management, quality assurance, training, documentation and working with standards bodies.

I've been thinking a lot about the training aspect lately. The foundation itself hasn't done a great deal of that (thanks to everyone who has run the programmer's café!) but one could see a role for the foundation in being, essentially, the equivalent of developer support (again, "developer" being broadly construed to include everything from requirements to QA to documentation).

Here's an attempt at a mission statement for this aspect of the Sakai Foundation:

A key goal of the Sakai Foundation is to maximize the time the community members spend developing innovative new tools and uses for the Sakai CLE. We do this in part by taking care of many administrative tasks related to development and by lowering the barriers to entry for participation, making it possible for even smaller community members to contribute meaningfully. We lower these barriers by creating tools for developers and by providing training, documentation and support.

I should be careful to say that it will take some time and re-prioritization or resources to move the Sakai Foundation in this direction. I'd be very interested in community feedback about this.

How big should the Sakai Foundation be?

This is a two-part question, budget and staff. In terms of budget, I believe we should be taking a bottom-up approach, that is, how much do we need to do the things the community wants/needs us to do? We should target that amount and, if a surplus develops, be equally open to reducing membership dues as to taking on new tasks.

In terms of staff, we should stay as small as possible. We should think about staff members outside of the US, however, to make it easier to provide support to those geographies. Depending on the direction this conversation takes, I think we are likely to want two or three of new staff positions, but not much more than that.

What about the community aspect of the SF mission?

I think the values the community espouses (meritocracy, etc.) are excellent and I don't see a need for much refinement of those. I do see a need to (a) communicate them clearly, (b) ensure that we live up to them and (c) make it as easy as possible for folks to participate in the community.

Regardless of the product strategy, I do think the foundation needs to be more proactive in driving requirements development. This work is hard to do across institutions when there are local production issues and an SF resource should be able to help here. Whether the SF is "just" a facilitator or is taking a more active role in creating requirements is a question that depends on answers to some of the questions above.

Again, implicit in all of this is a question about how active the community wants the Sakai Foundation, including the Board of Directors, to be in answering questions like those that are posed above.

My personal view is that we should be very active in soliciting and synthesizing community opinion into fairly concrete statements. A "less active" alternative is to let discussions like this evolve at their own pace and assist with documenting the results. A "more active" alternative would be for the SF to be making them decisions and announcing them to the community.

....more to come, here, but I want to get this circulating sooner rather than later...