Column 2

Best Mashup Camp quote: “music is to mashups as porn was to the internet: it’s what drives it”.

I’m in the session on “Mashing” client-side mashup tools, where Jason Cooper from Google is demonstrating a mashup called Jookebox that he created using multiple Yahoo Pipes, such as one to retrieve album tracks from Amazon, assembled using the Google Mashup Editor (which I just received an account on the closed beta yesterday, by coincidence).

You can build the entire web page in the browser-based Mashup Editor in XML format, with the big difference between Pipes and GME is that Pipes outputs an RSS feed whereas GME outputs a web page. We had a discussion about how the mashup tools can often be categorized into enablers (which build the widgets, data feeds, etc. from underlying data sources, like Pipes) and builders (which assemble the components into a mashup, like GME).

Google’s goals in building their mashup editor was to remain standards-based, and eventually to open it up for extensions. There’s a whole gallery of mashups built using GME here (weirdly, not searchable…), and if you go to any of these, then there’s a “View Source” link in the top right that allows you to grab the source to learn how it was written. There’s a lot of mapping applications there, obviously, but there’s also things like a simple feed reader and a task list with nary a map in sight (or in site, if you like bad geek puns). You’ll also find a list of resources in the sidebar of the gallery page, such as how to get started, event handling, using the JavaScript API, etc.

We discussed a number of competitors, such as IBM’s QEDwiki, BEA’s Pages and Bungee Labs, although the Google guys state that these products play in a different place than them: GME is much more of a developer tool, since it’s basically a browser-based text editor that you drop code into rather than a drag-and-drop environment. They may decide to add nicer UI stuff in the future, such as a design view to accompany the code view.

Jason also talked about more complex mashups, such as using Dapper to parse a page into a more structured data source, feed it into Pipes for further slicing and dicing, then take the output feed from that and create the mashup using Google Mashup Editor.

We ended up with a discussion about the use Google’s geocoding in a GME-created mashup; currently, all GME apps use a single geocoding API key so there’s no issue of going over your daily limit, although there may be changes to this in the future.

Product roadmap:

• Open up the beta by the end of this quarter
• Allowing mashups to be hosted on other domains
• Feeds from Google Calendar and other sources
• New UI widgets

I’m looking forward to trying it out.

This was really Chris Radcliff’s bitch session on why don’t people just use the Eventful API instead of writing their own event functionality over and over again 🙂 but we discussed a number of interesting points that have analogies in any development environment:

Why people write their own functions even if something exists:

• Discoverability, that is, they don’t know that the function exists externally
• Lack of functionality (or perceived lack)
• Lack of control over functionality, which is a sort of subset of the previous point
• Lack of service level agreement
• “Not invented here” syndrome
• Complexity of external APIs

Why people shouldn’t write their own functions, but use one that already exists:

• Someone else maintains the code
• That particular function is not a core competency and not a competitive differentiator
• It takes longer to get up and running if you write it yourself than if you use an existing API

There was an extended discussion of event APIs and functionality in general, which was not really the point of this session, but it’s an interesting case study for looking at the issues. There’s a ton of other examples here: spam filtering, address lookups, geocoding; all of these are readily available from a couple of competing sources. Of course, it’s all a matter of timing: I can recall when we wrote TIFF decompression and display algorithms in the late 1980’s because nothing else existed, something that would never be considered now.

There’s obvious differences in APIs that deliver content versus those that manipulate content with respect to both copyright issues and currency: if an API is maintaining an up-to-date database of information behind the API (like Eventful, which has about 4 million future events in their database at any given time), then it may be much better positioned to deliver the right content than something that you build yourself.

My speed notes from the speed geeking sessions are all on paper, so I’ll have to transcribe them later. In the meantime, however, I’m at the next session on enterprise mashups.

This was a bit slow-moving; I blame that on the post-lunch energy dip and the frenzy of speed-geeking that wore everyone out.

We talked around a number of subjects:

• Enterprise mashups have a focus on multiple data sources, especially unstructured data, acting in part as a replacement for manual cut-and-paste.
• Current IT development methodologies are not sufficiently agile to develop mashups, leading to the discussion about whether enterprise mashups should be done outside of IT: are mashups the next generation of end-user computing, replacing Excel and Access applications created by the business units? If so, who’s responsible for the result of the mashup, and for the underlying data sources?
• The current IT environment tends to be command+control, and doesn’t lend itself to enabling mashups to occur in the business units. They need to unlearn scarcity of computing resources, and learn abundance.
• What’s the boundary between EAI and mashups? What’s the boundary between business processes and social collaboration?

Another vendor-proposed session (Plaxo), but no formal presentation and not at all around Plaxo’s stuff so not really commercial at all.

The issue is all the multiple unlinked social networks to which we all belong, most of which aren’t open to data extraction or mashup in any way. For example, Facebook will link to a couple of different online address books (such as Gmail) to see if any of your contacts are already on Facebook, but there’s no programmatic way to do the same so that you could, for example, check to see if any of your LinkedIn contacts are also on Facebook (something that I’m checking out a lot lately as more business contacts start to find me on Facebook).

Most of the social networks are very much walled gardens, with no way to even get your own information out. LinkedIn allows you to download each individual’s contacts in as a vCard, but doesn’t allow for bulk export or API access to that data.

We listed data that should be opened up (i.e., made more easily accessible) in social networks:

• My profile
• Who I know
• Friends’ content
• Permissions that I’ve set on people/objects (which might include some implied categorization, like the Flickr family/friends subsets)
• Attention or activity with contacts

We also discussed some of the problems with social networks, such as how you add people to your network but rarely delete them even if you never interact with them any more because that seems a bit harsh to just dump them from your network.

Getting back to the “set my data free” problem, there’s really a need for standards that would allow data to flow between sites that I allow to communicate. Although Plaxo provides some of that functionality, it’s not an open standard and it doesn’t interact with most of the social network sites; possibly something like Plaxo could be used to broker the data and relationships between these sites. LinkedIn’s toolbar for Outlook does a bit of this too, by allowing you to easily link up what you have in Outlook with what you have in LinkedIn; again, it’s not open and only covers that pair of data sources.

One issue is how to recognize the same person across sites: email address is most commonly used, but not perfect because many people use different email addresses for different sites, like a business email on LinkedIn and a personal email on Facebook.

Since sponsors are allowed to propose sessions, AOL proposed a session on feed mashups where they gave a short presentation/demo of their new customizable portal page (comparable to Netvibes or iGoogle) that also includes Mgnet, a way to do what they refer to as mashing up feeds, although it appears to be feed aggregation and filtering. Maybe that’s a good question: when does aggregation and filtering (which are basically functions of a feed reader) become a mashup? It appears that some of the interactive “mix & share” functionality is similar to the “share this” functionality in Google Reader, where you can set certain posts (or even a whole folder/collection of third-party feeds) to become part of a new, customized feed that can be shared with others.

The cool part is a set of APIs (both REST and RPC) that allow this functionality to be accessed programmatically rather than interactively:

• Manage users’ bookmarks and feed subscriptions, organized by tags or folders
• Retrieve feed articles
• Apply chained operations (sort, trim, html) during feed processing

This allows aggregated feeds to be accessed in an application as a URL, create a mixed feed from a folder or tag, or dynamically create a synthetic feed from several feeds. This makes it similar to Yahoo Pipes for feed manipulation, but with a bit more flexibility.

AOL also seems to  be providing the only t-shirts at camp, since there’s no official Mashup Camp t-shirt this time; having scored a t-shirt, I’ve fulfilled my home obligations and can relax. 🙂

The session turned into an interesting discussion about widget standards, including how IBM and BEA are both supporting Google gadgets in their portals, making it somewhat of a de facto standard. Even the AOL guys admit that a standard widget format (even if it’s not theirs) is valuable, and they also support Google gadgets.

We also discussed how the difficulties with authentication for feed subscribers is part of what’s inhibiting adoption by businesses, particularly for delivering any sort of secure information to customers outside the firewall, such as a feed of transactions from your financial institution. AOL is using OpenID as a provider (every AOL username also corresponds to a set of OpenID credentials), but isn’t accepting OpenID — this seems to be the way that a lot of sites are going, which is not going to work until they all start accepting as well as providing credentials: providing OpenID credentials without accepting them is little better, in my opinion, than implementing a proprietary credentials scheme. One attendee pointed out, with some head-nodding around the room, that the dream of OpenID may actually be better than the practice since most people don’t want a single point of failure for their online credentials: you might use OpenID for all the logins that don’t contain any sensitive information so as to have a single signon around the web, but are unlikely to use it for financial and other critical sites.

I think that feeds are becoming more important in general, and also are going to start making some significant inroads within enterprises, as I saw at the recent Enterprise 2.0 conference. Inside the firewall, the credentials issue gets much easier, but there’s a much bigger cultural gap to using feeds as applications.

A slow start, in spite of the announced 8:30am start time, and a smaller crowd than I remember from last year’s Mashup Camps, but a few familiar faces and lots of enthusiasm in a low-key sort of way. Like every unconference that I’ve been to, there’s a few minutes before the grid of sessions starts to fill up when I’m convinced that this is all a great waste of time, then people get up and propose interesting sessions, and I’m hooked.

David Berlin is our able host, as usual, and Kaliya Hamlin is facilitating the Open Space concepts for us, providing a bit of education on how an unconference works and getting people up in front of the room to propose sessions and sign up for speed-geeking.

You can keep an eye on the sessions grid here, which should eventually have links to notes from the individual sessions.