This is a bit of expansion of my previous status update. I need to expand my "Educause revelation" a bit.
Educause is a nifty way to measure how far Sakai has come because it is an annual event and one where we give talks, hold meetings, etc. So I take the occasion of Educause to reflect on things to make sure that I remain grounded in what we are doing and why we are all here.
First a little history...
At the Educause 2004 meeting, I was just amazed at the fact that so many people had heard the word "Sakai". I was pleased to sit in the back of a talk about some cool thing like Sophia from Foothill and see the Sakai logo and an offhand reference like "we are part of Sakai". When crowds were asked if they had heard of Sakai - nearly all hands went up in the room - it was amazing to me that in 8 short months we had so much mind-share - of course we released Sakai 1.0 the week of Educause and only Michigan and Indiana were running serious production with 1.0. We spent most of our time recruiting members - it was fun - folks wanted to join - they did not care how far we had progressed - we had just gotten our shipment of buttons and were handing them out like candy - folks just wanted to support what we were doing. The overall sense I got from folks could be summed up as "Sakai - Open Source LMS? Cool!".
At the Educause 2005 meeting, we had put out our Sakai 2.0 release and it was really clear that we *might* actually survive - we have a number of sites in production and even more in pilot. Now people wanted to understand *what* Sakai was and how it might fit into their plans - each presentation anyone gave about Sakai was overflowing with people who wanted to get every shred of detail about this *new shiny open source LMS called Sakai*. This was also very exciting - frankly because folks were still in love with the *idea* of Sakai.
At the Educause 2006 meeting - we clearly had arrived. People still crowded into Sakai talks - but with a different view. From the questions I was getting it was clear that Sakai was just one of many alternatives - folks stopped being in love with the idea and wanted to know what was in it for them. What features does Sakai have? What hardware does it run on? Is XYZ integrated into Sakai? How many developers/support people does it take for Sakai - what is the Total Cost of Ownership (TCO) of Sakai? This fits with recent evaluations where schools pit Sakai against Moodle or Blackboard and simply look at the product features and make their decision. This is a far cry from folks swooning just on the idea of an Open Source LMS. But at the same time it is *exciting* - because it means Sakai has *arrived* in the market place - instead of a cool idea - we are the #12 vendor of LMS systems (I have no idea where we fit - just decided to start low).
This is a sobering notion - that Sakai has to compete - the period where we could just say "Sakai" and win people over is coming to an end.
The discussions around the patent and having conversations with BlackBoard about the patent also brought the fact that we are just another option in the LMS field. This is no longer a "grand experiment" - execution is what matters.
The final straw that made me wake up and "smell the coffee" was a 1 hour discussion with Barry Walsh of Indiana University. This conversation covered a lot of topics but the one that really hit me was talking about Samigo.
I won't bother reiterating the Samigo history again - Samigo has been in Sakai since early 2005 and has never been 100% solid - it has always been improving - but we have been fire fighting for almost 2 years now. Indiana, Rutgers, and Etudes probably have taken the brunt of the pain caused by Samigo. We moved Samigo from full release to provisional in the 2.2 release to make sure that new schools would take a close look at Samigo before making a major deployment.
We all kept hoping that Samigo would turn the corner at each improvement - I kept hoping that "things would just work out" and that the community processes would just work out - I was holding onto the pure notion of the Foundation operating in a coordination and communication role and not in a directed development role. Some would say that I was just being an ostrich and "burying my head" so I could conveniently ignore the problem.
My one hour conversation with Barry came down to this simple notion - all the fancy process and purity of model does not matter much if Samigo is not a 100% solid production ready testing engine that we can all be proud of by Fall of 2007. Effectively he suggested that everything else was noise compared to the impact of Samigo - if we don't turn the corner - and just "letting it happen" was *not* what the Foundation Executive Director should be doing.
Because of Samigo's shortcomings, we have already lost a few schools that converted to Sakai - they converted back to something else - aargh. I know of several schools that are delaying moving from pilot to full production because of Samigo - usually the cost of such a delay at each school is between $5K and 20K per *month* where they have to run two systems side by side. My estimate is that Samigo's incompleteness has probably cost nearly $1 million dollars across our partners in programmer time and the cost of running multiple systems. Ouch.
What is worse - is I estimate that there are likely 50+ schools that will seriously evaluate Sakai when the 2.4 release comes out - these schools are different from our core base - our core base is from schools that have lots of programmers and often have years of experience with home-grown code. We groove on debugging stuff. This next round of adopters will want Sakai to replace a commercial or open source system that is probably pretty mature and solid - they will not be impressed when the testing engine does not scale under heavy use and all I can say is "Samigo *is* marked as provisional - it *has* an asterisk in our release notes".
So, armed with this strong smell of coffee (and a headache from Barry's talk) in the past month a lot of focus has moved to Samigo - we called for resources - and set about fixing things up using the most direct path possible - spending resources, time and money in the effort. We are not going to stand on principe or worry about process - this is a fire fight of the most basic form. I am glad we started in time - I shudder to think where we would be if this were being done June 2007 for a Fall 2007 rollout with 150,000 users at Indiana.
Stanford has been 100% supportive and helpful in this effort. Etudes has volunteered to test the new high performance code - Etudes is at the greatest immediate risk of negative outcome followed closely by Rutgers - Indiana will be in a crisis September 2007 - if anyone else is at risk because of Samigo - please let me know.
Now we don't need 110 people working on Samigo - we just need everyone to understand that Samigo needs to be the #1 priority until it performs at scale. It does not mean that everything else needs to stop - just know that if there is a priority choice between Samigo and anything else - Samigo wins until we really turn the corner.
OK - Enough of the gloom and doom - lets look toward the future.
First - I am 100% sure that Samigo will rock and roll and kick ass by September 2007 - it will be in production at Indiana September 2007 with 150,000 users and run smoothly - the kind of talent we have in Sakai to throw at this problem is amazing - our problem so far has been one of focus - not resources or talent - with the focus properly aimed - this will all work out.
I started this update talking about Educause and want to wrap up back on Educause. How will it feel to be part of Sakai October 23 at Educause in Seattle?
Well, first off we will have a product (including Samigo) that is solid across the board. There are architectural changes (RSF, JSR-168, new approaches to JDBC, and others) that will put us in a very strong position to build and deploy an awesome set of tools with far greater developer ease of use and developer efficiency.
By the way - something happened that we barely noticed with the release of Sakai 2.3 that we need to really celebrate - architecture work for the first time in the project is being done *in parallel* - Cambridge has taken the lead on a number of architectural areas - other architectural elements like import and course management are also being done at Texas State and Berkeley/Stanford/AU Arizona respectively. Site Setup is being modified by Arizona State - many things that two years ago were single threaded are now running in parallel. I will tell you that it feels great not to be single threaded any more.
Enough back patting - back to Educause.
At the next Educause we need to be a solid alternative LMS system and we need to act like it. We need some pre-conference sessions - we need a session on Developing for Sakai and a session on Teaching with Sakai - we need people to submit papers and give talks about Sakai - I should probably upgrade from the $25.00 trade show registration and have a real $500.00 registration and go to sessions. It seems like it has taken a while for Educause to warm up to Open Source in general - but to me the Educause Board statement about BlackBoard's patents that came out in October is about as open a door as we can expect for us to dive in and participate more fully in Educause.
The recent update to www.edutools.org is really neat - we need to up our game beyond this to better support folks doing comparative analysis and looking at Sakai as an alternative - hey we need a session at Educause called "How to Evaluate Open Source LMS Systems in a Procurement Process" and a "Total Cost of Sakai Ownership" presentation as well at Educause - I could go on and on..
I think that we should all put on a full-court press on Educause - we should be proud of what we have accomplished in three short years - where three years ago I was amazed when someone simply said the word "Sakai" out loud - to being a significant force in the market place.
I am looking forward to seeing everyone in Atlanta. For the first time in three years, I won't be giving the Architecture talk - Ian Boston of Cambridge will be giving that talk - my only talk is the Sakai Foundation Update where I will cover costs, expenses, org charts, processes, and lots of cool minutia about the workings of the Sakai Foundation - if you are a partner representative I also encourage you to attend the "Partner Retreat Session" which is representatives only. The purpose of the rep-only meeting is *not* to have a bunch of "secrets" - the financial stuff is in the public session - fully disclosed. The purpose of the retreat is to get together and talk and discuss whatever topics come up. A key outcome it to make sure to get a strong understanding of what the "Sakai shareholders" (the folks writing the checks) really want from the Foundation.
Thanks for listening.
I answered a Brian Jorgensen e-Mail proposing a Community Roadmap - he also has a Blog entry about it.
http://www.moosetrout.com/braindrain/sakai-community-roadmap
This is my answer. While I liked the basic idea - I very consistently am negative when something smacks of a "community driven management layer" - where some group appoints themselves to "be in charge" and drive all of Sakai to be "deterministic" as if we were a set of non-volunteer developers.
Sakai is a federation and we need to accept that - it is simply reality - all the fantasy of us as a company is not there (until we get to 2-3 million of revenue annually).
Once we have 2-3 million in revenue, then we will become a non-profit development company where the paying community has *every* right to have all kinds of checks, balances, determinism, and detailed reports.
But then, folks should look deeply into whether they want the community to *do* the work or delegate the work to a single organization (The Sakai Foundation).
To operate as a real federation where there is true respect for each organization that is in the federation - we must accept that each of those organizations (and individuals) will self-determine to some degree.
Freedom has a price - it is taking responsibility for ones *own* actions and respect for the actions of others.
Brian,
I am going to give you two conflicting responses :)
First I am going to agree with you and suggest that we do what you suggest *and more* - second I will point out some things in your approach that seem to be fallacies and will likely be pitfalls. Overall, I think that this is worth a try - but our confluence is littered with half-baked attempts to do some kind of well-intentioned uber cross-cutting grand vision communication solutions which were proposed to work grassroots WikiPedia style and ran out of steam after the first draft.
WikiPedia works because the ratio of people to pages is usually well above 1.0 - in Sakai's confluence the ratio of people to pages is way less than 1.0 so our Wiki is pretty crufty (http://en.wikipedia.org/wiki/Cruft).
Here is the positive encouraging version of the message.
I like organic grassroots efforts - you suggest a link from the Sakai Home page to the Community Roadmaps - I don't want to do this because then folks will assume that this *is* an official roadmap and will hold me accountable for executing the roadmap - since this is an experiment I would like it noted as such until it clearly bears fruit and seems to have staying power beyond the first draft. From my comments below, it will be clear that I am more than a little nervous that the Sakai Foundation's official "commitment to delivery dates and scope" is a document that is world-writable by anyone in the community.
I think that the right way to go about this is to build a whole Sakai Community Home Page that is completely maintained WikiPedia Style - pretty much we give write access to pretty much anyone in the community. Somewhere in this page, we make it clear that this is the community's home page. On this community page we have lots of links - to requirements, to your proposed roadmaps, to particularly tasty places in Confluence, to a list of published documents - etc etc etc. Effectively if this is done well it could someday simply become *the* www.sakaiproject.org main site or at least take over a major role in Sakai's public web site - particularly the highly dynamic stuff that is hard to update quickly.
I would suggest that we could either do this in Confluence, or even possibly more cool - make a site in collab called WG: Community Web Site and use the Sakai wiki tool - I made a quick mockup at:
http://collab.sakaiproject.org/access/wiki/site/1110027684970-84324/sakai%20community.html
If we use collab, then we have mailing lists, resource areas, etc and we are "eating our own dog food" and if we find flaws in wiki we can ask for feature requests :) Of you really wanted to do this in Confluence - that would be OK - I would just like one place to point to from the main Sakai page. Maybe there would be even a Community RSS feed.
So if you are willing to change the deal so that the link is to a community maintained home page that is a jumping off spot for a bunch of many community efforts - then I am happy to make a link to this new page from the www.sakaiproject.org site - I will even personally help edit the Community Home page. We will need a mailing list to work through the design of the community home pages - but we can do that WikiPedia style and involve the whole community.
Now my positive recommendation is to "do it" - "write up a first draft" and see if it has legs - see if it adds value to the conversation - if it works - I will be its biggest fan.
--- Now to the concerns and caveats I have with your approach.
On Nov 22, 2006, at 11:51 AM, Brian Jorgensen wrote:
We are trying mightily to make up Roadmaps:
http://issues.sakaiproject.org/confluence/display/MGT/Home
(CHUCK from an earlier message)
It is like pulling teeth to get updated information. It is easy to
assert that we need better roadmaps - it is hard to get roadmaps.
Volunteer developers simply prefer to announce things or make
commitments when they reach a maturity level where they feel that
success will be assured.
(BRIAN)
Sorry, Chuck, perhaps I haven't properly defined what I mean by the term
"Community Roadmap".
http://issues.sakaiproject.org/confluence/display/MGT/Home#Home-ProjectStatusSummary
is not a Community Roadmap in the sense that I mean; neither is
http://issues.sakaiproject.org/confluence/display/MGT/Sakai+2.4+Roadmap
(While I could point at examples of other open source projects'
Roadmaps, I won't, since one size does not fit all, and I believe that
it is something that we should all create, not copy.)
(CHUCK)
I would point out that Apache does *not* have a roadmap - each of the Apache projects has their own roadmap and they maintain it independently. Sakai is not *one project* - we are lots of little projects working together in a federation. We (like Apache) have a group of project leads we call the PMC (like Apache) - the first meeting of the PMC will happen December 8 and 9 in Atlanta - led by Peter Knoop.
I am sure that the meeting will be a good first step and we will iterate after that.
(BRIAN)
I think that a Community Roadmap should *provide accountability to our
members and to potential members by making goals and their associated
timelines with respect to planned releases as clear as is possible
whenever possible*.
(CHUCK)
Funny this is *exactly* what the MGT pages are *supposed* to do. The only reason that they do not accomplish this goal is because the volunteer teams working on their projects refuse to provide this information - not because there is not a place to put the information - and they are regularly asked for the information. Is there some reason that by naming the document "Community Roadmap" the development teams will be forthcoming with vast amounts of information and commit to solid dates when they keep cards close to their chests and won't contribute to a document titled "Project Coordination" where all they need to do is give a two-sentance status update from time to time and give a two-sentance summary of their plans for the next release.
Some developers have privately told me that one of the reasons that they prefer to work without publishing a big roadmap and/or precise dates for their work is that when they do - they are continuously pestered by community members who need up-to-date status - and if they miss a date - some members of the community who depended on the date - come down hard on those teams. Volunteer teams do not like making promises - just to have those promises thrown in their faces repeatedly if something changes and the dates need to be shifted. It is just easier to announce when things are done.
(BRIAN)
Yep, this is not about managing or committee-ing Sakai to death, it's
simply about trying to have an open and predictable process to get the
main goals down for everyone to see.
It depends - who will write these roadmaps? A small group of people? Isn't that the definition of a committee? As an example, will the Samigo team write the Samigo roadmap? Or will some random community member with world-write access and a personal agenda write the Samigo roadmap for them? Will the Samigo team be allowed to comment on their roadmap? Will the Samigo team be allowed to remove a community added milestone from the roadmap?
Could someone just edit the roadmap document and add an entry saying, "Samigo will deliver QTI 2.0 by June 1, 2007?" and put that in the community roadmap? Then if some Sakai adopter reads this thinking it is official and makes production plans around the milestone - and then if it turns out that this is not something the Samigo team agreed to - then it is the "Foundation's fault"?
I do not like separating authority and responsibility - if the team has the responsibility to deliver - then they have the authority to control their own destiny. You take the responsibility - you have the authority. This is the contract I give to you in your 2.1.x work - it is also the contract I give to the Samigo team and the AUTHZ committers and everyone else in the project.
The schools adopting Sakai would by far prefer a small amount of information that is solid and true to a wealth of information that is mostly made up and does not really reflect any reality.
If you look at successful companies like Google - they thrive on small talented teams that are given a lot of autonomy during the early and mid-phases of their work. As the work emerges - then more folks get involved and then the serious business of getting something production ready and set up to make Google money brings in a lot more people. Google makes up for the possibility that any one team will fail by having lots of teams - at times with potential overlap - genetic diversity of a form.
In a way - the contrib - provisional - production is set up to mirror this notion of letting teams work quietly in their early phases. We are a little messed up because some Sakai elements were grandfathered into "production" or "provisional" status prematurely because of historical factors to do with the grant phase of Sakai. We have been and continue to do some firefighting to get elements of our release to an appropriate maturity level.
(BRIAN)
A Community Roadmap:
a. should be a living document, and a new version should be published at
least twice a year;
b. should outline where the Sakai Community is going in terms of its
main directions (technologies, features, community building,
advocacy/marketing, QA, etc) and should summarize goals met from prior
documents.
(CHUCK)
Will the teams responsible for the elements in the documents be involved in producing the documents or will random volunteer authors from the community just write the documents and inform the teams?
(BRIAN)
By this definition, the link mentioned above is really no closer to a
final Community Roadmap on any random day than trunk is to being a
release on that same random day. In fact, one might argue that it is
farther from being a Community Roadmap than trunk is from being a
release because trunk, at minimum, gets fixed every day if it ceases to
build, and also has QA and documentation teams waiting in the wings to
turn it into a Release on a pre-determined schedule.
(CHUCK)
Right - but unless the teams responsible for the delivery of the software are deeply involved in the production of the roadmap - the roadmap is most likely to be 100% fantasy of a few people who write down what they "want" and then fuss in public about the developer teams not following the "community roadmap".
(BRIAN)
For the sake of argument, let's borrow the appropriate headings and call
Peter's document the "Important Dates/Project Status Summary". Is this a
Community Roadmap? No. Is it invaluable input into a Community Roadmap?
Definitely, absolutely, no question.
I would like to propose the following to kickstart a Sakai Community
Roadmap:
1. a "Sakai Community Roadmaps" link is added on our homepage,
sakaiproject.org;
(CHUCK)
I am willing to have a Sakai Community Home Page link added - as long as these "Community Efforts" are clearly labeled in that page as "unofficial" - I am not going to commit the Sakai Foundation to delivering whatever ends up in these documents.
(BRIAN)
2. a page is added in confluence (under MGT, if Peter's OK with that)
called "Sakai Community Roadmaps";
3. another page is added in confluence called "Sakai Community Roadmap
v1.0 (Draft)" (we would need to figure out what editing permissions
would be required in order to facilitate and maximize input);
4. we give ourselves until December 31st, 2006 to complete this
document. By definition, it will be complete on December 31st, 2006, and
will be our community's best plan for the upcoming year (and, yes, if
it's going well, we could slip the deadline a little :));
5. we then create v2.0 by June 30th, 2007, again planning for the next
12 months;
6. rinse, lather, repeat.
(CHUCK)
In a way you just described the Sakai Requirements process where the "Roadmap" is just the final report of each of the bi-annual requirements phases.
(BRIAN)
I will, of course, volunteer to work with whomever else has interest. In
general, without repeating my last email on this topic, I think that the
hardest work will be figuring out what level of granularity to use, when
to align content with existing Sakai groups, when to summarize across
them, and what processes will be required to facilitate gathering the
content.
This work, of course, would be meant to enhance the ongoing work that
Peter does with respect to Project Management and Coordination and that
Chuck does with respect to Community Evangelism and Technology Visioning.
(CHUCK)
This whole idea seems to be right between the Requirements gathering process and the Project Coordination and not likely to do a decent job of either.
Requirements is where the broad community has formal input into where "Sakai Should Go Next". There are lots of nice open and transparent processes around requirements - there are big public announcements requesting input and guidance is given on how to prepare the input.
The one thing that was missing in the inaugural round of requirements was a nice summary document that gave a high level view of the requirement priorities. Mark has produced a version of such a document for 2.4:
http://bugs.sakaiproject.org/confluence/display/REQ/Requirements+Summary+for+Sakai+2.4
It is forward looking, roadmap like, and represents strong community consensus built up through processes that respect both the needs of the community and the project teams.
The Requirements process feeds the project coordination effort where we try to get dates and commitments from the teams responsible for different aspects of Sakai and track how much progress is being made toward requirements. While this is not working perfectly in all cases - the work on the Resources tool has been *very much* driven by the community and the requirements process. If you look at the "Resources" entry in the MGT report - there is a little Resource Roadmap and a nice little link showing you a way to attend the resources meetings if you want to really see what is going on.
As elements of Sakai mature we will see future efforts increasingly driven by requirements and increasingly provide better information to the MGT report. When things are in firefighting mode - the long term is not practical to focus on - this is just reality. I think that our current processes will ultimately produce excellent tracking and reporting once firefighting subsides.
Each release as part of the release notes, the project coordinator reports on the progress on Requirements so we get some feedback to the requirements process.
http://source.sakaiproject.org/release/2.3.0/fixed-issues.html
From my perspective, with these processes in place and functioning
pretty well - I don't see a place for a world-writable grass-roots produced Roadmap document. My concern is that a few people with a lot of time on their hands will sit around and develop a roadmap document without involving the developer teams and then approach the developer teams brandishing the "Community Roadmap" which most developer teams will likely ignore. Then it will fall to me to force the developer teams to work according to the Community Roadmap. Which I will not do - at that point I will tell the Roadmap committee to simply cease operations and take away the confluence space.
It seems as though your idea of a Community Roadmap is a way to bypass the Requirements Process and allow a committee of Roadmap writers to "set the agenda" for Sakai. Perhaps what you should really do is participate more fully in the Sakai Requirements process - which is where the real long term Sakai roadmap is already being formed.
End of Rant..
In preparation for Atlanta, I am trying to characterize the level of effort that it takes to run Sakai right now and who was doing the work to make "Sakai happen". A lot of these people work pretty quietly so I want to recognize their contributions.
It totals over 15 FTE this point, 3/4 of which is volunteer and 1/4 of which is paid.
I will revise this list and improve it so this is best thought of as a draft.
If I have missed something - please let me know. If you are an institution with a FTE commitment working on the Sakai Core, a Sakai Tool, or Sakai QA - please drop me a short describing the work and give me %FTE in a note so I can add these other contributions to my lists. Do not include the staff it takes to keep Sakai running at your institution - only those who are working on Sakai itself.
These percentages go up and down - I tried to estimate the contribution levels over the past year. Sorry if I over or underestimate these contributions - feel free to correct me.
Paid Staff - Focus on Coordination
Charles Severance - Executive Director - 100%
Mary Miles - Membership Coordinator - 100%
Anthony Whyte - Community Liaison - 100%
Peter Knoop - Project Coordinator - 80%
Megan May - QA Director - 50%
Brigid Cassidy - Conference Coordinator - 40 %
Mark Norton - Requirements Coordinator - 15%
Susan Hardin - Web Master - 25%
Institution Provided Staff - Focus on Coordination
Lon Raley - Finance - Michigan - 50%
Megan May - QA Director - Indiana - 50%
Pam Dietz - Finance/Support - Michigan - 50%
Kathy Riester - Conference/Support - Michigan - 30%
Aaron Zeckoski - Training - VA Tech - 40%
Tony Atkins - Server Support - VA Tech - 20%
Duffy Gilman - Server Support - Univ. Arizona - 20%
John Leasia - Production/Configuration - Michigan - 20%
Margaret Wagner - Newsletter/Web - Michigan - 20%
Crystal Hancock - Designs - Indiana - 20%
Stephen Marquad - QA Leadership - U. Capetown - 20%
Seth Theriault - QA Leadership - Columbia - 20%
Board Members That do Jobs that Staff Should Do
Chris Coppola - rSmart - Licensing - 15%
Joseph Hardin - Michigan - Patent/Legal - 50%
Brad Wheeler - Indiana - Licensing/Patent - 10%
Mara Hancock - Berkeley - Requirements - 15%
Institution Provided - Core Development Team *
Glenn Golden - Michigan - 80%
Ian Boston - Cambridge - 80%
Antranig Basman - Cambridge - 80%
Jim Eng - Michigan - 50%
Andrew Poland - Server Support - Indiana - 40%
Lance Speelmon - Release Manger - Indiana - 30%
Beth Kirschner - Internationalization - Michigan - 30%
Gonzalo Silverio - Skins/UI - Michigan - 30%
Josh Holzman - Testing - Berkeley - 30%
Clay Fenleson - Documentation/Release - Boston University - 20%
Zach Thomas - Import/Export - Texas State - 20%
John Ellis - Helper Tools/JSF rSmart - 10%
Joshua Ryan - Arizona State - 10%
Chuck Hedrick - Dav/Resources - Rutgers - 10%
* These are the people that are those people who are (1) either working on a foundation-assigned task, or (2) available to work on a foundation-assigned task. These are the people that have voluntarily made themselves available to take "on demand" tasks. Sometimes these tasks are to help someone out of a jam or a tight spot. At any moment, these folks are busy on something and can't be instantly micro-reallocated - but in the long run they tend to work on cross-cutting issues.
I am sorry I don't have the names/list of the people working on QA or tools - I will have those lists by Atlanta.
The common thread amongst the people on the list is that their local institutions/situations are stable enough that they or their management have made a commitment to work broadly across the product on cross-cutting issues and to let their agenda be set to a high degree by the Sakai needs rather than local needs. Perhaps the key metric is that they are highly skilled in Sakai and they have "spare time" and ask "how they can help?" and they are "cost-free" from the point of view of the foundation.
Developing these kinds of flexible resources is the key to long-term stability for Sakai - it is important task that I take very seriously. But I will be frank - these are jobs for which there is no training. You can't just go to a two week class and become a "flexible" resource. The people on this list are by nature self-starters and self-learners and self-managed. They have an instinct about where the problems are that need solving. Usually all I have to do is give some simple, general guidance and these people figure out the problem themselves and then solve it. These are the kind of people that *any* organization would love to have on their team.
The most important way to extend this list is for people to have time - (1) time to look at and understand the product and/or code base from one end to the other and (2) time to concentrate on hard problems without being continuously interrupted by your "day job" and (3) time to actually take on and make progress on tasks that likely have little or no immediate value to your local institutions and do these tasks in a timely manner (i.e. there often *is* a deadline). My experience is that it takes at least six months of building expertise before someone can be part of this group.
The good news is that these lists of Foundation resources are growing and even more importantly these lists are becoming increasingly diverse with respect to institution. Diversity on these lists is what keeps us from being too dependent on any one institution or any one individual in the long term.
/Chuck
A status update is way overdue - perhaps after this week I can make a longer status update. But here is a short one.
With Sakai 2.2 and 2.3 in hand, Sakai is in pretty solid shape except for Samigo and OSP (both provisional tools). Samigo has improved a great deal in the past six months but still suffers from scalability as the database gets large. OSP is pretty functional but is very hard to bootstrap due to a lack of good documentation, examples, and a few features that make it a little hard for system administrators to work with.
A few weeks back (at Educause) it became really clear that Samigo's scalability was becoming such a crisis as to put the entire Sakai project at risk. The bad scenario happens when Fall 2008 increasing numbers of schools are moving from pilot to production and instead of 3-4 schools we have 15-20 schools in performance crisis - so the time to fix this is now.
An essential part of the problem with Samigo is the overall size of the database - as more assessments are taken - performance continues to drop off dramatically.
So the Foundation assembled some resources to focus on Samigo's scalability - UM donated 100% of Glenn Golden and others have devoted staff or financial resources. Glenn has been working for the past few weeks and hopes to have a very fast version of Samigo Assessment delivery in the hands of Foothill for testing mid December aimed at production in early January - if this goes well other sites can experiment with this new assessment delivery engine. The essential change was to write the new assessment from the ground up using SQL rather than Hibernate. This has resulted in speedups of several hundred fold improvement on some of the slowest Samigo screens.
Glenn should be checking this into SVN in the next week or so - then Foothill and Stanford can begin to look it over and begin QA. For now this is best though of as a "patch" - and after the first of the year we will reorient things to deliver a solid 2.4 release in March. Using the funds gathered by the volunteers I hope to get performance testing done and some extra QA resources. Peter Knoop will project lead the effort.
It is important to emphasize that this is all being done in concert with Stanford and Stanford will continue to be the lead in functionality - there will be no change in functionality from the speedup effort.
In terms of OSP - a 2.4 kickoff meeting was held to help set priorities to meet the most pressing needs of OSP - new resources were identified and we should look forward to important improvements in OSP's configuration and use for the 2.4 release.
Both of these efforts really highlight an increased emphasis on investing effort on those aspects of Sakai which are visible to the users. Brad uses the term "user delight" to describe this focus.
At Atlanta - I will be giving a talk about the Sakai Foundation where I will cover the organizational structure and finances of the Sakai Foundation. Getting a solid understanding of the Foundation finances is important for us to go forward and make decisions. I look forward to the presentation and the Partner-only retreat as well. the Foundation is a year old and it is a good time to take a check of where we are ant and where we want to go. For those of you who cannot come to Atlanta - I will put up the slides and MP3 record the talk as well and put that up too.
Peter's Friday/Saturday meeting in Atlanta is an important new pattern - an attempt to actually manage our efforts collectively. This is the new "integration week" where we brainstorm tactical priorities for 2.4 - what we should attack before the code freeze in March. This meeting is an experiement - in the future - I expect these meetings may be 3-4 days long. How we organize these meetings will depend in how well things get done at Atlanta.
TTFN.
There is a new bus service from Lansing, MI to Detroit Metro Airport called Michigan Flyer (http://www.michiganflyer.com/). I am writing the Blog entry from the bus. It has wireless networking and costs $25.00 each way. This Blog entry details the trip. It reminds me of the bus from Oxford, UK to Heathrow (http://www.oxfordbus.co.uk/airline1.html).
First lesson - make reservations a day in advance. It has a human in the loop. But in a pinch you can pay the driver $25.00 cash and just hop on the bus. I made my reservations at the last minute and had to make a 4:30 AM phone call - everything worked out.
4:15 AM - The cab was suposed to arrive - it is $9.00 from Holt to the Dunkel Sunoco drop off
4:21 AM - Cab actually arrives - lesson in Lansing Cabs - order early - not right on time - guess I have used cabs too much outside the US.
4:40 AM - Bus shows up right on time at the Sunoco on Dunkel.
http://www.dr-chuck.com/images/2006/11/index.php?img=20-11-06_050124_01.jpg
Now I can relax :) I relax until Jackson at 5:15 and try out the wireless. Seems to work OK. There is a computer with a printer on the bus as well. Mebbe I will try the printer later.
http://www.dr-chuck.com/images/2006/11/index.php?img=20-11-06_052800_01.jpg
Off to read E-Mail.
Arrived right on time at 6:36 AM.
I attended the Kuali Days event (www.kuali.org) in Tucson, AZ this week. The event was hosted by the University of Arizona and it was a wonderful meeting location. The hotel is carved out of a mountain covered in Sagauro cactus. The view from the hotel onto the Tucson valley.
http://www.dr-chuck.com/images/2006/11/index.php?img=14-11-06_110743_01.jpg
The meeting had sessions that ranged from overviews of Kuali Foundation and governance, a demo of Kuali 1.0 functionality, announcement of the Kuali appliance from rSmart, , as well as technical sessions talking about the Kulai Architecture and Technologies.
The Kuali project is reaching the end of its project phase (6/30/2007) and is beginning its movement into its Foundation phase much Like Sakai's transition from project to Foundation at the end of 2005. So in many ways this was a meeting to present Kuali to prospective Foundation members.
The overwhelming impression that I walked away from all of the sessions I attended was one of excitement. All the attendees were very engaged and interested in all of the details about Kuali. I will admit that the conversations about the finer points of cross-unit sub-chart code link associations was a bit dry for my taste - people engaged in the conversations with gusto.
What was amazing to me is how well each attendee seemed to understand their own requirements and needs very precisely and how they could communication those requirements. The Kuali team members knew Kuali very well and were able to discuss how to adapt Kuali to some tricky local need in great detail.
I met Brian McGough the Kuali Chief Architect and Kathleen McNeely the Chair of the Kuali Functional Council. Both are excellent leaders and good speakers - clearly strong leadership is an important factor in the success of Kuali to date.
On the technical side I was interested in many aspects of the Kuali Architecture - they are building the Kuali Service Bus (KSB) to interconnect the various Kauli applications like Kuali Funancials (KFS) and Kuali Research Administration (KRA). This bus is already present in the Kuali 1.0 release and as Kuali moves into scalable production - they will gain increasing experience with the KSB. Once Kuali figures out the issues in the KSB, I would expect that there is some best practice and even possibly technology that might be useful in Sakai - perhaps in particular to talk to some future open source Student Information System (SIS) that folks keep talking about in hushed tones.
On a personal note, I played Texas HoldEm for money for the first time in my life. I had an amazing streak of luck - at one point I took all of Kymber Horn's chips when she went "all in" and I called - she had me totally beat until I made a flush on the River - total luck. I had far more chips than anyone else (see photo). When we got down to three players we decided to split the pot - since Tony Pottts was still in - I figured I should quit while I was ahead. Now I am afraid that if I ever play again, I will lose and break my 1-0 unbeaten streak :). Here is picture of my chip stack:
http://www.dr-chuck.com/images/2006/11/index.php?img=15-11-06_012401_01.jpg
Aargh - lost track of time and missed my flight from Phoenix to San Fanncisco - thankfully there is a flight at 10:30 PM through Las Vegas that goes to SFO.
Phoenix Has free Wifi
Las Vegas has Free Wifi
Cool trip. Wated a few hours missing a flight but was a good voyage to discover free WiFi spots!!
This is what I think would be really cool. This weekend UM wins over OSU but it is a close game and many feel that OSU was the better team.
At some level the only logical ranking the following week would be
UM #1 and OSU #2
Then UM and OSU would meet *again* for the national championship!
This would make up for the times that the big 10 does not make the national championship because other conferences are easier.
Some day they will tell tall tales of how wonderful the KPN.NL wireless ISP is.
Someday when all wireless ISP vendors have ceased to be stupid, we will look back and see that KPN was the first to break ranks and actually provide decent service! Service that is worth what you pay for it.
Here are a few things about KPN that are unique:
- You can buy a weekly pass for $25 Euros
- It worked at my hotel, all NL train stations and Schipol Airport - I used it 10 times
- They have a real human tech support - I called and got my password reset
Bravo!
This was a action packed week. An IMS Meeting, learning a whole bunch about IMS Learning Design (IMS LD), meeting with Rob Koper and his technical team (H. Martens and H Vogten). My head is crammed with new information.
I am still jetlagged from coming back from Australia - even though I spent 2.5 days in the US - it still feels like I am in Australia.
Here is a cool fact - the wireless provider www.kpn.nl that I used in the hotel also is the wireless provider in train stations. And they give out weekly accounts. Tres cool.
Now it is off to Amsterdam by train and then home tomorrow.
Sometimes I come up with an idea that I want to patent but I am so busy that I just blog it instead. Hopefully this will make it into the internet archive and folks can send me money when they want to license my invention.
This idea is pretty simple - headphones with a retractible cord. Basiclly I just want *everything* on the planet to have a retractible cord.
Here is my picture:
http://www.dr-chuck.com/images/2006/11/index.php?img=07-11-06_042259_01.jpg
I scribble these patents on scraps of paper and then type them in later.
Sometimes I come up with an idea that I want to patent but I am so busy that I just blog it instead. Hopefully this will make it into the internet archive and folks can send me money when they want to license my invention.
The basic idea here is to put RFIDs in luggage. This way the systems at airports can slowly develop a profile of a pices of luggage.
How many times have we seen this luggage?
What countries has this luggage been to?
How many times has this luggage been pulled for security check?
Who has used this luggage?
We can either manufacture this RFID into luggage from the beginning or can add it after the fact. For those of you in Homeland Security - you could evne slip this into baggage while it is in the airport. Or perhaps you could work with TSA and voluntarly have them install their RFID.
You can establish the identy of the person who is associated with *this* piece of luggage each time a person checks in. This could also be done at a security checkpoint if we got some type of air traveller ID or perhaps we put RFIDs in passports.
So most folks would think of this as "Big Brother" - sure - like you being uncomfortable with Big Brother stops it from happening. If you don't want to be tracked, photographed, searched, etc - stay away from public transportation. As far as I am concerned once I get near a plane - my life is an open book and I expect that the rest of the folks sharing that transport with me are equally willing to be scrutinized.
Ah well - this is not about politics - this is about roylaties for me and my patent.
Sometimes I invent things and don't have time to file a formal Patent - so I just Blog it.
The basic idea is to be able to take a completely dynamic video or audio on demand system and allow arbitrary groups to create synchronized shared experiences. These groups will self-organize and membership will be dynamic.
This will allow a person working with a VOD system such a as a digital CATV system. The idea is that instead of simply starting the program - one would indicate that they want the program to start at a particular time in the future - typically in 10 minutes or so. The VOD system would display a "joining code" on the screen and count down to the start of the program. This join code could be send to friends or other groups who want to watch the program in a synchronized manner - those other folks would enter the join code on their systems and become part of the synchronized VOD stream. You could even join after the program started. The likely distribution of the code will be IM, SMS, Phone, or E-Mail. Maybe even the CATV system would have a notification mechanism or a group capability.
So the upshot is that you and your group can watch the same thing *at the same time* - all on demand - effectively this is VOD for groups. This has a number of aplications - teaching, learning - where there could be IM or other out of band communication to allow rreactions - also you could collectively pause to discuss things. Other things would be effectively like watching a movie Saturday evening with pals around the world - they might also have separate monitors with webcams so follks could interact and hear each other's laughter or screams. Effectively creating a distributed theater.
So where did I come up with this idea? Well on a A330 coming to England I watched as two children next to me struggled with their individual VOD systems so as to watch the *same* movie at the *same* time. They navigated to the start of the movie and pressed "Play" at the *same* time so they could share the experience.
As we get to the point where we can completely isolate ourselves with totally customized entertainment - we will slowly yearn for group interactions. And the beauty is that adding a group interaction layer on top of a completely personalized system - this also saves bandwidth, etc becuase information can be multicast and precious resources like Digital channels can be used for multiple destinations at the same time.
This provides a nice hybrid between pure VOD and the "movie will start in 35 minutes" of partial VOD.
Please call me if you want to license this patent :)
I was in Australia last week at Charles Sturt University. I had many meetings - in one with CELT (Center for E Learning Technology) - Matt Morton-Allen said I could not say *anything* nerdy.
He helped me with this little outline - which I need to turn into Powerpoint. I put this down so I can throw the paper away:
- Pedagogy focus - hot tech but not luddite either
- What are others doing
- How does the community organize itself? Working and Discussion Groups.
- Talk about Bodginton
- Accessibility
- Usability
- Goal Aware Tools
- Talk about Wiki
- Talk about ePortfolio
- Relate to Moodle
- Talk about Samigo
- Talk about training and communities of practice (Etudes example)
- Prioritization and requirements process
Looks like a good outline.
Thanks Matt.
This is a Netherlands week. Monday I am doing a video shoot of some K12 students using Sakai and portfolio - with JJ Doherty. I will edit and publish as soon as possible. This is more in my video series on "Using Sakai".
Tuesday through Thursday is in Maastricht at the IMS meeting - at the Open University of the Netherlands - my first visit there. The meeting will be cool - I hope to see IMS Enterprise and IMS Tool Interoperabiltiy v2 move forward as well as IMS Common Cartridge.
I feel bad that we don't have more representation and technical involvement in IMS from Sakai schools. I keep going to the meetings but I am weakly covering three technical areas. Josh Holzman has gotten involved in the IMS Enterprise - that helps a lot. Zach Thomas and others did all the technical work on Sakai's IMS Common Cartridge. Of course Steve Lay of Cambridge is an IMS icon in the QTI space. I just wish there were more folks that came to the meetings and helped with the technical work. This really is not a "Sakai" responsibility - Sakai is not a member of IMS - this is something that our schools need to do as schools.
Ah well enough whining - I look forward to meeting folks like Rob Koper and getting totally immersed in the Learning Design stuff - this is a great meeting to come up to speed on *that* topic. Also I will run into Kerry Blinco of DEST fame and catch up - there are lots and lots of fun topics to talk with Kerry about from RAMS to CORDRA to Arrow - etc etc etc.. The Aussies have some fun stuff going on in the area of data repositories.
What a week it looks to be. And JJ is picking me up in an hour to go to the video taping..
I am in the Netherlands this week to attent the IMS meeting in Maastricht. I had to stay a night in Amsterdam so I picked the Movenpick that we will use at the Sakai meeting in June
I took some blog pictures as I found my way from Schipol to the Movenpick. To save money I took EasyJet from Gatwick - a lot less convienent than Nowthwest direct to Shipol airport. As you see Schipol is already decorated for Christmas - makes sense since Schipol is an Airport, Trainstation, and mall all rolled into one.
http://www.dr-chuck.com/images/2006/11/index.php?img=05-11-06_115244_01.jpg
Overall this is an excellent hotel. The decor is totally modern - reminds me of a W but with lighter woods and lots more color. They give you a glass of juice when you check in. The wireless is open and free (at least in my room). Tomorrow morning I will Blog some pictures of my room and the hotel when it is light.
=== More Review
Breakfast is excellent - the only weird bit is the chairs. The decor is totally modern and the chairs are these cool backless cube things with pads. The problem is that they are heavy and you need to bend way down to move a chair and at the four person tables you share a moveable bench with one other person. They are going for a faux-Japanese look - the look is a 150% winner - functionality is not so good for us chubby American travellers. But all in all a delightful breakfast.
In terms of location - it seems that the hotel is 15 minutes walking distance from the fun bits - but the tram stops *right* in front of the hotel - so we will all might as well learn the tram system and buy that multi-day tram pass as soon as we get off the airplane :)
http://www.gvb.nl/english/travellers/maps/lijnenkaart.html
Zoom into Centraal Station and look for the red tram line from the Centraal Station to Piet Heinkade.
The view out of the window to the northeast back towards Centraal Station is almost a clone of a view from the JA-Sig hotel in 2004 in New Orleans:
http://www.dr-chuck.com/images/2004/12/index.php?img=05-12-04_1752001.jpg
http://www.dr-chuck.com/images/2006/11/index.php?img=06-11-06_014426_01.jpg
/sbin/iptables -L
[root@s-sakai-1 etc]# vi /etc/sysconfig/iptables
# Chuck ports
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8090 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8092 -j ACCEPT
# Lancaster ports
root@s-sakai-1 etc]# /sbin/service iptables restart
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: filter [ OK ]
Unloading iptables modules: [ OK ]
Applying iptables firewall rules: [ OK ]
[root@s-sakai-1 etc]#
Grrr - I dislike fancy newfangled things - in BSD 4.3 - we did not have to do this!
-------- Comments -------
Too bad you don't allow comments in your blog. :)
Anyway, I wanted to share an iptables tip - to restart it, it's safer to use iptables-restore:
iptables-restore < /etc/sysconfig/iptables
This will do a syntax check and only reload it if it's correct - useful when hand-editing. The other way could stop the firewall but not bring it back up if the syntax is off.
Mike Osterman
Whitman College
Sakai will not start up with the default JVM settings. You need the following:
[csev@s-sakai-1 ~]$ grep OPT .bash_profile
JAVA_OPTS='-Xmx512m -Xms512m -XX:PermSize=16m -XX:MaxPermSize=128m -XX:NewSize=128m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC' ; export JAVA_OPTS
Here is the message you get when you forget this:
INFO: Deploying web application archive sakai-help-tool.war
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)
Caused by: java.lang.OutOfMemoryError: PermGen space
Exception in thread "QuartzScheduler_QuartzSchedulerThread" java.lang.OutOfMemoryError: PermGen space
Exception in thread "QuartzScheduler_QuartzScheduler-s-sakai-1.dmc.dc.umich.edu_MisfireHandler" java.lang.OutOfMemoryError: PermGen space
The following URL - based on code from John Leasia gives you Google Earth version of the Sakai Map data.
http://www.sakaiproject.org/sakai-map/kml.php
You have to save this as a file with a .kml extension and then open it in Google Earth.
If anyone knows how to make it auto start in Google Earth let me know.
I am just back from a trip to New Zealand and Australia. I was an invited speaker at the University of Auckland so they covered the expenses of the trip.
The trip was great - I got to sail on the ocean for the first time in my life with Scott Diner. The whole crew at University of Auckland is first rate - Scott, Stephen, janet, and the dev team - I learned a lot while I was there.
I also visited Charles Sturt and talkedwith Mark about the IMS Enteprise Provider - we came up with a nice design that leverages the IMS Enterprise work from Scott Wilson of CETIS - this wil be pretty neat. We decided to go ahead and do the current IMS spec after I talked with Linda Feng of Oracle and got the scoop on the IMS Enterprise Interoperbility demo for next year's learning impact - we will likely extend IMS Enterprise a bit for the demo - so it is good for us to go ahead and implement the current spec for IMS Enterprise Services for Sakai at Charles Sturt.
Had a great discussion with the Instructional Designers at CSU and realized that I need to make some more PowerPoint about how to teach with Sakai.
I talked to Paul about many different architecture bits - we came up with lots of cool designs to allow some nice upwards compatibilities with their old system - the idea was to make a special tool called "CSU setup" with buttons that say "Add Subject Outline", "Add Osais" and other CSU local links - put that in the worksite setup - this is a better approach than patching site setup as it allows for business rules.
I ran into some SOA folks as there was a Australia-wide SOA conference at CSU the day after I left - had some great conversations - showed them my new favourite ZapThink SOA poster. Talked a lot about my new slogan "Free the Data" and how RSS and iCal federation is the way of the future - and to think about the Web interface as the "fall back" interface.
Talked a lot about the role of Portals, JSR-168, JSR-286, and all of that stuff. Debated whether or not to rewrite their local perl-based five-year-old MyCSU portal - I suggested not to rewrite but to add a cool synoptic web services to Sakai that returns a cool Dom and then put some simple XSLT in their current portal. Sweet idea. Free the Data! Redo the portal later as a separate project and do it right - perhaps waiting for 286 based portals to appear. At least if you are rewriting - have a reason other than "we need a Sakai Dashboard!"
Later met with James Dalziel of LAMS fame. They are just about done with V2 - looks great - talked about RAMS, CORDRA, Shib, XACML, et c etc etc. This is some really really good stuff. Take a look at the CORDRA project - tres interestingvous!
Notes to self:
- We need to have a Sakaiproject starting page for project managers, developers, designers, and other folks involved in the project. We can call this the Sakai Intranet page - it compliments the Sakai Home Page.
- The Continetal Presidents Club in SFO has free wireless - Sweet
- Register the domain www.freethedata.org
Take a look at this picture:
http://www.dr-chuck.com/images/2006/10/index.php?img=31-10-06_231808_02.jpg
This is James Dalziel (http://www.dr-chuck.com/media.php?comment=feed&id=59) of LAMS fame.
It turns out that Melete's export format is a well-formed IMS Content Package with proper sequencing so that you can export content from Melete and import it into the LAMS 2.0 IMS Content Player and it works nicely!
This worked on the first try - I simply exported from Melete on my laptop - put it on a USB stick and James imported it into LAMS - Viola.
And we had a beer too!