Short answer: working.

Check out the new and improved Fan Profiles: http://sportsnation.espn.go.com

Check out our wildly popular Facebook game: http://apps.new.facebook.com/fightforthetop/

Grab some of our new and improved widgets: http://widgetcenter.espn.go.com/

We've also been reading up on XP and Scrum methodologies in preparation for a group offsite in September.

And make sure to keep an eye out for an awesome new feature coming soon to a Fan Profile near you...

Scanning Google Reader this morning, I noticed "Corporate Blog" in one of my headlines, and I prepared myself for another usual bashing.

Fortunately, Don Reisinger's Mashable post accurately summarized my feelings on such blogs.

I wrote about some of the nuiances of operating a corporate in our first post, and since then, I've sometimes been frustrated with some of the limitations we assume when writting a corporate blog. And yes, I still cringe when I read corporate blogs that would be better off labeled "Press Release".

Still for those with even the slightest ability to take the good with the not so good, corporate blogs provide valuable insights into what the company's up to.

How else could I tell you that we are scrambling toward a big relaunch of Fan Profiles?

Also, as Reisinger points out, these blogs can give companies a face instead of being brick and mordar. We make a concerted effort to be honest and interactive. We've enjoyed going to conferences, working with developers in Google Groups and eleswhere.

I just hope we can get more involved and encourage more of the company to do so, too.

MySpace will launch its Data Availability later today (see here and here), beating Google and Facebook to the punch.

Unfortunately all three will be pretty much useless to us.

First, there are legal issues with sharing data, which I wrote about previously.

But that's not the biggest problem. None of these services will allow you to store anything beyond simple ids (no social graph, photos, etc). In MySpace's case, a developer can't even cache this data.

So every time we render a page, we'd be calling out to MySpace. The performance implications of doing this would relegate potential asewome data to a buried link, like "See my MySpace data". Vomit.

Let me know when we can sync. That's what data portability really is. I want to be able to upload a photo, add a friend, remove a friend, write a comment or change my first name, and have it appeaer across all my social networks. I want to see relationships. What team is most popular among MySpace users? Between MySpace and Facebook users, who is more accurate at picking scores and winners?

Sure, this may be a boon for sites that don't have any compelling user data of there own and get virtually no traffic, but those sites aren't relevant anyway.

Until we can sync data across social networks, all this "Data Portability" is just PR.

Steven Hodson wrote a nice post about the absurdity of a newspaper deathwatch.

Sometimes, people in our industry never cease to amaze me with how myopic they are. Couple quick points. When we say newspapers are dying, are we talking about the physical paper we hold in are hands or are we talking about the industry itself? Both are fairly ridiculous, but I would be willing to  entertain the notion that the physical paper may be on its way out with this green movement and technology shift. But to assume that, say, the nytimes.com will be replace by a network of blogs is patently absurd.

Sure, blogs like techcrunch, mashable and the usual suspects often scoop traditional media, but technology is one of hundreds of topics newspapers cover.

When blogs start covering local townhall meetings and writing features and ride-alongs, then we can talk.

As I was writing my last post about the arms race between the client and the server, a thought crossed my mind.

Why has the social networking arms race come down to Facebook and Google?

Facebook is #2 in the social networking space and Google is #I-don't-care. Why? Because Google doesn't have a viable social network.

Don't bother with Gmail, YouTube or Okurt.

Okurt isn't in the same league as Facebook. Just trust me on this.

Gmail, YouTube and whatever other Google properties aren't social networking sites. Just don't try to make that argument.

That's like saying Hotmail, the LA Times or Amazon is a social network. Stop it.

So then I read the Cold War comparison( more here ), and I realized it was very exaggerated and not really true, but made for an interesting headline and topic. (Well played, Duncan, well played).

So Google is trying to tip the dominoes. With the release of OpenSocial and FriendConnect, Google is trying to get other countries, er, ah, sites to join them and thrust itself into the social networking scene. As more fall, more will be more likely to fall, or something to that effect.

The problem is, Google is shooting blanks, and Facebook is still firing back, playing right into Google's hands.

Google opens. Facebook opens some more. Google opens even more. Facebook... you get the point.

The difference is, people actually care about, and can build applications around Facebook's openness.

It's like poker, but not. Google is getting Facebook to go all in, but Google is playing with house money. Why should they care if they lose?

On the other hand, if Google can accumulate second-tier sites and entice Facebook into blowing open it's doors, there is an open conduit from Facebook to thousands of other sites, and that conduit is Google.

If I were Facebook, I'd call Google's bluff before I lose the only thing valuable I have.

So TechCrunch confirmed that Facebook will be turning their application framework into an open-source project, meaning that pretty soon, anyone who wants will be able to host Facebook Apps on their own site.

The details are still scant at this point in terms of what features will be available and how it could/should/would be implemented.

But I'm guessing it's going to be pretty much exactly like OpenSocial.

With one rather enormous exception.

Facebook Apps rely on server components. To make Facebook Apps stupidly simple. A Facebook server makes a request to your server, your server returns markup and wawmo, you have a Facebook App. What you want your server to run is up to you. The Official (cue the Choir and sunrise) API is implemented in PHP, but has been ported to ActionScript, Ruby, Java, blah, da, blah, blah, blah.

OpenSocial requires no servers -- aside from the one(s) acting as the host/shell/container/whatever-you-want-to-call-it. So, in theory, and I guess, in practice, you could build an entire OpenSocial app with no server, relying completely on client-side Javascript. And really that's your only option.

Now, pros and cons aside, many have wondered whether Javascript is the wave of the Web X.0 future because of it's ubiquitous nature and nearly absolute install base.

If OpenSocial with its client-side glory comes out on top, it would go a long way in proving that is true.