The state of video codecs online has been a mess and there’s been no clear choice, making it very difficult to do awesome video sharing. Luckily, all of that changed when Adobe finally added H.264 support to Flash.

Thanks to Adobe, we finally have a video codec that we can get behind and that’ll be great for our customers. And so back in December, we released a major new update to our video offering that’s 100% based on H.264. And it supports resolutions all the way up to 1280×720p. That’s right - SmugMug has truly awesome hi-def video sharing.

Today, I’m thrilled to announce that our Flash player is out (we used QuickTime for a few months while we polished up our player), so it’s easier than ever to embed on your blogs and share with your friends:

Here’s all the gory details:

• Upload almost any video format you like. We’ll do our best to convert to H.264 in an extremely high quality way. (Thanks EC2!)
• We’ll generate multiple sizes for you, so you’ll have a version that’s perfect for sharing on the web (YouTube size), perfect for using on your iPod/iPhone (DVD size), and even your Hi-Def TV in your living room.
• We’ll automagically display just the right sized video for whichever browser and monitor you happen to be using. Ditto for your friends. Example from my friends in Dallas hard at work on Duke Nukem.
• You can embed the videos in your blog, website, or wherever else you like online. And you can do so at DVD quality resolution - 640×480 - more than 4X the pixels and quality of YouTube.
• You (and your friends and family, if you let them) can easily download all the different sized versions of your videos so you can do whatever else you’d like with them, like add them to YouTube or burn to a DVD.
• H.264 means it’ll play on a huge, wide variety of computers and devices, not just SmugMug. iPods, AppleTV, Playstation 3, and the list goes on…
• Speaking of Apple devices, we provide a complete podcast RSS feed for your account that you and your friends can subscribe to with a single click in iTunes. All your iPods, iPhones, and AppleTVs will then magically stay up-to-date. All your online videos in your pocket, and your living room, all the time. Neat, eh?
• I’m thrilled we’re making good use of the OpenShareIcon project, too. Rather than use some trademark-encumbered, company-owned, non-open ShareIcon, we’ve chosen to use the real deal. Viva open web standards!
• One gotcha: Flash takes 200% more CPU to play video on the Mac than QuickTime does, so in-gallery, Mac users will still see QuickTime. We can’t wait until that’s not true - but that’s up to Adobe, not us.

So there you have it. I’ll probably post again soon with lots more detail about how great the integration is with Apple devices: iPod, iPhone, iTunes, and AppleTV. We love us some Apple over here at SmugMug.

Oh, and you can count on our video player to continue to rapidly evolve. This is definitely just a 1.0 product - it may have some warts and it’ll get even better over time.

So go wild - share your crystal clear video with the world!

Oh, and demand your video to be awesome:

I’m on a panel called ‘Small Business Hacks’ at the Web2Open part of the Web 2.0 Expo today at 1:30pm.  Swing by if you’re interested in building a successful business on the cheap.  More details here.

One great thing about Web2Open is that it’s free - anyone can attend!

See ya there!

First:  Very cool.

Next:  I think it’s interesting that Google has basically taken a sniper scope out and aimed it at a specific cloud computing target.  App Engine is only for web applications.  No batch computing, no cron jobs, no CPU/disk/network access, etc.  

I think this is very smart of Google.  Rather than attacking Amazon head-on, Google has realized there’s a huge playing field for cloud computing, and are attempting to dominate another portion of it, one where they have a lot of expertise.  Very good business move, imho.

Will we use it?  I wouldn’t be surprised.  I’ve long thought that we’ll continue to mix in web services from a variety of providers, and it looks like App Engine can solve a slice of our datacenter need that other providers don’t yet provide.  

I’m more than a little concerned, though, by how much vendor lock-in there is with App Engine.  At first glance, it doesn’t look like the apps will be portable at all.  If I want to switch providers, or add in other providers so I’m not relying solely on Google, I’m outta luck.  

I’m hopeful other languages get supported, too.  I think Python is great - don’t get me wrong - but we have a lot more experience with other languages, so there’ll be a learning curve.

Finally, I’m dying to find out what pricing for an application of our scale will look like.  I can see some immediate, obvious things I’d like to try to do on App Engine, but the beta limits aren’t gonna cut it for us.  :(

Will it replace Amazon?  It sure doesn’t look like it from where I sit.  In fact, I don’t see this as much of a competitor to Amazon Web Services.  There’s some overlap in some small area (hosted web apps on EC2), but I doubt that’s the bulk of Amazon’s business.  As I said, we’ll likely end up using both (and other providers as they come along, too).

My favorite bit?  In theory, Google has solved the data scaling problem.  I don’t mean raw binary (blob) storage, which S3, SmugFS, MogileFS, and plenty of other things have solved, but the “database” scaling problem.  Every popular web app runs into this problem, and it’s typically solved with a combination of memcached, federation, and replication.  But it’s messy.  In theory, Google has automated that piece for us.  I can’t wait to play with it and see if that’s true.

I also can’t wait to see who else is going to wade into this fray.  Sun?  Microsoft?  Yahoo?  IBM?  

Bring it on!

photo by: Kirk Tanner

Hardly.

Hank Williams over at Silicon Alley Insider has a guest post up about how VCs are ruining the online tech economy by fueling free services, wrecking it for small and/or premium services. Matthew Ingram has a response out that resonates much more closely with how I feel.

First of all, SmugMug is living proof that you can make it as a premium service. Second, I think you’d be hard pressed to name a market where there isn’t stratification. Cars, airlines, music players, shoes - you name it, there are premium brands and there are commodity brands. On the web, commodity = free. That’s just how the game is played.

There are a lot of reasons why it makes sense for us not to be free, but perhaps my favorite is: We’re forced to hone our business. If we do don’t do it right, we don’t eat. Doing it right becomes priority #1 rather than growth.

There are quite a few reasons I love that there are *lots* of free sites with deep pockets in our space, too:

• Free training. Lots of our customers go chew up customer service dollars somewhere else first, learning the basics of how to upload, share, etc, before coming to us. By the time they get to us, they know the ropes and getting up to speed is easy.
• They’ve seen how bad it is elsewhere. By comparison, our product looks amazing. The ‘Wow factor’ is huge.
• Coattails marketing. We don’t have to spend a lot of money raising awareness of the photo sharing concept - other, bigger companies are doing it for us.
• Keeps us on our toes. As if our customers weren’t enough to keep us nimble, big deep-pocketed competitors surround us on all sides. Try slowing down and we die.

There is one big nasty downside, though, that really gets me. Every time a free site dies (and they’re dropping like flies), some of those burned customers get gunshy. Sure, we pick up lots of refugees, but there are some people who just get turned off by all photo sharing sites. They lost their priceless photos, afterall. That sucks.

With the market downturn, that last point really scares me. If we really do have another bubble burst in the web space (and I predict we will), free photo sharing sites are going to be devastated.

I just hope they don’t burn an entire generation.

UPDATE: I found our problem! We don’t have a FreeTardis! I’m gonna get one.

A few of you have been asking when/where I’ll be this year, conference-wise. Since Audrey was born, I’ve tried to keep my travel and speaking gigs to a bare minimum so I could help with my three kids and keep my wife sane. If you’d like me to speak or otherwise help out your conference this year, being local (Silicon Valley) is almost your only bet, I’m afraid.

That being said, there are a few things that are ‘must attend’ for me, and a few local California shows, too. I’m sorry if I had to turn down your conference this year, but please ask again in future years - especially those of you with foreign events.

Here’s what’s on my calendar so far:

• MySQL User’s Conference - A must-attend for me. Helps that it’s local, too.
• D6 - A must-attend for me. Best business conference there is, imho.
• foo camp - Must-attend *if* I’m lucky enough to get an invite. No hard feelings if I don’t.
• Velocity - New conference around operations & scalability (finally!). Local, too.
• Web2Open - Speaking on a business hacks session. Local, too.

I wish I could go to OSCON this year, and wish I could have gone to ETech, too, but I just can’t & couldn’t.

And while I have your attention, I’d just like the mourn the death of the Web 2.0 Summit for me. I’ve enjoyed going all the previous years, but I just really didn’t get anything out of it last year. It’s turned into a massively popular event, but one that’s mobbed with VCs and bankers - almost no startups or entrepreneurs to be found. I have nothing against VCs or bankers, but that’s just not why I attended. So I think I’ll pass this year. Might come up to the city to hang out or get lunch, though, so ping me if you’re in town then.

If you are an entrepreneur with a hot startup, I suspect TechCrunch50 is going to be the place to be this year, btw. Get your demos ready!

UPDATE:  Jesse just posted a 20% discount code in the comments:  vel08js  Thanks Jesse!

photo by: Steven Le Vourc’h

I’ve been telling everyone I know just how great Tripit is, but realized I hadn’t told all of my readers.

It’s the most useful web service I’ve seen in years.  It’s drop-dead easy to use (just forward your email confirmations) and just plain works.  I’m learning a lot about ease-of-use from these guys, and  I can’t imagine traveling without it anymore.

If you haven’t checked it out, go.  Now.

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)