Response to Clay's "Outsource" Post...

classic Classic list List threaded Threaded
5 messages Options
Dr. Chuck Dr. Chuck
Reply | Threaded
Open this post in threaded view
|

Response to Clay's "Outsource" Post...


I also have this response in my blog at:

http://www.dr-chuck.com/csev-blog/000582.html

Here is the content:

Now that the first day of class is over, I have a few minutes to  
respond to Clay's recent advocacy post. To me there are several themes  
in the post that I want to react to. Clay implies:

- Things are not working so well in the Sakai community - so we should  
think outside the box and entertain the notion of radically different  
approaches to how we do things.

- It seems as though our coordination is not working so well - we just  
can't seem to muster enough resources to accomplish board initiatives  
in a timely manner. So perhaps we need a different form of government  
- perhaps more like Kuali where the Kuali Board (or sub-boards) *own*  
resources.

- Since we are not so good at board initiatives, perhaps we should  
outsource the Kernel work to a better organized group like Kuali Rice  
or Spring and focus on making really cool widgets on the Rice  
infrastructure.

I will respond to each in turn.

First, the Sakai community is very healthy.  There are a few weak  
spots- but 95% of the open source projects would give their right arm  
to have half what Sakai has.  Let me list the bright spots: (1)  
Running in production at 200 schools, (2) 1-1.5 million *daily* users  
of the product, (4) an amazingly productive developer community (83  
commits in the last 12 hours), a list of the "who's who" of top  
schools in the world involved deeply in Sakai, (5) 2-5-x is a very  
strong release - it has good performance and great reliability - all  
we need is some functional improvements and we will be finally on-par  
with the leading commercial products,  (6) we have a wonderful array  
of commercial affiliates who provide a wide range of relevant services  
that basically kick the pants off most commercial offerings in terms  
of the diversity of the kinds of services you can pay for if a school  
cannot do the work themselves.

Let me elaborate as to the *range* of commercial services.  We have a  
series of "boutique ASPs for Sakai" - LongSight, Etudes, Potfolio4U -  
these ASPs give far more than just software and hardware - they help  
organizations truly apply and contextualize Sakai - by training,  
configuration, etc.  We have rSmart that is working to scale our  
community by adding value to the Sakai releases and improving  
documentation  and packaging. We have CampusEAI who provides Sakai as  
part of a full suite of outsourcable campus IT. We have innovative  
development commercial companies like Unicon, Edia and Psybergate who  
have the community credibility to work right in the trunk of the  
product on things like Offline Sakai or Terracotta.  Oracle *and* IBM  
have roadmaps that have Sakai as part of their long-term strategy! The  
diversity and sophistication of our commercial partners approaches are  
wonderful and the options available to those would rather buy than  
build already are far better than *any* commercial product.

I am not saying our functionality is universally better (yet) - I am  
simply saying that those who would pay for services have a nearly  
ideal array of service choices from which to choose from. BlackBoard  
customers would kill to have these kinds of service choices. An open  
market allows diversity to evolve to meet all the shapes of customer  
demand - something that a centrally managed organization like  
BlackBoard will find it very hard to ever emulate.

In terms of "coordination not working so well", I completely  
disagree.  We have very high levels of commits and amazing levels of  
community support which insures extremely solid and up-to-date  
branches for the past two years of releases.  This is all done in a  
highly coordinated and efficient manner.  We are both innovating and  
expanding rapidly and yet paying very close attention to maintaining  
production quality releases for the last two versions - giving out  
community a lot of flexibility in timing their upgrades.  This  
attention to detail is not fun work - and yet it is done  
professionally and with tremendous care and attention to detail.  
Members of our community are willing to take plenty of responsibility  
and follow through for several years of service to the greater good.

You complain about the community not rallying around board initiatives  
- this is completely not true.  Here are some examples:

Board Initiative 2005: Integrate OSP into Sakai - this board  
initiative took a *lot* of resources and continues to do so. In 2005,  
the OSP software was pretty non-functional.  For the past three years  
5-6 FTE have been working on OSP to make its basic functionality  
usable.  This may have not been the wisest resource investment - but  
it was a board initiative - the community is pouring resources in  
trying to make it a success one way or another because folks believe  
in the importance of portfolios to us.

Board Initiative 2006: Improve performance, fix data models, reduce  
session usage, and fix Samigo - there have been 3-5 FTEs working on  
this board initiative and real significant progress has been made in  
all areas.

Board Initiative 2007: Fix the User Interface - Again there have been  
about 2-3 FTEs working on this since the initiative was started.  
Sometimes the improvements are small and localized improvements to a  
single tool and sometimes they are grand experiments like the  
Cambridge flat portal which is the inspiration for Sakai 3.

Board Initiative 2008: Move to a Kernel + tools architecture and  
replace content with Jackrabbit.   This has had 2-3 dedicated FTEs  
working for about two years and if all goes well, it will be in  
production in September 2009 - rocket speed progress for such  
innovative software development.

So perhaps the reason that folks don't "drop everything" to work on  
the next big thing is that they are busy finishing detail work on the  
"last big thing".

The board simply needs to be more patient - you can rest assured that  
resources are being invested wisely - this is the magic of open  
source.  By allowing some central strategic guidance but having local  
tactical management - we have far more overall talent applied to the  
problem and decisions get made closer to the problem so the decisions  
are better.

Open source not is predicable in the short term - but in the long term  
it nearly always makes the right decisions about directions and  
priorities.  I can imagine that it is frustrating to the board to be  
meeting all the time and coming up with lots of "great ideas" and then  
not seeing folks immediately switch to the new idea.  In crowd-sourced  
situations - the crowd is best at *evaluating* amongst many good ideas  
- particularly when the crowd is diverse and has something at stake.  
This maps perfectly to the Sakai community - we have many sources of  
possible good ideas and about 150 smart people in the community who  
examine the ideas, prioritize, and assign resources.

You have to understand that it is *not* the board's job to discern the  
good ideas from the bad ideas and make the final go/no-go decision -  
this is the function of the whole community.  The board is just one of  
many sources of possible good ideas.  So as a board member - you have  
to be prepared to face the fact that a board idea may just be a bad  
idea. Good ideas get legs - bad ideas are quietly ignored.

Speaking of bad ideas, that brings me to my last point.  The notion  
that we can't build a kernel fast enough for your tastes so we should  
just take something from Kuali such as Rice and start over.  Sakai  
would focus on making cute bits of JavaScript and HTML while Kuali  
does the heavy lifting.

This idea has a high probability of being "bad".  My guess is that you  
and the rest of the board members know very little about Kuali  
technically and never have downloaded the software - not looked it in  
detail - not tried to pull out bits of Kuali and see if they really  
operate in a stand alone mode.  What you say "sounds good" - and as  
long as there is no real detail - it sounds great.

Lets turn this around and say I was on the Kuali board and proposed  
that Kuali use Sakai's ContentHosting capabilities to store blobs in  
Kuali.  After all Sakai is a popular LMS that scales nicely and  
Sakai's Content Hosting has decent support for metadata.  So why not  
just pull ContentHosting out of Sakai (and the Resources Tool) and  
reuse it in Kuali!  Of course because *you know the detail* of Sakai's  
ContentHosting - so you know just how much pain and what a complete  
waste of time integrating Sakai's ContentHosting into Kuali would be.  
But it might sound good to a Kuali board member interested in saving  
the development costs of their own repositiory and resources tool.

Don't get me wrong - I *am* a fan of integrating external software and  
throwing away our "invented here" code to much as is practical -  
particularly when there is a maintenance win in addition to an initial  
development win.  I have been a fan of Jackrabbit for nearly five  
years now.  Jackrabbit is a nearly perfect solution to solve content  
hosting for Sakai and already factored to be a "plug in" for another  
application.

So why has it taken three years for the "perfect fit" Jackrabbit to  
replace Sakai ContentHosting+Dav and we are still not done?  Because  
there are a *lot* of details.   In a board meeting with mostly  
managers - the details are not foremost in the minds of board  
members.  They just fall in love with the "headline" without thinking  
about the consequences or difficulty or flow time involved of the  
proposed idea.

In order to truly understand Jackrabbit, the Sakai community needed to  
take a detour and get deeply involved in Jackrabbit - to learn about  
the software, its conventions, community, experiment with the  
software, and internalize its its tacit roadmap.   Sakai now has folks  
who are contributors to Jackrabbit, Shindig, and Pluto - this is good  
because we can see these products for what they are and make sure that  
the needs of our application are met in these products - so they are  
suitable for integration.  The lead committer on Pluto is now also the  
lead committer for uPortal. This kind of cross-polination insures that  
tacit and explicit roadmaps are well aligned - it often takes several  
years for these things to line up.

You are proposing to outsource *the entire kernel* to folks interested  
in credits and debits.   Perhaps to you, the kernel is a trivial thing  
- but even though we love decoupling of software - we cannot tolerate  
an impedance mismatch between tools and kernel.  So the only decent  
way for them to progress in a satisfactory manner is for them to co--
evolve.  Once the APIs are well known and capture the nature of the  
interactions between tool and kernel - then the kernel implementation  
can be smoothly altered without any impact to the tools.  Hmmm - this  
is how we are doing the transition from Sakai 2.4 to Sakai 3.0 - a  
finely crafted multi-year effort that is progressing well.

But apparently not fast enough for you and the board - since you want  
to give up and outsource this to Kuali.

Actually, I think that as the Sakai Kernel progresses properly, Kuali  
Student might be wise to adopt the Sakai kernel as the base of part of  
its application.  Interestingly given the maturity of both projects -  
Sakai is in a *far better* position to make good decisions w.r.t. the  
kernel - because we are in heavy and at times painful production - we  
will test the heck out of any new kernel to make sure that performance  
does not backslide.  If things go well in 2 or so years - you might  
find a number of projects using the Sakai kernel as their base  
software. DSpace and Sakai may be finding ways to quietly share code  
its in the next generation of both products - this is not trivial work  
but with deep linking of the two communities and the growth of trust  
and respect - some truly innovative and efficient things might just  
happen.

In summary, I think that your concern comes from a simple  
misunderstanding of the notion of open source.  You think that the  
Sakai Board is the "Government" for the Sakai community.  You think  
that we have chosen and elected a "parliament" who will make laws that  
will be enforced for the health and safety of all.  In this metaphor,  
I am just a grouchy backbencher :) The Sakai Board is not Sakai  
Parliament and Michael is not the Sakai Prime Minister - I always am a  
noisy backbencher - even at the UM School of Information Curriculum  
Committee meetings.

According to "The Wisdom of Crowds", the aggregate decisions made by  
crowds are far more intelligent and informed than any expert or small  
group of experts.  There are important things that make crowds wise:  
(1) distribution, (2) diversity, (3) reasonably large number of  
people, (4) independence of thinking, (5) independence of information  
context and (6) not making an attempt to find a least common  
denominator make everyone happy.  What is needed is to figure the  
average of the independent efforts - not discuss endlessly down to a  
single compromise choice.

The Sakai Community is an ideal "wise crowd" - we are distributed  
geographically, we have many cultures, we are made up of many  
different kinds of people who come from any different professions, we  
only get together once or so per year - so we are pretty independent  
thinkers, and we are not afraid to disagree sometimes - and go our  
separate ways for a little while when we cannot agree.  These are the  
necessary prerequisites for the wisest of crowds.

The Sakai board on the other hand is a very small number of people,  
most of whom are managers.  The board meets and talks a lot and works  
toward single grand compromises that the board calls "initiatives".  
The board is not confrontational - everyone is civil - people who  
disagree with board discussions often are nice and polite - no need to  
be rude of course.  As a result - the board is a perfect example of a  
"unwise crowd" that is likely to make less wise decisions on the  
average.

On the other hand if you keep reading the "Wisdom of Crowds" (which  
required reading in one of my classes this semester because I like the  
book so much), you find that there is a purpose for a smaller group in  
a community like Sakai.  It turns out that the large crowds of  
independent thinkers are not so good at forming a short list of  
possible choices.  Since the large crowd often has just too many ideas  
- they don't converge on thinking up the 4-5 possible things we might  
do "next".

This is where the small group comes in.  The small group produces the  
set of possible ideas because that is what small groups do well.  Then  
the large group is very very good at sifting through the ideas and  
picking the good ones and discarding the bad ones.

Come to think of it - this is how Sakai has operated for nearly six  
years and gone from a nothing - to a significant market force.

So in while your picture sounds pretty glum as if drastic  
organizational change is needed,  I have the complete opposite view -  
the community and our software quality are the best they have ever  
been.  We are effectively working on a host of little things that are  
important to the community and making good slow and steady progress on  
several very important and complex long-term market-changing  
initiatives.    And the board continues to present visionary ideas to  
the community - which is exactly what it should be doing.  If the  
board could accept the notion that not all board ideas are great ideas  
- and sometimes ideas take a long time to implement those ideas - then  
things would not seem so glum to the board members.

Hey send me your iTunes account and I will gift you the Audio book of  
"Wisdom of Crowds" - you really only need to listen to the first two  
hours (Chapters 1-4) - it will cheer you up and leave you feeling damn  
proud of a community that you and GA Tech can take a lot of credit for  
for.


----------------------
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: Response to Clay's "Outsource" Post...


You've recoiled a bit from the negative formulation of my post, and
I'm afraid this has led you to react against a position in which I
can't recognize a view I actually hold.  You may be making a good
argument against someone; I just don't know who that person is.  Some
of that I'll blame on my own proclivities:  a critical frame of mind,
and a tendency to find bracing clarity in starker terms.

But rather than try to chisel through all the misunderstandings, let
me instead suggest another, more charitable way to take my thought
experiment, one which sees past my personal failings and tries to take
it as simply stated:  no matter what train of thought, morbid or
otherwise, led me to that picture of the future, might it not still
represent a move into even greater health and success?  We are the
best we've ever been.  We may yet be better, and other open source
communities better along with us.  Can I not believe both, and try to
think about what a better future might look like?

I'd welcome any further thoughts on why what I've sketched in the air
could leave us better or worse off.  We've heard some good thoughts on
both sides already.  I am sincere in taking this discussion as a guide
to my own thinking.

~Clay

On Fri, Jan 9, 2009 at 9:13 AM, csev <[hidden email]> wrote:

> I also have this response in my blog at:
>
> http://www.dr-chuck.com/csev-blog/000582.html
>
> Here is the content:
> Now that the first day of class is over, I have a few minutes to respond to
> Clay's recent advocacy post. To me there are several themes in the post that
> I want to react to. Clay implies:
>
> - Things are not working so well in the Sakai community - so we should think
> outside the box and entertain the notion of radically different approaches
> to how we do things
>
> - It seems as though our coordination is not working so well - we just can't
> seem to muster enough resources to accomplish board initiatives in a timely
> manner. So perhaps we need a different form of government - perhaps more
> like Kuali where the Kuali Board (or sub-boards) *own* resources.
>
> - Since we are not so good at board initiatives, perhaps we should outsource
> the Kernel work to a better organized group like Kuali Rice or Spring and
> focus on making really cool widgets on the Rice infrastructure.
>
> I will respond to each in turn.
>
> First, the Sakai community is very healthy.  There are a few weak spots- but
> 95% of the open source projects would give their right arm to have half what
> Sakai has.  Let me list the bright spots: (1) Running in production at 200
> schools, (2) 1-1.5 million *daily* users of the product, (4) an amazingly
> productive developer community (83 commits in the last 12 hours), a list of
> the "who's who" of top schools in the world involved deeply in Sakai, (5)
> 2-5-x is a very strong release - it has good performance and great
> reliability - all we need is some functional improvements and we will be
> finally on-par with the leading commercial products,  (6) we have a
> wonderful array of commercial affiliates who provide a wide range of
> relevant services that basically kick the pants off most commercial
> offerings in terms of the diversity of the kinds of services you can pay for
> if a school cannot do the work themselves
>
> Let me elaborate as to the *range* of commercial services.  We have a series
> of "boutique ASPs for Sakai" - LongSight, Etudes, Potfolio4U - these ASPs
> give far more than just software and hardware - they help organizations
> truly apply and contextualize Sakai - by training, configuration, etc.  We
> have rSmart that is working to scale our community by adding value to the
> Sakai releases and improving documentation  and packaging. We have CampusEAI
> who provides Sakai as part of a full suite of outsourcable campus IT. We
> have innovative development commercial companies like Unicon, Edia and
> Psybergate who have the community credibility to work right in the trunk of
> the product on things like Offline Sakai or Terracotta.  Oracle *and* IBM
> have roadmaps that have Sakai as part of their long-term strategy! The
> diversity and sophistication of our commercial partners approaches are
> wonderful and the options available to those would rather buy than build
> already are far better than *any* commercial product.
>
> I am not saying our functionality is universally better (yet) - I am simply
> saying that those who would pay for services have a nearly ideal array of
> service choices from which to choose from. BlackBoard customers would kill
> to have these kinds of service choices. An open market allows diversity to
> evolve to meet all the shapes of customer demand - something that a
> centrally managed organization like BlackBoard will find it very hard to
> ever emulate.
>
> In terms of "coordination not working so well", I completely disagree.  We
> have very high levels of commits and amazing levels of community support
> which insures extremely solid and up-to-date branches for the past two years
> of releases.  This is all done in a highly coordinated and efficient manner.
>  We are both innovating and expanding rapidly and yet paying very close
> attention to maintaining production quality releases for the last two
> versions - giving out community a lot of flexibility in timing their
> upgrades.  This attention to detail is not fun work - and yet it is done
> professionally and with tremendous care and attention to detail.  Members of
> our community are willing to take plenty of responsibility and follow
> through for several years of service to the greater good.
>
> You complain about the community not rallying around board initiatives -
> this is completely not true.  Here are some examples:
>
> Board Initiative 2005: Integrate OSP into Sakai - this board initiative took
> a *lot* of resources and continues to do so. In 2005, the OSP software was
> pretty non-functional.  For the past three years 5-6 FTE have been working
> on OSP to make its basic functionality usable.  This may have not been the
> wisest resource investment - but it was a board initiative - the community
> is pouring resources in trying to make it a success one way or another
> because folks believe in the importance of portfolios to us.
>
> Board Initiative 2006: Improve performance, fix data models, reduce session
> usage, and fix Samigo - there have been 3-5 FTEs working on this board
> initiative and real significant progress has been made in all areas.
>
> Board Initiative 2007: Fix the User Interface - Again there have been about
> 2-3 FTEs working on this since the initiative was started.  Sometimes the
> improvements are small and localized improvements to a single tool and
> sometimes they are grand experiments like the Cambridge flat portal which is
> the inspiration for Sakai 3.
>
> Board Initiative 2008: Move to a Kernel + tools architecture and replace
> content with Jackrabbit.   This has had 2-3 dedicated FTEs working for about
> two years and if all goes well, it will be in production in September 2009 -
> rocket speed progress for such innovative software development.
>
> So perhaps the reason that folks don't "drop everything" to work on the next
> big thing is that they are busy finishing detail work on the "last big
> thing".
>
> The board simply needs to be more patient - you can rest assured that
> resources are being invested wisely - this is the magic of open source.  By
> allowing some central strategic guidance but having local tactical
> management - we have far more overall talent applied to the problem and
> decisions get made closer to the problem so the decisions are better.
>
> Open source not is predicable in the short term - but in the long term it
> nearly always makes the right decisions about directions and priorities.  I
> can imagine that it is frustrating to the board to be meeting all the time
> and coming up with lots of "great ideas" and then not seeing folks
> immediately switch to the new idea.  In crowd-sourced situations - the crowd
> is best at *evaluating* amongst many good ideas - particularly when the
> crowd is diverse and has something at stake.  This maps perfectly to the
> Sakai community - we have many sources of possible good ideas and about 150
> smart people in the community who examine the ideas, prioritize, and assign
> resources.
>
> You have to understand that it is *not* the board's job to discern the good
> ideas from the bad ideas and make the final go/no-go decision - this is the
> function of the whole community.  The board is just one of many sources of
> possible good ideas.  So as a board member - you have to be prepared to face
> the fact that a board idea may just be a bad idea. Good ideas get legs - bad
> ideas are quietly ignored.
>
> Speaking of bad ideas, that brings me to my last point.  The notion that we
> can't build a kernel fast enough for your tastes so we should just take
> something from Kuali such as Rice and start over.  Sakai would focus on
> making cute bits of JavaScript and HTML while Kuali does the heavy lifting.
>
> This idea has a high probability of being "bad".  My guess is that you and
> the rest of the board members know very little about Kuali technically and
> never have downloaded the software - not looked it in detail - not tried to
> pull out bits of Kuali and see if they really operate in a stand alone mode.
>  What you say "sounds good" - and as long as there is no real detail - it
> sounds great.
>
> Lets turn this around and say I was on the Kuali board and proposed that
> Kuali use Sakai's ContentHosting capabilities to store blobs in Kuali.
>  After all Sakai is a popular LMS that scales nicely and Sakai's Content
> Hosting has decent support for metadata.  So why not just pull
> ContentHosting out of Sakai (and the Resources Tool) and reuse it in Kuali!
>  Of course because *you know the detail* of Sakai's ContentHosting - so you
> know just how much pain and what a complete waste of time integrating
> Sakai's ContentHosting into Kuali would be.  But it might sound good to a
> Kuali board member interested in saving the development costs of their own
> repositiory and resources tool.
>
> Don't get me wrong - I *am* a fan of integrating external software and
> throwing away our "invented here" code to much as is practical -
> particularly when there is a maintenance win in addition to an initial
> development win.  I have been a fan of Jackrabbit for nearly five years now.
>  Jackrabbit is a nearly perfect solution to solve content hosting for Sakai
> and already factored to be a "plug in" for another application.
>
> So why has it taken three years for the "perfect fit" Jackrabbit to replace
> Sakai ContentHosting+Dav and we are still not done?  Because there are a
> *lot* of details.   In a board meeting with mostly managers - the details
> are not foremost in the minds of board members.  They just fall in love with
> the "headline" without thinking about the consequences or difficulty or flow
> time involved of the proposed idea.
>
> In order to truly understand Jackrabbit, the Sakai community needed to take
> a detour and get deeply involved in Jackrabbit - to learn about the
> software, its conventions, community, experiment with the software, and
> internalize its its tacit roadmap.   Sakai now has folks who are
> contributors to Jackrabbit, Shindig, and Pluto - this is good because we can
> see these products for what they are and make sure that the needs of our
> application are met in these products - so they are suitable for
> integration.  The lead committer on Pluto is now also the lead committer for
> uPortal. This kind of cross-polination insures that tacit and explicit
> roadmaps are well aligned - it often takes several years for these things to
> line up.
>
> You are proposing to outsource *the entire kernel* to folks interested in
> credits and debits.   Perhaps to you, the kernel is a trivial thing - but
> even though we love decoupling of software - we cannot tolerate an impedance
> mismatch between tools and kernel.  So the only decent way for them to
> progress in a satisfactory manner is for them to co--evolve.  Once the APIs
> are well known and capture the nature of the interactions between tool and
> kernel - then the kernel implementation can be smoothly altered without any
> impact to the tools.  Hmmm - this is how we are doing the transition from
> Sakai 2.4 to Sakai 3.0 - a finely crafted multi-year effort that is
> progressing well.
>
> But apparently not fast enough for you and the board - since you want to
> give up and outsource this to Kuali.
>
> Actually, I think that as the Sakai Kernel progresses properly, Kuali
> Student might be wise to adopt the Sakai kernel as the base of part of its
> application.  Interestingly given the maturity of both projects - Sakai is
> in a *far better* position to make good decisions w.r.t. the kernel -
> because we are in heavy and at times painful production - we will test the
> heck out of any new kernel to make sure that performance does not backslide.
>  If things go well in 2 or so years - you might find a number of projects
> using the Sakai kernel as their base software. DSpace and Sakai may be
> finding ways to quietly share code its in the next generation of both
> products - this is not trivial work but with deep linking of the two
> communities and the growth of trust and respect - some truly innovative and
> efficient things might just happen.
>
> In summary, I think that your concern comes from a simple misunderstanding
> of the notion of open source.  You think that the Sakai Board is the
> "Government" for the Sakai community.  You think that we have chosen and
> elected a "parliament" who will make laws that will be enforced for the
> health and safety of all.  In this metaphor, I am just a grouchy backbencher
> :) The Sakai Board is not Sakai Parliament and Michael is not the Sakai
> Prime Minister - I always am a noisy backbencher - even at the UM School of
> Information Curriculum Committee meetings.
>
> According to "The Wisdom of Crowds", the aggregate decisions made by crowds
> are far more intelligent and informed than any expert or small group of
> experts.  There are important things that make crowds wise: (1)
> distribution, (2) diversity, (3) reasonably large number of people, (4)
> independence of thinking, (5) independence of information context and (6)
> not making an attempt to find a least common denominator make everyone
> happy.  What is needed is to figure the average of the independent efforts -
> not discuss endlessly down to a single compromise choice.
>
> The Sakai Community is an ideal "wise crowd" - we are distributed
> geographically, we have many cultures, we are made up of many different
> kinds of people who come from any different professions, we only get
> together once or so per year - so we are pretty independent thinkers, and we
> are not afraid to disagree sometimes - and go our separate ways for a little
> while when we cannot agree.  These are the necessary prerequisites for the
> wisest of crowds.
>
> The Sakai board on the other hand is a very small number of people, most of
> whom are managers.  The board meets and talks a lot and works toward single
> grand compromises that the board calls "initiatives".  The board is not
> confrontational - everyone is civil - people who disagree with board
> discussions often are nice and polite - no need to be rude of course.  As a
> result - the board is a perfect example of a "unwise crowd" that is likely
> to make less wise decisions on the average.
>
> On the other hand if you keep reading the "Wisdom of Crowds" (which required
> reading in one of my classes this semester because I like the book so much),
> you find that there is a purpose for a smaller group in a community like
> Sakai.  It turns out that the large crowds of independent thinkers are not
> so good at forming a short list of possible choices.  Since the large crowd
> often has just too many ideas - they don't converge on thinking up the 4-5
> possible things we might do "next".
>
> This is where the small group comes in.  The small group produces the set of
> possible ideas because that is what small groups do well.  Then the large
> group is very very good at sifting through the ideas and picking the good
> ones and discarding the bad ones.
>
> Come to think of it - this is how Sakai has operated for nearly six years
> and gone from a nothing - to a significant market force.
>
> So in while your picture sounds pretty glum as if drastic organizational
> change is needed,  I have the complete opposite view - the community and our
> software quality are the best they have ever been.  We are effectively
> working on a host of little things that are important to the community and
> making good slow and steady progress on several very important and complex
> long-term market-changing initiatives.    And the board continues to present
> visionary ideas to the community - which is exactly what it should be doing.
>  If the board could accept the notion that not all board ideas are great
> ideas - and sometimes ideas take a long time to implement those ideas - then
> things would not seem so glum to the board members.
>
> Hey send me your iTunes account and I will gift you the Audio book of
> "Wisdom of Crowds" - you really only need to listen to the first two hours
> (Chapters 1-4) - it will cheer you up and leave you feeling damn proud of a
> community that you and GA Tech can take a lot of credit for for.
>
>
> ________________________________
> 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
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.
markjnorton markjnorton
Reply | Threaded
Open this post in threaded view
|

Re: Response to Clay's "Outsource" Post...

In reply to this post by Dr. Chuck

Where it makes sense to leverage the work of other people - let's do
it.  Ian and the K2 team seem to be doing a good job of considering what
needs to be developed by Sakai, and what should be brought in from other
opens source projects.

 From where I sit (acting Chairman of the Kuali Technology Road Map
Committe that advises the technical direction of Kuali Rice),
outsourcing the Sakai kernel to Kuali would be a very difficult thing to
do.  At this time, the various Kuali projects (Finance, Research/Coeus,
and Student) are trying to really understand what it means to be based
on a shared set of kernel services (Kuali Rice).  Rice started in
Finance and later extracted to make it usable by other Kuali projects.  
Coeus is the first Kuali project to really try to integrate to it and
they are nearing their first major release based on Rice.

Meanwhile, Kuali Student has committed to basing several of their core
services on Rice.  The Student project has recently committed 1-2 FTEs
to work on expanding Rice to meet Student needs (as well as improving it
overall).  Given that, it seems unlikely that Student would consider
using Sakai-K2 at this time.  See below, however.

The Rice architecture, at this time, still reflects it's origins as a
financial system framework.  That's changing, but slowly.  Rice was
identified as a separate Kuali project with it's own board (I attended
it's first meeting in Nov).  This is similar (in some ways) to Sakai
creating K2 as it's own project withing the Sakai community.  Work is
progressing on organizing Rice as a Kuali project.  Meanwhile, the Rice
development team is getting ready to release their 1.0 version of the
platform.  Note that while our current kernel effort is labeled K2, it
is actually the third generation of a kernel platform, if you include
it's CHEF origins (which I do).  In addition to the points that Chuck
made, there is a depth of maturity to our software that other projects
have a long way to go to match.

So, while I think it's not in our best interests to out source the Sakai
kernel development at this time, we should keep an open mind about
collaborating with other projects like Kuali (and Jackrabbit, Pluto,
etc.).  In time, it would be very interesting to consider how elements
of the Sakai kernel could be shared out to Kuali and how solid elements
of Kuali (like Kuali Enterprise Workflow) might be brought into Sakai.  
Much depends on understanding how requirements between different
projects are the same, similar, or different.  The recent discussion on
Authorization use cases is great example of really trying to get at the
requirements for a kernel service.  I hope that results of this (and
similar) conversations are extracted into more formal documentation
rather letting it languish in old email threads.

- Mark Norton

csev wrote:
> I also have this response in my blog at:
>
> http://www.dr-chuck.com/csev-blog/000582.html
>

----------------------
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.
Dr. Chuck Dr. Chuck
Reply | Threaded
Open this post in threaded view
|

Re: Response to Clay's "Outsource" Post...

In reply to this post by Clay Fenlason


On Jan 9, 2009, at 10:02 AM, Clay Fenlason wrote:

> You've recoiled a bit from the negative formulation of my post, and
> I'm afraid this has led you to react against a position in which I
> can't recognize a view I actually hold. You may be making a good
> argument against someone; I just don't know who that person is. Some
> of that I'll blame on my own proclivities: a critical frame of mind,
> and a tendency to find bracing clarity in starker terms.


I think that you hit the nail on the head.  I agree that we can and  
should talk about a lot of things and always be looking for ways to  
improve.  However - the length of your note, the fact that you were  
tying a lot of threads together, and seeming to move toward a pretty  
significant conclusion - it started to sound like a "plan" rather than  
a discussion.  So I reacted and said "no" to the plan that your note  
kind of laid out.

The part of your note I like the best is the notion that the future in  
5-6 years in the use of technology for teaching and learning might be  
quite different than today - and the development environment might be  
very different - and indeed by that time - things like the Sakai  
Kernel might emerge and be broadly available in such a way to make  
building tools light and fun - and it will work *really* well - and we  
will have a zillion new ways to teach.

Frankly I have been pushing this and writing about this for years - so  
I like the notion of thinking about what Sakai 4 might look like - and  
enjoyed reading that bit of your note.

If Sakai 4 ends up being built on some glorious framework that we  
don't have to build - that framework will not likely come from Kuali  
or Spring - or frankly any of the patterns we are used to seeing and  
using.  The Google AppEnine is the closest thing to such a nirvana -  
it is a framework - it is a kernel - software and hardware magically  
scale somewhere in the cloud - we write little widgets and mash them up.

Part of my comments on Sakai 3 suggest that we are not thinking about  
a few issues of hyper scalability needed to go 4akai.  I got these  
ideas as AppEngine sinks into my conciousness:

http://www.dr-chuck.com/csev-blog/000578.html

Perhaps my ideas of sharding and read-only replication are before  
their time for 3akai - I accept that in time a wise crowd will see and  
do the right thing - and do it at the right time.

Google AppEngine is likely to see competitors in the next 2-3 years  
from Microsoft and Yahoo - and perhaps while AE may not be the be-all  
and end-all - as the market for cloud services matures - I bet things  
will turn out pretty nicely and support the model you propose.  And as  
you suggest - at that point "Sakai" will be a "different thing" - the  
cool thing is that we will likely still be a bunch of great people  
working together around teaching and learning.

And by then, we might be the #1 vendor across both the commercial and  
non-commercial sector.  Not by our clever project management - but  
instead because we simply out-innovate everyone else by experimenting  
with everything at the same time.

Just as some experiments, I wrote a book on Google AppEngine that will  
be published by O'Reilly (www.appenginelearn.com) and have an  
independent study course with seven graduate students experimenting  
with building learning tools using IMS Tools Interoperability and  
Google AppEngine and seeing how these things mash up.  Of course since  
Sakai already has superb support for IMS Learning Tools  
Interoperability and it is in production at UM, these tools can be  
dropped into a course in the middle of the semester or even the middle  
of a weekend.

The first tool I will be writing in this new environment will be a  
"Wisdom of Crowds" tool so I can do live experiments in my classes to  
demonstrate that wise crowds are smarter than wise individuals.  I  
need it to be written and in production and deployed into CTools by  
Wednesday morning.

/Chuck

----------------------
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: Response to Clay's "Outsource" Post...


Thanks for this.

Sorry for setting teeth on edge. The negative formulation of my
thought experiment would be "we have some constraints on our full
potential, and here's a way to think about addressing them," and I may
have erred too far in emphasizing that side.  But even if you don't
agree that there are obstacles or constraints holding us back, I think
there is still a positive formulation:  "Could this be a way of
increasing our quality and capacity, through stronger alliances over
common back-end technologies?"  The Apache project in my thought
experiment was put forward as an ideal type, neatly (I thought)
summarizing the potential advantages and difficulties in a single
package, and thus a good foil for discussion.

But I meant it when I said "thought experiment."  There is no plan,
just some ideas I wanted to air in advance of a Board retreat next
month, as a check and a guide.  Even if there were a plan, it has many
different possible forms, and I couldn't see any of them being
realized any time soon, though we might start folding some of these
considerations into our activity:  making more space for becoming
committers on other projects, putting a little extra thought into a
"productized" kernel as something non-Sakai-adopters might want to
engage with, and so forth.  Testing the waters, and generally being
open to the idea that the kernel may not simply be part of a stovepipe
for Sakai releases.

K2 is already beginning to address the question of lowering technology
thresholds and empowering front-end developers.  Some of this is
through the RESTful exposure of functionality, but some of it is also
through the OpenSocial API, providing opportunities to draw in tools
developed outside Sakai.  A less provincial back-end allows for a
richer front-end.  Part of the hope of the thought experiment is to
take those ideas further:  not only making the Sakai community more
productive through interior innovations and coordination, but by
putting it in a better position to harness the innovation and talent
coming from elsewhere.

Lots of practical questions not yet broached, of course, in this
painting of fantasies in the air, and I'm not yet attempting to.  With
my Board member's hat on, one of the big ones would be "What would the
Foundation's role be in such an environment?"  The initial thought was
that it would continue to be focused on putting out first-rate Sakai
releases for higher ed, with all that that implies, it's just that the
terms on which one does that will have shifted somewhat.  But I'm once
again just thinking out loud; this shouldn't be mistaken for either a
plan or a representation of other Board member's views - nor even my
own considered opinion, for that matter.  The wisdom of crowds may
move slowly, but it still sometimes outpaces me.

~Clay

On Sat, Jan 10, 2009 at 3:53 AM, csev <[hidden email]> wrote:

>
> On Jan 9, 2009, at 10:02 AM, Clay Fenlason wrote:
>
>> You've recoiled a bit from the negative formulation of my post, and
>> I'm afraid this has led you to react against a position in which I
>> can't recognize a view I actually hold. You may be making a good
>> argument against someone; I just don't know who that person is. Some
>> of that I'll blame on my own proclivities: a critical frame of mind,
>> and a tendency to find bracing clarity in starker terms.
>
>
> I think that you hit the nail on the head.  I agree that we can and should
> talk about a lot of things and always be looking for ways to improve.
>  However - the length of your note, the fact that you were tying a lot of
> threads together, and seeming to move toward a pretty significant conclusion
> - it started to sound like a "plan" rather than a discussion.  So I reacted
> and said "no" to the plan that your note kind of laid out.
>
> The part of your note I like the best is the notion that the future in 5-6
> years in the use of technology for teaching and learning might be quite
> different than today - and the development environment might be very
> different - and indeed by that time - things like the Sakai Kernel might
> emerge and be broadly available in such a way to make building tools light
> and fun - and it will work *really* well - and we will have a zillion new
> ways to teach.
>
> Frankly I have been pushing this and writing about this for years - so I
> like the notion of thinking about what Sakai 4 might look like - and enjoyed
> reading that bit of your note.
>
> If Sakai 4 ends up being built on some glorious framework that we don't have
> to build - that framework will not likely come from Kuali or Spring - or
> frankly any of the patterns we are used to seeing and using.  The Google
> AppEnine is the closest thing to such a nirvana - it is a framework - it is
> a kernel - software and hardware magically scale somewhere in the cloud - we
> write little widgets and mash them up.
>
> Part of my comments on Sakai 3 suggest that we are not thinking about a few
> issues of hyper scalability needed to go 4akai.  I got these ideas as
> AppEngine sinks into my conciousness:
>
> http://www.dr-chuck.com/csev-blog/000578.html
>
> Perhaps my ideas of sharding and read-only replication are before their time
> for 3akai - I accept that in time a wise crowd will see and do the right
> thing - and do it at the right time.
>
> Google AppEngine is likely to see competitors in the next 2-3 years from
> Microsoft and Yahoo - and perhaps while AE may not be the be-all and end-all
> - as the market for cloud services matures - I bet things will turn out
> pretty nicely and support the model you propose.  And as you suggest - at
> that point "Sakai" will be a "different thing" - the cool thing is that we
> will likely still be a bunch of great people working together around
> teaching and learning.
>
> And by then, we might be the #1 vendor across both the commercial and
> non-commercial sector.  Not by our clever project management - but instead
> because we simply out-innovate everyone else by experimenting with
> everything at the same time.
>
> Just as some experiments, I wrote a book on Google AppEngine that will be
> published by O'Reilly (www.appenginelearn.com) and have an independent study
> course with seven graduate students experimenting with building learning
> tools using IMS Tools Interoperability and Google AppEngine and seeing how
> these things mash up.  Of course since Sakai already has superb support for
> IMS Learning Tools Interoperability and it is in production at UM, these
> tools can be dropped into a course in the middle of the semester or even the
> middle of a weekend.
>
> The first tool I will be writing in this new environment will be a "Wisdom
> of Crowds" tool so I can do live experiments in my classes to demonstrate
> that wise crowds are smarter than wise individuals.  I need it to be written
> and in production and deployed into CTools by Wednesday morning.
>
> /Chuck
>
>



--
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.