Embedded below is a video of the presentation Chris Messina gave at the 2010 Google I/O developer’s conference a couple of weeks ago.

Chris has been instrumental in birthing and evangelizing many of the social web’s protocols for sharing data across sites and applications (ActivityStrea.ms, OpenID, OAuth), and he recently went to work on these technologies at Google. Chris is a designer, not necessarily a programmer, so his presentation is light on code. But it very clearly presents the concepts behind social sharing protocols — how they work, why they’re important and how they are currently implemented across the web.

Plus, he apes Lost, and it’s funny.

See Also:

• New ‘OpenID Connect’ Proposal Could Solve Many of the Social Web’s Woes
• Mozilla Gets It Right, Moves Identity Management Into Firefox
• Facebook Adopts Open Standard for User Logins

One of OpenID’s biggest proponents thinks part of the problem lies in the name.

Identity guru and noted open source advocate Chris Messina breaks it down in a post on his Factory City blog, where he lays out his ideas for making OpenID “both easier and sexier” for the general web audience.

Consider OpenID in the shadow of Facebook Connect, its far more successful competitor based on Facebook’s proprietary platform. Forget that Facebook is much more widely known than OpenID — the real problem is that Facebook Connect is attached to an actual thing you can log in to, a website you can visit, a company you’ve heard of.

OpenID, on the other hand, is more nebulous. Your identity… on the web… portable… everywhere… what?

Everyone knows what Facebook is, so add “Connect” to the familiar Facebook logo and most people can work out what’s probably going to happen — the site you’re using is going to connect to your Facebook account, and some information about you and your friends will be shared between the two.

OpenID lacks the brand recognition of Facebook, not just because of Facebook’s fame, but because Facebook is a website and OpenID is an abstraction.

Messina suggests adding “Connect” to OpenID so that it mirrors Facebook Connect, Twitter Connect and other sign-in systems might help. And Messina’s rebranding — the snazzy black button above — is certainly a step up from OpenID’s current logo and branding.

As for the “connect” aspect, Messina gives a layman’s definition of OpenID as “a technology that lets you use an account that you already have to sign up, sign in, and bring your profile, contacts, data, and activities with you to any compatible site on the web.”

In order to do that, however, Messina is proposing more than just a name change. He’s suggesting that OpenID be repackaged as a profile of the OAuth WRAP protocol. The idea is that OAuth WRAP could handle the actual connections between the websites sharing data and OpenID would then offer a standardized way to pass along profile data, relationships, access controls, and activities (what you’ve “liked,” “loved,” “favorited,” etc.).

So, how would that simplify OpenID for new users? For one, it would help solve the “NASCAR problem” — current implementations of OpenID often display a half-dozen or so sign-in options, and the effect is similar to the garish mish-mash of ads covering NASCAR vehicles. It’s visually and psychologically confounding.

Messina’s design would mean that, instead of an assortment of rainbow-colored logos from Yahoo, Google, Microsoft and other OpenID providers, there would simply be the singular black button above. He admits that after you click the shiny black button, the NASCAR problem might still be there on the next step — at least for now — though he does promise some additional screenshot mockups and suggests that “the browser could handle this at an earlier stage.”

See Also:

• OpenID: Over One Billion (Potentially) Served
• Facebook Announces Support for OpenID Logins
• OpenID Is Here. Too Bad Users Can’t Figure Out How It Works

The logic behind that maxim is that, as long as the source code is out there and freely available, someone will always show up to work on it, add to it, improve it. Indeed, that’s often the motivation behind releasing a project under an open source license.

One example is tr.im, the URL shortening service that shut down temporarily, but whose code is now open source. Another is OpenTape, a clone of the popular (and long gone) Muxtape music streaming app. Both released into the wild after the original developers became overwhelmed in the hopes that someone, anyone, would keep those projects alive. Whether or not the community actually forms around the release is irrelevant. The point is that it could.

But what do you do when an ostensibly open source project lacks support from its creators, and it becomes nearly impossible for the community to contribute? That’s the question programmer Jeff Atwood raised in a blog post Tuesday regarding John Gruber’s Markdown software.

Markdown is a text-to-HTML conversion tool which allows you to write web code using an easy-to-understand plain text format. Markdown text is then converted to structurally valid XHTML (or HTML). Markdown is used all over the web — it’s even understood by the content fields and comment forms within most popular blogging platforms, including WordPress and Movable Type. It’s been ported to Python, Ruby, PHP and other popular languages.

However, the original Perl script has remained largely unchanged since its release in 2004. In his post, Atwood takes Gruber to task for what Atwood calls “bad parenting,” an indictment of Markdown’s lack of bug fixes, updates and improvements.

Markdown was released under a BSD-style open source license, meaning the community can do pretty much whatever it likes with the code, so long as it respects the copyright notices and naming rules. Indeed, many ports of Markdown enjoy rather widespread support with numerous contributors and an aggregate community of active developers that the original Markdown lacks.

So while the various implementations of Markdown have regular fixes and updates, Gruber’s original code lacks such activity. What’s the difference? Atwood lays some of the blame at Gruber’s feet, citing what Atwood calls “passive-aggressive interaction with the community,” and quotes one of Gruber’s famously bristly e-mails (Gruber also writes the famously bristly blog, Daring Fireball) that shows the author discouraging changes. Single programmers rarely have that sort of influence. Which isn’t to say we disagree with Atwood’s assessment, just that Gruber is an extreme example and that it shouldn’t matter either way.

The bigger reason Markdown’s original Perl source doesn’t see bug fixes and maintenance releases seems to lie more its hosting situation than any other single problem Atwood raises. Without a way to easily contribute to your project, your potential users can’t improve your code.

The Perl source of Markdown is hosted as static download on Gruber’s website. Download the zip file and you’ve got a copy of Markdown you can use, modify and even redistribute according to the terms of the license.

But you don’t have a copy that’s easy to patch, and there’s no simple way to contribute back to the project, short of sending code directly to Gruber or to the support mailing list.

If the Markdown source code lived somewhere like GitHub, BitBucket, Google Code or any of the other free, open source code repository hosts, it would be infinitely easier for the community to contribute. To be fair, none of those sites existed when Markdown was released, but moving the code wouldn’t be hard — it’s a single archive with a license and readme text file.

A good project hosting service allows the community to contribute in ways that it just can’t when the code is static download.

Markdown isn’t alone in this respect. Django programmers were very excited to get their hands on the EveryBlock source code when it was finally released. However, since the EveryBlock code is, like Markdown, a static download, there isn’t and easy way for the community to contribute.

I have been using the EveryBlock code in a personal project for some time, and I’ve found at least a dozen bugs and several oversights and contradictions in the documentation. None of these stumbling blocks have stopped me from using the code, but it would be nice if I could contribute patches so others don’t also have to bang their heads against a wall for days on end trying to make the code work.

Yet a static hosting environment prevents that. There’s no easy way for me or anyone else to contribute to the code, update the documentation, add helpful links to a wiki, ask a question and get it answered. As a result, the whole community around the project suffers.

While it’s true I could put the codebase into a version control system and host my own copy, but not only does that feel wrong, it shouldn’t be necessary. The “you can always fork it” motto of open source has proved one of its least helpful tenets, leading to a proliferation of nearly identical code forks that are difficult to keep track of and work with.

We understand that the people who release open source code might not have time to work on it, or might simply lose interest in it over time, but that’s precisely why version control systems exist — to take the burden off the developer and let the contributions of the community pick up the slack in an open, organized manner.

Does a project still need an maintainer and someone to check in code, run tests, merge branches and so on? Sure, but that need not be a single person. Sizable open source projects — take Firefox for example — have dozens of committers and (in theory) no one person winds up feeling overwhelmed.

While in this particular case, it could be argued that Markdown doesn’t need further development. We use it everyday without issue. But the larger issue remains for other projects. Without active development, particularly bug fixes and maintenance releases, your open source project will rarely be successful.

Get your code into a decent version control system and make it easy for other users to do what you don’t have to — make your code better.

Photo by gerhard3/CC BY-NC-SA 2.0

See Also:

• Why Great Documentation Matters in Open Source
• Making Open Source Software More “Humane”
• Money, Not Spare Cycles, Drives Open Source

OpenID lets you log in to your favorite website using only your e-mail address or a URL — your blog’s address, a profile page on a social network or your social network username/password. Using one of those identifiers, you can log in to any website or service where OpenID is welcome, saving you the trouble of having to keep track of dozens of account names and passwords. There are also companion technologies that help you automatically fill out a profile and connect you with your friends once you’re logged in to a new social website.

For a long time, OpenID was a fringe technology, and few large players supported it. In January 2008, Yahoo and AOL were the first major destination sites to host OpenID accounts. 2009 has seen everyone from Microsoft to Facebook to the U.S. Government embracing OpenID. In addition to the one billion accounts coming from OpenID providers, the OpenID foundation says that nearly 9 million websites will allow you to login using your OpenID credentials.

The short story is that OpenID is now well established on the web. But the story doesn’t end there.

Sadly, one billion potential users does not one billion users make. Many people with OpenID accounts remain blissfully unaware of OpenID and what it can do for them. OpenID also faces strong competition from proprietary ID solutions like those of Facebook or Twitter.

OpenID interfaces are another problem we’ve covered before — different sites use vastly different sign-in forms which has creates confusion for less-than-savvy web users. Couple that with Facebook’s far simpler Facebook Connect tools and you begin to see why OpenID doesn’t have one billion actual users.

The good news is that the OpenID Foundation and its partners have been working hard to streamline the login process and improve the usability of OpenID on those 9 million sites that accept OpenID.

We’re excited to see that what began as little more than a grassroots effort to solve the problem of remembering too many usernames and passwords, has turned into a massive, web-wide effort to create better, portable identity tools. So even if OpenID hasn’t seen the widespread adoption of other login systems, it certainly set the ball rolling among the web’s social networking technicians.

See Also:

• As Yahoo Adopts Facebook Connect, Questions About OpenID’s Future Loom
• Facebook Announces Support for OpenID Logins
• Google’s New Design Helps Eliminate OpenID Confusion
• OpenID Is Here. Too Bad Users Can’t Figure Out How It Works

Of course, there are occasionally good reasons to move your content and now there are some new ways to let Google know what you’re up to. The Google Webmaster blog recently announced that Google will support the cross-domain rel="canonical" link element. That means you can effectively migrate your site to a new domain even if you don’t have server access to do redirects.

In most cases, Google still suggests that, if possible, you use 301 permanent redirects to point both visitors and search engine bots to your new domain. However, if that’s not possible for some reason, (for example, if you’re migrating from a hosted blog service to your own domain) then you can add rel="canonical" element to your page headers and Google will index the new URL.

Note that in our example — moving from a hosted blogging service to a self-hosted domain — it’s OK if there are some differences between the new and old pages, but the basic content (the blog post) should be the same.

Previously, Google would look down on cases of duplicate content across domains. Given the number of content-stealing “splogs” out there, filtering duplicate content by domains is a good way for Google to stop search engine spam. The problem is there are legitimate reasons to have duplicate content, like migrating a site to a new domain, and now there’s a way to do it.

One important note, Google no longer recommends blocking access to duplicate content on your website, whether with a robots.txt file or other methods. Just use the rel="canonical" tag instead.

See Also:

• New Google Tools Help Speed Up Your Website
• Search Engine Optimization Is Part of Good Web Design
• Google Adds Links To Webmaster Tools

Now, every time Jenny friends somebody, posts a photo or writes a blog post, you’ll be able to make that notification show up in your app mere seconds after it happens.

The company announced the new Real Time Stream API, along with two other social APIs, Wednesday morning at the Le Web conference in Paris, France. It posted all the details on its developer website and kicked off a contest to see who can create the best apps. The new APIs offer access to every MySpace user’s stream in real time. MySpace publishes its user activities using the ActivityStrea.ms format, and it’s using PubSubHubbub to push the streams out in real time.

Wednesday’s announcement comes during a big week for MySpace. Only a day before, the company completed its acquisition of iMeem, the music sharing service, which also published ActivityStrea.ms data about its users’ actions. It also comes the same day that Facebook announced it was making status updates from its users publicly available to the web at large — previously, the default setting was to only publish status updates to Facebook’s own platform or approved Facebook apps. The new APIs at MySpace will allow its developers to post users’ updates with the same frequency as Facebook and other services.

So, what’s going to happen next?

MySpace has long been eclipsed by Facebook as the hottest social network for individuals, but bands and musicians of all levels remain incredibly active on MySpace. Lots of musicians don’t even have a website anymore, they just have a MySpace page, and maybe a Twitter account. A handful of major clubs in every city book all of their shows using MySpace. If you’re in a band, you pretty much have to be on MySpace — like it or not. It’s one of the key web tools driving the music industry right now.

However, one big thing missing from MySpace’s music experience (well, one of the big things) is the ability for people to easily share a song they like. When an artist uploads a song, their status update provides a link to that song. But for fans, all music sharing happens through playlists, which are clunky.

If you are listening to a song and you want to tell all your friends about it, you add it to your profile playlist. That action shows up in your stream, and the song shows up in the player widget on your MySpace profile, (Here’s what it looks like). It’s only there as long as you decide to keep it there, and since MySpace only get 10 songs at a time, if you’re an avid music lover, chances are it won’t be there for longer than a day or a few hours.

Compare this to other popular music sharing services, like LaLa, Mog, Last.fm and iMeem, or even smaller ones like TheSixtyOne, and you’ll notice that it’s much easier for users to send a Facebook update or a Tweet about a particular song they like (and as many songs as they like) complete with a short link leading back to the page where their friends can listen to the song right away. They don’t have to deal with playlists or anything similar, they just share a link to that song.

It’s an elegant and direct way to spread music, which is why it’s become the standard for song sharing on every social network except for MySpace.

This open sharing, along with direct short URL links, is one of the most powerful forces for artist exposure, and for fans to express enthusiasm, driving the music business. For evidence of this, see Ted Greenwald’s post on our Epicenter blog, “Geeks to Music Industry: APIs Can Set You Free

,” about how open song sharing is changing the way people engage with and encounter new music.

MySpace’s music sharing system works, but it feels backwards and weird when compared to the rest of these tools. But with the purchase of iMeem and with the launch of these new APIs, we’ll probably see some positive changes quickly.

For MySpace’s sake, we hope so. The only reason for most of us to visit MySpace these days is to interact with bands. So, anything at all that makes it easier for users to like, link to and comment on songs, and to publish those activities out onto the web in real time would be a boon for the old beast of a social network.

See Also:

• Facebook Cracks, Here Come the Apps
• Why Facebook Shut Down the Only Useful App it Ever Had
• 8 Things on the Web We’d Like to Throw Down a Black Hole

So says Google’s Brad Fitzpatrick in a Twitter post Wednesday.

You can now use the URL of your Google Profile to confirm your identity on any website that supports OpenID. When the site asks you for an OpenID identifier, just plug in the URL of your Google Profile and you’ll be directed to Google, where you confirm the request.

OpenID Foundation board member Chris Messina has posted a screenshot of what the user flow looks like when using your Google Profile URL to log in on a website that supports OpenID:

Brad is one of the creators of OpenID and one of the driving forces behind Google Profiles. Google launched its public profile service, which allows anyone with a Google account to create a public profile on the web that shows up in Google’s search results, earlier this year. At first, Profiles were rather spare, but Google has slowly been enhancing the features of Profiles to include vanity URLs and support for microformats.

These profiles are advantageous over proprietary social networking profiles because of their high visibility in Google, the depth they allow, and because they function as a social hub — most people use them to point to their social presences on other sites. Not to mention that Google Profiles appear on the open web rather than inside of Facebook, where, by default, a profile can only be seen by people you’ve connected with on Facebook.

Webfinger, also referenced in Fitzpatrick’s tweet, is a new protocol Google is building into Gmail. It lets you attach any public identity data to your e-mail address. Learn more about it at the Google Code project site.

See Also:

• Google Profiles and Creating a ‘Social Hub’ on the Open Web
• Google Makes It Easier to Search for ‘Me’
• Google Social Search Adds Your Friends to Your Search Results

The site has enhanced its Share feature — the tiny “Share this on Facebook” widgets seen at the bottom of blog posts, videos and photos — to include live stats tracking. Starting Monday, publishers can see a live count of how many times a particular post or piece of media has been shared on Facebook.

The new live stats counter for Facebook Share closely mimics Tweetmeme‘s popular “Retweet” badges, or the live widgets that show the number of Diggs or up-votes on Reddit a piece of content has accumulated.

Facebook Share is getting some analytics tools, too. In addition to learning how many times Facebook users have shared a post, publishers can also see whenever somebody “likes” the shared post, leaves a comment, or clicks back to the original site from within Facebook.

It’s not the only tweak to Facebook’s real-time data flow the company has made to its site within the last few days.

On Friday, the Facebook home page for logged-in users was redesigned to show a filtered stream of updates. Rather than just showing a stream of every status update, every post and every “like” from within their network, Facebook users can now choose between a streamlined, filtered view and a raw, unfiltered view.

This change basically incorporates the old “Highlights” feed — the most important posts from your friends — into the main News Feed. The result is a stream of the most interesting or important stuff that’s been posted within the past couple of days.

The new filtered News Feed is now the default. The more times a post is commented on or liked, the more “popular” it becomes. An algorithm determines what goes into the feed and what stays hidden. The old “Highlights” box is being removed, as it’s now redundant.

The Live Feed, which can be accessed by clicking on the new “Live Feed” tab at the top of the home page, gives a more immediate, Twitter-like stream. It displays all of the recent activity, posts and updates from you and your friends, regardless of popularity.

The odd thing here is that one of these changes brings Facebook up to speed with its competitors in the real-time content sharing game, while the other change sets it back.

Publishers want to know how their content is doing out in the wild, so the new Share tools make sense.

But in altering the News Feed in the way it has, Facebook actually becomes less of a real-time news source for its users. By adding popularity filters, important stuff might not bubble up into your News Feed for hours or days. I just looked at my News Feed, and the newest item is four hours old. If I really want to know what my friends are doing, reading, liking and talking about right now, I have to switch over to the Live Feed. Luckily, this is as easy as one mouse click.

But what does this say about the proliferation of real-time data streams on the web? Publishers always want better real-time data, but do users? Are regular people by and large tired of the massive firehose of updates their favorite sites now all offer? Is it all becoming just too much?

If so, Facebook made the right move with the News Feed changes. If not, hey, there’s always the Live Feed option one click away. Or there’s Twitter. And if you want a real-time stream you can filter even more minutely, you can turn to FriendFeed or Cliqset or Plaxo Pulse.

If the changes to Facebook’s stream bothers you — and judging from the comments of my own Facebook friends, the changes aren’t being seen as that friendly — they are easy to alter. Facebook Insider has an excellent post showing how to change your feed settings. Additional tips are in the comments.

See Also:

• Bing Is in Your Facebook, Indexing Your Status
• Let’s Be Friends: Facebook Acquires FriendFeed
• Facebook Cracks, Here Come the Apps