Copyright, Charles Severance 2010 – All Rights Reserved
From time to time I will put up draft excerpts of the book I am writing about Sakai. Feel free to comment and/or correct where I am mistaken by sending me E-Mail.

The Sakai project was formed in a moment of transition between a hierarchical / centrally controlled approach in campus information technology infrastructure and an organic / distributed approach to coordinating across a community of like-minded individuals and organizations. As a result, the Sakai effort has always been at the boundary between old-school approaches and new-age approaches to technology development and deployment. At times Sakai has achieved great success through a blend of old-school and new-age approaches and at other times operating at that boundary has led to great long-lasting conflict and stresses in the community.

By the year 2000, the concept of open source as an approach to software development was well established with the Linux operating system and Apache Foundation projects as solid sustainable examples. These efforts collected the talents of volunteer developers from around the world with relatively loose leadership and a commitment to working together to solve a common need. Generally the developers who worked in these projects fell into one of several categories: (1) volunteers who had paying day jobs who worked on the software in their spare time, (2) consultants or small companies who made their living doing consulting on the open source software and gained competitive advantage from their involvement in the project, or (3) individuals hired by large companies such as IBM who were given release time to contribute to these projects to support the projects and insure that the company had a voice in the projects going forward.

Many universities used open source software throughout their enterprise since the early 1990’s. Open source software was ideal or University use because it was low-cost and allowed University technology staff to make small changes to the software where some particular or unique feature was needed. Open Source gave Universities a sense of “control” over their destiny and future costs when it came to their information technology solutions. Open source software also allowed a certain level of “agility” as technology needs shifted throughout the 1990’s as things like the Internet and World Wide Web became part of the required campus information technology suite of services.

However, few universities were regular contributors to open source efforts. Universities typically felt that the software and other intellectual property produced by their employees had potential value and if a staff member built something that was valuable, then the university wanted to profit from that creation. After all, the university had paid the person’s salary while they were doing the work. It made perfect sense to a university administrator or attorney but was very frustrating to individual university employees who yearned to work with their colleagues around the world as part of a community effort.

This led to Universities writing a lot of software for their own use but not sharing that software with other universities unless there was some profit to be made on the interaction. And because no University was willing to invest the time and staff in making their software commercial-quality, most University-developed software was “just barely good enough” for local use.

One of the most common examples of “locally developed” software in the late 1990’s in use at Universities was the campus-wide Learning Management System. Learning Management Systems were pretty basic software and allowed instructors to distribute materials for students and interact using e-mail, chat, or threaded discussion forums with the students. These systems were simple enough that it only took a small amount of resources to get a basic system developed, up and running with a team of 1-2 developers in with less than a year of effort. Often the efforts were done “on the side” or “below the radar” of the typical campus IT operations.

In some cases these university-developed course management systems developed to the point where were purchased and turned into today’s commercial Learning Management Systems. The WebCT commercial LMS product was based on software developed at the University of British Columbia in 1995. The initial Blackboard product was based on a system developed at Cornell University in 1997. The ANGEL Learning system was created in 2000 based on technology developed at Indiana University-Purdue University at Indianapolis (IUPUI). The Prometheus system was developed at George Washington University and later purchased by Blackboard in 2002.

Often the universities would make some money in these transactions, but the real winners were the companies that took the software, cleaned it up and began to sell it to all of the other universities who were growing tired of their local home-grown systems. These companies started building market share and applying economies of scale to their software development. In time these companies began merging and buying one another to become ever larger and more pervasive in the marketplace. At the time of this writing, Blackboard has purchased Prometheus, WebCT, and ANGEL resulting in a very large market share.

??? Did D2L come from McGill University ?? When/How ??

Stanford University developed CourseWork system in 2001 and began to share the software with other Universities around the world. Also in In 2001, the Moodle project also starts with a simple LMS system with an open source license. The MIT Open Knowledge Initiative (OKI) was a project funded by the Andrew W. Mellon Foundation in 2001 to try to bring order to the chaos of so many independent LMS projects and so many divergent Learning Management Systems at so many Universities. Other projects such as Boddington at the University of Leeds, OLAT at the University of Zurich and CHEF from the University of Michigan were pursuing an open source approach and tried to convince other schools that their solutions were something that could be adopted.

From 2001 through 2003, the MIT OKI project regularly brought together many of the leading thinkers about LMS systems and technology from Universities around the world. The OKI meetings and discussions began to form a community of technical staff who slowly started to know one another and realized that even though they worked at many different organizations, that they were all facing the same problems and challenges.

As the OKI project funding was ending in 2003, several of the participants in the OKI efforts decided that perhaps they should band together to form a consortium and work more closely together to develop and release a shared Learning Management System that they would all work on collectively and all use in production at their institutions. By pooling resources, the partners would gain much greater leverage and each school would not have to solve the entire software development, testing, and maintenance tasks.

The goal of the Sakai project was to take the “best of breed” of the current university-developed learning management systems and produce one system that included the best of each of the systems. As a key founding principle, the Sakai project was going to operate on open source principles and every school that received Sakai funding was required to agree to give away all their rights to commercial gain from the software that they produced as part of the Sakai project.

Demanding these open source principles was quite necessary because university adopters of “free” software had see the pattern more than once where a piece of software started out as a “free and collective effort” and then once it had a few customers, the university which owned the software sold it a commercial company along with the customers who had adopted the software. The university that had originally written the program typically made some money and was giving the right to use the software forever. but the adopting schools were given no such deal. They were usually forced to pay the new owner of their software to continue to use it.

So Sakai was to be owned by no university – it was to be owned by the collective. That way all the participants in the project could be assured that the software would stay free forever and that no school would profit from participation in Sakai by selling the adopters of the software to a commercial vendor.

The University of Michigan was selected as the lead institution for the Sakai project and the Principle Investigator for the Andrew F. Mellon Foundation grant was Joseph Hardin and I was to the the Chief Architect for the project. The three other partner schools were Indiana University, MIT, and Stanford University. All the schools had a very strong track record for leadership in software for teaching and learning. The Sakai project also included the uPortal project as well as continued funding for the OKI project.

As a condition of being a partner in the project, each school was required to sign the agreement that they would forgo any commercial gain from the software developed as part of the Sakai project. This agreement was relatively easy for the University of Michigan and Indiana University to sign, but both Stanford and MIT had made significant revenue from licensing software over the years so it was a pretty impressive that the decided to agree to the terms and join the project. There was a fifth school who was considered as a potential partner who wanted a few weasel words put into their contract terms for the intellectual property. We just said “no thank you” and went ahead with the four core schools. A four-way split would be more lucrative than a five-way split so there was little reason to compromise the core principe of giving away the intellectual property forever.

A key element of the Sakai proposal was the notion of “community source”. We wanted to operate using open source principles but with more central coordination than was typical in open source projects. The idea was that each of the four schools would contribute five staff members to a central pool of talent that would be centrally managed in order to build a coherent product that could meet the collective needs of all for schools.

The combination of the outstanding team of schools, the community source approach, and the fact that it was a good time to try to build cross-school coordination in the area of Learning Management Systems led to the Andrew F. Mellon Foundation awarding the University of Michigan and its partners $2.4 million over a two-year period starting in january 2004 to build the “one open source LMS” that could bring the fragmented higher education market with each building its own independent LMS system together.

The plan seemed simple enough and almost certain to succeed.

Copyright, Charles Severance 2010 – All Rights Reserved

Here is my “best practice saying”:
The label “best practice” is most typically applied to emergent, questionable or even bad practices so that people holding minority opinions can win arguments.

If you cannot win an argument for your approach based on the merits of the approach – simply label it as a “best practice”. The logic used is, “Who could argue against a best practice”.
Sadly this approach works because of the tendancies of human nature best reflected in the Stanley Milgram experiments:

http://en.wikipedia.org/wiki/Milgram_experiment.

People using this “best practice” tactic use verbal prods very similar to the Milgram experiment such as making the statement, “The best practice requires that you comply.” or “You must comply.” in a monotone voice while wearing a lab coat and horn-rimmed glasses.

P.S. This is not just about the “deprecating Sakai 2.x static covers” argument (which I fully expect to lose) – it is equally a reference to IETF’s BCP-47. While BCP-47 may be a fine idea – the 100+ page document approved in September 2009 looks more like wishes and dreams than actual “best practice” – it looks like “what some group of 10 idealists someday hopes to be adopted in the far-off future as best practice’. I have no problem with the ideas in BCP-47 – in many ways the ideas are quite good and very forward-looking – I just find it galling that a significant change in direction for representing locale is arrogantly labelled “best practice” so early in its lifecycle with so little adoption and support around it.

Thanks to this blog post:

http://thinkwrap.wordpress.com/2006/12/11/how-to-duplicate-cd-on-a-mac/

I now have solid instructions again as to how to duplicate an audio CD-ROM on my Mac using Disk Utility.

I pre-ordered my Apple iPad in that first-day flurry that allegedly sold 50,000 iPads in the first two hours. I knew I had to have the new iPad and I know the iPad will simply revolutionize everything.
But….
I have no idea what I will do with my iPad when I get it in a few weeks. I really don’t. I never saw much value in an iPod Touch – I am not crazy about music or movies – I have an iPhone and love it because it is a small device that includes data networking, E-Mail, Twitter, web browsing, Music and a Phone – all in a pocket-sized form factor. But my iPad has little of that and needs WiFi to communicate.
I sure hope I like iWork on it.
Here is something I would like – I would like it to be able to handle a bunch of PDF and HTML blobs – like all of the Python Documentation and all the JavaDoc for Sakai and my Python for Informatics Textbook and my Networks textbook by Jon Kleinberg. I don’t want to buy new books – Kindle-style – I want to read the ones I already have. And I want to browse HTML stored locally on the iPad – not over the web or via iTunes. I don’t want it so that the iPad is only useful with a network connection – I want it to be like a book that works without WiFi.
I have this deep and abiding fear that I won’t be able to just put files on my iPad – that somehow I will need to view all data through the iTunes lens or send them to myself in E-Mail as attachments. Or perhaps I need to write an iPad application called “File Folder Downloader/Reader” that is kind of like the Mac OS Finder or Windows Desktop.
I want to put my stuff on the iPad just like on my laptop. I just want to drag and drop it from one to the other and then be able to go “off the net” with my iPad and read it.
I have this big fear that while I have not jail broken any Apple product ever that I will have to Jailbreak my iPad immediately so it can store and open local files.
With all of this angst and concern inside of me, then why did I buy one within the first hour?
Uh – “Because” is all I can think of to say. Just had to have one – I will work out the details of why I want one later.

I don’t know why I am in a weird mood this morning – probably because I am writing the exam for SI502 – which of course includes a question about the request-response cycle.
I started thinking about how important the request-response cycle is to information, networks, and people these days and somehow I leapt to the idea that we needed something like the “Pledge of Allegiance” to say at the beginning of every SI502 class to reinforce this notion of the importance of request-response cycle.
Here is my first draft of the “Pledge of Allegiance to the Web”:
“I pledge allegiance to the web and the open standards upon which its built, and to the request-response cycle upon which it stands, one Internet for the greater good, indivisible, with liberty and equal access for all.”
Comments welcome.
Now back to writing that midterm exam for SI502.

I have been trying to find time to write a book about the Sakai experience. I am thinking about a book like “Dreaming in Code” but about Sakai. I will focus on the early years 2004-2007 when I was most heavily involved.
It will be a combination of historical description, open source lessons, fun anecdotes, and inside information about what it took to make Sakai happen.
I am going to try to write it as light and high level as possible to appeal to as wide of an audience as I can
I am planning on starting in earnest next week and having a draft done by the Sakai conference in June.
As part of my pre-work, I have developed a time-line that I will use to trigger my memories to write into the book.
http://docs.google.com/Doc?docid=0AbX1ycQalUnyZGZ6YjhoeHdfMjY3ZnBzdHRmaw&hl=en
The timeline is in a Google Doc – If you have any comments or memories or the answers to the questions in the document any help would be much appreciated.

I was going to write a long message to John Norman about wishing for a 2.x PMC that functioned without higher-level priority setting authority and came across this note from John to Clay and Anthony on January 24 about the Maintenance Team:

“My instinct also is to avoid formality unless it is shown to be needed. Why don’t we just proceed with these people acting in a broadly similar way to an Apache PMC (which allows for anyone to be out of contact for a period) and see if that is good enough. I’m more interested to know if the maintenance team has managed to get any bugs fixed and what issues are concerning them with regard to their mission to improve the code.”

Once I saw this, I realized that I could not say it any better than John already had said.

The message I did not send

On Mar 13, 2010, at 4:03 AM, John Norman wrote:
Personally, I see it as a valuable function of the MT to ‘tidy up’ the code base. I am not sure I care when a decision is made so long as (a) it is properly discussed and consulted on and (b) all decisions that affect a release are reviewed at the same time. So I can view this as early opening of the consultation (good) and potentially a process that allows decisions to be reviewed carefully without rushing (also good). So, while I accept Stephen’s point, I think I might advocate that we don’t wait to consider such issues, but we do insist that they be recommendations and if acted upon (e.g. for testing dependencies) they should be reversible until the tool promotion decision point.
It feels like the PM and/or Product Council should be able to help here

I don’t see the ambition for the structures that you attribute to them. I think we are seeing incremental steps to fill gaps and respond to community needs. Of course if you don’t share those needs it may be hard to empathise and my own view may not be that of other participants in the efforts, but I have none of the intent that you seem to rail against.

Chuck’s Response:

John, the thing I rail against is the statement you made above – “It feels like the PM/PC should be able to help here”. I interpret (and I think others do as well) that statement as “perhaps the MT should get approval from the PM/PC in order to properly set overall priorities for the community”. What bothers me is that I see a PM/PC structure that seems primarily set up for Sakai 3.x having “authority” over a structure that is set up for Sakai 2.x simply because 3 > 2.

By the way – I am not sure that the MT in its current form *is* the right place for these 2.x discussions either – what I dream of is one place where 2.x is the sole focus – not four places where 2.x is partial focus. I want separate but equal – I want 2.x to be able to follow its own path without priorities and choices about 2.x being made from the perspective of “what’s best for 3.x”. I want a win-win situation not a one-size-fits-all situation.

I *do* want to make sure that things get added to 2.x in order to make 3.x happen as effectively as possible – as a matter of fact my own contributions in 2.x in the past few months have been heavily focused improved connectivity between 3.x and 2.x and I am really excited about the progress and looking forward to when 3.x runs on my campus. Even in some future state after my campus is running Sakai 3.x in hybrid mode and I am happily using it as a teacher, and perhaps I have even become an active Sakai 3.x contributor, I *still* will be opposed to structurally viewing Sakai 2.x priorities though a Sakai 3.x lens in the name of “overall brand consistency”.

And interestingly, if *I* think that the PC/PM is a group that cares mostly about 3.x and you think that the PC/PM cares mostly about 2.x – that itself is an interesting question. Particularly because you are a member of the PC and I am a confused 2.x contributor. :)

On Mar 14, 2010, at 5:39 AM, John Norman wrote:

PS I have long held that Sakai is a community of institutions, rather than a product. I think the efforts look a little different through that lens.

Chuck Wrote:

For Sakai 3.x, I think that it *is* a community of institutions and that is a pretty reasonable structure for Sakai 3.x at this point in its lifecycle – and for Sakai 2.x I think that it is a community of individuals at this point in its lifecycle and that is the perfect structure for Sakai 2.x at this point in time. *Neither is wrong* – it is the nature of the development phase of each project – and why I am uncomfortable with to our current PC/PM “one-committee-to-rule-them-all” governance (or perceived governance).

There is some recent discussion on the Sakai lists about the role of the maintenance team, product council, and product management w.r.t. Sakai 2.x. I have become increasingly frustrated about how this community treating the Sakai 2.x / Sakai 3.x work.
The thing that frustrates me the most is how there is this notion that somehow we need to alter our approaches to 2.x so as to give Sakai 3.x the greatest benefit and most resources. This is really grating to me every time I hear even the hint of a win-lose conversation about Sakai 2.x and Sakai 3.x.
The real problem in my opinion is that we have single management structures that are trying to “define Sakai”.
The real problem is that when you only have one management structure responsible for two very different efforts – it is very natural to spend some time thinking about trade-offs. And because some schools and individuals are a bit “out on a limb” with Sakai 3.x, I see a tendency for people who see themselves as community leaders conveniently conflating the “community will” with their own local risks and issues.
I understand the pressure that people who have bought into 3.x are feeling – it makes perfect sense – the whole community felt that pressure around 2.x in June 2005. We got through that and we are in a good place now with 2.x. That sense of pressure and feeling of risk is what spurs the right kind of investment. I hope that the stakeholders of 3.x see that the only way to reduce their risk must step up and really contribute resources to 3.x. Believing that somehow risk is reduced by making a “really intricate and clever management structure” is usually a recipe for failure. If folks delegate the “worry” to a management structure – they are usually disappointed. They end up with “someone to blame” but not the result they desired in the first place.
So back to my main concern at hand – “What is the right management structure for 2.x?” My primary answer is “Not the same management structure as 3.x”. I would like to see these separated and allowed to evolve to meet the different needs of their real stakeholders for 2.x and 3.x.
There will be overlap – of course with the transition and there will be plenty of folks who will be involved in both – and over time as 3.x matures – people will shift – and as 3.x matures – its own management structure will naturally adjust to meet the new realities of the problems facing the development team.
—– Here is one of my responses to a message thread about this topic
On Mar 13, 2010, at 4:03 AM, John Norman wrote:
Personally, I see it as a valuable function of the MT to ‘tidy up’ the code base. I am not sure I care when a decision is made so long as (a) it is properly discussed and consulted on and (b) all decisions that affect a release are reviewed at the same time. So I can view this as early opening of the consultation (good) and potentially a process that allows decisions to be reviewed carefully without rushing (also good). So, while I accept Stephen’s point, I think I might advocate that we don’t wait to consider such issues, but we do insist that they be recommendations and if acted upon (e.g. for testing dependencies) they should be reversible until the tool promotion decision point.
It feels like the PM and/or Product Council should be able to help here.
— Chuck Says
As I listen to this, it all simply seems too complex – particularly for Sakai 2.x. Sakai 2.x is a mature and stable open source product with solid rhythm and an annual release. There are about 20 people deeply involved in fixing bugs and moving the product forward and getting releases out. I love the notion of some strategic 2.x code cleanup and would like to see a place where the 20 people that are working on 2.x could coordinate with each other so we don’t open too many construction projects at the same time. Communication and coordination are really valuable and necessary and the folks doing the work will naturally want to talk to each other about this.
It seems like we spend way too much time debating the “purpose and authority” of the PC, PM, and MT. That alone suggests a broken structure.
I would suggest that we move 2.x toward a situation where a single named “group/committee/etc” is where 2.x decisions are made – maintenance, release, everything. Like an Apache PMC for 2.x.
If Sakai 3.x wants layers of management and multiple interlinked committees to guide its progress and a marketing plan etc etc – that is their choice. I don’t personally like that approach to software development and so I can choose not to work on 3.x. If there was a single place that 2.x was discussed – I would probably join that group as I am quite interested in Sakai 2.x for the long-term because I think that many schools will be running Sakai 2.x for the next 7-8 years and so some investment in 2.x will be warranted for some time.
I would like to see us starting to apply different approaches to structuring our 2.x effort and 3.x effort – they are at such different phases in their life-cycles and to attempt to come up with the “one true management structure for all time” – seems to be an impossible task – so perhaps we should just accept the fact that 2.x and 3.x are *different* and separate structures for each and let those structures be controlled by the people in the structures and meet the needs of the people doing the work in each activity.
/Chuck

One of the more mysterious errors one gets with App Engine is when the application fails to start up with the following error:

*** Running dev_appserver with the following flags:
--admin_console_server= --port=8080
Python command: /usr/bin/python2.6
Traceback (most recent call last):
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/
GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/
dev_appserver.py", line 68, in 
run_file(__file__, globals())
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/
GoogleAppEngine-default.bundle/Contents/Resources/google_appengine
/dev_appserver.py", line 64, in run_file
execfile(script_path, globals_)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/
GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/
appengine/tools/dev_appserver_main.py", line 66, in 
from google.appengine.tools import os_compat
ImportError: cannot import name os_compat

If you look through the forums there is a lot of talk about Python 2.5 or Python 2.6 and suggestions to go back to Python 2.5 – that seems not to be the problem at all because it fails in 2.5 as well with the same error.

I have carefully reproduced the problem and it is when a non-administrator person tries to run the App Engine Launcher. The fix is to simply make the person an administrative user. And here is the strange thing – once you make the use an “Allow to administer this computer” user and start App Engine once as an the user with admin powers and then log out and take a way admin powers and then log back in – then it works! Crazy.

This problem is generally reported on Mac OS 10.6 versions.

Now after an hour of debugging and researching, I can get back to recording those “introductory – see how easy this to install” videos :)

I started a tradition last year to try to spend Spring break coding somewhere. This year thanks to gracious support from JISC to participate in the JISC Dev8D Developer Days in London, I had airfare to Europe. I decided to add some pre-and-post travel at my own expense to touch base with some collaborators in Europe. It was a wonderfully productive trip – here are the details.
I departed for Zurich on February 20, arriving on Sunday Feb 21 – in order to save costs, I stayed with my good friend Dave LeBow in Zug and commuted to Zurich each day.
Monday February 21
I spent today at the University of Zurich working with the OLAT (Online Learning and Training). I worked with Joel Fisher, Guido Schnider, Florian Gnagi, and others. I had built a simple OLAT Course Node extension for IMS Basic LTI which we cleaned up and checked into the 6.4 Branch of OLAT for the next release.
Tuesday February 22
I spend most of the day in Zurich with the OLAT team and gave a talk on Basic LTI featuring Marc Alier’s Dinosaur video. We finished the LTI Course Node and talked about Common Cartridge and QT 2.1 plans. That night I hopped an EasyJet flight to London.
Wednesday February 23 – Saturday February 27
I already blogged about my Dev8D experiences.
Generally, I was going all-out every day and every night – I gave a new presentation three of four of the days of Dev8D and was fixing / documenting something nearly constantly. My most fun talk was my “Informatics: The End of Dilbert” lightening talk – which I had been afraid to give because was my thoughts were still a bit unformed and I thought it might be controversial. But I figured “what the heck” and the crowd seemed to like it.
Sunday February 28
Travelled to Cambridge – Talked to Ian and John about Sakai 3, the Sakai board, and other stuff. It was nice to catch up in person. I apologize to their families for taking them away to the Eagle pub on a Sunday afternoon.
Monday March 1
Visited Matthew Buckett at Oxford. We reviewed their Sakai installation with Hierarchy – very nice and very very cleverly done with surprisingly simple modifications to Sakai. Shows the flexibility inherent in Sakai 2’s underlying approach. Matthew also showed me their mobile portal – m.ox.ac.uk – it is done in DJango and uses a very nice architecture. I hope to get University of Michigan interested in being a partner in the effort when Oxford open sources it all in a few months.
Tuesday March 2
Went to the Open University at Milton Keynes – to visit with all my pals there and the OLnet team. I may get some funding to work with Open University folks such as the Cohere Project that is building a tool to build concept maps of web content. Cohere is a Firefox Plugin – kind of like CloudSocial – but further ahead and more practical. I may also do some other things like a CC authoring program or Basic LTI in their production LMS.
Wednesday March 3
Visited my friends at the Open University of Catelonia (UOC) Campus Project and got some updates. We talked about Open Social and their recent integrations that made MediaWiki and WordPress into OKI Bus tools. It was really clear that there architecture had morphed to become very similar to IMS Basic LTI and that it would be a simple matter to make a Basic LTI Producer for these tools quite easily.
Here is a cool video taped in 2008 in an earlier visit to UOC: Campus Project Overview
Thursday March 4
Went to visit my Marc Alier and Jordi Piguillem at the Polytechnic University of Barcelona (UPC). There I also met Nikolas Galanis who had done the most recent work on the Basic LTI support for Moodle 1.9 – it was in good shape but we put the finishing touches on it to bring it up to par with the other Basic LTI Consumers. Thursday evening I ended up at the Universal Disco to spend a few hours to catch up with Lluis Vincent of LaSalle University.
Friday March 5
We a taped a podcast for Marc’s “Bite of the Apple” podcast and talked about things like the history of technology before Windows, Linux and Mac OS/X in the 1990’s and how standards and interoperability he been an important part of how we got where we are. Later Nikolas and I continued to clean up the Moodle 1.9 Consumer.
Saturday March 6
I continued to work on Moodle from my hotel room doing cleanup and then using it to test me IMS Certification for Basic LTI Tool Consumers and produced this video:
http://www.vimeo.com/9957979
After three days of coding on Moodle, I gave myself a little “treat” by renting a scooter for a few hours and seeing if I enjoyed it. The scooter was fun but a little scary. I had one close call that was enough for me to decide (at least for now) – no more scooters for Chuck in Barcelona.
After I came back from scootering, I decided to fix a few Sakai bugs in the JSR-168 portal which were identified during the JISC Dev8D meeting and get that taken care of while it was all fresh in my mind. I finished the code, tested things, checked in my fixes and went to bed.
Sunday March 7
The flight back was pretty grueling – I had kind of worn myself down over the two weeks by eating too much rich food and not getting enough sleep. I felt pretty queasy all the way back. But I got back in one piece and fell into bed.
Monday March 8
I woke up with a splitting headache and had to teach my SI502 class at 8:30 AM. I made it through the class and took a nap in the afternoon. But then I could not get the idea of a WordPress plugin that I saw at UOC out of my head so I started coding, imitating the UOC code. In four hours where I kept having to take little naps because I felt so woozy, I had a working prototype of a Basic LTI Producer for WordPress which I gleefully sent around screen shots and the URL access information for the Basic LTI tool and quickly got confirmation that it was working from Desire2Learn, Moodle, and Jenzabar.
Tuesday March 9
Antoni Bertran of the Open University of Catalonia Project quickly imitated the patterns in my WordPress Basic LTI Producer and wrote his own Basic LTI Producer for MediaWiki and released the source code.
Wednesday March 10
I got Antoni’s MediaWiki plugin installed and running on one of my servers for folks to test and of course it worked great in Desire2Learn, Sakai, Moodle and Jenzabar (this interoperability stuff is starting to feel really fun). I also helped Steve Swinsberg of Australia National University improve the Sakai Basic LTI Producer so he can plug Sakai tools into uPortal using BasicLTI.
I was feeling well enough to eat solid food again on Wednesday.
Thursday March 11
I think that I am caught up and ready to go back to programming being a background activity. It was fun to drop everything else and purely code for 2+ weeks and do so with my best friends and collaborators around the world.
In summary, I visited two countries, six cities, wrote and committed code in three different open source projects, found the coolest new Basic LTI tools so far (MediaWiki and WordPress).
It just goes to show that sometimes doing a bit of wandering around can result in some really cool things. I wonder how I can top it during next year’s spring break.

programmer_mode = off
teacher_mode = on