OVERVIEW & UPDATE
February 2009, Valencia, Spain
Agenda
Sakai in 2008 Focus on Quality Challenges
Sakai 3.0 Approach Demo Getting involved
Community Survey & Board Retreat Survey Results New Development Structure?
Focus on Quality
August 2007: My first month at Sakai Sakai release 2.4 going in production Large institutions spending too much time on
troubleshooting & maintenance Fewer resources for new feature development
Immediate Foundation Goal Quality, Quality, Quality
Other Issues Dissatisfaction with Sakai UX Upcoming Newport Beach Conference No location selected for Summer 2008 conference Too much time/money spent on organizing
conferences
Changes & Results
Increased Foundation staff focused on QA Extended QA Cycle for 2.5
Formal Beta and Release Candidates University of Cape Town running Beta in
production Final 2.5.0 release in March instead of November
Introduction of Maintenance Releases Currently on Sakai 2.5.4, the most reliable
version of Sakai to date Challenge: Managing 2.5 and 2.6 releases
simultaneously
UX Improvement
Did not make 2.6 release Not enough work completed in time for code
freeze Many felt design needed happen on tools before
they would deploy on campus 2.7 or 3.0?
Currently the Foundation is working towards 3.0 Design work can be implemented for 2.7, but we
need resources willing to do this Overall Result
Positive change in direction Won’t be satisfied until changes reach release
Foundation Spending
January - September
Slowly Moving in Right Direction
Current Challenges
Predictable Roadmap Good things are happening When will they emerge into the release?
Creating large changes User Interface Improvement Major Tool Rewrites A Completely New Version?
Why and What and When
Sakai 3
Sakai 3 Needs
Changes in user expectations Web 2.0 Beyond course support
New technology More standards open source projects to
leverage JCR (Jackrabbit) Open Social (Shindig)
Client-side programming JavaScript/AJAX
Sakai 3 for Users
Academic Networking Connections are important Not friends, per se, but connections Includes research and people
Content authoring and organization Flexible page creation Template-based authoring Everything is content
Searchable, linkable, portable
Sakai 3 for Users cont.
Groups & Sites (call them spaces?) Join a group
A collection of people with something in common Have access to a site/space
A collection of content and functionality Multiple groups can have access to the same
space Treatment of content
Stored in a general repository Available in a variety of sites/spaces “Everything” is content
Content in Sakai 3
Sakai 3 for Users (cont.)
Beyond Tool Silos Academic work flows often cross tool
boundaries Anything can be graded! Anything can be discussed!
This is beginning to appear in Sakai 2 But more needs to be done
Example: Assignments Tool Yes, students need a list of all assignments But should they need to go to the
assignments tool in each class to find them?
http://3akai.sakaifoundation.org
Sakai 3 Demo
Sakai 3 Technology
Scalability Remove bottlenecks from Sakai 2. Initial tests show large improvements; need
more proof. Developer Productivity
Faster builds UX & back-end development separated
Code Quality & Maintenance Reliance on other open source efforts Increase unit testing
Easier to install/build To improve initial experience for new developers
JCR as Content Store
Standards-based JSR 170 Ships with Apache Jackrabbit, but can be
changed Everything as content
Discussion post, User profile information, etc. Components put Content into JCR Content store Sakai Kernel creates relational indices in DB
Component doesn’t need to do anything Automatic tracking of most events by kernel
JSON
Sakai Kernel provides JSON microformat Components use REST calls to interact with
Kernel Again, standards based
JAX-RS currently in Kernel (JSR 311) Benefits
Back-end services stay Java-based UX programmers more often skilled in JavaScript
Easier UX developers can work on Sakai Tools like GWT can be used for Java-based UI Components can be written using other languages
Sakai 3 Participation
K2 Working Group http://groups.google.com/group/sakai-kernel
UX Design Work UX list http://groups.google.com/group/3akai
How would you like to be involved? Development
Java & JavaScript Design
Conceptual, interaction and visual
When
Q1 2009: Sakai 2.6 Q3 2009: Sakai 2.6.#
A maintenance release for fall production 2010
Q1: Sakai 2.7 (New assignments tool and gradebook?) Later: First versions of Sakai 3
Not functionally equivalent to 2.7 Suitable for new adoptions “Hybrid” version for existing Sakai schools
2011 Sakai 3 as full replacement Maintenance releases for Sakai 2.7 through 2013 No version 2.8
Community Survey & Board Retreat
Changing Practices?
Survey
50+ Organizational Responses 150+ Individual Responses Overall
Sense of overall stability Trust in Sakai board Want to spend more time on community
Sakai Believe that Sakai will be the best platform
Community Wants
Clear product vision & direction More communication from Foundation Roadmap that allows campus advocates to
effectively communicate with stakeholders Project structure that attracts sufficient
resources and uses them effectively More input from functional experts &
designers Allow diverse types participation
Large and small, Formal and informal, Institutional and individual
Ways of Getting Work Done
Organic – Contributors participate in the community based on personal/local interests and priorities. It is the responsibility of the individual to communicate and request broader contribution.
Coordinated – Community structures actively seek to identify and align common contributions. Unmet needs are identified to leaders to encourage investment.
Managed – Resources are committed to achieve a defined set of deliverables. Central authority determines priorities.
Pro
duct Life
Cycle
Majo
r Pro
duct
Changes
• Generate new ideas• Try new technologies
• Prove desirability• Create dev team/plan• Reduce dev risks
• Finish building• Test• Document
Community
Product Council
Product Council
Product Council
Changes
What’s the same? Open development process Low barrier to entry for R&D projects Independent projects possible/encouraged Small feature development remains the same Structural Similarities, possible misperception
R&D ≠ Contrib, Incubation ≠ Provisional, Project ≠ Core
What is different? Adherence to criteria from Incubation to Project Managed process for development team(s) Product Council to enforce criteria for making
release The notion of a maintenance group
Remaining Questions
Will the community accept the model? Foundation recommends, but community
decides Who is the Product Council?
A small group led by Sakai Foundation? A larger panel of community representatives?
A Maintenance Team? A group of developers (part time), directed by
the Foundation to fix bugs Incentive for products to be in official release
And meet standards for inclusion