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

I seldom blog about my oldest daughter Mandy – she is a bit of an online recluse so I have always respected her privacy. But somehow she found a prank call to Fashion bug in 2008 on YouTube where she was the one who was on the receiving end of the prank. I thought it was funny – so I figured I would share.
http://www.youtube.com/watch?v=rwS77fXgsNI
I have to agree with one of the commenters in the YouTube Video,”Wow. That girl at Fashion Bug kind of pwn’d you guys…”. Smoothly done. Dad is proud.