Open Source and the Cloud

Lately, I've been thinking about how the cloud computing model of providing software intersects with the open source model.

We've all gotten pretty comfortable with supporting Open Source apps that utilize a LAMP stack, Wordpress being a good case in point. This model works very well, generally speaking, but there are a couple problems with it, from the perspective of cloud computing.

• First of all, if you use something like Wordpress, you regularly need to update your code and you need to deal with various compatibilities as you migrate systems. I really like applications that just kind of upgrade themselves over time, like GMail.
  
• Second, applications that are installed as single instances on multiple servers can't leverage Web 2.0 style network effects like single installation, web scale applications can (eg Flickr, YouTube, WorldCat.org (what, did, I just call an OCLC product Web 2.o?), etc.).

The recently released Omeka product got a lot of things right, I think. It's really a Web 2.0 digital collections system that allows for TWO-WAY interactions with collections.

We're eager to try it out here at Lewis & Clark. To get it up and running on our server, I had to upgrade MySQL from 4 to 5. This broke our compiled version of PHP. A newly downloaded version of PHP fixed things, but that broke a couple other components on our web site. A few hours later, all was well, but the point is, loading and running something like Omeka does still require some "heavy lifting" on a sysadmin's part.

The other element lacking in Omeka is the fact that its data isn't part of a larger system. Sure it's harvestable and can be syndicated through RSS, but it's not part of a greater, two-way information ecosystem.

So how should Open Source projects be done in this cloud computing environment? Code should be shared and improved by a community and those improvements should be tested and then applied to a centralized running instance of the application.

Google has just released a platform that would work well for this sort of model, called "Google App Engine."

NITLE Summit

Mike Wesch of "The Machine is Us/using Us" fame, gave a great talk at the NITLE Summit on the ways he believes digital technology changes learning. A major point was that the "sage on the stage" lecture model just doesn't make sense anymore. Knowledge is no longer scarce--the professor no longer has the kind of authority that they used to.

Not sure how much I buy the part about lack of authority. There were always ways to challenge a professor's authority in the past. To do so is still hard. To challenge a professor's knowledge and authority, you need much more than just information--you need knowledge and understanding of that information, and digital technology doesn't endow students with that. And the professor still sets the agenda for a course and hands out the grade. But the point about the lecture as a somewhat outmoded vehicle for instruction in higher ed is well taken.

On a more practical level, one thing that was striking about this guy was that he cobbles together his own learning management system out of freely available, open Web 2.0 tools: Zoho databases, WetPaint wikis, YouTube, Netvibes, etc. Bryan Alexander, in his intro to Wesch, referred to him as a "faculty member from the future." One might say that he represents the beginning of a third stage in the evolution of teaching technology:

• from individually managed, desktop teaching tools like Word, Powerpoint that confine information to the teacher's personal information space and rely on the lecture to get that information across
• to institutionally managed, server based tools like Moodle, WebCT, BlackBoard that can serve to share and discuss information within a particular course or institution
• to systems that are managed at the network level and in some cases (like Wikipedia) serve to share knowledge globally

When someone in the room, which was full of educational technologists, among others, asked, "what can we do to help faculty like you", Mike's memorable quote was: "Get out of my way!"

Lorcan Dempsey on The Big Switch

Lorcan Dempsey has just posted some thoughts on Carr's The Big Switch. I like this quote:

The 'big switch' is going to be a major issue for libraries over the next few years. They spend too much time getting their systems to work, and not enough time putting them to work.

Thanks to him for linking back to synthesize-specialize-mobilize.

Meanwhile, I must confess that I have yet to read The Big Switch, just excerpts from it on the web. I've put a hold on our library's copy of it (I think I know who has it checked out).

bibliographic utility computing

As OCLC re-invents itself from a staid bibliographic utility to a company that can provide "next generation" library services, it's funny how that old fashioned term "utility" takes on a new meaning.

I was at the Orbis Cascade Alliance Council meeting last week as the group was discussing the possiblity of a partnership with OCLC for a group catalog on the WorldCat.org platform. As I reflected on the consortium's potential move from an isolated, server based union catalog, to one that lives in the cloud I thought about how this decision parallels those that many organizations will be making in the next few years as they make what Nick Carr has dubbed, The Big Switch to utility style computing. OCLC likes to call this "moving to the network level," but I think it's also just as much a move to "cloud" or utility style computing.

I'd heard most of what the OCLC sales force had to say at the meeting before. But one thing that struck me was how they explained the point of worldcat.org. OCLC believes that libraries need a "presence" on the web like EBay, Amazon, or Google. And that presence needs to be two-way, meaning users interact with the site and their interaction improves it.

If WorldCat is able to become a real "presence", maybe more database vendors will be open to representing their content in it and it will become a federated search killer. Maybe libraries can have more control over the digital content they give their users vs. just sending them off to an external, commercial website.

Where does local customization and control play in this potential juggernaut? Hopefully OCLC will keep opening up their APIs, and let libraries still have the ability to customize their own records in various ways.

Introducing accessCeramics

Our Flickr-based database of contemporary ceramics images is up and running at accessceramics.org.

We're now at the stage where we are working with invited artists to submit images.

Wikipedia's internal dilemma

between inclusionists and deletionists is discussed in the Economist.

Google Sites

As mentioned previously in this blog, as former JotSpot users, we've been eagerly awaiting Google's re-release of the JotSpot wiki technology. Well, it just happened with the release of Google Sites.

Google is only releasing Sites as part of their Google Apps for Enterprise suite, so it was a little hard for us to access it, being a department in a larger organization. Our IT sysadmin had signed us up for Google Apps for Education (just to trial it), so I had to contact him to enable access, which fortunately wasn't a problem.

We may try out sites for our departmental intranet, which serves to manage policies, procedures, etc. for the library.

Sites is a fairly nice, easy to use wiki, definitely up a level from early wiki software. It allows for very modular page layout with easy insertion of widgets like Google Gadgets or spreadsheets, documents, and presentations from Google Docs.

The feature set strikes me as fairly basic however. It really does not aspire to be the "programmable wiki" that JotSpot did. With JotSpot, you could basically create these little database-backed applications with some pseudo-programming.

Another thing that's a little disappointing is the lack of integration with Google Docs...it's easy to post a Google Doc or spreadsheet on your page, but you have to copy the url to it and it can't be edited right there within the page if you want it to.

The access control options are pretty limited, too. We have parts of our intranet that we'd like to wall off from the rest of the world and parts we'd like to show off. With sites, access is controlled at the level of the whole web site. We thought that we might work around this with access control on individual Google Docs.

There are plenty of up-and-coming wiki options out there like Wet Paint, but I have a feeling we may go with Google Sites because we're enjoying Google Docs so much and it's nice to have things in the same ecosystem. Funny, Google is managing to make this web-ecosystem application tie-in that might be called similar to Microsoft's desktop and Office strategy. And it seems to be sort of working.

Currently we use an old fashioned static web site with Macromedia Contribute editing software for our staff web site/intranet. I'm thinking the advantages of Google Sites would be:

• moduler - we can drop dynamic elements like RSS feeds from basecamp project mangement right into our pages
• easier to edit - wiki style, no filesystem confusion
  
• search is included
• integrated with Google Docs
• access management may be easier than what we use now (Apache .htaccess)