I'm going to attempt to keep this short and simple, because so many others have already done a great job documenting, giving examples of use, and extending oEmbed that it'd be silly of me to rewrite all of that here.
However, since I've never mentioned oEmbed here on my site, I wanted to quickly go through how it came to be, how I got involved, what it is, and who is using it so far.
I wasn't in the room, so I can't be sure without asking the four most involved people in the development of the spec, who was the "inventor" of oEmbed. It was either Cal Henderson, Leah Culver, Mike Malone, or Richard Crowley. Leah, on her blog, says that they were all at dinner and were discussing this solution. So we'll give them all credit.
I got involved, not the with the development of the spec itself, but with implementing it in one of the first providers of the spec, Viddler. Mike Malone, who is a friend of mine who happened to begin working at Pownce, the first consumer of the spec, told me it'd be a neat idea if I implemented oEmbed early-on for Viddler. I took one look at the spec and immediately thought it'd be a good idea.
If you are like me, then you think of the World Wide Web as a library of information. This information has a wide range of media types. Just like in a library, there are countless numbers of books each having their own pages, photos, words, etc. However, if I said to you - go pick up John Steinbeck's The Grapes of Wrath, turn to page 157 (which is the first page of Chapter Eleven) and let me see it - you could do that pretty easily.
Now, think of that page 157 as a URI. You're probably used to seeing the acronym of URL, which rolls of the tongue much easier, but URI or Uniform Resource Identifier, is a much more proper term. So it is an unique identifier for a resource. In the case of The Grapes of Wrath, the resource is just plain old text. But on the web we have URIs that link us to text as well as photos, audio, and video.
If I were to link you to this URI and you followed it, you would see that its primary purpose is to show you my iPhone macro lens video demonstration. Viddler is the book, my video is the page, the video itself is the resource.
Get it? Got it? Good.
Now. Lets say that you were a developer and you wanted to allow people to link from your application to a any resource on the Web, and embed that resource into your application directly. Here is a quick example, which at this time does not yet exist but I think it should. Lets say that you are having an instant message conversation with me and you give me a URI to one of your photos on Flickr. Wouldn't it be neat if that photo automatically showed up, as a small thumbnail, within our conversation just because you linked to it? This is the type of innovation oEmbed allows for.
It would seem that oEmbed.com's "Providers" section is being maintained, so that'd be the best resource to see who are the providers of oEmbed so far. It doesn't seem like the "Consumers" section of the site is being maintained, as I'm fairly sure more than just Pownce is using this. I think Lijit might be experimenting with it, but it may not have gone live yet.
As of this writing Flickr, Viddler, Qik, Pownce, Hulu, and Revision 3 are providing end-points for this service. You can navigate to the documentation for each of these service providers by going to oEmbed.com's Provider section.
I think if you are a potential provider of oEmbed you would do well to add it to your development roadmap to implement it when you can. If you are developing an application where you think oEmbed would come in handy, and you need any help - don't hesitate to ask me or any of the people I linked to above. I just got an email last night letting me know about the tutorial on Webmonkey for oEmbed, so it won't be long before the press of the existence of oEmbed begins to turn into tutorials for use and then I hope a large number of implementations are announced. Like the IM one I mentioned above, I think that'd be awesome.
Until next time, I'm going to Pownce some Viddler videos.