Well the Sakai 2.2 release is out and it is a good time to core dump a few thoughts.
In a way 2.2 "completes" the work we started in the 2.0 release. Looking forward, we do not have any more "shoes to drop" as big as 2.0 and 2.2 releases. We can gracefully evolve Sakai without having to do major surgery for the next year or so. This should lead us to have at a 1-2 year period where we can focus on making Sakai better rather than having to "clear the decks" for a rewrite.
Frankly, we need to focus our energy on improving the end-user, developer, and deployer experience in Sakai if we are to truly reach our full potential. Brad Wheeler uses the term "user delight" - users should be happy to use Sakai.
A good way to get our focus on to "user delight" is to revisit the requirements list and take a look at what is most important on the list - we may want to run another round of requirements to see if more stuff has popped up. We need to probably think about a plan to work on the requirements over the next 9-10 months rather than trying to rush them into the next 6-8 weeks.
My personal wish list is pretty short - that feels pretty good. Import and export are probably the hottest button for me - it is kind of shameful not to support IMS Content Packaging and Common Cartridge - especially because we have mostly-working patches from Zach Thomas of Texas State. I also think that we can make progress on accessibility and Charon improvements based on the TILE work at University of Toronto. Both of these things can be done touching only a small are of the code. There are several other architecture efforts like CourseManagement that can be done without too much disturbance - these can nicely fit in to any release when developer resources come available. I am sure that these can fit nicely with a set of community-driven priorities around functionality.
Even though we have been operating as a community informally for some time now, this is our first official release "as a community". The release team was made up of volunteers from the community with increasingly strong and diverse voices around the release process. These new voices and their new perspectives changed the release process for the better.
Even though Sakai 2.2 was late by five weeks, I think that in some ways the 2.2 release process was the best yet. I think that we learned some new best practices in this release. We slipped because the release wanted to make sure that there were no big or even medium sized things wrong with the release. I think that the time where we QA in four weeks is long past. In the future, we need to build time into the schedule to QA until the release is solid.
There were some mistakes made in the release process which added to the delay and increased the effort which the QA and development teams had to invest in 2.2. The biggest problem was several features which we thought we could finish, starting just a short time before the freeze date. These features took longer than we expected and hence we had to develop after the freeze - a bad pattern which wastes a lot of time and QA energy. We have to have the discipline to "wait for the next release".
In a way, it is good that we took a little time to get things right for 2.2, because we really need to feature freeze maintenance releases going forward. This will take some discipline on the part of the whole community. We will need to find a way for some members to evolve more rapidly and deploy new features. We need to keep folks "together" - if we all run slightly different versions over time, the value proposition of common QA starts to go away.
There is some discussion on the dev list to switch from two major releases per year to a single major release per year in the Spring. Folks should make sure their opinions are known in that discussion so we as a community can make the right decisions for the whole community.
Regardless of the number or types of releases, in a way we need to slow down a bit. The 2.2 release really completed the rewrite and cleanup that we started in the 2.0 release. If you remember, the 2.0 release what a complete rewrite of the low-level framework. We got the low-level framework completed but never got to clean up the tools and services to be as clean as the low level bits in 2.0. In 2.2 we re-factored the "legacy" module - this was out catch all for everything that we did not get time to fix in 2.0. In 2.2 we finally "finished" the work so we have both a nice framework *and* a nice looking source tree.
We really need to get disciplined about maintenance releases and maintenance releases to bug fixes only. I was talking to a friend who runs a software development company about how/when they did QA. He said that they maintain a bug-fix branch and on the first of every month, QA takes that branch and runs tests on it. The check to see if (a) the bugs are fixed and (b) that there were no regressions and (c) no new features sneaked in. If QA did not like a patch - they simply kicked it out and QA continued on. That way, QA was in total control of the release and the development team was only involved when they were needed by the QA team. One thing they did *not* do was use each maintenance release to go through and choose a set of bugs that were targeted to be fixed and then work with developers to fix the bugs. This would lengthen the process quite a bit because unless you had the full attention of the right developer the QA process had to wait.
I think that we should move toward this approach for Sakai. We would do simpler maintenance releases more often - we get better at doing the QA in a maintenance release to the point where perhaps we are doing maintenance releases every 1-2 months without too much pain. So far we have treated maintenance releases like they were just "little major releases" where we try to decide "which bugs need fixing" during the QA process and negotiate with the development team to get fixes for the "big bugs". Using the new pattern, If the QA team wants to suggest that something needs a high-priority fix - they make the suggestion but it comes out in the next maintenance release - we don't delay or even re-QA this maintenance release to get "one more bug fix". The upshot is that the QA team is 100% in control of the maintenance release process.
Samigo was a big topic at the meeting in June - time for an update here as well. Things have gotten better over the summer - a number of significant problems were found and fixed. Several sites have run tests that worked pretty well. But we should continue to be ready for anything - as you ramp up Samigo use - don't over sell it and don't put Samigo into high-performance, all-at-the-same-time, high-stakes situations or you may be disappointed. Lets keep talking about the experiences and sharing problems and solutions.
Just so you know neither Etudes nor Rutgers triggered their backup plans - there was just not enough time to develop and QA a whole new solution in time for September. So they too will be running Samigo and watching carefully. We still have a tentative meeting now scheduled for sometime in October to talk about Samigo technically. We will have a better idea where we are at, once the September production kicks in. Please keep talking on the lists about this. Also congratulations to the Samigo team for continuing to work though the issues for all of us.
We should also celebrate the full integration of OSP into Sakai for this release. This completes a long journey that really has taken several years to complete - like Sakai, OSP can invest some time is improving their "user delight" rather than working on "plumbing issues" :).
Another topic going forward is looking at other open source learning management systems that we are starting to work with and talk with. This is a natural effect of becoming more mature. As we get our technology more solidly in place, we can invest some time in looking at ways to connect in other technologies.
Our relationship with LAMS is well established and with the release of LAMS 2.0, we are looking to evolve the Sakai Architecture in ways to align with the LAMS tool contract. Take a look here:
http://wiki.lamsfoundation.org/display/lams/Tool+Contract
I like to think about the LAMS tool contract as a possible next step in the evolution of the IMS Tool Interoperability effort.
We also have been talking with the Bodington folks in the UK. Bodington is an open source LMS developed initially at University of Leeds. (http://bodington.org/index.php)
We have also been talking very briefly with the ATutor folks at University of Toronto (http://www.atutor.ca/) about possible collaboration around the IMS Tool Interoperability.
Two weeks back, I visited the Lleida in Catalonia - mostly to thank them for their internationalization work in Sakai 2.0.
I figured that I should write this up and share it.
Here are some pictures from the trip (sorry my photo blog is out of order because of the inconsistent delivery of SMS messages from Spain).
Neat Barcelona Architecture:
http://www.dr-chuck.com/images/2006/07/index.php?img=22-07-06_1256004.jpg
The Lledia Team:
http://www.dr-chuck.com/images/2006/07/index.php?img=22-07-06_1250003.jpg
http://www.dr-chuck.com/images/2006/07/index.php?img=22-07-06_1257004.jpg
Eating Baked Snails - A Lleida speciality
http://www.dr-chuck.com/images/2006/07/index.php?img=22-07-06_1257003.jpg
http://www.dr-chuck.com/images/2006/07/index.php?img=22-07-06_1257004.jpg
http://www.dr-chuck.com/images/2006/07/index.php?img=22-07-06_1257005.jpg
http://www.dr-chuck.com/images/2006/07/index.php?img=22-07-06_1256010.jpg
http://www.dr-chuck.com/images/2006/07/index.php?img=22-07-06_1256011.jpg
http://www.dr-chuck.com/images/2006/07/index.php?img=22-07-06_1318004.jpg
Drinking San Miguel - A Lleida specialty
http://www.dr-chuck.com/images/2006/07/index.php?img=22-07-06_1257007.jpg
http://www.dr-chuck.com/images/2006/07/index.php?img=22-07-06_1257008.jpg
You may not know the history of Lledia and Sakai - so I figured that I would write it down and share it.
The University of Lleida was looking for an open source course management system early in 2004 and was considering CourseWorks from Stanford University. When Stanford joined Sakai, Lleida turned its attention to Sakai.
Lleida evaluated the Beta release of Sakai in May of 2004 and was pleased enough to put it into pilot production. Since Lleida is part of Catalonia there was a need to translate Sakai into the Catalan language. The Lleida technical team did this work by locally modifying all of the text in the Sakai source code. This was completed and placed into production at Lleida. Lleida quietly continued to run with their modified version of the Sakai 1.0 Beta for over a year, giving support to 80 course sites and 200 students for the pilot.
During 2004, the Sakai project quickly went from a small effort to a worldwide activity. When Sakai 1.5 was released in December 2005, I made a list of what I felt would be the "impossible challenges" that I felt that we had zero chance of compling by Sakai 2.0. This was simply sent out in a spreadsheet to the development list. One of the items in the buried deep in the spreadsheet was generalized internationalization for Sakai.
Several days later I received this simple and direct message from Lleida:
On 12/13/04 7:25 AM, "David Barroso"
Hello Charles,
We, at University of Lleida, can do the internationalization
work for sakai 2.0.
We are very interested in it !!
When can we start job ?
Regards,
This started a three-month effort during which the Lleida technical team, composed of four developers (Alex Ballesté, David Barroso, José Garcia, and Carol Manchó) took the entire Sakai 1.5 code base, one section at a time, and internationalized the code. Then they prepared the English localization and Catalan localization as well. Each element was carefully tested and given back to the Sakai team for integration.
Beth Kirshner at the University of Michigan acted as the "traffic cop" for the process, making sure that the Lleida team was given the right versions of each section of the Sakai code, and then integrating the changes back into the Sakai source tree. This work was done in parallel with the massive rewriting activity and significant development effort of the Sakai team to produce Sakai 2.0.
Because there was so much rewriting going on throughout the rest of the Sakai code base, each element to be translated had a very small window of opportunity for success - so each time we handed a component to Lleida - they had to work at breakneck speed so as not to slow down the rest of the Sakai 2.0 development effort.
The team was able to maintain the fast pace and the work was completed in March 2005, in plenty of time to make the June 2005 release of Sakai 2.0. The Sakai 2.0 release was the first release of Sakai that was heavily used outside the United States of America and we were very fortunate to have Sakai internationalized for the Sakai 2.0 release.
Lleida as a campus is committed to open source across the board and is very willing to invest the effort to make open source a success. Nearly all of the desktops on campus run Linux and Open Office.
We lost dial tone at home. I tried everything - unplugged all the phones and fax machines - powercycled the alarm system and still NOTHING. No dialtone - not even a click - not even the kind of echo that you hear when you have a phone off the hook.
The phone line was dead. As if disconnected.
I was about to call the phone company and be a wimp - but then I noticed that somone had taken a phone wire connected to a wall plug and connected it into a free port on the 10/100 switch!
that was indeed out of the box thinking as a possible ereason why Internet would be down - but it made the phone system *very* unhappy. Unplugged the Ethernet switch from the phone jack and viola - all better.
Fooling with an XServe. Not fully successful - probably a firewall. :(
http://images.apple.com/server/pdfs/Command_Line_v10.4_2nd_Ed.pdf
sudo /System/Library/ServerSetup/serversetup -createUser "Charles Severance" csev password
curl -O http://metissian.com/downloads/macosx/subversion/subversion-client-1.3.1.dmg
sudo hdiutil mount subversion-client-1.3.1.dmg
cd /Volumes/Subversion\ Client\ 1.3.1/
installer -pkg SubversionClient-1.3.1.pkg -target /
scp build.properties collab4.dc.umich.edu:
scp -r maven-1.0.2/ collab4.dc.umich.edu:dev
scp -r .subversion/ collab4.dc.umich.edu:
sudo ipfw list
sudo ipfw add allow tcp from any to any 8090
sudo ipfw add allow tcp from any to any 8090 via en0
sudo ipfw add allow tcp from any to any 8090 setup
sudo ipfw add allow tcp from any to any 8090 in
sudo ipfw add allow tcp from any to any 8090 out
(did not work)
It was great to meet Carles, David, Yolanda, Jose, Alex, and the whole Lledia team.
They have a very nice Sakai installation and are doing some very unique work using Sakai that they will share with the community when it is more mature. The short version is that they are building basic Enterprise software like helpdesk software, student evaluations and doing it all in Sakai, JSF, and Hibernate. Very Cool.
Lledia is a great place to visit - the weather is like Phoenix and flora is like Los Angeles. There is a neat castle in the center of the town. It is very hot during the day - often above 100F. But the evenings are *very* nice.
For dinner we went to a very very special restaraunt - it is a small family run restaraunt that makes the Llledia specialty - snails to perfection. The the photo blog for snal pictures when I get back and sent in all of the pictures.
This is not like french style snails - they are land delling snails. They are pretty small - about 1/2 - 3/4 incin across. The snails are arranged in a flat iron pan with their shell opening pointing up. They are alive. Then they are seasoned with some salt and some paprika and then they are cooked over charcoal.
Then after about 20 minutes, they come to your table and you use a sharp little needle like thing to get them out and eat them. MMM-good! Sometimes they are a little undercooked and the snail's mucous did not completely cook away - you can either eat it or wipe it off.
The snails were so awsome.
Also Lleida has a beer factory - San Miguel - I liked the beer too - kind of a combination of a medium body with a very solid taste.
In Barcelona I met with cool folks from the Caalan Government and a very very cool open source lawyer (yes you heard me right - a cool lawyer). Malcom was his name (he is originally from London) and he was using his lawyer skillz to further the cause of open source and help make licensing better and help university lawyers and administrators better undertand open source. Of course I liked him!
Usually I don't do basic, "dear diary" / "kitty blog" stuff - but I am so happy that my hotel in Barcelona has free wireless that I figured that I would use the free bandwidth to kitty blog.
My phone does not send pix form Barcelon so they are queueing up to be sendwhen I re-arrive in the US on Saturday.
Barcelona is a nice city - I am not sure I saw any Spanich people here - so many tourists - it looks like Disneyland :). The cathedrals and squares and the Gaudi house all were pretty cool. Couple of hours walking, and a subway ride back, and in one evening I got the outline and a few blog photos to prove I was there. The subway was quite clean and easy to figure out - unlike Paris there is a single price (1.20 Euro) so you don't have to have a Phd in Metroology to buy a legit fare.
Things in Sakai are going great. There is a lot to do - I stay nervous about the 2.2 release. Lately, we have gotten used to "not slipping" 2.0 and 2.1 were right on schedule. Later, we can wonder why we slipped - to me it really comes down to several "include or not to include" decisions we made back in May. We thought a couple more things "would not hurt" and low and behold a 5 week slip - wearing out the QA team and getting us dangerously close to Fall for folks who want the release for a few months before going live.
But the release is looking good and those fetures will hold us in good stead for the next year - probably worth it in the final analysis.
Coming off a lot of travel since the Vancouver meeting. UK is busy this time of year. The sequence ws Vancouver(Sakai + JASig), Indianapolis (TeraGrid), Indianapolis (Alt-I-Lab), London UK (holiday), Manchester UK (gave talk), Cambridge UK (gave talk), Lancaster UK (played cricket, worked, gave talk), York, UK (went to meeting), Toronto CA, (meeting), Edinburgh, UK (gave talk), and now Barcelona (meetings).
Wow - Not home for more than 48 hours since June 1. But a LOT of cool stuff got done. The Edinburgh meeting was invaluable - it was basically folks mucking around int he portal world sharing their deepest secrets and stories. The data we got from each other would have taken a very long for each of us to figure out independently. Nicely Sun and IM were there too which caused some cool discussions.
I got inspired by both Jason Novotny and Marcus Christie's talks where they postulates that in the future we will want portlets in "web sites" rather than making all of our web sites these "portals".
This got me all charged up to dig up an idea that I had for a whaile - taking some Ian Boston Sakai 1.5 code and see if I could create the "smallest possible portal" that was not the null portal (i.e. the 0.00001 portal)..
I am almost done.
TTFN dear diary.
If you want o do Sakai Development at Lancaster University whilst visiting, make the following changes. Make sure to remove them or comment them out when you leave.
~/.subversion/servers
[global]
http-proxy-host = wwwcache.lancs.ac.uk
http-proxy-port = 80
~/build.properties
maven.proxy.host=wwwcache.lancs.ac.uk
maven.proxy.port=80