Yes, you’re right that the “big problems” are a bit biased at this point. We agree. You’re not the first person to point that out (the others were sent privately), and we’ll definitely fix that.

Thanks for the feedback!

As part of the Kuali Student project, I foresee a strong need for sharing calendar data. Mobile devices will increasingly be part of Berkeley life, adding another layer of varied technologies. Stanford recently replaced its Oracle Calendar implementation with open source Zimbra, with great success:

http://www.stanford.edu/dept/its/projects/integratedemailcalendar/benefits.html
http://www.zimbra.com/community/downloads.html

Also, either take out the mention of “credit crunch and housing price collapse” or make sure you bridge the gap between that and “most units… face flat or reduced funding for the next several years.”

Off topic, I hope the university looks hard at Zotero (http://www.zotero.org/) and the Dataverse Network Project (http://thedata.org/).

—–

Rob:

A few responses to your points are below. We will work on finding ways to make all this clearer in the final version of the strategy. If you noticed particular spots that were especially unclear, we’d love to hear about them.

1) With this strategy our goal is not to prohibit the use of any particular tool, but rather to encourage the use of a much wider variety of tools. This is really what the “Embrace the chaos” catch-phrase is all about. We need to stop thinking that we can control everything and dictate what is or is not used on campus, and shift to a mode where we support the development of communities of practice around the use of collaborative tools (regardless of whether they’re from an on-campus or off-campus provider).

The “Tier 7″ you see in strategic goal 3 is designed as a category for tools that are malicious, illegal, or harmful. We hope that there would be very few if any tools listed in this category. We’ll make that clearer in the final version.

2) At the same time, the university must find a way to reduce the risks and liabilities that inappropriately-handled data can impose. For example:
- If restricted data is stored inappropriately or transmitted over unsecured networks, that can impose huge financial costs (tens or hundreds of thousands of dollars) on the university, and can also lead to various personal consequences for anyone found responsible for that breach.
- Data stored with outside entities (be they commercial like Google or Amazon, or organizations or consortia) is often stored in data centers in other states or countries, making it subject to different disclosure, legal discovery, and privacy laws.
- Important data stored with an outside provider can be irretrievably lost if the provider shuts down or radically changes their service. (For example: What happens if the only copy of a picture of a new frog species was stored on a researcher’s Flickr account and Yahoo decides to shut down that service or modify the picture?)
- See section G (pages 69-73) of the document at http://dsblog.berkeley.edu/wp-content/uploads/2008/03/4_findings.pdf for a more in-depth discussion of these and other similar issues.

3) We feel that the only way to allow the use of a broader range of collaborative tools (#1, above) while minimizing the risk (#2), is to educate and guide the campus community’s decisions about which tools to use, with which data, to maximize productivity while minimizing risk and cost. Via strategic goals 3, 4, and 5, we hope to make the information necessary for members of our campus community to make prudent decisions in this area easily available.

Of course, we could be wrong–the reason we’re asking for feedback is to search for even better approaches for managing these issues. We would definitely appreciate any thoughts about alternative approaches.

4) We have indeed been talking with many outside vendors of collaborative tools (Microsoft, Google, Yahoo, and others) about these issues and this strategy document. We have invited them to comment on the draft strategy and participate in this discussion. We hope they will do so.

(As an aside: one interesting data point–we’re actually quite small when you talk about consumer-oriented services such as GMail, Yahoo Mail, and Hotmail. According to comScore, in December of 2007–the most recent month I could find data for easily–GMail had about 90 million active users, Hotmail had about 255 million, and Yahoo had about 256 million. In this case, the roughly 60,000 accounts from UCB or the 250,000 accounts from UC systemwide start to look pretty minimal. Still, the vendors we have talked to so far have been quite helpful and interested in our feedback.)

* Have we talked to Google and other providers to see if a more
secure arrangement can be made for using their tools? Berkeley
is big, and UC is huge - they will talk to us. As these tools
become more convenient - and free (ad-supported) - we see
people transferring their campus email addresses to, say, a
Gmail account with auto-forward of their Berkeley account -
because very few people can live with a 256-mbyte IMAP account
in the era of 160-gig PC drives.

* How secure is data via authentication? when much restricted
data is provided via email attachments? or from a source via
authentication, then downloaded to a home computer, laptop or
thumb drive? is there really a great difference in security
over a non-campus collaborative tool? how secure is
authenticated access to CalMail via Eudora, a non-supported
software tool that is still widely used on campus, compared to
say Gmail? in the era of phishing scams, is the weak link in
the security chain the tool, or the education of the user and
the inability to really enact ideal security practices when
alternative practices are far more available and productive?