sakai

Blogging at threecanoes.com

Three Canoes

Since May, I have been an independent consultant on Sakai and the Open Source Portfolio. So has Janice Smith, formerly of rSmart. We have worked together on a few projects and found that we make a very good team. We have decided to formalize this relationship by working together as Sakai/portfolio consultants under the shared name of "Three Canoes". Also joining us is Michael Heroux, an instructional designer, teacher, and information architect whom I worked with for several years at Syracuse University.

I will continue to blog about Sakai and OSP at http://threecanoes.com/blogs/sean.

Thoughts on budget crunches in higher ed and open source

Today I received an mass email from the chancellor at Syracuse University with a message about the university's approach to addressing the financial crisis. At the heart of the message was that the university will be cutting central administrative costs by $8 million this year and $11 million next year. If I interpret that correctly, IT budgets are going to come under close scrutiny at Syracuse, with a lot of pressure to cut out the fat where possible. I am sure many other colleges are already looking ways to jettison dead weight to make their IT departments float. I also would love to know how this will impact the funding of open source software adoption on campuses. I am particularly interested in how this will affect the adoption of Sakai by new schools.

I suppose it depends on the leadership in place at these schools and how they have positioned themselves with regard to the priority of "taking control of their IT destiny" as a strong strategic direction that they wish to (or MUST) pursue. For the bulk of schools who are looking to maximize ROI on their investment, they need to look carefully on how they will measure their investment returns. We know too well that open source software is not necessarily cheap. Sakai requires a sophisticated infrastructure to scale up to provide service to a large school and a skilled technical staff to maintain it. Switching from any one software to another is a very expensive proposition.

On the other hand, there are vendors who are poised to provide inexpensive hosting that may be compelling for schools that are looking to adopt an eLearning platform. You might think that using an "off the shelf", vendor supported solution would be counterintuitive to the whole idea of open source software. In the Sakai community the brightest lights usually shine on the biggest "innovations", but I think that when the rubber meets the road, the advantage of open source software comes when an institution can pinpoint its resources to address their highest priority support items. Time and time again I hear that the main reasons for many schools to move away from their chosen proprietary vendor is that they were not able to provide good support.

When you choose an open source vendor, you not only get that vendor's added value and support promises, you can also participate in that effort and eliminate your top support headaches by fixing local issues and contributing them back to the community. It is harder to articulate the value of the support tickets that you did need to field because you weren't waiting for the next major release of software or for a vendor response. Of course, convincing your local leadership that this is a better investment than completely relying on a vendor for everything may be a tough sell if they are simply looking at short term costs.

Sakai Virginia Tech Conference

This week I took a trip to Blacksburg, VA for the Sakai regional conference. It was a low budget trip now that I am pulling from my own funds to come. The Red Carpet Inn is $54/night including tax and I spent about $100 in gas to drive the 18 hours from Syracuse, NY and back. My late registration cost $200.

The session by Virginia Tech on outcomes was really good and tied in directly with the Assessment Institute that I attended a couple weeks back. I think the experience I had at Syracuse with NCATE accreditation and the use of Sakai portfolios and Goal Management is hitting lots of other schools now. Schools like Virginia Tech and Indiana University that are exploring variations on the theme of Goal Management are building a free (not as in beer) system that integrates the student centered ideas of portfolios with the institutional perspective needed for long term sustainability and aggregation needed for program assessment over the long haul. Although Syracuse University is not actively involved in the development of those tools, I believe that the return on the investment that was made when the School of Education developed and disseminated the proof of concept GM tools has not come full circle yet. In a year or so, I bet that the community will improve upon this theme and a much more refined approach will be available for use by SU and other schools.

The presentation by TX State entitled "Bye, Bye Blackboard" was interesting as I felt it represented an interesting dichotomy that has popped up on the list a few times and will be highlighted by present financial strains that college IT departments will be feeling for a while. Texas State had been running an early version of Blackboard that was written in perl and had customized it for their local needs a great deal. The costs of licensing Bb for an upgrade in 2005 were going to increase from $5K to $55K per year. The rationale for investigating an open source solution was to allow them to continue to make their customizations (to innovate) and to simultaneously avoid the high license costs. However, the number of FTE needed to maintain Sakai and the weight of moving from perl to enterprise java development seems to have negated cost savings. I asked the presenters (the project director and some IT staff) if they could comment on the discrepancy between their implied goal of reserving the right to innovation versus what seemed to be an implementation that looked like a commodity service replacement. The IT staff member who had done the perl customizations admitted that they were not customizing their software as rapidly as they could in perl and that the staff were not able to turn on a dime and react to faculty requests in the way that they once could. Much of the talk revolved around training faculty to do the same sorts of things that they did in Bb in Sakai and maintaining the more complicated infrastructure to support Sakai. The development work they have done seems to be more targeted towards administrative work (migrating Bb courses to Sakai) and enterprise integration projects than towards the faculty and student end users at this point. I think that is natural and probably necessary, but the perception that Sakai is a great platform for rapid innovation and response to feature requests is a tough sell unless you throw a ton of resources at the problems. I really appreciated their attention to the different needs of their faculty as they encouraged their faculty to make the choice to move to Sakai. This is undoubtedly one of the nest Sakai success stories in the community, but it is filled with lessons we could all learn from.

This underlying message resonated with what some Sakai implementors have been saying on the list. It struck me that Luke Fernandez's comments about discussing Sakai design in terms of Bb and Moodle were telling in the sort of Bb service replacement that many schools are expecting from Sakai. At this point Sakai may be behind the curve on meeting these expectations for those schools, but will quickly be moving forward to change the paradigm. Michael Korcuska's demo of the ideas that are coming out of the Sakai 3.0 UX work are evidence to that.

There was an OSP BOF at the end of the first day. Since the BOF was my bright idea, I ended up doing some demonstrations of the OSP tools and reviewing the documentation that was available on the wiki. In general I think it was well received. For the most part, I think that the schools that are interested in OSP are not interested in large vendor contracts to set up and run their portfolio implementations. I think that the model for giving schools a "leg up" and then letting them do their own work is more in keeping with many of the committed Sakai schools. I also received positive feedback on building community documentation into a consulting job. I made sure that I credited Weber State for funding the development of the community documentation that is on the wiki and encouraged others to talk to Janice Smith and I if they would like help with their own implementation and/or would like to fund further documentation efforts.

Open Source Portfolio Screencasts - Exploring the Tools

I just created a few screencasts about the Open Source Portfolio. Hopefully this documentation (funded by Weber State University) will help others understand how to use the OSP tools in Sakai.

I start by introducing how to setup a worksite in Sakai, how to import data structures from the community library and how to recreate a teaching "Best Practice" from another university as a way to jump start the portfolio discussion in just three screencasts.

See the complete docs here

Setup a demo site

Import and export a form

 

Recreate an Existing Portfolio Best Practice from the Community Library

 
 

The barrier to entry into OSP

I've been working with a small team at Weber State to give them a quick "leg up" on some of the "ins and outs" of the OSP tools so that they can move forward with an initial implementation of their own matrix and portfolio template. I asked Vicki Napper if I could quote her, because I think she really nails a problem that the OSP community has.

She said (in reference to the built-in ambiguity of the tool suite):

"Should the term open source mean ...without an opinion about use? I don't think so. Open source's power is that many people are thinking about common problems...but they need to document why they chose the solutions they did and why it works for them."

I think its telling that (given the popularity of ePortfolio's in education circles today) OSP doesn't have many adopters nor contributors. The charge ahead is largely lead by a few large institutions. I stopped for a second and told her my opinion:

"Its rather amazing that their isn't some "out of the box experience" isn't it? Not even a "basic portfolio" that lets you throw together a few pages. The community of schools that have been building it have been very cautious not to pigeon-hole the software into one or two uses. None of us like it, but are unsure what common portfolio experience "other" schools would find most useful. This would require a research (maybe even a marketing) budget to discover what "other people" want. Keep in mind that the schools throwing resources into OSP are ALREADY using it to support THEIR portfolio processes and any resources they have for OSP are spent on that activity...not on the kind of research that would likely benefit newcomers. Of course, they are open to new ideas, but often the effort required to participate in the discussion is a barrier to the input of new ideas."

I'm feeling empathy for Nathan Pearson as he tries to get his head around the basic functionality of OSP, its application and history. I think Nathan has the newcomer's perspective in mind in his UX effort.

I wonder what sort of research effort should go into this before Sakai 3.0? It would seem an ideal project for a UX group to take on as a purely exploratory piece....and not just from current users, but from potential users that are frequently turned away by the traditionally high barriers.

Open Source Portfolio Tool Documentation

I recently have begun working with a small team at Weber State University. Their School of Education is interested in moving forward with an OSP implementation. My proposal to them included:

  • an OSP overview
  • informal training of the tools they need to complete their project
  • documentation of those tools on the public Sakai wiki

This approach will benefit the team involved in the immediate project, their successors and the entire Sakai community. We’ve allocated about 15 hours to writing an overview of the tools and how to use the “Forms” and “Portfolio Template” tools. The effort will be largely guided by Weber State’s needs, but I believe that any newcomer to OSP will find the documentation we write to be useful.

UPDATE: See the following confluence pages:

Sakai Reports Tool / Data Warehouse Documentation Interest

A few weeks ago I mentioned that I was interested in doing a bit of freelance consulting for OSP. A couple people asked me if I was available/interested in doing work outside of OSP for Sakai in general. Of course, I am. The Reports tool (now core, like the rest of the OSP tools suite) seems to blur the boundaries between OSP and Sakai. In a nutshell, the reports tool allows someone to define SQL based reports that can be run against the live database or a set of data warehouse tables (you may have noticed a bunch of tables named "dw_xxxxx" in your instance). To complicate matters, much of the data related to portfolios are stored in XML on the file system and are therefore unavailable to the reports tool unless converted. The system is powerful, but poorly understood by the community and sparsely documented.

I have set up an account and a project at fundable.com to see what sort of interest the community has for this effort.

The Sakai Reports tool documentation needs improvement.

Many schools deploying OSP as a portfolio system want to use custom reports to aggregate data for institutional purposes. The reports that the community has included in the OOTB experience have little to do with the type of data that schools would actually want to report about. Building custom reports for your institution makes a lot of sense, but very few schools have been successful at it because they just don't know how.

I would be interested in investigating and writing related community documentation in Sakai confluence if anyone is interested in funding my independent effort to do so. My initial guess is that I will probably need to also document the job scheduler and the data warehouse in order to successfully move the documentation forward. While it is difficult to promise a "complete package" will result from my effort I feel that a few good interviews and some time devoted to understanding and disseminating the capabilities (and limitations) of the report tool functionality would benefit the entire Sakai community.

e/merge 2008 Conference and OSP

I whipped up some rough-and-ready portfolio items for the upcoming e/merge2008 conference for Stephen Marquart in response to his questions about possibility to use the OSP tools to do something he normally does with a simple php script.

He wanted a simple form where a conference organizer could enter structured data about a "presentation", including a (rich text) description, as well as presentation files (pdf or PowerPoint) for download. I created the form to prompt the user for that information.

I also created a Portfolio Template that (by default) shows the list of "presentations" added to the portfolio with links to detail pages. Stephen wanted to be able to show the appropriate icon next to each presentation file, but I realized that the mom-type of the file does not get brought along in the XML document, just the URL (and that isn't even complete).

Anyway, here is my "rough and ready" answer to his request:

Open Source Portfolio Consulting

I'm sitting on our porch swing on a hot Saturday morning. My kids (2 and 5 years old) just ate their pancakes and are playing in the sprinkler and plastic pool. It's going to be a hot one and I probably need to break down and put the air conditioners in the windows today. For the first weekend in quite some time, I am probably not going to work…on anything…on portfolios, Sakai, coursework, side projects…nothing…I'm going to spend some family time.

Last month I finished my long-in-coming master's degree in Information Management at the iSchool at Syracuse. My eight-year stint at Syracuse University supporting students and faculty is complete. I did all that I could to make my recommendations for next steps and close the projects associated with the grants that funded the Living SchoolBook.

I don't have a "real job" right now, at least not in the sense that I really wanted or planned for. Without getting into the details, I am currently paying the bills working on a couple of Sakai/OSP and Drupal related projects out my home. While I enjoy working with the Sakai and OSP community and software, there are issues with doing this sort of work as an independent consultant.

First of all, a lot of what makes working with an open source project a very rewarding experience is the opportunity to "get in the game" and participate in the "upstream discussion". When employed by SU, I was encouraged (and paid) to participate where I could and to help shape the direction of the software in a manner consistent with our objectives. As an independent consultant, I feel that I still need to participate and not be a "free rider" on the community of professionals that work so hard to make this useful software. However, I recognize that I will rarely be paid to engage in these conversations and I do so at my own short-term loss…one less beach trip for my family in exchange for my personal gratification and credibility in this meritocracy-driven community.

Second, there is all of the "meta-work" associated with managing your own micro-business. Filling your own business pipeline, creating invoices, learning the business tax rules and all of that sort of stuff is more time spent not DOING anything that adds value to any project or my quality of life. I hardly even know what I am talking about here…I am so green…

I am passively pursuing an option for more "stable" employment in the community, but part of me asks (Letterman-style), "Is this anything?" about the whole Sakai/OSP self-employment idea. I wonder what sort of demand there is for someone like me to provide consulting services to schools looking to engage in agile, short-term projects around the OSP tool suite.

It strikes me that with the right people in the room, a small, devoted team could make great strides in an OSP project in just a 1 or 2 week sprint if they had just a little "leg up" and just-in-time "support". I could provide that "leg up" and help a small team to make something useful quickly, document ideas for new enhancements and features…and LEAVE when they want me to. The transaction costs within a small team are much less expensive than between that team and me, so knowing when to leave (and for schools to know when to tell me to leave) is an important decision that an institution would need to make in order to ensure that they were getting the biggest ROI on the project.

I think that these sorts of sessions could spin-off a lot of documented examples and material to contribute to the community library (the OSP community's emerging body of knowledge around deployment strategies and data structures). I could play a role in documenting projects I am involved in and ensuring that they are contributed for others to use.

Keep in mind, this is not necessarily something I believe is sustainable as a business model long-term; however, given my current situation, I would be willing to discuss how this model might work (or not) for individual institutions. This sort of short-term employment would simultaneously add value to the community and (I believe) be a low-cost way to start getting productive with OSP with real, tangible results that we build together. If this is something you think you want to talk about, let me know.

Enterprise Portfolio Support vs.Web 2.0 Computing

UPDATE: This post was renamed from "Enterprise Portfolio Support vs. Cloud Computing...a grossly wrong title for what I am talking about.

I have been so impressed by the incredible amount of work and diligence I have seen demonstrated by the administrators, teachers and support staff here at the RINET Sakai conference over the last two days. It is really amazing to me to see the hard work that we did on Goal Management at Syracuse in use by real people. The Goal Management tool and the Goal Aware Assignment tool are one of the key components of the RIEPS (Rhode Island Electronic Portfolio System) implementation of Sakai and OSP. Their implementation is supporting:

  • 15 districts
  • 25 High Schools
  • 40,000 students
  • 3,200 teachers
  • 13,000 courses

The thing that is "right" about RIEPS is the enterprise decision that they made to support a large school reform movement. It is something that an enterprise decision can do to shape the discussion on a very large scale. By providing support and services around the authoring and assessment of student portfolios as a means for students to demonstrate competency in the state and district standards and expectations necessary for a student to graduate, they are making a radical departure from the world of high stakes standardized tests that most of the rest of the country is involved with. It is a big deal.

Attending this conference are quite a few folks who have been talking about portfolios in the context of "cloud computing", using Web 2.0 tools (Google docs, Twitter, Facebook, etc.) and mobile devices to enable and empower individual teachers to engage students using tools that they already love to use. This very forward thinking group sees the possibilities that these tools afford for "socializing" information amongst the other learners (the teacher being one of those learners) in the class and promoting constructive dialogs around issues relevant to the curriculum. The keynote speaker in the morning was Philip Long from MIT who showed a lot of interesting examples.

As cool as all that was (and it was cool stuff that many folks around the room were really interested in), I feel pretty certain that most teachers will find it difficult to make an investment of their time to research tools that they would like to use and to integrate them into their class on a regular basis. In fact, it might be a bad idea to start developing plans to use a service that isn't supported by your district for a number of reasons:

  • They are subject to change faster than you may want them to since you have no relationship with that provider to provide a consistent service
  • They may not be regulated in a manner consistent with your school's privacy policies and could be vulnerable to attacks, exposing student information to "ne'er-do-wells"
  • The company may be taken over and your data sold
Furthermore, an ad-hoc "cloud computing" strategy draws on the enthusiasm, passion and energy of the early adopters of technology while providing little support for the rest (majority) of other teachers to bring them on board with the change. While the idea of a "Yahoo Pipes-style" mashup of information as a part of a Web 2.0 portfolio sounds pretty cool, its complex nature compounds the above problems and creates a rather brittle model that I wouldn't entertain for long without engaging in serious discussions with each of the component service providers.

While talking briefly with Trent Batson about this idea, he mentioned that he is starting to think less in terms of "life long" portfolios and more in terms of them being ephemeral bits that serve a purpose for a very short time. This was a big shift for me as I had been thinking (and hearing others thinking) of portfolios as the large pile of "my stuff" and presentations of that stuff for various purposes. The notion of a P-80 (Preschool to 80 years old) portfolio was mentioned several times during this conference.

Of course, the flip side of the coin that everyone is sensitive to is an institutionalized/enterpise system that places too much emphasis on institutional needs for accountability and not enough on providing services that provide an environment for authentic learning. Based on what I am seeing here and the excitement that the teachers are describing in having access to a system that allows them to constantly communicate with their students (this is one of the first times I have seen a truly teaching and learning centered Sakai conference), I think that this effort will result in some big changes in the culture of the classroom if it continues to receive the support it needs. Among the exciting things I saw:

  • Large numbers of Rhode Island teachers (many of whom professed not to be early adopters) are using the RIEPS system and are really excited about it.
  • They have a relationship with a commercial affiliate and seem receptive to engaging in the community discussions relavent to their work so that they can support and change their system at their own pace.
  • The effect of the system appears to be a lever by which the RI schools can affect school reform away from standardized tests and towards assessment for learning.
  • Teachers are being draw into and are asking for professional development space within RIEPS and having "light bulb" moments in which they see the connection between the technology they are using and how it can be integrated into their classes

Syndicate content