There have been a few interesting threads on sakai-dev recently; today's post is an email I sent responding to a thread about establishing a "Sakai code convention".... (Sorry, I had to turn off anonymous comments after a recent upgrade broke the captcha module.)

Here's what the eclipse folks have to say:

http://wiki.eclipse.org/index.php/Development_Conventions_and_Guidelines

"As with any product being built by a team, there are various areas
where standards, conventions, and other guidelines can play a role in
helping to ensure that the resulting product presents to developers and
customers as a unified whole rather than as a loose collection of parts
worked on by a variety of individuals each with their own styles and
ways of working."

and there is a link to

http://wiki.eclipse.org/index.php/Coding_Conventions

For me, I think the key phrase is "...presents to developers and
customers as a unified whole...."

While some in this community seem to think of the Sakai project as a
loose amalgamation of separate groups (hmm... sounds like the "bag of
tools" phrase we hear describing the UI), I suspect that many
institutional administrators may be concerned that the project teams are
not quite "black boxish" enough; being more "black boxish" may not only
allow for simpler wholesale replacement of developers if a given
institution decides to drop out of the community, but it may also lead
to an increase in the attitude that teams from different organizations
could or should work *together* more, thereby reducing the "silo" effect
that we often see.

And, of course, finding the right blend of standards is in the best
interests of our leading development organizations because it reduces
learning/setup curves for their staff, which also has the nice -- if
lesser -- side-effect of keeping key developers involved by increasing
mobility *within* the Sakai community.

[Not naming any names, but the UK seems to be a bit of a recent human
resources gravity well. :) ]

I would also suggest that we should not underestimate the value of
consistency (and public claims of consistency, as with the Eclipse
webpage I referenced) appearing more professional than inconsistency,
and therefore also appearing more "reliable" or "a safer long-term bet",
leading to increased uptake, more momentum, etc etc. (I know these are
pretty wishy-washy intangible-based statements. Feel free to
challenge/support them with statements from Gladwell's "Blink" or
whatever authorities you know about.)

The fact is, we already choose to "standardize" every day, by choosing
to share a repository, a bug tracking system, a wiki, this mailing
list... nevermind all of the agreed-upon-workflows that have arisen out
of the existence of those very tools. Each of these standardizations
helps to create a community momentum that helps keep us all headed in
roughly the same direction.

While there will always be a certain amount of desire/requirement to
"support free speech / individualism" and to "do research" in
academic-based communities such as ours, I would suggest that these
desires/requirements *increase* the importance of doing the hard work to
find the standardization balances, so that those local goals can be met
while still presenting ourselves as a "unified whole".