Inhouse registration vs. OpenID vs. Google Friend Connect vs. Facebook Connect vs. (etc)

It really depends on the type of site and who your users are.

We looked at the possibility of using OpenID for our e-commerce store (we sell apparel), and the conclusion was that we would be flat out nuts to implement it. I'm not the smartest software developer in the world by any means, but if I could barely wrap my mind around it enough just to get an account for StackOverflow (Why do I have to go to some third party provider? Why should I trust them? What happens to my account if they go under? As a business, what do I do if a customer asks me to reset their password?), then it's not just anecdotal to say that our customers would have problems with it. In addition, for any e-commerce business, it's usually unwise to take on a third-party dependency unless carefully considered, and especially for something as critical as logging in. If a major OpenID provider were to go down, you'd be losing sales. If we implemented OpenID, it would definitely be an alternative, red-headed step child implementation when compared to the native sign in mechanism.

Even with our in-house registration of e-mail addresses and passwords, we had to use an Amazon.com style login form because users kept filling out the "new customer" form even when they already had an account:

Login screen. Amazon's sign-in screen remains a model to be emulated, minimizing the common problem of new customers who try to log in without having registered. Amazon presents two questions in linear order: (1) "What is your email address?" and (2) "Do you have an Amazon.com password?" For the second question, users can select one of two radio buttons: "No, I am a new customer," or "Yes, I have a password." Many other sites present the new- and established-user sections side-by-side, and thereby divert new users to the established-user section through the magnetic attraction of type-in fields. -- Jakob Niesen, answered 2008-12-09T04:28:51.223

It really isn't a lot of work. For a project still not even close to being public I downloaded Dope OpenID and after just a few hours (mostly spent doing CSS/HTML work which I really hate) of playing around I had a login procedure setup that looks and works like the one you see when logging in to SO.

For example.. if you allow both the in-house registration and openID, what percentage of your users are using OpenID?

Now when you can use you yahoo, AIM and GMail login as OpenIDs there is really little point in creating your own user verification and have to worry about salting hashes correct and about things like if users failing to login 3 times/second should be banned for a few minutes, restoring passwords when users have forgot about them etc.

You can of course provide an ordinary login as well but then you would still have to carry all the good stuff that OpenID lifts from your shoulders. It is not that frightening to ask the users to register gmail or yahoo account they can use, most of them probably have one already.

If you will need to maintain state information about your users (preferences and such) then you probably should provide your own user/password mechanism. This does not stop you from allowing users to take advantage of OpenID and its ilk. The question you need to answer is how much time should you devote in your project to supporting more than one method. Like all design decisions, there is a cost and a benefit to everything. Weight them both and pick the answer that fits your budget.