blog.ecorrado.us

Call for chapters: Getting started with cloud computing: A LITA guide 2010 August 27

Dear Librarian Colleagues:

Consider writing a chapter for the forthcoming book, “Getting started with cloud computing: A LITA guide”.

Edward Corrado and Heather Moulaison, editors, are looking for 8-12 page (double spaced standard font) chapters on either:

1. Applications and services used by librarians in the cloud and how they might be used in a variety of libraries, including information on:

a. The tool itself (what it does, why it could be of use to libraries)
b. Why librarians should know about this application or service

2. Descriptions of best practices/ok practices/not good practices in using cloud services, including information on:

a. The background to the project: Describe your library, your collection, your resources, or any other element that will be necessary to understand what you did and why

b. The project: Describe what you did, why you did it, who did what, and how, being sure to mention any special funding you needed or resources you used

c. The assessment: How have you assessed your project and what are the results of that assessment

Possible topics: Using Amazon S3 for backups/storage, Hosting Websites, blogs, wikis, etc., in the Cloud, Hosting Library Subject Guides in the Cloud, Using Google Docs and other Google Applications, etc.

Examples can focus on all kinds of libraries, including public, special, museum, academic, etc.

Projected deadline for chapter: Nov. 1, 2010.

Authors will receive a copy of the book as compensation.

If you are interested in submitting an idea for consideration, please send a rough outline of your proposed chapter to ecorrado@ecorrado.us before Sept. 15, 2010. Clearly indicate in your email your name, contact information, and any other information the editors should take into
consideration about the context of your proposal.

Little Things Matter 2010 August 22

Dear Open Source Software developer,

Little things matter. If you want me to take your project serious, doing the little things right can make a big difference. Here are just a few things you should try to do, IMHO. I know that some of these are not as fun as coding in your favorite programming language, but if they aren’t done, your project will less likely be chosen for me to use, and possibly contribute back. Instead of making a long list, I will give you my five of my pet peeves about Open Source projects. These are some little things that I have seen with a number of projects that could easily be rectified.

1. Include complete install instructions. Don’t assume people know what you mean by things like create a database and grant CREATE, UPDATE, DROP, etc. means. Just tell people how to do it. People with more skills can read between the lines if they want to do it differently. You need to design documentation for people who are just learning. Also, don’t make me download the whole package to see the instructions. I tried to use one project that had instructions for install the project on MySQL/Linux but was written on Solaris/Postgres. I naively assumed that they actually tested the Linux instructions. Wrong! After struggling with it for a day, I e-mailed the project’s list and learned they weren’t even tested ans I should use Solaris/Postgres. I have nothing against Solaris/Postgres, but it would have been nice to know I should use it before wasting a day following instructions that weren’t even tested. I went elsewhere even though I would have probably used the project on Solaris/Postgres if I knew that in the begining.
2. On your Website include (at least) basic operating instructions and screen shots. I recently saw an announcement for a new Open Source project that I thought sounded interesting, but when I went to the URL and it was basically just a place to download the code. I at least want some idea what it looks like and what it does beside being a statistics package, a time management package, or _____.
3. Respond to posts on your forum/blog/e-mail list. Nothing screams dead project like questions and inquiries not being answered. It is possible they are answered in private, but someone investigating your project won’t know that. If it is asked in public, answer it in public or at least post something saying you contacted the person privately).
4. Keep people informed/updated. I went to a OSS project Web site last week and found a new version of the software to download posted about a month ago with absolutely no mention of how they got there or what was different about the new version from earlier versions. A quick post saying new files are available would have been nice. The same project’s home page says beta software for a new version is coming in Spring 2009 (it is now Summer 2010!). I think the beta version was actually version 1.1 and was posted in March, but who knows? Even if you are not actively releasing new code, a blog post with a hint or tip every now and then will add confidence.
5. Treat users (even newbies) with respect.

Not everyone is an expert with Open Source, but you should treat them with respect. If they ask a dumb question don’t attack them, ask them for more information in a friendly manner Karl Fogel in Producing Open Source Software describes this as treating every user as a potential volunteer. He writes:

A corollary of this is that developers should not express anger at people who file well-intended but vague bug reports. This is one of my personal pet peeves; I see developers do it all the time on various open source mailing lists, and the harm it does is palpable. Some hapless newbie will post a useless report:

“Hi, I can’t get Scanley to run. Every time I start it up, it just errors. Is anyone else seeing this problem?”

Some developer—who has seen this kind of report a thousand times, and hasn’t stopped to think that the newbie has not—will respond like this:

“What are we supposed to do with so little information? Sheesh. Give us at least some details, like the version of Scanley, your operating system, and the error.”

This developer has failed to see things from the user’s point of view, and also failed to consider the effect such a reaction might have on all the other people watching the exchange. Naturally a user who has no programming experience, and no prior experience reporting bugs, will not know how to write a bug report. What is the right way to handle such a person? Educate them! And do it in such a way that they come back for more:

“Sorry you’re having trouble. We’ll need more information in order to figure out what’s happening here. Please tell us the version of Scanley, your operating system, and the exact text of the error. The very best thing you can do is send a transcript showing the exact commands you ran, and the output they produced. See http://www.scanley.org/how_to_report_a_bug.html for more.”

This way of responding is far more effective at extracting the needed information from the user, because it is written to the user’s point of view.

These are just a few things that I think, if followed, will give a project a much better chance of being successful. Also, by doing this you may have a better chance of growing community who can assist with things like documentation and answering questions from other users.

Sincerely,

Me

P.S. Anyone have their own pet peeves to share?

 

Staying Free from “Corporate Marketing Machines”: Library Policy for Web 2.0 Tools 2010 August 8

The presentation, Staying Free from “Corporate Marketing Machines”: Library Policy for Web 2.0 Tools, that Heather Lea Moulaison and I gave at the Marketing Libraries in a Web 2.0 Worldd IFLA Satellite conference is available on codabox. Here is the citation:

Moulaison, Heather Lea and Corrado, Edward M. (2010) Staying Free from “Corporate Marketing Machines”: Library Policy for Web 2.0 Tools. In: Marketing Libraries in a Web 2.0 World, 7-8 August 2010, Stockholm University, Sweden. Available at http://codabox.org/66/

New Article: SkyRiver and Innovative Interfaces File Antitrust Suit Against OCLC 2010 August 2

I just had an article, SkyRiver and Innovative Interfaces File Antitrust Suit Against OCLC, published as an Information Today NewsBreak. The introduction states:

SkyRiver Technology Solutions filed a complaint for Federal and State antitrust violations and unfair competition against OCLC in United States District Court, Northern Division of California on July 28. The suit [1] alleges that OCLC is “unlawfully monopolizing the bibliographic data, cataloging service and interlibrary lending markets and is attempting to monopolize the market for integrated library systems by anticompetitive and exclusionary agreements, policies and practices.” Innovative Interfaces, Inc. is listed as a co-plaintiff. OCLC released a statement on July 29 saying that it hadn’t reviewed the complaint yet and after it reviews the complaint and “have had an opportunity to review the allegations with its legal counsel, a statement in response will be forthcoming.” This suit could have major implications in the library software and technology services industry. If the suit is successful, OCLC may have to provide for-profit firms access to the WorldCat database and there could be implications for OCLC’s status as a non-profit cooperative.

Please go to the Information Today Web site to read the whole article.