Sakai is a collaboration and learning environment suitable for both teaching and learning and collaborative research using the same software. Sakai sees teaching and learning and collaborative research simply as variants on collaboration. Using the same software for both purposes serves several purposes – natural crossover of activity between teaching and research and the reduced need to run multiple servers for multiple purposes, and a reduced need for users to learn multiple software packages. Sakai supports several modes of Virtual Research collaboration – Sakai can be used as a collaborative portal for a a research effort where Sakai provides both the public facing web-site for the research organization as well as a Lotus-Notes like collaborative back-end to support the work of the organization. Sakai also supports a mode where the system is installed as a teaching and learning tool with research collaboration features are enabled – this enables research collaboration to happen and grow organically at an institution. Sakai supports the notion of federating identities from multiple organizations allowing Sakai groups to be formed with a combination of users from within and outside of the organization.
The presentation will cover the features and approach used in Sakai to support virtual research and describe particular features useful to virtual research. Sakai’s approach to library and institutional repository integration will be described as well. A case study will be presented as well as a vision for a service oriented approach to functionality which will greatly improve the flexibility of deployment of virtual research environments.

As of Tuesday morning July 24, 2007, I am no longer the Executive Director of the Sakai Foundation. Michael Korcuska is now the Sakai Executive Director and he is already doing a great job and I will continue to work closely with Michael to ensure a smooth transition.
For me personally it is a big transition – not so much because of a change in title – but instead in a change in what I will be doing with my workday and work week. I have had the distinct pleasure over the past 3.5 years to have a single job to do and great flexibility, resources, and people to advance the cause of Sakai.
Each day I could wake up and think about only one thing – “how to move the Sakai needle in the right direction today” – for me this was a blend of all the things I like to do – writing code, talking to people, making decisions, making presentations, traveling to far off lands, editing a video, sitting across a table from a faculty committee evaluating Sakai, and on and on.
We operated at a fast pace – we built the bicycle while we were riding it. We defined “Community Source” under crucible-like pressure and then re-adjusted the definition when we needed to evolve.
My job with Sakai stretched every bit of my skills to the limit and made me grow as a person as a result. I am very thankful for that.
I am amazed at the diverse talent that we have assembled around Sakai from all over the world and the dedication of the Sakai community. Working this fast and under this much pressure leaves everyone some bumps and bruises. What amazes me is that through it all – we have stuck very much together like a family – we never let small and medium sized issues distract us from the overall goal. Ultimately we knew that from the beginning we were all in this together so we had to adjust as we went along.
As I drop from 50 hours a week on Sakai to 4-5 hours per week, I am happy that there are so many passionate members of the community that do such a good job and with such dedication.
Starting now I will be very focused on learning Ruby and preparing for my classes. This Fall will take a lot of my attention to make the transition back to the faculty approach to things – teaching, writing papers, writing grants, not-much travel, etc. This is the first time I will be full-time in a faculty role – so I want to do it well.
I would just like to close thanking everyone in the Sakai community – without your willingness to make a commitment and take a bit of a risk on Sakai – we would have nothing at this point. Each new pair of hands reduces the risk for the rest of the community – we have grown to an amazing point in Sakai – the key is not just adoptions – but the size, strength, and diversity of the worldwide creative community around Sakai.
For me I never set out to just produce software – I tried to build a real community of friends that would naturally produce software once we got together and had a few beers.
I am pleased to report that we have made excellent progress on the “making many friends” and “having a few beers” goals.

I have always wanted to try motocross racing – so this weekend I decided to give it a try. I had to purchase some boots, a chest protector, and a new set of golves – also I had to join AMA District 14 and pay a $20 pit fee and $25 class fee – and there I was racing with 7 other old guys on old bikes.
My motorcycle is a late-70’s Suzuki PE175 which I have owned since the early 80’s and have ridden it through out that time. The PE175 is a trail bike that was based on a motocross bike of an earlier year. It is kind of over built and has started on the first kick for over 20 years.
My race was uneventful. I had two goals: (1) not crash and stop the race (2) not get lapped. I was planning in going for last place – I accomplished that as well.
At the practice I met the other riders – that was fun – they encouraged me to relax and gave me good advice – slow down over the jumps on an old bike. The track was really mucky in places – I really had to stretch to make corners without slowing to a crawl – this pointed out a pre-race mistake – need to stretch. The first lap I was stretching while riding. I won’t make that mistake again. The mucky track made for some very obvious lines that were easy to follow. Practice was three laps – seemed like forever.
At the start of the race, I let everyone leave before me – and they did tear off. One guy had a 1999 bike and the others were real vintage. Each lap I got more confident – particularly of where I could go fast and where I needed to go really slow – there were some double jumps on the back straight away that I almost endo’ed just going over the hill because it dropped so quickly after the crest. After a while I started to feel like a big sand pit in Leota and just started riding. By then I had been lapped by the guy with the 1999 bike (but no one else). I was quite ready to get off the track after four laps.
All in all a fine Sunday morning. Here is an Action Photo.

Just a review of the way we vote (like Apache) on decisions that need to be made. Vote have two purposes: (a) make a decision and (b) stimulate disucssion on complex issues.
First I will review how I have seen Apache (Pluto in particular) operate.
In Apache only committer votes count.
In practice in Apache – generally the trend is toward forward progress. Working code that does not break stuff is generally allowed to move forward. When a proposal is voted down – usually it means something is “broken” or will break something. Generally when something is shown or discovered to be broken or is a generally bad idea, the proposers don’t even wait for more -1 votes – they simply withdraw the proposal and go back and fix what they have.
In the case where there is one or a small number of -1 votes – there is generally four cases: (1) there is really something wrong that is quickly relaized by the whole goup in short disucssion and the proposal is withdrawn, (2) it turns out to be a misunderstanding or something that a quick discussion resolves and the -1 vote turns to a +1, (3) there is some technical ickiness in the approach – the -1 voter volunteers to quickly help fix the problem in a week or so, or (4) it is an interesting opinion from someone not really in the mainstream and after some examination – it is ignored and things move forward.
In Sakai, this is the rough procedure:
If it comes down to a “count” – the votes that “count” are the folks with long-term commitment to the particular element in question.
In Sakai the “project team” is more than just developers – it includes designers, usability experts, developers, etc. The key is that the counted vote is amongst the people with a history of and plans to continue directly working on the particular part of Sakai that is being discussed.
Any one in the community is very much encouraged to vote and comment and the project team of the element in question are encouraged to listen to and strongly consider the community votes.
Negative votes should include what it would take to make the vote positive.
It is the responsibility of the project lead and project team for the component to evaluate the votes/comments, etc and make the “wise” choice given the discussion.
Summary
We want more votes to happen and more exploratory development to happen in branches with votes before the merge. This gives the community a better chance of catching things that might destabilize the product or cause harm in other ways.
This approach is designed to give project teams a safe way to have discussion about issues and get community input while maintaining the project team’s control over their own destiny.
Without the rule that the project team gets the final say, it tacitly encourages project teams to quietly make their changes in trunk and then we all get surprised at release time.
We have a number of examples in our past history of these “trunk release surprises” – they are not so much fun – because we are faced with the decision “do we keep the flawed stuff we have in trunk – or go way back and lose all the neat new features”.
So to encourage open discussion it is important to remember that people outside the project team do not have veto power with a single negative vote.
Folks who want things done differently should get involved in producing the solutions to problems – not just sending out -1 votes when a vote call is being done.
We have to remember tht project teams often spend weeks or months of work to get something working well enough in a branch to propose a vote. When the work is complete and being voted on – it can be very costly to delay the merge of the work significantly because as time passes the merge becomes harder and harder. So we need to make sure that we have a solid reason to tell a project team to “go back to the drawing board”.

I have produced a new script for us folks fearful of Maven 2 and/or with a poor memory.
This is a bootstrap script. It only requires Unix (preferably Mac OS/X), Java and SVN – it does everything else including:
– Installing the right version of Maven
– Installing and setting up the right version of Tomcat
– Putting the demo sakai.properties into Tomcat
– Setting things like MAVEN_OPTS and JAVA_OPTS
– Telling you what to do to your .bash_login file to make live easier
– Wiping out the sakai bit of your Maven 2 repository to insure a clean slate
– Checking out the Sakai trunk (tags can be specified with a parameter)
– Compiling the Sakai trunk with Maven 2
– Deploying Sakai to the nice fresh tomcat
– Then it even starts the Tomcat
All with the fresh, new hip Maven 2.

Continue reading →

Upgrade to Maven 2.0.6 because I had 2.0.3
http://bugs.sakaiproject.org/confluence/display/ENC/Using+Maven+2
<settings xmlns=”http://maven.apache.org/POM/4.0.0″
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd”>
<pluginGroups>
<pluginGroup>org.apache.pluto</pluginGroup>
</pluginGroups>
<profiles>
<profile>
<id>sakai</id>
<properties>
<maven.tomcat.home>/Users/csev/dev/apache-tomcat-5.5.20/</maven.tomcat.home>
<maven.test.skip>true</maven.test.skip>
</properties>
</profile>
</profiles>
<activeProfiles>
<activeProfile>sakai</activeProfile>
</activeProfiles>
</settings>
mvn clean
mvn install
mvn sakai:deploy

Meet at 9 or 9:30 here:
Maple Leaf Chinese Restaurant
707 148th Ave NE
Bellevue, WA
98007-4710
Phone: (425) 747-8700
2.2 Miles South of Microsoft

Looking for karaoke Box close to Redmond WA – the closest were about 15 miles away.
Confirmed:
9PM Wednesday
Venus Karaoke
#102 – 601 S. King Street
Seattle, WA 98104
(206) 264-1779
Notes:
This is a 20 minute drive to the south side of Seattle downtown – pretty simple and direct drive from Redmond.
No Liquor license – BYOB – Need a Washington Personal Liquor Permit – whatever that is.
Potentials:
Karaoke Box
140 University Wa N.E.
Seattle, WA 98105
(206) 632-9260
I called this Karaoke Box at 11PM – no answer – not a good sign.
I have not yet called this MARS yet.
MARS INTERNET/KARAOKE BOX
18230 E Valley Hwy
Kent, WA 98032
425-291-9777
This is north of Redmond WA – looks like a less
convienent drive.
Karaoke Club is closer to Redmond.
It is important to know which nights these folks do Karaoke – a phone call is required
Maple Leaf Chinese Restaurant
707 148th Ave NE
Bellevue, WA
98007-4710
Phone: (425) 747-8700
2.2 Miles South of Microsoft
They have a karaoke bar, which has also been deserted every time we’ve been –
maybe they do some major business on the weekends and that’s why they can afford to have an empty dining room most evenings?
Seoul Olympic Korean Restaurant
(425) 455-9305
1200 112th Ave Ne
Bellevue, Washington 98004
5 Miles South of Microsoft
Shi-lin Cuisine of China
15932 NE 8TH St
Bellevue, WA
98008-3908
Phone: (425) 644-1010
2 miles south of Microsoft

I tried to re-compile Sakai with Pluto 1.1.4 and apparently an API changed:
/Users/csev/dev/sakai/portal/portal-render-impl/impl/src/java/org/sakaiproject/portal/render/portlet/services/SakaiPortalCallbackService.java:128: org.sakaiproject.portal.render.portlet.services.SakaiPortalCallbackService.SakaiPortletURLProvider is not abstract and does not override abstract method isSecureSupported() in org.apache.pluto.spi.PortletURLProvider
class SakaiPortletURLProvider implements PortletURLProvider
Probably no big deal – just part of the Pluto QA.

I took movies of everyone at the Sakai Project kickoff – February 19-20, 2004 at Stanford University. We were all a lot younger then.
http://www-personal.umich.edu/~csev/media/2004/sakai-people/