Shifting our gravitational center

classic Classic list List threaded Threaded
13 messages Options
Clay Fenlason Clay Fenlason
Reply | Threaded
Open this post in threaded view
|

Shifting our gravitational center


In the last 9 months or so, particularly following the emergence of
the ambitious 3akai and K2 initiatives, a fair bit of energy and
thought has gone toward how difficult it is for our collaboration to
achieve large aims.  It's a frequent theme of the discussions between
managers, and has also become a pivot of Board discussion in how to
drive toward a Sakai 3.

The tilt of these discussions has been toward how we can rally deeper
commitments while better structuring the coordination of our
resources, and with good reason.  Such measures need to be taken.  But
I have had the nagging feeling throughout that we are not attending
closely enough to the lessons of the last couple years if that's as
far as we go.  Open source products have succeeded to the extent that
they have harnessed the expertise and passions of their contributors,
and we've not been playing to our strengths in these areas.

I begin with the observation that a great deal of our resource is
still consumed by essentially technical problems.  At the same time
our pool of development resource has grown in the area of tool
development (as echoed by the number of new tools and tool rewrites),
while our resource devoted to core services has remained fairly
static, and may even have shrunk.  This is not really due to shifting
areas of concern as the underlying services have matured, for
stability, scalability and reliability have been real pain points for
deploying institutions over this period.  I am of the opinion that
there are simply limits to the "bench depth" that our institutions can
attract and retain (let alone apply to eLearning problem spaces) when
it comes to Java service architectures.

I follow with the observation that our core services are really of
general interest.  They are certainly not exclusive to the LMS/VLE,
but neither are they exclusive to higher ed.  Witness recent
discussions on content, or note how much Sakai's service needs overlap
with fledgling Apache projects (Sling and Shindig, to name a couple
from the K2 investigations) or Kuali services.

To this I might also add relatively recent successes in loosening the
coupling of the backing logic and the UX.  We are on the cusp of a
future where Sakai functionality may be easily produced without
knowing Java at all.  Even in its "legacy" state Sakai could be
re-packaged in a variety of flavors, ranging from the portfolio system
to the VRE - how much more so will this be the case when K2 provides
data APIs that afford an even greater proliferation of user-facing
functionality?

And it's in that user-facing functionality, addressing the needs of a
breadth of requirements for varying pedagogies, learning styles,
curricula, research collaborations, etc., where our community's real
strength lies.  That is our proper focus, our core mission, and what
we can best coordinate around.

So I'm proposing a thought experiment, before attempting to work out
practical steps. Imagine that the Sakai Foundation were focused almost
entirely on a user-facing product, an assemblage of tools and a
user experience packaged as the Sakai release, which nevertheless took
its underlying services largely for granted.  To string the fantasy
out further, imagine that the "kernel" (those core services, whatever
we determine them to be) were a single Apache project, that its APIs
were well documented and its services could be developed against with
PHP-level skills in a RESTful way; Sakai releases would then simply be
a higher-ed-focused packaging of capability riding on top of this
loosely-coupled kernel.

How would that change our community?  How would it change the
conversation and the activity?  How would it change our resource
issues and the coordination questions around them?  What new resources
might be brought productively to bear, and in what new configurations?
 How would it change our relationship to other higher ed community
source projects?  How would it change our relationship to other open
source projects outside higher ed?

Would it change how you think about Sakai?

--
Clay Fenlason
Director, Educational Technology
Georgia Institute of Technology
(404) 385-6644
----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Strategy & Advocacy site.
You can modify how you receive notifications at My Workspace > Preferences.
Michael Korcuska Michael Korcuska
Reply | Threaded
Open this post in threaded view
|

Re: Shifting our gravitational center


Thanks, Clay. I have a couple of comments on this email that  
thoughtfully captures a lot of recent thinking.

* For those of you who have comments, please send them publicly. This  
kind of discussion often generates private emails that, with a little  
extra care in the crafting, would benefit everyone.

* We could also imagine the Foundation focused on the "kernel"  
project, essentially delivering the infrastructure needed for the tool  
development by the community. A different thought experiment, but one  
worth having while thinking this through. I see some advantages (and  
disadvantages) to this way of thinking.

* Whether or not "the kernel" would be an "Apache" project, per se, is  
not the point.  The point is that it would be generic and try to be of  
use to other communities. But this leads me to wonder who these  
communities are and how open they are to meeting our needs. This is a  
cultural evaluation as much as a technical one, and should be equally  
focused on the users of the technology. It's not clear to me who uses  
Sling and how much they share our interests. Shindig is a bit clearer  
but also covers much less of our overall needs.

Kuali is certainly a community we know and share interests with (to  
say the least). Perhaps the Sakai kernel would be, for example, a few  
bits of Kuali Rice. With Kuali comes a particular development model  
that is not Apache-like. To follow from the previous though  
experiment, could one imagine the Sakai Foundation being a member of  
Kuali (focused on Rice) and delivering a kernel that the Sakai  
community could use to implement a CMS, portfolio system and academic  
collaboration system?


Michael

On Jan 5, 2009, at 19:28, Clay Fenlason wrote:

> In the last 9 months or so, particularly following the emergence of
> the ambitious 3akai and K2 initiatives, a fair bit of energy and
> thought has gone toward how difficult it is for our collaboration to
> achieve large aims. It's a frequent theme of the discussions between
> managers, and has also become a pivot of Board discussion in how to
> drive toward a Sakai 3.
>
> The tilt of these discussions has been toward how we can rally deeper
> commitments while better structuring the coordination of our
> resources, and with good reason. Such measures need to be taken. But
> I have had the nagging feeling throughout that we are not attending
> closely enough to the lessons of the last couple years if that's as
> far as we go. Open source products have succeeded to the extent that
> they have harnessed the expertise and passions of their contributors,
> and we've not been playing to our strengths in these areas.
>
> I begin with the observation that a great deal of our resource is
> still consumed by essentially technical problems. At the same time
> our pool of development resource has grown in the area of tool
> development (as echoed by the number of new tools and tool rewrites),
> while our resource devoted to core services has remained fairly
> static, and may even have shrunk. This is not really due to shifting
> areas of concern as the underlying services have matured, for
> stability, scalability and reliability have been real pain points for
> deploying institutions over this period. I am of the opinion that
> there are simply limits to the "bench depth" that our institutions can
> attract and retain (let alone apply to eLearning problem spaces) when
> it comes to Java service architectures.
>
> I follow with the observation that our core services are really of
> general interest. They are certainly not exclusive to the LMS/VLE,
> but neither are they exclusive to higher ed. Witness recent
> discussions on content, or note how much Sakai's service needs overlap
> with fledgling Apache projects (Sling and Shindig, to name a couple
> from the K2 investigations) or Kuali services.
>
> To this I might also add relatively recent successes in loosening the
> coupling of the backing logic and the UX. We are on the cusp of a
> future where Sakai functionality may be easily produced without
> knowing Java at all. Even in its "legacy" state Sakai could be
> re-packaged in a variety of flavors, ranging from the portfolio system
> to the VRE - how much more so will this be the case when K2 provides
> data APIs that afford an even greater proliferation of user-facing
> functionality?
>
> And it's in that user-facing functionality, addressing the needs of a
> breadth of requirements for varying pedagogies, learning styles,
> curricula, research collaborations, etc., where our community's real
> strength lies. That is our proper focus, our core mission, and what
> we can best coordinate around.
>
> So I'm proposing a thought experiment, before attempting to work out
> practical steps. Imagine that the Sakai Foundation were focused almost
> entirely on a user-facing product, an assemblage of tools and a
> user experience packaged as the Sakai release, which nevertheless took
> its underlying services largely for granted. To string the fantasy
> out further, imagine that the "kernel" (those core services, whatever
> we determine them to be) were a single Apache project, that its APIs
> were well documented and its services could be developed against with
> PHP-level skills in a RESTful way; Sakai releases would then simply be
> a higher-ed-focused packaging of capability riding on top of this
> loosely-coupled kernel.
>
> How would that change our community? How would it change the
> conversation and the activity? How would it change our resource
> issues and the coordination questions around them? What new resources
> might be brought productively to bear, and in what new configurations?
> How would it change our relationship to other higher ed community
> source projects? How would it change our relationship to other open
> source projects outside higher ed?
>
> Would it change how you think about Sakai?
>
> --
> Clay Fenlason
> Director, Educational Technology
> Georgia Institute of Technology
> (404) 385-6644
>
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
> ) from the DG: Strategy & Advocacy site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.

--
Michael Korcuska
Executive Director, Sakai Foundation
[hidden email]
phone: +1 510-931-6559
mobile (US): +1 510-599-2586
mobile (FR): +33 (0)6 31 11 58 97
skype: mkorcuska




----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Strategy & Advocacy site.
You can modify how you receive notifications at My Workspace > Preferences.
Chris Coppola Chris Coppola
Reply | Threaded
Open this post in threaded view
|

Re: Shifting our gravitational center


This is a very interesting and important conversation. Clay thanks for  
getting it started. It has taken me a while to digest and I'm sure I'm  
still not understanding the full scope of your thoughts. I think  
Michael's comment below has helped me a bit by relating this  
conversation with another similar conversation in the Kuali community.

Clay please correct me where I'm not fully understanding, or over-
simplifying... Do I understand that one key point for consideration is  
whether we could reduce the overall effort our community is  
responsible for by relying on one or more other communities for  
Sakai's "Kernel?" If I understood correctly some of K2's key goals  
have been to do this by leveraging more readily available components  
and frameworks and reduce the amount of Sakai-specific code. Your  
thought experiment seems to take that a bit further, if I'm  
understanding it, by "outsourcing" the development of the Kernel  
itself. Outsourcing probably isn't the right term because presumably  
members of this community would be actively engaged in the project  
that took that on, but it wouldn't be the "responsibility" of the  
Sakai community per se.

I do believe that, in time, our collective capacity and talent could  
be better harnessed if we were able to find those things that were  
truly common and align our "project clocks" so that applications like  
Sakai, Kuali Financials, Kuali Student, etc. could leverage common  
underpinnings. Though experience so far tells me this is a simple idea  
that is very difficult to realize... and absolutely worth considering.

I also want to support a comment you made very early in your original  
message:

> The tilt of these discussions has been toward how we can rally deeper
> commitments while better structuring the coordination of our
> resources, and with good reason. Such measures need to be taken.

Your ideas for reducing the scope of our community's focus, if  
feasible, might allow more of those deeper commitments, and better  
coordination of our combined talent to go toward what really matters  
to end users.

/chris
--
rSmart
Chris Coppola | 602.490.0472
blog: coppola.rsmart.com

On Jan 6, 2009, at 3:49 AM, Michael Korcuska wrote:

> Kuali is certainly a community we know and share interests with (to  
> say the least). Perhaps the Sakai kernel would be, for example, a  
> few bits of Kuali Rice. With Kuali comes a particular development  
> model that is not Apache-like. To follow from the previous though  
> experiment, could one imagine the Sakai Foundation being a member of  
> Kuali (focused on Rice) and delivering a kernel that the Sakai  
> community could use to implement a CMS, portfolio system and  
> academic collaboration system?


----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Strategy & Advocacy site.
You can modify how you receive notifications at My Workspace > Preferences.
Clay Fenlason Clay Fenlason
Reply | Threaded
Open this post in threaded view
|

Re: Shifting our gravitational center


Some replies in-line below:

On Tue, Jan 6, 2009 at 9:13 AM, Christopher D. Coppola
<[hidden email]> wrote:

> Do I understand that one key point for consideration is
> whether we could reduce the overall effort our community is responsible for
> by relying on one or more other communities for Sakai's "Kernel?" If I
> understood correctly some of K2's key goals have been to do this by
> leveraging more readily available components and frameworks and reduce the
> amount of Sakai-specific code. Your thought experiment seems to take that a
> bit further, if I'm understanding it, by "outsourcing" the development of
> the Kernel itself. Outsourcing probably isn't the right term because
> presumably members of this community would be actively engaged in the
> project that took that on, but it wouldn't be the "responsibility" of the
> Sakai community per se.

It would not be the exclusive responsibility of the Sakai community,
right.  It would hinge upon whether we might draw the right sort of
boundary around the right body of code (whether it's what we currently
think of as the "kernel" will merit some consideration, but I'll use
the term for the sake of argument) that could attract other
organizations and people to help develop and maintain it - perhaps by
dovetailing with other open source projects, perhaps by attracting
commercial affiliates who have an interest in alternative packagings
that use similar services, and perhaps by better coordination with
other community source projects in higher ed.

If we can't attract that additional resource from other quarters, then
the motivation for this sort of move largely falls apart.  We'd be
left with what the K2 project essentially is now, and a question of
how to organize ourselves internally.

I was imagining that those currently involved with Sakai's core
services would continue to be, but to that extent under the umbrella
of a different community; one more technically focused, with a product
deliverable that takes tool and UI developers as its primary "users."
Sakai service requirements would be surfaced, negotiated and addressed
by dint of our engagement in this other community extending beyond
ourselves, while at the same time we organize ourselves better and
more directly around the academic mission.

~Clay
----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Strategy & Advocacy site.
You can modify how you receive notifications at My Workspace > Preferences.
Ray Davis Ray Davis
Reply | Threaded
Open this post in threaded view
|

Re: Shifting our gravitational center

In reply to this post by Michael Korcuska

Given Michael's nudge, and with the caveat that I'm an engineer rather
than a manager, here's the no-content message I dashed off to Clay
yesterday:

Your suggestion has had my vote since before Sakai 1.  :)  The only core
service I know of whose requirements *might* force something
LMS/CLE-specific is group-authz. Otherwise there's not much excuse for
taking on the cost of Sakai-specific service libraries -- our limited
resources would be better spent on light-weight UX-focused application
development.

So yes, it would significantly change the way I (and some others I know)
think about Sakai.

===

To add a bit more along Michael's lines.... When we *do* find that we
need something that's lacking in an external dependency, I'd prefer to
think about *contributing* to that external project before grabbing the
excuse to reimplement it. To use the example I mentioned, if we need
group-based authz libraries that aren't in JA-SIG or Spring Security, we
could try to design something that can be added to one of those
projects. Or, if we need a friendlier face on JCR services, we could try
to package that friendly face in a Jakarta commons-like fashion. My hope
is that by reducing our sprawling maintenance costs, we'd be able to let
a small community of service-oriented engineers focus on doing a very
clean job on the missing bits, while a larger end-user-focused
development community concentrated on delivering more functionality more
quickly. The K2 effort and UX development approach are definitely steps
in the right direction, but I hope it's possible to go a lot farther.

Best,
Ray

On 1/6/2009 2:49 AM, Michael Korcuska wrote:

> Thanks, Clay. I have a couple of comments on this email that
> thoughtfully captures a lot of recent thinking.
>
> * For those of you who have comments, please send them publicly. This
> kind of discussion often generates private emails that, with a little
> extra care in the crafting, would benefit everyone.
>
> * We could also imagine the Foundation focused on the "kernel" project,
> essentially delivering the infrastructure needed for the tool
> development by the community. A different thought experiment, but one
> worth having while thinking this through. I see some advantages (and
> disadvantages) to this way of thinking.
>
> * Whether or not "the kernel" would be an "Apache" project, per se, is
> not the point.  The point is that it would be generic and try to be of
> use to other communities. But this leads me to wonder who
> these communities are and how open they are to meeting our needs. This
> is a cultural evaluation as much as a technical one, and should be
> equally focused on the users of the technology. It's not clear to me who
> uses Sling and how much they share our interests. Shindig is a bit
> clearer but also covers much less of our overall needs.
>
> Kuali is certainly a community we know and share interests with (to say
> the least). Perhaps the Sakai kernel would be, for example, a few bits
> of Kuali Rice. With Kuali comes a particular development model that is
> not Apache-like. To follow from the previous though experiment, could
> one imagine the Sakai Foundation being a member of Kuali (focused on
> Rice) and delivering a kernel that the Sakai community could use to
> implement a CMS, portfolio system and academic collaboration system?
>
>
> Michael
>
> On Jan 5, 2009, at 19:28, Clay Fenlason wrote:
>
>> In the last 9 months or so, particularly following the emergence of
>> the ambitious 3akai and K2 initiatives, a fair bit of energy and
>> thought has gone toward how difficult it is for our collaboration to
>> achieve large aims. It's a frequent theme of the discussions between
>> managers, and has also become a pivot of Board discussion in how to
>> drive toward a Sakai 3.
>>
>> The tilt of these discussions has been toward how we can rally deeper
>> commitments while better structuring the coordination of our
>> resources, and with good reason. Such measures need to be taken. But
>> I have had the nagging feeling throughout that we are not attending
>> closely enough to the lessons of the last couple years if that's as
>> far as we go. Open source products have succeeded to the extent that
>> they have harnessed the expertise and passions of their contributors,
>> and we've not been playing to our strengths in these areas.
>>
>> I begin with the observation that a great deal of our resource is
>> still consumed by essentially technical problems. At the same time
>> our pool of development resource has grown in the area of tool
>> development (as echoed by the number of new tools and tool rewrites),
>> while our resource devoted to core services has remained fairly
>> static, and may even have shrunk. This is not really due to shifting
>> areas of concern as the underlying services have matured, for
>> stability, scalability and reliability have been real pain points for
>> deploying institutions over this period. I am of the opinion that
>> there are simply limits to the "bench depth" that our institutions can
>> attract and retain (let alone apply to eLearning problem spaces) when
>> it comes to Java service architectures.
>>
>> I follow with the observation that our core services are really of
>> general interest. They are certainly not exclusive to the LMS/VLE,
>> but neither are they exclusive to higher ed. Witness recent
>> discussions on content, or note how much Sakai's service needs overlap
>> with fledgling Apache projects (Sling and Shindig, to name a couple
>> from the K2 investigations) or Kuali services.
>>
>> To this I might also add relatively recent successes in loosening the
>> coupling of the backing logic and the UX. We are on the cusp of a
>> future where Sakai functionality may be easily produced without
>> knowing Java at all. Even in its "legacy" state Sakai could be
>> re-packaged in a variety of flavors, ranging from the portfolio system
>> to the VRE - how much more so will this be the case when K2 provides
>> data APIs that afford an even greater proliferation of user-facing
>> functionality?
>>
>> And it's in that user-facing functionality, addressing the needs of a
>> breadth of requirements for varying pedagogies, learning styles,
>> curricula, research collaborations, etc., where our community's real
>> strength lies. That is our proper focus, our core mission, and what
>> we can best coordinate around.
>>
>> So I'm proposing a thought experiment, before attempting to work out
>> practical steps. Imagine that the Sakai Foundation were focused almost
>> entirely on a user-facing product, an assemblage of tools and a
>> user experience packaged as the Sakai release, which nevertheless took
>> its underlying services largely for granted. To string the fantasy
>> out further, imagine that the "kernel" (those core services, whatever
>> we determine them to be) were a single Apache project, that its APIs
>> were well documented and its services could be developed against with
>> PHP-level skills in a RESTful way; Sakai releases would then simply be
>> a higher-ed-focused packaging of capability riding on top of this
>> loosely-coupled kernel.
>>
>> How would that change our community? How would it change the
>> conversation and the activity? How would it change our resource
>> issues and the coordination questions around them? What new resources
>> might be brought productively to bear, and in what new configurations?
>> How would it change our relationship to other higher ed community
>> source projects? How would it change our relationship to other open
>> source projects outside higher ed?
>>
>> Would it change how you think about Sakai?
>>
>> --
>> Clay Fenlason
>> Director, Educational Technology
>> Georgia Institute of Technology
>> (404) 385-6644

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Strategy & Advocacy site.
You can modify how you receive notifications at My Workspace > Preferences.
Stephen Marquard Stephen Marquard
Reply | Threaded
Open this post in threaded view
|

Re: Shifting our gravitational center

In reply to this post by Clay Fenlason

One of the historical problems with Sakai is that the boundaries between tools and tools and the framework have been _too_ strong, i.e. the framework has not evolved to keep pace with demands from tool writers, and the lack of appropriate shared services has led tool authors to reinvent the wheel or implement tool/contrib code for services which should be core.

So the prospect of "outsourcing" the kernel brings with it the risk of making this situation worse rather than better - designers and tool authors could find a kernel that is doubly resistant to change, i.e. less responsive.

Regards
Stephen

>>> "Clay Fenlason" <[hidden email]> 01/06/09 4:52 PM >>>

Some replies in-line below:

On Tue, Jan 6, 2009 at 9:13 AM, Christopher D. Coppola
<[hidden email]> wrote:

> Do I understand that one key point for consideration is
> whether we could reduce the overall effort our community is responsible for
> by relying on one or more other communities for Sakai's "Kernel?" If I
> understood correctly some of K2's key goals have been to do this by
> leveraging more readily available components and frameworks and reduce the
> amount of Sakai-specific code. Your thought experiment seems to take that a
> bit further, if I'm understanding it, by "outsourcing" the development of
> the Kernel itself. Outsourcing probably isn't the right term because
> presumably members of this community would be actively engaged in the
> project that took that on, but it wouldn't be the "responsibility" of the
> Sakai community per se.

It would not be the exclusive responsibility of the Sakai community,
right.  It would hinge upon whether we might draw the right sort of
boundary around the right body of code (whether it's what we currently
think of as the "kernel" will merit some consideration, but I'll use
the term for the sake of argument) that could attract other
organizations and people to help develop and maintain it - perhaps by
dovetailing with other open source projects, perhaps by attracting
commercial affiliates who have an interest in alternative packagings
that use similar services, and perhaps by better coordination with
other community source projects in higher ed.

If we can't attract that additional resource from other quarters, then
the motivation for this sort of move largely falls apart.  We'd be
left with what the K2 project essentially is now, and a question of
how to organize ourselves internally.

I was imagining that those currently involved with Sakai's core
services would continue to be, but to that extent under the umbrella
of a different community; one more technically focused, with a product
deliverable that takes tool and UI developers as its primary "users."
Sakai service requirements would be surfaced, negotiated and addressed
by dint of our engagement in this other community extending beyond
ourselves, while at the same time we organize ourselves better and
more directly around the academic mission.

~Clay
----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Strategy & Advocacy site.
You can modify how you receive notifications at My Workspace > Preferences.

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Strategy & Advocacy site.
You can modify how you receive notifications at My Workspace > Preferences.
Sean Mehan Sean Mehan
Reply | Threaded
Open this post in threaded view
|

Re: Shifting our gravitational center


There is wisdom in what Stephen writes here. It is not to oppose the  
suggestion from Clay, but some analysis should be given as to why  
there was this historical need to re-implement internally, rather than  
"outsource" in the first instance. There are plenty of components that  
have been brought in, but others that were developed locally.

Is it "not invented here" or was it, rather, as Stephen suggests, a  
feeling that the fit wasn't just right enough and that the external  
community was not willing to accommodate enough change to make the fit  
more comfortable. If the former, then will can overcome, but if the  
later, then there is just more frustration waiting for tool writers  
against the new, outsourced kernel....

The same analysis then needs to be made with respect to the tools and  
interaction with shared services.

It may be a little of both, which will reduce the weight of either  
path, and make it even more difficult to judge:)

s.

On 7 Jan 2009, at 07:28, Stephen Marquard wrote:

> One of the historical problems with Sakai is that the boundaries  
> between tools and tools and the framework have been _too_ strong,  
> i.e. the framework has not evolved to keep pace with demands from  
> tool writers, and the lack of appropriate shared services has led  
> tool authors to reinvent the wheel or implement tool/contrib code  
> for services which should be core.
>
> So the prospect of "outsourcing" the kernel brings with it the risk  
> of making this situation worse rather than better - designers and  
> tool authors could find a kernel that is doubly resistant to change,  
> i.e. less responsive.
>
> Regards
> Stephen

>
<snip>


Sean Mehan
Head of Integrated Technologies
Learning and Information Services
UHI - www.uhi.ac.uk
www.weblogs.uhi.ac.uk/sm00sm/
--------------------
GuanXi - a SAML/Shibboleth IdP, SP and Toolkit - http://guanxi.sourceforge.net/
--------------------
Sakai - a Free VLE/VRE - http://sakaiproject.org/
--------------------

Creating the University of the Highlands and Islands / A' Cruthachadh  
Oilthigh na Gaidhealtachd's nan Eilean

A Millennium Commission lottery project. A limited company registered  
in Scotland No. 148203. Scottish Charity No. SC022228. Registered  
office: 12B, Ness Walk, Inverness  IV3 5SQ.

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Strategy & Advocacy site.
You can modify how you receive notifications at My Workspace > Preferences.
skeesler skeesler
Reply | Threaded
Open this post in threaded view
|

Re: Shifting our gravitational center


I'm the last guy that should be on this conversation, but I won't let
that stop me. :)

I bet that the motivation to build large parts of Sakai "from scratch"
was pretty benign. The apache projects that Clay mentioned probably
didn't exist back then, so Sakai (and probably a bunch of other
projects) had to "invent them here" to move the project forward. If we
think that Sakai can be refactored to incorporate these projects and
free us up to do something more relevant....that sounds like a good
idea.

I assume that an "outsourced" kernel could be done. However, I can
imagine different outcomes depending on how it was managed (or not). I
would hope that we would have clear set of objectives that we are
trying to attain (maybe more than just replacing parts) and that
decisions to adopt an external project as part of Sakai would need to
be held up against these goals.

I think of the decision NOT to make decisions around "this" or "that"
and the confusion that results from that way of doing things.

Sean



On Wed, Jan 7, 2009 at 5:21 AM, Sean Mehan <[hidden email]> wrote:

> There is wisdom in what Stephen writes here. It is not to oppose the
> suggestion from Clay, but some analysis should be given as to why
> there was this historical need to re-implement internally, rather than
> "outsource" in the first instance. There are plenty of components that
> have been brought in, but others that were developed locally.
>
> Is it "not invented here" or was it, rather, as Stephen suggests, a
> feeling that the fit wasn't just right enough and that the external
> community was not willing to accommodate enough change to make the fit
> more comfortable. If the former, then will can overcome, but if the
> later, then there is just more frustration waiting for tool writers
> against the new, outsourced kernel....
>
> The same analysis then needs to be made with respect to the tools and
> interaction with shared services.
>
> It may be a little of both, which will reduce the weight of either
> path, and make it even more difficult to judge:)
>
> s.
>
> On 7 Jan 2009, at 07:28, Stephen Marquard wrote:
>
>> One of the historical problems with Sakai is that the boundaries
>> between tools and tools and the framework have been _too_ strong,
>> i.e. the framework has not evolved to keep pace with demands from
>> tool writers, and the lack of appropriate shared services has led
>> tool authors to reinvent the wheel or implement tool/contrib code
>> for services which should be core.
>>
>> So the prospect of "outsourcing" the kernel brings with it the risk
>> of making this situation worse rather than better - designers and
>> tool authors could find a kernel that is doubly resistant to change,
>> i.e. less responsive.
>>
>> Regards
>> Stephen
>
>>
> <snip>
>
>
> Sean Mehan
> Head of Integrated Technologies
> Learning and Information Services
> UHI - www.uhi.ac.uk
> www.weblogs.uhi.ac.uk/sm00sm/
> --------------------
> GuanXi - a SAML/Shibboleth IdP, SP and Toolkit -
> http://guanxi.sourceforge.net/
> --------------------
> Sakai - a Free VLE/VRE - http://sakaiproject.org/
> --------------------
>
> Creating the University of the Highlands and Islands / A' Cruthachadh
> Oilthigh na Gaidhealtachd's nan Eilean
>
> A Millennium Commission lottery project. A limited company registered
> in Scotland No. 148203. Scottish Charity No. SC022228. Registered
> office: 12B, Ness Walk, Inverness IV3 5SQ.
>
> ________________________________
> This automatic notification message was sent by Sakai Collab
> (https://collab.sakaiproject.org//portal) from the DG: Strategy & Advocacy
> site.
> You can modify how you receive notifications at My Workspace > Preferences.
>
----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Strategy & Advocacy site.
You can modify how you receive notifications at My Workspace > Preferences.
Ray Davis Ray Davis
Reply | Threaded
Open this post in threaded view
|

Re: Shifting our gravitational center

In reply to this post by Stephen Marquard

Clay also mentioned the risk that this might widen the separation
between "service producers" and "tool producers," and thus lead to less
efficient and maintainable tool code.

A related (and all too familiar) risk is that Sakai's "service producer"
group might produce services that don't match what end users and
administrators actually need (for example, by blocking efficient DB
queries in favor of stovepiped object-oriented APIs). Any employer that
doesn't make it organizationally clear just who is jumping to whose tune
is asking for trouble.

But none of what we're talking about is worthwhile unless it reduces the
amount of work specialized core service producers need to take on (i.e.,
reduces the number of specialized core service producers universities
need to hire or train to make a CLE/LMS work). We don't want them
re-inventing wheels and we don't want them bottlenecking application
delivery. Lighter-weight application development needs to incorporate
application-specific data storage and application-specific RESTful web
services. And one aspect of lighter-weight development is production by
less experienced or less specialized or just plain *faster* developers
-- PHP+MySQL-style, Rails-style, or Grails-style development rather than
obsessive iron-to-LCD handcrafting.

To manage that, we need lighter-weight development of
application-specific data and application-specific RESTful services (not
just UI code, in other words), good scalability and performance metrics
in place (so that we can vet applications for particular environments
and figure out what, if anything, needs closer attention), industry
standard foundation technology (so that we can take advantage of
industry standard scalability improvements), and tools/services that
were cheap enough to be replaced without tears. "Shoddy code" (for
certain values of "shoddy") isn't something we have the money or the
time to eradicate, given our other goals.

As a real-world example, consider Harvard's distributed iSites approach.
They keep their most expensive eggs guarded in a centrally maintained
basket, while letting departments run their own (more specialized, less
scalable, and cheaper) applications on their own servers using their own
databases. When it seems worth the expense, applications are refactored
as needed and transplanted to the core. We won't necessarily be able to
support exactly that set-up at UC Berkeley, but the basic principles
seem sound and in line with industry trends such as cloud computing.

So I guess I'd agree that "outsourcing the kernel" won't work
brilliantly if "the kernel" code needs to frequently and rapidly change
in response to requirements from particular tools or use cases. But I
expect we're all aware of the cost of engineering hubris: Sakai simply
doesn't have (and isn't ever likely to get) the personnel to
re-implement and maintain all generic services better, more flexibly,
and more agilely than they've been implemented by non-Sakai-dedicated
experts. So long as we "outsource" (and contribute) to open source
projects with fairly good teams, we shouldn't be worse off than we are now.

Best,
Ray

On 1/6/2009 11:28 PM, Stephen Marquard wrote:

> One of the historical problems with Sakai is that the boundaries between
> tools and tools and the framework have been _too_ strong, i.e. the
> framework has not evolved to keep pace with demands from tool writers,
> and the lack of appropriate shared services has led tool authors to
> reinvent the wheel or implement tool/contrib code for services which
> should be core.
>
> So the prospect of "outsourcing" the kernel brings with it the risk of
> making this situation worse rather than better - designers and tool
> authors could find a kernel that is doubly resistant to change, i.e.
> less responsive.
>
> Regards
> Stephen
>
>  >>> "Clay Fenlason" <[hidden email]> 01/06/09 4:52 PM >>>
>
> Some replies in-line below:
>
> On Tue, Jan 6, 2009 at 9:13 AM, Christopher D. Coppola
> <[hidden email]> wrote:
>  > Do I understand that one key point for consideration is
>  > whether we could reduce the overall effort our community is
> responsible for
>  > by relying on one or more other communities for Sakai's "Kernel?" If I
>  > understood correctly some of K2's key goals have been to do this by
>  > leveraging more readily available components and frameworks and
> reduce the
>  > amount of Sakai-specific code. Your thought experiment seems to take
> that a
>  > bit further, if I'm understanding it, by "outsourcing" the
> development of
>  > the Kernel itself. Outsourcing probably isn't the right term because
>  > presumably members of this community would be actively engaged in the
>  > project that took that on, but it wouldn't be the "responsibility" of
> the
>  > Sakai community per se.
>
> It would not be the exclusive responsibility of the Sakai community,
> right. It would hinge upon whether we might draw the right sort of
> boundary around the right body of code (whether it's what we currently
> think of as the "kernel" will merit some consideration, but I'll use
> the term for the sake of argument) that could attract other
> organizations and people to help develop and maintain it - perhaps by
> dovetailing with other open source projects, perhaps by attracting
> commercial affiliates who have an interest in alternative packagings
> that use similar services, and perhaps by better coordination with
> other community source projects in higher ed.
>
> If we can't attract that additional resource from other quarters, then
> the motivation for this sort of move largely falls apart. We'd be
> left with what the K2 project essentially is now, and a question of
> how to organize ourselves internally.
>
> I was imagining that those currently involved with Sakai's core
> services would continue to be, but to that extent under the umbrella
> of a different community; one more technically focused, with a product
> deliverable that takes tool and UI developers as its primary "users."
> Sakai service requirements would be surfaced, negotiated and addressed
> by dint of our engagement in this other community extending beyond
> ourselves, while at the same time we organize ourselves better and
> more directly around the academic mission.
>
> ~Clay
----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Strategy & Advocacy site.
You can modify how you receive notifications at My Workspace > Preferences.
Anthony Whyte Anthony Whyte
Reply | Threaded
Open this post in threaded view
|

Re: Shifting our gravitational center


My K2 imaginings involve the creation of a package that is composed  
of a set of stable and reliable core services (incorporating where it  
makes sense, other open-source projects)  that I reach for both when  
working on Sakai and when dreaming up some other academic project  
where I need a set of low-level services bundled together that handle  
authz, db persistence mechanisms, content storage and RESTful  
addressability, etc. efficiently and elegantly--all the engineering  
below deck that is of critical importance to the success of any  
enterprise application.  I'd like to hear someone in the near future  
say "you don't need to write that low level stuff, just go get the  
Sakai Kernel."  Not some other community's kernel but the Sakai  
Kernel.  I do not view such a future as one that lies outside our  
academic mission nor do I see it as something that is beyond our  
capabilities or strengths as a community.

Cheers,

Anthony


On Jan 7, 2009, at 1:41 PM, Ray Davis wrote:

> Clay also mentioned the risk that this might widen the separation
> between "service producers" and "tool producers," and thus lead to  
> less
> efficient and maintainable tool code.
>
> A related (and all too familiar) risk is that Sakai's "service  
> producer"
> group might produce services that don't match what end users and
> administrators actually need (for example, by blocking efficient DB
> queries in favor of stovepiped object-oriented APIs). Any employer  
> that
> doesn't make it organizationally clear just who is jumping to whose  
> tune
> is asking for trouble.
>
> But none of what we're talking about is worthwhile unless it  
> reduces the
> amount of work specialized core service producers need to take on  
> (i.e.,
> reduces the number of specialized core service producers universities
> need to hire or train to make a CLE/LMS work). We don't want them
> re-inventing wheels and we don't want them bottlenecking application
> delivery. Lighter-weight application development needs to incorporate
> application-specific data storage and application-specific RESTful web
> services. And one aspect of lighter-weight development is  
> production by
> less experienced or less specialized or just plain *faster* developers
> -- PHP+MySQL-style, Rails-style, or Grails-style development rather  
> than
> obsessive iron-to-LCD handcrafting.
>
> To manage that, we need lighter-weight development of
> application-specific data and application-specific RESTful services  
> (not
> just UI code, in other words), good scalability and performance  
> metrics
> in place (so that we can vet applications for particular environments
> and figure out what, if anything, needs closer attention), industry
> standard foundation technology (so that we can take advantage of
> industry standard scalability improvements), and tools/services that
> were cheap enough to be replaced without tears. "Shoddy code" (for
> certain values of "shoddy") isn't something we have the money or the
> time to eradicate, given our other goals.
>
> As a real-world example, consider Harvard's distributed iSites  
> approach.
> They keep their most expensive eggs guarded in a centrally maintained
> basket, while letting departments run their own (more specialized,  
> less
> scalable, and cheaper) applications on their own servers using  
> their own
> databases. When it seems worth the expense, applications are  
> refactored
> as needed and transplanted to the core. We won't necessarily be  
> able to
> support exactly that set-up at UC Berkeley, but the basic principles
> seem sound and in line with industry trends such as cloud computing.
>
> So I guess I'd agree that "outsourcing the kernel" won't work
> brilliantly if "the kernel" code needs to frequently and rapidly  
> change
> in response to requirements from particular tools or use cases. But I
> expect we're all aware of the cost of engineering hubris: Sakai simply
> doesn't have (and isn't ever likely to get) the personnel to
> re-implement and maintain all generic services better, more flexibly,
> and more agilely than they've been implemented by non-Sakai-dedicated
> experts. So long as we "outsource" (and contribute) to open source
> projects with fairly good teams, we shouldn't be worse off than we  
> are now.
>
> Best,
> Ray
>
> On 1/6/2009 11:28 PM, Stephen Marquard wrote:
> > One of the historical problems with Sakai is that the boundaries  
> between
> > tools and tools and the framework have been _too_ strong, i.e. the
> > framework has not evolved to keep pace with demands from tool  
> writers,
> > and the lack of appropriate shared services has led tool authors to
> > reinvent the wheel or implement tool/contrib code for services which
> > should be core.
> >
> > So the prospect of "outsourcing" the kernel brings with it the  
> risk of
> > making this situation worse rather than better - designers and tool
> > authors could find a kernel that is doubly resistant to change, i.e.
> > less responsive.
> >
> > Regards
> > Stephen
> >
> > >>> "Clay Fenlason" <[hidden email]> 01/06/09 4:52  
> PM >>>
> >
> > Some replies in-line below:
> >
> > On Tue, Jan 6, 2009 at 9:13 AM, Christopher D. Coppola
> > <[hidden email]> wrote:
> > > Do I understand that one key point for consideration is
> > > whether we could reduce the overall effort our community is
> > responsible for
> > > by relying on one or more other communities for Sakai's  
> "Kernel?" If I
> > > understood correctly some of K2's key goals have been to do  
> this by
> > > leveraging more readily available components and frameworks and
> > reduce the
> > > amount of Sakai-specific code. Your thought experiment seems to  
> take
> > that a
> > > bit further, if I'm understanding it, by "outsourcing" the
> > development of
> > > the Kernel itself. Outsourcing probably isn't the right term  
> because
> > > presumably members of this community would be actively engaged  
> in the
> > > project that took that on, but it wouldn't be the  
> "responsibility" of
> > the
> > > Sakai community per se.
> >
> > It would not be the exclusive responsibility of the Sakai community,
> > right. It would hinge upon whether we might draw the right sort of
> > boundary around the right body of code (whether it's what we  
> currently
> > think of as the "kernel" will merit some consideration, but I'll use
> > the term for the sake of argument) that could attract other
> > organizations and people to help develop and maintain it -  
> perhaps by
> > dovetailing with other open source projects, perhaps by attracting
> > commercial affiliates who have an interest in alternative packagings
> > that use similar services, and perhaps by better coordination with
> > other community source projects in higher ed.
> >
> > If we can't attract that additional resource from other quarters,  
> then
> > the motivation for this sort of move largely falls apart. We'd be
> > left with what the K2 project essentially is now, and a question of
> > how to organize ourselves internally.
> >
> > I was imagining that those currently involved with Sakai's core
> > services would continue to be, but to that extent under the umbrella
> > of a different community; one more technically focused, with a  
> product
> > deliverable that takes tool and UI developers as its primary  
> "users."
> > Sakai service requirements would be surfaced, negotiated and  
> addressed
> > by dint of our engagement in this other community extending beyond
> > ourselves, while at the same time we organize ourselves better and
> > more directly around the academic mission.
> >
> > ~Clay
>
> This automatic notification message was sent by Sakai Collab  
> (https://collab.sakaiproject.org//portal) from the DG: Strategy &  
> Advocacy site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.

[see attachment: "smime.p7s", size: 2417 bytes]



Attachments:

smime.p7s
https://collab.sakaiproject.org//access/content/attachment/f071e66f-51d2-4c25-9d23-00d73dce0618/smime.p7s

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Strategy & Advocacy site.
You can modify how you receive notifications at My Workspace > Preferences.
David Haines David Haines
Reply | Threaded
Open this post in threaded view
|

Re: Shifting our gravitational center

In reply to this post by Stephen Marquard

We can try to outsource (or share) infrastructure, but we can't  
outsource innovation.  We run exactly the risk you point out if we  
try.  The kernel can't be implementing functionality that will need  
frequent tuning.

There could be a lot of shared benefit in a kernel that provided:
- a simple plugin approach to share services across a cluster,
- a standard efficient comprehensive approach to data and file storage  
and search,
- a simple approach to data access (which might be easier to use than  
the approach to data storage),
- standard and straightforward approach to authn and authz,
- cluster safety and scalability.

It shouldn't have any fixed UI.

It can look like a photo sharing service with file storage and  
appropriate widgets.

It can look like a project collaboration system if a wiki service and  
email are added.

It  begins to support Sakai functionality if you add service plugins  
that, say, provide APIs and implementations for course management,  
quizzes, announcements, calendar, presence, and other services.

It begins to actually look like an installation of Sakai when UX is  
added to access the services.


David Haines
CTools Developer
Digital Media Commons
University of Michigan
[hidden email]




On Jan 7, 2009, at 2:28 AM, Stephen Marquard wrote:

> One of the historical problems with Sakai is that the boundaries  
> between tools and tools and the framework have been _too_ strong,  
> i.e. the framework has not evolved to keep pace with demands from  
> tool writers, and the lack of appropriate shared services has led  
> tool authors to reinvent the wheel or implement tool/contrib code  
> for services which should be core.
>
> So the prospect of "outsourcing" the kernel brings with it the risk  
> of making this situation worse rather than better - designers and  
> tool authors could find a kernel that is doubly resistant to change,  
> i.e. less responsive.
>
> Regards
> Stephen
>
> >>> "Clay Fenlason" <[hidden email]> 01/06/09 4:52 PM >>>
>
> Some replies in-line below:
>
> On Tue, Jan 6, 2009 at 9:13 AM, Christopher D. Coppola
> <[hidden email]> wrote:
> > Do I understand that one key point for consideration is
> > whether we could reduce the overall effort our community is  
> responsible for
> > by relying on one or more other communities for Sakai's "Kernel?"  
> If I
> > understood correctly some of K2's key goals have been to do this by
> > leveraging more readily available components and frameworks and  
> reduce the
> > amount of Sakai-specific code. Your thought experiment seems to  
> take that a
> > bit further, if I'm understanding it, by "outsourcing" the  
> development of
> > the Kernel itself. Outsourcing probably isn't the right term because
> > presumably members of this community would be actively engaged in  
> the
> > project that took that on, but it wouldn't be the "responsibility"  
> of the
> > Sakai community per se.
>
> It would not be the exclusive responsibility of the Sakai community,
> right. It would hinge upon whether we might draw the right sort of
> boundary around the right body of code (whether it's what we currently
> think of as the "kernel" will merit some consideration, but I'll use
> the term for the sake of argument) that could attract other
> organizations and people to help develop and maintain it - perhaps by
> dovetailing with other open source projects, perhaps by attracting
> commercial affiliates who have an interest in alternative packagings
> that use similar services, and perhaps by better coordination with
> other community source projects in higher ed.
>
> If we can't attract that additional resource from other quarters, then
> the motivation for this sort of move largely falls apart. We'd be
> left with what the K2 project essentially is now, and a question of
> how to organize ourselves internally.
>
> I was imagining that those currently involved with Sakai's core
> services would continue to be, but to that extent under the umbrella
> of a different community; one more technically focused, with a product
> deliverable that takes tool and UI developers as its primary "users."
> Sakai service requirements would be surfaced, negotiated and addressed
> by dint of our engagement in this other community extending beyond
> ourselves, while at the same time we organize ourselves better and
> more directly around the academic mission.
>
> ~Clay
> ----------------------
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
> ) from the DG: Strategy & Advocacy site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.
>
>
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
> ) from the DG: Strategy & Advocacy site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.


----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Strategy & Advocacy site.
You can modify how you receive notifications at My Workspace > Preferences.
Kenneth Romeo Kenneth Romeo
Reply | Threaded
Open this post in threaded view
|

RE: Shifting our gravitational center

In reply to this post by Clay Fenlason

For me, Clay's comments were very encouraging.  Because of my limited
background with this project, I can't really comment on how much of a
gravitational shift is necessary or justified, and I have to take his word
for it that the ability to address user-facing functionality is where the
strength of this communities lies.  However, I do feel strongly that Sakai
3.0 is an opportunity to re-think the LMS and academic technology in
general, and this will involve serious consideration of the "user-facing
functionality".  And, although I am not a developer, I hope that I can find
some way to contribute to that effort.  

 

Maybe the things that LMSs do were revolutionary 10 years ago (15?), but now
just about anything online can upload documents, facilitate collaboration
and provide some boundaries.  I teach a series of classes for
non-matriculated students (in Continuing Studies) so I can't use our LMS,
but I use 2 pbwikis (one for administration, one for collaboration, for a
total of 4GB of storage), grandcentral and email and accomplish everything I
need.  In fact, grandcentral offers my students a telephone interface for an
audio response, which is something that Sakai hasn't even thought about yet
(but I have logged a feature request with our developers here!).

 

It is very valuable to talk about new ideas like social networking, but
there are any number of other things that could be included in future
versions Sakai, whether that is 3.0 or later.   Just to name a few:

 

1.       Mobile - All the end-of-the-year Future of Technology articles /
blogposts mention the growth of mobile applications.  We have a rather
surprising number of students with iPhones here on campus, and, more
importantly, the percentages are the highest of all in the freshman class:
the numbers aren't going to do anything but go up.

2.       Posting video - And I don't mean just a way to embed a YouTube
clip.  Students are more and more comfortable creating video, and some
courses here are accepting (even requiring) multimedia presentations for
assignments.  Video files are usually huge things that do not do well
uploading and downloading, especially for teachers who live off campus and
don't always have smokin' fast internet connections.  Why can't we have
something that automatically converts video files to streaming?  Why can't
there be something like YouTube in Sakai?  Flash Media Server includes
instructions for building something like this for free (almost) in their
sample applications.  The thing that is missing is the fine-grained
permissions, so that I can limit the viewers to just me and one student, or
share it with the whole class, or share it with the whole university.  

3.       Watching video - There is more than just listening going on.  I saw
a presentation here about some technology at scpd.stanford.edu that uses
time-stamps to allow the viewers to collaborate on note-taking,
question-raising and answer-proposing.  

4.       Testing - Go beyond the usual multiple choice / short answer / file
upload options.  In the languages we follow ACTFL proficiency guidelines
which are built around an Oral Proficiency Interview.  These are one-on-one
sessions that can last 30 minutes, so assessing each individual student can
be prohibitively time consuming.  So for the last 7 years we have done a
Simulated Oral Proficiency Interview that interfaced with CourseWork with
custom built software.  The next version will interface with Sakai and once
again we have been struck by how difficult this is to do:  Media must be
controlled so that it plays once and once only, recording must start and
stop automatically with no opportunity to pause, and the interview must move
on to the next item automatically with no chance for going back.  Simulating
a conversation like this is very difficult to do on the web, but something
that teachers need to do all the time.  

5.       Grades - And while we are on testing . why not put some item
analysis in there:  classical and maybe even some item response theory
number crunching.  Maybe even include pseudo-random draw based on the
performance on the previous question.  Tools for figuring out a curve,
custom graphing to *really* show students the point spread and arbitrary
curve on last week's physics test, comparisons to last year's items - yes,
items, not assignments.  This is what computers are good at, isn't it?
We've got the databases right?  This involves an extended concept of
question pools, which might be another candidate for open education.

6.       Privacy - Helping faculty and staff comply with data security
regulations.  In a sense, universities have been doing cloud computing for
years, with unix systems.  Learning management systems are quite similar in
that students can access them anywhere and securely store their data.  For
this reason, I tell the instructors I work with that our LMS is the best way
they can avoid FERPA violations:   If they just leave student work, rosters
and grades on the LMS, then it is not on their laptops and there is less to
worry about if those go missing or get stolen.  Are there other ways that we
can use this?  Can we work with the various IRBs to make sure that the LMS
can be a place to store human subjects data?

7.       Research data collection - Start with psychology.  Researchers use
software to collect data from one subject at a time:  sets of responses,
reaction time, etc.  Wouldn't it be cool if they could do that with a whole
classroom of subjects?  Wouldn't it be cool if the experiment was a part of
a pedagogically valid activity?  At the very least, make data collection via
a flash application (maybe in the SCORM player?) possible, and you will get
a whole new group of people interested in using LMSs.

8.       Indexing and search - I am at a disadvantage here, because the
version of Sakai we are using at Stanford does not have any such
capabilities (to speak of).  So maybe a later version has it, but how
efficiently can you filter?  Can I find all documents by a certain student?
Can I find all instances of a certain word?  How about logging?  Can we find
which departments have been posting more materials over the last year?  Can
we compare student or instructor time on task over time between departments
and even assignments?  If we want to justify budgets for investing in Sakai,
then we need to provide detailed numbers showing that it is both being used
and being used effectively.

9.       In-class activities - This is what my language learning example
(http://www.stanford.edu/~kenro/essays/Sakai3ProposalComments.html) was
about.  Yes, it is very specific, but the issue is that we need to think
about what people do in classrooms, as separate from homework, as separate
from distance learning.  What can technology do for us in the classroom
beyond projecting PowerPoint?

10.   Self-study - This is where the open education topic has application
for me.  It has been useful for me to start to think about activities that
students can do on their own as opposed to activities that I would lead as a
teacher.  With the 24/7 availability of the web, I have realized that I can
and should provide my students with material that they can study on their
own.  In the past, this used to be part of the class, and teachers would use
it when they had time.  But if we put it online, then the more ambitious
students can take advantage of it whenever they want.  However, this should
be combined with some sort of learner training for *all* students, to make
sure that they know how to efficiently use the resources available to them.
This learner training is not yet fully explored, but I am working on a
colleague here with some techniques for language learners (come see us at
CALICO).

11.   Interoperability - Can this connect to other applications?  Is there
some way to have it interface with Matlab, or whatever the science students
use?  How about the design and debugging software that the EE or CS students
use?  Can linguists draw their tree diagrams somehow?  What would even be a
useful form for instructors in these departments to get the work their
students produce?  And is there a way to facilitate collaboration between
professors who don't just create text documents?

 

Maybe these are already being seriously considered for Sakai, or maybe they
are specific to my field, but my point is not the details but the direction.
I would argue that the one of the most important tasks in front of us is to
start surveying various fields and trying to think seriously about how
technology can really change the way that we teach and learn.  The LMS of
tomorrow should not just be a replacement for what has been done on paper,
but a way to facilitate and even foster the innovation of teachers.  I
cannot stress this enough:  the goal is not just to facilitate instruction,
but to facilitate innovation.

 

Finally, Ray's point about making it clear who is jumping to whose tune is
important.  One important implication in the Sakai 3.0 proposal was
usability.  However, I think this should be expanded so that usability
really has an established place in the Sakai project.  I had the opportunity
to talk with oa user experience engineer at Google who explained why their
products are just so easy to use:  they run every imaginable user test on
them, including eye-tracking and at-home observations.  We can't really
expect to be able to do that with Sakai, but if we are honest, our users
have come to expect that kind of usability from anything they use online.
Some sort of standards should be set out for testing the kernel and tools
before they reach schools that will depend on them.  So perhaps I am saying
that that the user experience side *should* call the tune, if for no other
reason than the fact that the people who decide the budgets to give to Sakai
related projects are usually strongly influenced by user-facing
functionality.

 

Ken Romeo

 

[http://www.stanford.edu/people/kenro]

Academic Technology Specialist [http://ats.stanford.edu]

Stanford Language Center [http://language.stanford.edu]

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Clay
Fenlason
Sent: Monday, January 05, 2009 10:29 AM
To: [hidden email]
Subject: Shifting our gravitational center

 

In the last 9 months or so, particularly following the emergence of
the ambitious 3akai and K2 initiatives, a fair bit of energy and
thought has gone toward how difficult it is for our collaboration to
achieve large aims. It's a frequent theme of the discussions between
managers, and has also become a pivot of Board discussion in how to
drive toward a Sakai 3.

The tilt of these discussions has been toward how we can rally deeper
commitments while better structuring the coordination of our
resources, and with good reason. Such measures need to be taken. But
I have had the nagging feeling throughout that we are not attending
closely enough to the lessons of the last couple years if that's as
far as we go. Open source products have succeeded to the extent that
they have harnessed the expertise and passions of their contributors,
and we've not been playing to our strengths in these areas.

I begin with the observation that a great deal of our resource is
still consumed by essentially technical problems. At the same time
our pool of development resource has grown in the area of tool
development (as echoed by the number of new tools and tool rewrites),
while our resource devoted to core services has remained fairly
static, and may even have shrunk. This is not really due to shifting
areas of concern as the underlying services have matured, for
stability, scalability and reliability have been real pain points for
deploying institutions over this period. I am of the opinion that
there are simply limits to the "bench depth" that our institutions can
attract and retain (let alone apply to eLearning problem spaces) when
it comes to Java service architectures.

I follow with the observation that our core services are really of
general interest. They are certainly not exclusive to the LMS/VLE,
but neither are they exclusive to higher ed. Witness recent
discussions on content, or note how much Sakai's service needs overlap
with fledgling Apache projects (Sling and Shindig, to name a couple
from the K2 investigations) or Kuali services.

To this I might also add relatively recent successes in loosening the
coupling of the backing logic and the UX. We are on the cusp of a
future where Sakai functionality may be easily produced without
knowing Java at all. Even in its "legacy" state Sakai could be
re-packaged in a variety of flavors, ranging from the portfolio system
to the VRE - how much more so will this be the case when K2 provides
data APIs that afford an even greater proliferation of user-facing
functionality?

And it's in that user-facing functionality, addressing the needs of a
breadth of requirements for varying pedagogies, learning styles,
curricula, research collaborations, etc., where our community's real
strength lies. That is our proper focus, our core mission, and what
we can best coordinate around.

So I'm proposing a thought experiment, before attempting to work out
practical steps. Imagine that the Sakai Foundation were focused almost
entirely on a user-facing product, an assemblage of tools and a
user experience packaged as the Sakai release, which nevertheless took
its underlying services largely for granted. To string the fantasy
out further, imagine that the "kernel" (those core services, whatever
we determine them to be) were a single Apache project, that its APIs
were well documented and its services could be developed against with
PHP-level skills in a RESTful way; Sakai releases would then simply be
a higher-ed-focused packaging of capability riding on top of this
loosely-coupled kernel.

How would that change our community? How would it change the
conversation and the activity? How would it change our resource
issues and the coordination questions around them? What new resources
might be brought productively to bear, and in what new configurations?
How would it change our relationship to other higher ed community
source projects? How would it change our relationship to other open
source projects outside higher ed?

Would it change how you think about Sakai?

--
Clay Fenlason
Director, Educational Technology
Georgia Institute of Technology
(404) 385-6644

  _____  


This automatic notification message was sent by Sakai Collab
(https://collab.sakaiproject.org//portal
<https://collab.sakaiproject.org/portal> ) from the DG: Strategy & Advocacy
site.
You can modify how you receive notifications at My Workspace > Preferences.


----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Strategy & Advocacy site.
You can modify how you receive notifications at My Workspace > Preferences.
Michael Korcuska Michael Korcuska
Reply | Threaded
Open this post in threaded view
|

Re: Shifting our gravitational center

In reply to this post by Clay Fenlason

I just added an entry to my blog that relates to this thread....since
the thread itself has changed focus a bit I thought I would respond to
the originating message instead of the most recent:

http://sakaiblog.korcuska.net/2009/01/13/sakai-board-retreat/


On Mon, Jan 5, 2009 at 7:28 PM, Clay Fenlason
<[hidden email]> wrote:

> In the last 9 months or so, particularly following the emergence of
> the ambitious 3akai and K2 initiatives, a fair bit of energy and
> thought has gone toward how difficult it is for our collaboration to
> achieve large aims. It's a frequent theme of the discussions between
> managers, and has also become a pivot of Board discussion in how to
> drive toward a Sakai 3.
>
> The tilt of these discussions has been toward how we can rally deeper
> commitments while better structuring the coordination of our
> resources, and with good reason. Such measures need to be taken. But
> I have had the nagging feeling throughout that we are not attending
> closely enough to the lessons of the last couple years if that's as
> far as we go. Open source products have succeeded to the extent that
> they have harnessed the expertise and passions of their contributors,
> and we've not been playing to our strengths in these areas.
>
> I begin with the observation that a great deal of our resource is
> still consumed by essentially technical problems. At the same time
> our pool of development resource has grown in the area of tool
> development (as echoed by the number of new tools and tool rewrites),
> while our resource devoted to core services has remained fairly
> static, and may even have shrunk. This is not really due to shifting
> areas of concern as the underlying services have matured, for
> stability, scalability and reliability have been real pain points for
> deploying institutions over this period. I am of the opinion that
> there are simply limits to the "bench depth" that our institutions can
> attract and retain (let alone apply to eLearning problem spaces) when
> it comes to Java service architectures.
>
> I follow with the observation that our core services are really of
> general interest. They are certainly not exclusive to the LMS/VLE,
> but neither are they exclusive to higher ed. Witness recent
> discussions on content, or note how much Sakai's service needs overlap
> with fledgling Apache projects (Sling and Shindig, to name a couple
> from the K2 investigations) or Kuali services.
>
> To this I might also add relatively recent successes in loosening the
> coupling of the backing logic and the UX. We are on the cusp of a
> future where Sakai functionality may be easily produced without
> knowing Java at all. Even in its "legacy" state Sakai could be
> re-packaged in a variety of flavors, ranging from the portfolio system
> to the VRE - how much more so will this be the case when K2 provides
> data APIs that afford an even greater proliferation of user-facing
> functionality?
>
> And it's in that user-facing functionality, addressing the needs of a
> breadth of requirements for varying pedagogies, learning styles,
> curricula, research collaborations, etc., where our community's real
> strength lies. That is our proper focus, our core mission, and what
> we can best coordinate around.
>
> So I'm proposing a thought experiment, before attempting to work out
> practical steps. Imagine that the Sakai Foundation were focused almost
> entirely on a user-facing product, an assemblage of tools and a
> user experience packaged as the Sakai release, which nevertheless took
> its underlying services largely for granted. To string the fantasy
> out further, imagine that the "kernel" (those core services, whatever
> we determine them to be) were a single Apache project, that its APIs
> were well documented and its services could be developed against with
> PHP-level skills in a RESTful way; Sakai releases would then simply be
> a higher-ed-focused packaging of capability riding on top of this
> loosely-coupled kernel.
>
> How would that change our community? How would it change the
> conversation and the activity? How would it change our resource
> issues and the coordination questions around them? What new resources
> might be brought productively to bear, and in what new configurations?
> How would it change our relationship to other higher ed community
> source projects? How would it change our relationship to other open
> source projects outside higher ed?
>
> Would it change how you think about Sakai?
>
> --
> Clay Fenlason
> Director, Educational Technology
> Georgia Institute of Technology
> (404) 385-6644
> ________________________________
> This automatic notification message was sent by Sakai Collab
> (https://collab.sakaiproject.org//portal) from the DG: Strategy & Advocacy
> site.
> You can modify how you receive notifications at My Workspace > Preferences.
>
----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Strategy & Advocacy site.
You can modify how you receive notifications at My Workspace > Preferences.