I don't have the technical expertise to have any constructive thoughts
on Sakai's kernel but, given my own bookish sentiments, I'm always
psyched when we attempt to frame what we're doing by reference to a
broader literature on what open source is. So thanks to Chuck for the
cite. One takeaway that I get from Chuck's short synopsis of The
Wisdom of Crowds is that a certain amount of humility and deference on
the part of open source leadership is a good thing because no single
individual (or small subset of the group) have an omniscient
perspective. We leverage our strengths best when we are open to a
broad set of perspectives (institutional bias here: including those
perspectives framed and defined by Moodle and BB). Here's some quotes
from Clay Shirky, Bill Joy, and Aristotle that support this point as
"No matter who you are, most of the smart people work for someone
else." Bill Joy (cf. p. 254 in Clay Shirky's HERE COMES EVERYBODY)
"People connected to groups beyond their own can expect to find
themselves delivering valuable ideas, seeming to be gifted by
creativity. This is not creativity born of deep intellectual ability.
It is creativity as an import-export business. An idea mundane in
one group can be a valuable insight in another." (Ronal Burt, "The
Social Origin of Good Ideas" again in Shirky p. 231)
"Open source is a profound threat, not because the open source
ecosystem is out succeeding commercial efforts but because it is
outfailing them....open systems lower the cost of failure" (Shirky, p.
"....the builder can certainly form an opinion on a house, but the
user, the household manager, will be an even better judge. So too the
user of a rudder, the helmsman, is a better judge of it than the
carpenters who made it; and it is the diner not the cook that
pronounces upon the merits of the dinner." Aristotle in The Politics
On Fri, Jan 9, 2009 at 7:13 AM, csev <[hidden email]> wrote:
> I also have this response in my blog at:
> 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
> 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
> 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
> 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
> 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.
|Free forum by Nabble||Edit this page|