We announced OpenID support last week. I then responded to some comments asking us why we were a provider first, rather than a consumer. Now, I’m answering some more comments basically asking why they should care about OpenID and how it helps SmugMug customers.
Honestly, I had no idea it wouldn’t be obvious how great this is. To me, the picture seems perfectly clear. There are no dastardly designs or secret agendas – to me, it just makes sense. Here’s are a few reasons why:
We are a pay site. Every SmugMug customer pays for the right to share their photos here. They get what they pay for. That comes with both pluses and minuses where identity is concerned, though. On the one hand, we have a much much stronger relationship with our customers than somewhere free like Hotmail, for example. On the other, we have no good mechanism to interact with viewers, who don’t and shouldn’t have to pay (or even sign up) to see their friends’ photos.
Let’s talk about the pluses first. There’s a much higher level of trust and respect between the customer and SmugMug than a free email provider. They feel secure in knowing that we treat their data carefully and with respect. They consider SmugMug to be their home (or at least a major part of their home) online. They strongly identify with the brand and even more strongly identify with the fact that their memories are stored and shared from our servers. They identify with us.
Do you see where I’m going with this? While everyone has multiple identities online, from email to IM, blogs to photo sharing, the ones where there is a volume of priceless content, such as their photo-sharing site or blog, are the ones our customers identify with the most. Email addresses are “less permanent” since they’re free, easy to forward, etc. Ask your typical passionate Flickr or SmugMug customer, though, and they’ll tell you about their passion for their photos and the pain and anguish it would cause them to move or if the service died. Note that not everyone falls into this category – but those passionate about photo sharing *do* fall into this category, and that describes every SmugMug customer.
Further, I believe the customer should get to choose which site they identify with most. I’d hate to limit them to only their email provider if they happen to hate their email provider. Just like everyone resonates with different brands of cars, jeans, computers, music, etc, they also resonate with different sites. Leave the power in the hands of the customer – let them choose their own identity.
Now, let’s talk minuses. Since there are no free accounts at SmugMug, we can’t interact as well with our viewers. They’re allergic to setting up “yet another account,” something I resonate with, or even passing over their email address. I completely get that – it really really sucks when you go to view someone’s photos at KodakGallery or Shutterfly and they demand your email address so you can get spammed till the end of days. It also sucks when you want to leave a comment at Flickr but can’t without signing up for a Yahoo account. What a pain.
OpenID goes a long way towards solving some of these problems. Comments can now be far more spam-free since identity can be verified, yet the commenter doesn’t have to go through the hassle of signing up for yet-another-account. Access controls to photos and galleries can be specified by the owner of the photos in such a way that sensitive data (like email addresses or passwords) no longer has to be exchanged. Even if we wanted to, SmugMug couldn’t spam someone using their OpenID to leave a comment or view a photo. That’s big – I hate giving my email address out to sites because so many of them *do* spam, you’re never sure which ones are the “good guys” like we are.
OpenID isn’t perfect. There’s no trust here – just identification. There’s still no complete single sign-on. There are issues with dangling stale IDs being left around. Consumer education is going to be interesting. But it’s still a huge step in the right direction. Just verifying that someone has an identity somewhere online gives you the ability to make your apps richer, regulate abuse more easily, and generally improve the user experience.
What’s not to love?
I hope you’ve heard we now support OpenID. If not, now you have. 🙂
A commenter asked politely (after deleting his first rant) why on earth we were being a provider, when being a consumer was more important. I completely disagree, and here’s why:
We should be both. And we will be. But I believe in releasing features quickly and incrementally, so I had to choose one or the other. I chose being a provider. Why?
You can’t sell lightbulbs to those without electricity. You can’t sell gasoline cars to those without access to gas stations. You can’t consume OpenID if there’s no-one who has an OpenID.
Up until AOL’s announcement, LiveJournal/SixApart was the best (and only?) source of OpenIDs on a reasonable scale (100,000+ users), as far as I know. That’s really not very many users. I figured throwing our 100,000+ into the mix would help. I certainly hope it has. AOL, though, threw 63,000,000+ into the mix – so now we’re even closer to a critical mass.
This is a chicken-or-the-egg problem, and I believe you need lots of providers with established user bases to jumpstart it. I’m glad there are tons of brand-new OpenID providers who’ll give you an ID for free – but I believe the real make-or-break metric will be existing services enabling huge chunks of people in one fell swoop.
We just swooped. 🙂
On a side note, while I rarely whine about our lack of coverage (generally, I believe the best way to get coverage online is to buckle down and improve your product), I was surprised to see our OpenID news fall on the net in complete silence. More than 30,000 people read my blog on Friday, but not a single blogger or news source I’m aware of picked it up. Digg can announce that they’ll have support “later this year” and get tons of coverage but we enable more than 100,000 people overnight, making us the 3rd largest OpenID provider on the planet, and no-one cares?
We didn’t do this to get coverage, we did it because I’m a geek and I think OpenID rocks. But a little, tiny bit might have been nice. I guess my “improve the product” theory doesn’t work after all. Can someone enlighten me as to what I’m doing wrong?
Oh, and I’m sorry for the whining. I’ll try not to let it happen again. 🙂
The subject says it all and I’m thrilled. Here’s some details:
- We’re an OpenID 1.1 Provider. Hundreds of thousands of SmugMug customers can now use their SmugMug homepage URL as their ID on sites all over the net.
- We don’t yet support Diffie-Hellman association, so if plaintext isn’t ok, you’ll have to fall back to dumb mode. Sorry about that. I’m hoping we can support DH soon, but I’m really waiting for Wez’s PHP patch to use OpenSSL’s functions. I may end up creating a custom build, we’ll see.
- We’re planning on consuming OpenID for photo comments and other things shortly.
- We probably have bugs. Sorry about that – let me know and we’ll get them fixed.
I’m a little worried with the direction OpenID 2.0 seems to be going – one of the great things about OpenID is how simple and easy-to-implement it is. I haven’t taken a good, close look yet, but the preliminary 2.0 spec seems to be complicating things a great deal. I see that as a Bad Thing(tm) but maybe I’m smoking crack.
The documentation for OpenID leaves a lot to be desired. Specifically, there’s no example messages, including sample values, for you to make sure your code is doing the right things. Luckily, the spec is so simple that some trial-and-error takes care of things, and someone has written a great narrative overview of the implementation. I will put up an OpenID page on our wiki that includes example requests and responses, including secret keys, so anyone else implementing this from scratch has some values to work from.
LiveJournal (and thus, Brad’s CPAN module used by lots of other services) seems to have some bug in it where it doesn’t like OpenID server URLs without a trailing “/”. It returns a useless (to me?) error message: “naive_verify_failed_network” which meant I spent hours and hours of time going over my code with a fine-toothed comb. Finally, out of ideas, I made a 1 character change to my HTML and everything magically worked. I don’t understand why, since the docs don’t state this, and Vox seems to have an openid.server without a trailing /, but oh well. It fixed my problem. 🙂 Hopefully this will help someone else figure out what that message might mean.
There are clearly still issues around OpenID, such as what happens years from now when your OpenID identities are lingering out there long after you’ve closed the account from which the ID was provided? Someone else may even own or use that old URL if it’s been repurposed. But there seem to be smart people thinking about the problem, so hopefully everyone will figure it out without bloating it or making it unusuable.
I think OpenID is huge, and I’m glad we’re able to move the ball up the field a few more inches.
Man, I love the company we’ve built!
We had a bunch of SmugMuggers in from out-of-town this week and, being a fun-loving photography company, we had to get some shots of our employees. Since our Help Desk is manned by Support Heroes, we thought a Super Hero theme would be appropriate. 🙂
I’m blue-and-gold Wolverine, above, with my co-founder and father Chris MacAskill as J’onn J’onnz aka Martian Manhunter. Last night four of us even showed up at the YUI party at Yahoo’s HQ with our faces still on. It was a blast – congrats to YUI on their first year!
Below, you can see the half of the company that was in Silicon Valley this week. Can you name each hero?
Lots more shots, including close-up portraits, in the gallery.
I’ve been hounding GreenJimmy, our resident Web SuperHero, to write up our approach to solving the Browser History problem when using AJAX apps. I wrote in broad terms about our solution (and how it worked on Safari, the tough one, in addition to Internet Explorer, Firefox, etc), and promised that Jimmy would update his blog with a detailed explanation.
That was exactly a month ago, and Jimmy has written exactly nothing. I guess I need to employ more Lex Luthor management techniques, because clearly I’m sucking in the boss category. 🙂
Luckily, our friends over at Yahoo have a new Browser History Manager in the latest YUI release, and it does the same thing we did in the same way. Best part? They actually wrote up how they did it so the rest of the world can use it. So if you’re curious as to how to get Safari to behave with proper history, including full back/forward button support, go read up.
Many apologies for everyone waiting around (and emailing me) for our solution. Many thanks to Yahoo for stepping up to the plate and sharing.
Today, the YUI blog mentions they’ve released a great new version. As you probably know, we’re a huge fan of YUI – we couldn’t have done our fantastic new UI without it. We’ll be at the YUI party this week, celebrating with everyone else.
When talking about the new Browser History Manager, they mention that “No one, as far as we know, has resolved the technical issues in a satisfactory way across the A-Grade.” Alas, that’s just not true – SmugMug has solved this technical issue, and we did it first. What’s more, the YUI team knows about it – we had lunch with them and told them exactly how we did it. Their Safari implementation is exactly the same as what we did and explained. We even offered to give our code back to them under a BSD license so they wouldn’t have to duplicate our work.
It looks like they missed one technical detail of our implementation, though. Safari has an issue with “permathrobber” (basically, the Safari throbber never stops throbbing) which we managed to solve.
Note that I’m not upset that they have a great Browser History Manager – far from it. I just wish they’d give us a little credit where credit is due, given that we pimp YUI any chance we get for them.
We built it first, they know it, and sharing the love is the right thing to do.
UPDATE: Just called Yahoo and the love is still flowing. 🙂 Turns out the two guys who wrote the Browser History Manager are new to the team, weren’t at our lunch, and had no idea what we were doing. Great minds think alike. 🙂 And Yahoo can’t accept our code currently, even under a BSD license, but they’re working hard at getting that changed. Sounds like an internal big-company roadblock.
We have a bunch of SmugMuggers in town so we’re getting together with Thomas Hawk and anyone else who wants to go shooting in San Francisco. Should be a blast, and with Thomas and Andy on board, we should get some great shots.
If you’d like to come, bring your camera and show up!
Also, as most of you probably already know, we take groups out shooting fairly often, to places like Yosemite. The next upcoming one is Wild Utah, hosted by one of our artists-in-residence, the incredible Marc Muench. I believe there are 5 slots left if you’re interested in shooting with the pros.