I told you we’d listen.

After Philipp brought the issue up, we carefully listened to both our current customers and our potential would-be customers. Our current customers were a mixed bag. Luckily, most didn’t care one way or the other. Of those who did care, many didn’t want this change. But it was clear that lots of potential customers did. And as I said in my initial post, “Philipp is absolutely right.”

So we fixed the problem.

We made two big mistakes with this situation, one technical and one around setting user expectations. I was dumb for using autoincrement IDs alone, and we were dumb for calling the gallery setting ‘Private’ when that wasn’t clear enough. “Private” means different things to different people, and we should have known better. Both of these things, I believe, have now been remedied.

Here are the gory details and we have a dgrin thread with more:

• Your new galleries, photos, and videos are more private, and secure, than ever before.
• GUIDs did turn out to be both messy and expensive, as I thought they would be. We opted not to go that route.
• Instead, we created Keys for galleries and photos/videos and appended them to the relevant URLs. Kudos to Barnabus for planting this seed.
• The keys are made of 57 possible alphanumeric characters, and are 5 characters long, making the search space 57^5, or 601,692,057, strong. In theory, still guessable, but in practice, prohibitively expensive/difficult to do. Not to mention the fact that you have all the usual additional security and privacy settings you can turn on.
• Yes, this made our permalinks uglier. No, we’re not happy about it. But we think the tradeoff is worth it.
• Yes, older galleries and photos/videos are grandfathered. Their old URLs without the Keys still work. All new photos/videos, as well as old photos/videos inside of new galleries, require Keys to access. Same with new galleries.
• If you don’t want your older stuff grandfathered, simply create a new gallery and move your photos & videos from your old gallery into the new one. Key’d links will instantly be required for access (if you change your mind, just move them back and they’ll be re-grandfathered). Alternatively, you can set a password and turn off external links.
• The privacy options when creating a gallery and changing a gallery’s setting now use “Public” and “Unlisted” rather than “Public” and “Private” to better explain the difference and match customer expectations.
• When creating a new gallery, there’s a new option called “Lock it down” that’ll take things a step further and set all the right privacy *and* security settings to prevent unwanted access.
• This is a big, complicated release, so there will likely be bugs and bumps along the way. Let us know if you find any and I promise we’ll fix them.

I’m sorry this change took so long to ship. We were actually in testing last Thursday, January 31st, but then I was traveling from Friday to Wednesday, so we had to put it off. Thanks for your patience while we thought about the problem, discussed it with our community, and put together an update.

Special thanks to our customers and friends who weighed in with lots of detail both about the problem and the implementation, and Philipp for being so passionate and firm about the situation.

We’d love to hear your thoughts about this either here in the comments or over on this dgrin thread.

I’ve been getting a little flack for not joining DataPortability.org and want to set the record straight:

• SmugMug has believed since the beginning that your photos and metatdata are yours to do with what you will. We view them as being on loan to us for safekeeping, and we take that role very seriously.
• SmugMug has emailed DataPortability to see about joining, contributing, whatever. No response. Don’t ask me why – ask them. I imagine they’re busy.
• SmugMug already supports OpenID (and better support is coming), XFN & FOAF, RSS, Atom & KML, and has a rich API to both store and retrieve your data.
• We’re committed to all of the ideals that DataPortability.org is pushing, and hope to see this stuff become the rule, rather than the exception.

While I’m on my soapbox, I think it’s important to note that many of the participants in the DataPortability project have been making their data portable for many years. I’m not sure why the media is trumpeting each new company that joins as if it’s just gotten religion, but companies like Flickr and SixApart (and us) have been doing more than talking about this for a long time. Give credit where credit is due.

Anyway, whenever we figure out how we can contribute, we will. We love the idea of our customers’ data being portable. It’s the right thing to do.

Over on IEBlog and A List Apart, they detail a new flag for the upcoming IE8 that would enable you to “lock” the browser down to older versions should you be expecting older broken behavior from IE6 or IE7.

This is a bad idea. The Safari team has a great write-up about why they think it’s a bad idea, which I agree with, but I also have an additional take:

Pages and sites that are likely to care about this are poorly written and poorly maintained. Microsoft created this problem themselves when they let IE6 sit idle for more than half a decade, and now they have to deal with it. Instead of letting someone flag their site as being broken (that’s what they’re doing), why shouldn’t they finally force them to fix their site and improve the browsing experience for everyone (not to mention improve the stability, speed, and maintainability of their codebase)?

If someone owned a car, but didn’t know how to drive it properly, would we bend the driving laws to let them on the road? Of course not. Some reasonable adherence to standards and moving things forward is the only thing keeping the web browser mess from descending into pure chaos.

Laura Thomson has an interesting post about the MySQL acquisition. And I think it really highlights a fundamental disconnect that some companies built on providing open source applications for enterprises face:

Their means of getting revenue are at odds with their customers’ needs.

I’m a paying MySQL Enterprise Platinum customer, and I’m seriously considering not renewing for another year if Laura’s thoughts are on target. In a nutshell, here’s why:

I would pay more for a version of MySQL that has Yasufumi Kinoshita and Google’s patches than I would pay for a version without.

In fact, as I mentioned already, I probably wouldn’t pay for MySQL as it stands today. I paid for it in the hopes that, as a paying customer, my feedback that these patches (and others like them) are vital would be listened to. Thus far, it hasn’t.

I could care less about MySQL’s desire to keep their released, supported software dual-licensed (commercial and GPL). I don’t consider our Enterprise subscription to be for the software – mentally, I’m paying for service and support. And the support (fixing InnoDB’s concurrency problems) is increasingly at odds with the business (releasing a commerical binary-only Enterprise release). But they’re on a collision course – I’m not the only one who will stop paying for it, resulting in damage to MySQL’s business.

I believe the right (and admittedly scary) thing to do is provide paid support for the GPL’d version and move the ball forward – accept community patches that fix major problems.

You can bet that I’ll be telling Sun this, over and over again. Since they have a history of listening, I’m optimistic.

(BTW, this problem isn’t unique to MySQL. Red Hat has the same dilemma – and they won’t take my money, no matter how hard I try to throw it their way)

Remember when I said Sun was a company that listened? They sure do.

Maybe MySQL will finally start fixing all the performance/concurrency issues with InnoDB (basically, InnoDB’s threading and concurrency aren’t working well with modern multi-core CPUs). Google’s had some fabulous patches for awhile, and the brilliant Yasufumi Kinoshita does as well, but they don’t seem to be making their way into MySQL anytime soon.

Personally, I worry they’re focused too much on Falcon and not enough on InnoDB – but luckily Sun listens, so that may change.

SmugMug isn’t your normal Silicon Valley startup. We do everything differently. And Jessica Guynn’s Column One article on the front page of the LA Times this morning captures our quirky nature perfectly. If you want a glimpse into our mad, wonderful world, head on over there for a great read.

Special thanks to Terry Chay and Stan Chudnovsky for introducing Jessica and making sure I followed up with her.

And an extra special thanks to all of our customers who’ve become part of the family and made SmugMug the company it is today. You’re the best!

Ok, so I guess I’m a total n00b. In hindsight, SLAs make a lot of sense after all. The whole point isn’t to compensate SmugMug for our loss, it’s to make it unprofitable for the service provider to keep making the same mistakes.

In other words, let’s say Amazon’s margins on S3 are 15%. (I have no data, I’m just picking that number out of the air). If Amazon has a serious problem during a month, they have to cough up 25% to all their customers. In other words, they lose 10% instead of make 15%.

That’s pretty major incentive – and it now totally makes sense why SLAs are so highly valued.

Carry on.

Read over on O’Reilly Radar about David Recordon’s post at Six Apart entitled We Are Opening the Social Graph. He talks about the emerging tools and technology to allow shared social graphs, like OpenID, XFN, FOAF, and others.

Given that Thursday night is ‘Release Night’ at SmugMug and I had a few minutes to kill, I felt inspired and whipped up XFN and FOAF support to compliment the partial OpenID support SmugMug already has. (I apologize for not finishing our OpenID implementation yet, but I’m finding OpenID 2.0 to be a complete disaster and find myself at a loss as to what to do. Anyway, I digress…).

I’m absolutely positive we’re barely scratching the surface, and people like David will set me straight, but at least we’re making forward progress – 150K SmugMug accounts now have auto-discoverable FOAF, embedded XFN, and are OpenID endpoints.

What does this mean for you? It means, hopefully, that SmugMug can play nicely with other social applications on the web. Your network of friends & family is now published in machine-readable formats so that other networks can do intelligent things with that data. How exactly this will happen remains to be seen, but there are lots of bright people thinking about it, so hopefully it’ll happen.

At the very least, when the Semantic Web actually works in the year 2022, SmugMug will be ready.

UPDATE: I should have mentioned that these technologies do properly obey your SmugIslands and other related privacy settings to protect you should you not want to share this information.

Aye, ye be hearin’ right: Sony ImageStation be shutting down, the latest in a long line of free photo sharing sites to make for port and haul down their Jolly Roger. Back when I was just a young deckhand and the Dread Ship SmugMug was barely a gleam in me eye, Sony ImageStation was one of the heavy hitters in these seas, and the thought of running up against them on the high seas in the dead of night did shiver me timbers.

Things be different now, with the Dread Ship SmugMug hailed in all the seas of the living and the dead as the greatest pirate ship to have ever set sail. Once mighty cap’n Sony has hung up his hook for all time. But in a last dastardly act, that scurvy dog tried to foist off all yer booty onto Shutterfly, a true land lubber if ever I saw one.

If ye prefer to sail the high seas with the rest of us honorable scum, though, ye’re not outta luck! A new beta version of SmuggLr adds ImageStation support in addition to the great Flickr support it’s had for quite some time. Simply install the free Firefox extension (instructions here) and a few glugs o’ grog later, yer booty’ll be safe inside SmugMug’s holds, protected and supported by the best o’ me hearties on deck. Best of all? Enter the secret password ImageStation to receive a 50% discount on yer first year’s passage.

As ye can probably tell from me portrait, the Dread Ship SmugMug and her crew are quite fond of grog, booty, and International Talk Like A Pirate Day. If ye be needin’ help from one o’ the deckhands, be sure to throw an ‘Arrr’ or ‘Ahoy’ their way. Oh, and one o’ the slaves in our brig lays tale that the Black Ship Flickr be flying the Jolly Roger particularly high today as well. I raise a jug of grog in their honor, and the honor of all those who plunder the high seas.

Yo-ho!

I fell asleep last night dreaming about all the neat things we can finally do with Flash because Adobe now supports H.264 video with AAC audio! Lots of great tech details here.

I think it’s safe to say that everyone building web apps said “wtf?!” when Flash 9 shipped without H.264 support, and we all said “WTF!?” when Microsoft shipped Silverlight without it, too. I mean, come on! We finally have an industry standard that’s efficient, used basically everywhere but on web pages, and neither the leader (Flash) nor the upstart (Silverlight) thought to include support, opting for expensive proprietary encoding formats instead? Talk about dumb.

Silverlight, especially, is a head-scratcher. Silverlight 1.0 is focused almost entirely on video, including HD, and clearly gunning for Flash. So why wouldn’t they go right for Flash’s big Achilles heel – no H.264 support?

Oh well – that opportunity is now lost, and I believe this basically nails Silverlight 1.0’s coffin shut. (The bad Mac installation process had nearly done this for us already) Sad, because I had high hopes for how beneficial strong competition would be for those of us building Rich Internet Apps.

Adobe deserves lots of kudos for actually listening to their customers and doing what we want. Honestly, I never thought this day would come. Finally, we can all encode video without expensive closed-source Windows-only encoders. You can’t imagine how limiting that is unless you’re in the trenches, but mark my words:

You’re going to see a massive boom in the online video space shortly. You ain’t seen nothing yet.