> “Connected world, Connected Software”, “Open source produces better software” (81% of respondents via Gartner)

Matt’s perspective on focusing innovation on the “last mile” plays well with my thoughts on focusing on delivering institutional value. It’s interesting in that he combines that perspective with the pitch that open-source empowers you to build software to suit your needs, as opposed to being at the mercy of a vendor. For all that we spend time trying to prevent forking (in a good way , I do agree with his perspective that forking is perhaps the definitive open-source right.

2 interesting facts mentioned:

> Research shows that 85-100% of core development work is done by less than 15 core developers. 55% of projects get no outside involvement, 72% have less than 2 developers.

The implication of this seems to be a need for projects to enable “drive by development” to gradually expand the circle of contributors. Modular architectures, anything that enables the same people who would contribute small patches or other pieces.

70% GPL “marketshare” for licensing in open-source. It’s funny that as a Java developer, Apache looms so large, but that’s an interesting number to consider in terms of the dynamics of free software. Also, given the uncertainties behind Apache+GPL, makes uPortal’s new-BSD license possibly more of an asset than we would have thought.

Conclusion: “Capitalist Manifesto.” Matt posits that open-source has a huge opportunity in higher education. Both because open-source is easiest to examine, teach, and learn from, but also because we have more interest and ability to share — administrative IT systems typically aren’t a differentiator in Higher Education…

Matt has 10 commandments:

1. engage and put community before cash
2. don’t treat communities like tools
3. don’t make open-source a gimmick
4. partner with community/commercial projects
5. respect the norms of open-source, and community culture
6. fit the license to the desired outcome
7. don’t expect open-source to be easy or a panacea, it will amplify successes and failures
8. innovate on and with open-source communities
9. encourage students to experiment
10. start today

Jens’s talk is focusing on Identity Management where he’s focusing on life-cycle of identity data. Looks like the talk is going to focus on moving towards user-centered identity.”Access to the right resources, to the right users, at the right time” — focused on providing, not preventing access (e.g. from a security perspective).

Authentication vs. Authorization is an important distinction which as an industry we’ve definitely treated sloppily. The delegation scenario (e.g. Kim Cameron’s many writings on the topic) is also very interesting, as “acting on behalf of” really is such a core capability that we often lose when we move into the electronic realm.

Lessons:

• Identity is about relationships – (especially) university ones change over time
• Multiple authoritative sources – authorities for attributes, not people
• Separating account names from stored account ids
• Dynamic rules instead of static roles – interesting in how that pattern’s been modeled in the uPortal community via the adoption of PAGS groups over statically defined ones…

Interestingly, Jens (also in previous conversations) does believe that Federation has some low-hanging fruit and is worthwhile, at least in the short run. I’m still not sure — though he made a very good distinction in the amount of work necessary for IdP vs. SP participation. Shibboleth… one of the key distinctions that Jens is making for the federation case is that Shib maybe more appropriate for federation requirements with generalized, lightweight access where you have similar rules across all members – e.g. all members can access protected library resources.

TurnItIn, iTunesU, JSTOR are on Jens’s list of shibboleth providers and products, which is a pretty attractive list. Not sure what kind of federation agreements have to be in place for these various resources.eduRoam is neat looking — ability to login to another institution’s wifi would be cool.

Identity 2.0: now we’re talking! Claims based — the comment Jens made about University-centric identity assuming that institutional relationships are the most important relationships people have, but that’s not how users are likely to see it seems quite apropos. Claims combined with self vs. 3rd-party verification in a mixed-model really is a neat model for thinking about identity data, and does seem to match the real-world situation well.

The privacy angle of not requiring the IdP to process the transactions, and hence possibly have access to what I’m doing is something that doesn’t seem to get talked about in the US as much, but as more things move online does seem key.OpenID — where we’re seeing convergence in the identity space. CardSpace is also a key player. OpenID support in CAS really seems to make it well positioned to participate in this space.

Conclusion: not sure I’m sold on Federation as the low-hanging fruit, but some of the Shib enabled services do seem pretty compelling. User-centric definitely looks like it’s gaining steam though, which is definitely exciting. This definitely seems to be an area where Higher Education should be at the forefront, since our it is one of the few areas where Higher Education does seem to have legitimately more complex needs and requirements.

Thinking about things to do for the new JA-SIG. Some talk on various topics related to un-conferences, and other bits. There was actually a lot of interesting discussion about regional conferences, video meetings, un-conferences, events focused on collaborating on whitepages, etc. I’ll updated with an audio transcript… uhhh… when I get a chance…

Chuck is talking a bit more about his experience with portlets, and the implications for uPortal, Sakai, etc.

Sakai portlet notes: * Preferences – site.upd to change * Edit Mode – site.upd again * isUserInRole() mapped to Sakai permissions site.upd, content.read, etc.

The isUserInRole() mapping seems a little counter-intuitive — seems like really portlet.xml should be mapped to a particular Sakai role, and that the portlet implementation should decide whether to hardcode the semantics of that role, or look them up based on sakai permissions, or another approach.

Chuck is again advocating JSR-168 as an alternative to the Sakai tool API. At the end of the day, I really feel like the most interesting model might be building Sakai tools that use JSR-168 as the view API. So you throw away the cross-platform promise, and just rely within Sakai on JSR-168 as a well-defined, nicely separated tool component API. Though, he had a note on the end about Sakai-specific portlets, but I don’t think he’s sold yet.

Listening to Phil’s keynote. Will be trying to post video and audio at some point — in the meantime, there’s a good thread about reputation and privacy.

Update: Posted very rough audio recording of the keynote, also available as part of the podcast.

 

 Phil Windley Keynote [58:40m]: Play Now | Play in Popup | Download

Made it into JA-SIG: ran into Susan on the flight from Newark, which was kind of surreal. The irony was that immediately before seeing her at the gate, I was thinking to myself how strange it is that I’ve never run into anyone else I knew while travelling out to one of these conferences.

Arriving at the hotel was nice, must have done something right since there was a cheese plate sitting on the table in my room Dinner was good too — a bunch of committee types went out to this brazilian-style BBQ place Texas de Brazil which was great, if far too much food.

An Agile Update for Mansueto Digital:

Here’s an update: we’ve been running one of the most complex projects ever undertaken in business journalism, called the Inc. 5,000, using a variation of agile known as a scrum.

Interesting to see software development processes being applied out more of a pure business environment. This kind of experimentation must be why I’ve always liked FastCompany

Using Sakai in multiple institutional research settings – AERS

Case Study: Adult Literacy – used resources for file storage and as a documentation store, and diary entries stored as discussion entries. Teams liked the ability to contribute entries/discussions asynchronously, and despite being in many separate locations. Site Stats showed that most visits were content reads (~75%) followed by other tasks.

“Communities of Enquiry” – teams used Sakai as a collaborative environment, after a review of literature to assess models and others. Sites focused on encouraging:

• dialogue
• participation
• perspectives
• structure
• climate
• purpose
• control

An interesting characteristic that was noted was that groups tended towards relatively flat permission hierarchies, and high usage of communication tools (discussions, chat, etc – as opposed to other).

“The Moon would not be big if people took it apart…”

Jeshua Pacifici talked a bit about his experiences migrating from Blackboard to Sakai. Very broad detail focused, less information on the technical and detail sides of migrations (e.g. how to get Courses/Projects out of Blackboard). High level overview of some benefits, caveats, and others.