I ran across some great posts by Fred Stutzman about the whole debacle. Fred has some great comments in there and good insight to why such a screw up is really such a screw up.

Lesson #1 in community building/management: community feedback is critical to the success of your product. The Facebook community does not like these new features. Guess what? They can (and will) vote with their feet here and either a) not use Facebook b) use Facebook less or c) go somewhere else. I find it ironic that Facebook overlooked the key component that has made them successful; their community. Facebook, MySpace, even Digg and Slashdot are sites that are meant to cater to the needs of their communities. If you don’t meet those needs, users leave. If you piss them off, they revolt. This is a pretty simple formula.

Facebook replied effectively saying “Relax, Breathe” … and what? Get over it? That’s nuts. The first thing I would have done? Pulled the features. Yep, that’s right. I would have reverted immediately. Actually waiting a little bit longer to pull the features might be good for them. They might actually achieve the New Coke formula fiasco that actually resulted in a major win for Coca Cola. Make a big splash today about removing the features and your users will thank you. Not only that, they will be that much more loyal.

What would have been a better way to go about this? With large social networks like this you can’t introduce features like this with the flip of a switch. Was there any testing done? Any feedback from users? In fact, did the users even ask for it? If I were Facebook I would launch, you guessed it, labs.facebook.com where they could vet new features and engage the users so there aren’t any surprises. There will always be people who don’t like change or new functionality. However, if you can sway the early adoptors and thought leaders, that impact will be much less.

Update: It looks like the folks at Facebook have listened to their users. Great news.

OpenID started with a very simple assumption by one guy. Its grown over time and is really starting to mature as a protocol. Sometimes it takes a person who can just say “screw it, I’m doing it this way” to get something going. I call it the Firefox Effect; two or three people that solve a major pain point can gain adoption quickly. Blake and Ben did it with the original Firefox; not everybody in the Mozilla world was really excited with that product when they did it. Had you gone back to the drawing board from the start and said “Let’s build Firefox” with a team of developers and stakeholders it most likely would have failed. The same thing is true with OpenID. Something like that requires a big push, minimal tact and a serious pain point.

Although announced awhile ago, Sun finally released their Open Source Single Sign-on solution on Tuesday.

It’s great that Sun is embracing open source by releasing their products under the OSI-approved CDDL. I can see some great applications for OpenSSO in the higher education space that is leveraging a lot of Java technologies already. However, I’m still left thinking this is another attempt by a big company to say “Hey! Internet! Come build an eco-system around our product! Look, its Open Source ™!!” Yes, I’m biased. I think there is a better way with OpenID.

OpenID really is a grassroots, bottom-up approach. For something like this to be compelling there can be no hook back to the “mother ship”. Its truly got to be open and decentralized and that’s one of the main reasons people are finding it compelling. Has federated identity failed? In the past, yes. I believe in 5 years, there will be a federated identity that people use all over the Internet; you’ll have one login and it won’t be controlled by anyone but you. OpenID is hopefully going to be the driver of that; the HTTP of identity. Nobody but you should own your identity.

If I create today an identity say at `bob.foo.com’, can I move that identity later to a different location? Say my initial identity is hosted by my employer, and I switch jobs, I would like my identity to come with me; For instance are there mechanisms to:

* Not depend on the actual string `bob.foo.com’, but some actual key generated that actually is hosted in bob.foo.com?

* Be able to fetch the data so I can later host it at bob.newdomain.com?

This is not the first time time we have heard this question come up. My advice today? Make sure you pick an OpenID that you’d like to have for a long time. There isn’t a solution for this yet as most of the solutions out there today (for example, i-names) require some sort of centralized registry. (Full disclosure: JanRain is bringing up an i-broker as part of the i-names eco-system). The main premise around OpenID has been de-centralization and simplicity. Having a centralized registry flies in the face of that as well as adds another level of complexity. What I’m saying is I don’t have an answer for this, but again, I believe the community and marketplace will solve this problem in the very near future.

I should also mention that from its inception, OpenID was meant for really light-weight applications. Yes, its maturing and adding new functionality that makes it more robust. However, if you change your blog from LiveJournal to Wordpress today you can’t take your posts with you and more importantly your “identity” with you (unless of course you leverage something like claimID).

Finally, OpenID also has the concept of delegation. I can have two lines of code HTML on my site and delegate that to some identity provider. View source on Brian’s page to see an example of delegation in action. Its not ideal, but its definitely a start and it does give users more of a sense of control.

* What kind of security is there to prevent someone breaking into one of the openid servers from pretending to be me?

Today, it is a strong password. Versign recently proposed the concept of security profiles. The ability to choose the level of security you use for different applications. For things like blogging or commenting in forums probably don’t require heavy authentication. As we move into the realm of doing more “important” stuff with OpenID’s, these profiles will be critical and give the users choice in terms of picking how much/how little security they want. I also see the opportunity for value-adds in this space on top of OpenID as great business opportunities. However, it all starts with a unique identifier and that identifier is your OpenID.

These security profiles will hopefully go a long way towards addressing possibilities with man-in-the-middle and phishing attacks. DNS poisoning is also still an option but IMHO one of those “The Internet Sucks ™” problems.

Are there any available OpenID servers that I can run myself?

As a matter of fact there are. Shameless plug: we’ve developed a PHP Standalone Server that is open source and soon to be part of the ASF Heraldry Project. In addition, Verisign will be donating the Ruby on Rails code base that powers their PIP identity provider to the Heraldry project as well. I’m sure we’ll see versions of these servers in many more languages soon as the libraries start to mature and proliferate.

Now this is pretty cool. Imagine if you hooked in some free OpenID mojo to this. You could have your own custom domain that would be automagically OpenID enabled. This could be huge for AOL if they decide to look seriously at OpenID … the time is now!!

Very exciting news but probably not so good if you’re a registrar.

Every kid out there with a blog and a hosted machine is starting something new. Mash-ups are king (queen?!). Build a widget (and its hilarious that people are actually calling them this) that can get put up on MySpace and you’re a shoe in for being the next big thing.

We’re entering an era of instantaneous innovation. Ideas are flowing from blogs, user comments, user feedback, etc … People are throwing ideas up against the wall and some of them are sticking (while of course most of them are complete garbage). What is really interesting is that its not always about being first with the idea. Execution, position in the market and ‘reputation’ in the space are becoming the defining ingredients for success. Let me give you an example.

Meebo launched late last year and it fantastic. The out-of-box user experience was fantastic and it quickly gained momentum. Yes, I’ll say it; Meebo has hit a “tipping point”. Users are flocking there. MeeboMe launched with much fanfare last week. Its a really interesting premise. Embed the MeeboMe flash widget on your web page with the smallest bit of JavaScript and then login with your Meebo account. Voila, now you can not only get instant messages from your visitors but you can message them!! Alright, alright. This sounds like it could be annoying. However, imagine if you tie this to site heuristics. “Hmmm, this user has a full shopping cart but keeps flipping back and forth between this specific digital camera.” No problem, “Excuse me” you say through the MeeboMe interface, “Can I help answer any questions for you on digital cameras?” Wow. That could be cool. Or that could be totally annoying. But that’s not the point.

We’ve seen this before. Anybody heard of Chatango? It is essentially the same thing but its lacking the hook and eyeballs of existing users. This speaks to Guy’s top 10 lies startups say; if its a good idea, 5 other companies are working on it. What Meebo has been able to leverage is the fact that they have thousands of users, users that would be ideal for Chatango. However, since they use Meebo every, single day they end up hearing about MeeboMe and driving its adoption much quicker. The added benefit for Meebo is that MeeboMe is on their network; it doesn’t depend on the “bigs” IM networks.

Alright, so back to my points. Execution, position in the market and ‘reputation’ in the space. Looking at Meebo they have executed brilliantly (albeit with a few hiccups in getting the service out there). They have the perfect position in the market for this sort of application; users that IM all the time. Finally, they have a great ‘reputation’ in the space. I say ‘reputation’ in quotes because it can mean so many different things to so many people. This is best explained with an example.

Digg owns the social news space. Their users are rabid about Digg so much so that when Netscape launched a clone and tried to buy Digg users it it had the effect on Digg like when Coke changed their formula. It drove more people to Digg. Its hard to beat the power of grassroots marketing. Thousands of passionate Digg users out there angry (and complaining) about Netscape doing what they did had an amazing effect on adoption for Digg. Digg has a great ‘reputation’ in their space. They are the thought leaders on it and as such, even though anybody can copy them, they are continuing to grow.

(As a side note, I was having dinner with a friend from college – not a techie – and he asked me, “Have you seen this thing Digg?!”)

So back to Meebo. People love Meebo because they provide a great service and are fantastic at dealing with user feedback. Nothing like really engaging those early adopters to help drive your platform forward. As such, there will be clones, but Meebo will continue to dominate (as long as they don’t do anything evil).

The future of innovation and this crazy Web 2.0 space will manifest itself in true thought leaders that listen to their users and generate that loyalty that will drive their products/services/brands forward.

A thousand apologies go out to Gabe and the folks at AmSoft from me for not getting this news out sooner!

Way to go Chris and way to go to the BarCamp community the world over. I’ll be joining folks at BarCampPortland that weekend to join in the celebration/fun/antics. Hope to see you there!!

OpenID is an open platform for doing authentication. It just so happens that its being enabled by a bunch of open source code. Last week we announced the Bounty Program for open source projects as a great way to get OpenID integrated into the tools that people use to deliver their blogs, forums and websites. What a great way to give back to the community that has given us so much.

You can use OpenID on your website, open source or otherwise. We use it on ours and its not an open source application. Heck, that’s our bread and butter! Using OpenID on your site enables you to leverage the millions of OpenID users that are out there today and get them engaging in your site quickly and most importantly painlessly.

So, thanks Marc for making that point! I owe you a beer when I see you next week!

Oh yeah, and I’ll be there too! Hope to see you there!!

Updated: Kaliya mentions that this event is for everybody and anybody interested in OpenID; not just open source folks. Come one, come all!!

As I mentioned in my last post, OpenID is a decentralized, light-weight authentication mechanism for the Internet. It doesn’t do trust, reputation or much of anything else today. However, it is an open platform that anyone can participate in. The OpenID community believes simple is good and that having an open platform means more people are likely to use/develop/engage than if it was driven by one vendor or consoritia.

Alright, so let’s dig in. The first concept to understand is the Identity Provider (IdP for short). The Identity Provider is where the user serves up their identity. It’s a URL. In my case, I am http://kveton.myopenid.com. Now, I could easily be http://kveton.com or http://scott.kveton.com or http://scott.really.likes.openid.kveton.com but I chose to use a third-party IdP to deliver my identity for me (full-disclosure: myopenid.com is a free product developed by my company JanRain). Since OpenID is an open protocol, I could host my identity on my Linux machine at my house behind my DSL line if I want to. This is entirely up to the end-user (and of course their ability to deploy their own IdP if they choose that path).

Here are some screenshots of the IdP that I use:

The first one is the main screen when you show up at MyOpenID.com. Clicking “Sign Up Now” takes you to the sign up page (the second screenshot). Finally, the last one is of me actually typing in my OpenID of http://kveton.myopenid.com into the IdP and logging in.

(My point here isn’t to show off our IdP. There are plenty of other IdP’s that have a lot of the same functionality. Verisign has one. Four Kitchens has one. Pretty soon everyone will have one! But I digress.)

Now for the next round of snapshots!:

The first one shows your “homepage” when you login. This is really just a place for you to administer your personal information, etc. The second shot shows you the sites that I have listed as my “trusted” sites. More on this in a moment. Finally, you can see the rest of the information that I can fill out that can be used on other sites. Again, more on that in a moment.

So let’s see this in action. Remember, I already logged into my IdP so I’m ready to hit the Internet and find some sites that support OpenID. A great example is Zooomr (aka Flickr on steroids:

The first shot is of me entering my OpenID into Zooomr to login. The second shot is the interesting one.

Zooomr sees that I’m trying to login with http://kveton.myopenid.com. Zooomr heads over to that URL to authenticate me. Now, since I’m logged in, I get presented with the second screen above. If I wasn’t logged in, I’d be asked for my password. As you can see, Zooomr is asking for some information form me. This utilizes something OpenID v1.1 called simple registration. We realized that without some bit of information about the users, sites that would implement OpenID would actually take a step backwards which was a bad thing. So simple registration (SREG) was added to the specification to allow the transfer/exchange of 9 different attributes about the user. As you can see in the screenshot, the user is asked if they would like to give up some information (in this case, nickname, full name and email) and what duration they would like that to last for. This is great and super powerful for the users; now they know what they are giving to the site in question. Very cool.

I know what you’re thinking; only 9 attributes?! That stinks!! Well, we agree but we’ve got to start somewhere and that’s where we started. Remember, OpenID is simple and light-weight. Moving attributes back and forth is really a profile exchange issue; one that will be addressed soon. Lots of folks are thinking about this right now and OpenID v2.0 will have the means to let those things hook in seamlessly.

The third shot shows what the user sees after they agree to the information exchange. Voila. Okay, great. We’ve logged into a site. What did that do? More importantly, what now?

The first shot above is the list of trusted sites that I have for my identity served up by my IdP. Notice that “anything.zooomr.com” entry now? Anytime I go to Zooomr now (unless I clicked the “For this session only” button when logging in) I’ll be automagically logged in. The next shot shows me going to another site, schtuff.com (full-disclosure; JanRain site), where I already have “anything.schtuff.com” in my trust list. Since I’m logged into my IdP and since I already trust schtuff.com, I’m logged right in. Up in the left hand corner of that screenshot you’ll see my OpenID URL and links to my site preferences, etc. All very seamless, all very simple, all very easy.

So that’s the OpenID walk through in a nutshell. Now go spread the word about how great OpenID is!