An open letter to SmugMug

TL;DR

SmugMug is great, but its developer ecosystem is, in my humble opinion, crumbling, and can use some serious love — or put out of its misery and die…

Dear SmugMug, there are lots of people, myself included, who want to see you thrive and succeed. People who are spending their free time, resources and energy on sharing their tools with the community. People who can build great things on top of SmugMug, and can make SmugMug even more successful than it currently is. Please don’t forget us. We are the potential evangelists, multipliers, and we do this for free. Please treat our free gifts with respect. These gifts might be free, but they are precious. They should be cherished, rather than ignored, or discarded.

The long story

SmugMug is a truly inspiring company. Where others take VC money, SmugMug keeps it bootstrapped, selling their service for a fair price and building something that lots of photographers and other photo enthusiasts need. To make things even more amazing, SmugMug recently bought flickr. If I had to bet, I would have bet that the opposite would happen. Yahoo, or some other cloud provider would acquire SmugMug, not the other way around. Seeing a smaller, bootstrapped business “win” in this way makes me happy.

I started using SmugMug in early 2014, and immediately thought it was great. Unlimited photos and videos for a reasonable price (although, I’m still unsure whether they downsample videos, but let’s leave it aside for now). This wasn’t a loss leader, but a sustainable business. Shortly after starting to use it, I realized that there wasn’t an easy way to import or export albums, photos and videos. I did however find a python library (smugpy), and after spending a bit of time patching together something to help me sync with SmugMug, I realised that I might as well create a CLI so that others can more easily use it as well. And smugline was born (I searched for other alternatives for syncing from the command line, but couldn’t find anything).

I can’t say smugline was a huge success by any stretch of imagination, but it did serve a number of people, and I was personally happy to maintain it. Until things started to break.

But before I go into this, a small detour into the developer ecosystem.

Developer support?

SmugMug kindly offers a free SmugMug business account for developers who build tools that integrate with SmugMug. This sounds great. But it pretty much ends there. To qualify, you have to email the API team, and they need to approve you. Fair enough. Then, once a year, they actually send you a billing reminder, and then you have to go and remind the API team again that you exist. It’s just an email, but feels rather short-sighted in my opinion. How many developers are on this program? Can’t the billing team check that whichever tool they develop is being actively maintained? Or this billing email go directly to the API team? Why do I need to go begging once a year?

Furthermore, from my limited experience, API related issue can take a rather long time to get an answer on. I’ve personally bumped into backwards incompatible, breaking changes (specifically how MD5 signatures worked, or didn’t, which is crucial for duplicate avoidance or detection). Those issues didn’t get any sympathy from the API team when reported. They were left broken.

API updates and deprecation

Things have to move forward. I totally get it. And some things need to be deprecated. Removing HTTP and switching to HTTPS-only makes total sense. I know what it means to support legacy apps, and at some point, you have to make a hard call, even if it’s painful for some.

I think there’s a fine line however, between a way forward that keeps 3rd parties engaged and on board, and one that basically leaves them behind. I think SmugMug left too many 3rd parties and developers behind. This happened when API v1.2.2 was deprecated, and particularly when login auth was deprecated in favour of oauth-only.

Furthermore, API v1.3 is also deprecated now, but API v2 is still in Beta. For over 4 years. From their Apply for an API key page:

Interested in exploring API 2.0? Join the open beta by accepting the optional API 2.0 beta terms and conditions below.

Note: API versions 1.3.0 and earlier are deprecated and will be taken offline at a future date.

My own project (smugline), depended on the python bindings of another library (smugpy). The latter was pretty much abandoned. I can’t blame SmugMug directly for it. It won’t be fair. But is there any other python binding that supports API v2? Sadly not. Or I couldn’t find any.

So maybe this is unique to python, but other languages have better support? It doesn’t look like it. Let’s have a look at the official Third-party uploaders, downloaders, migration tools, and utilities (updated at Nov, 2018, or about a month ago, at the time of writing this):

• actionscript is hosted on Google code… I think it’s quite obvious how outdated this might be based on where it’s hosted alone… Is actionscript itself even still a thing? :)
• coldfusion – same
• Haskell – on bitbucket; last updated 2011-09-17
• another python binding also on Google code and looks very outdated
• There are 2 PHP libraries (phpsmug and dfm-smug-wrapper) that do seem to support API v2, the latter wasn’t updated since 2015 though

That’s it. I guess it’s possible to re-write smugline with PHP, but it won’t be my favourite language or the most obvious choice for a CLI. Not to mention the difficulties with the OAUTH flow for a CLI.

Besides those, the official page has numerous links to integrations that are outdated, broken or no longer exist. Smugline is there. A few other examples include: QuickMug ruby CLI (last updated 2015), smugmug-uploader python script (last updated 2010? using API v1.2.2), fileuploader for Smugmug perl script (2007), Fotofox Firefox addon (404) and lots more.

This feels like a rather sad state of affairs to me, and in my opinion a clear sign that SmugMug lost touch with their development community.

Creating my own binding?

So why not writing a python (or ruby) binding? I looked into it, and it’s definitely possible. But it would require a significant amount of work, especially around things like the oauth flow (which also have security implications). Plus, whilst smugline doesn’t need to use the entire API, it feels awkward to write a partial binding, or to bake the lower-level binding into the CLI itself. It makes sense to have a layer of abstraction here in my opinion. Even if it’s (ideally) thin.

And then the question I have is “why can’t SmugMug provide some bindings to support the development community?”. I think they definitely can. Or if they really had an engaged development community — this would happen “organically”. But they don’t seem to have an engaged community, nor do they seem willing to provide higher levels of API abstraction, beyond their API documentation (that to me personally feels rather complicated and clunky). And v2 is still in Beta…

Commercial 3rd parties

So maybe I should forget about any open-source integrations and use a commercial 3rd party to sync photos? It looks like the list of 3rd party commercial integrations is also nearly non-existent… I would guess it’s all connected. Without open-source language bindings or example integrations, even commercial providers are reluctant to bake support for SmugMug.

Is it only me?

Maybe I’m being unreasonable. When looking at posts on HackerNews, SmugMug generally seem to be well perceived and comments are by and large positive. I think they echo my feeling as well about SmugMug’s bootstrapped (David v. Goliath) state.

But I don’t think I’m the only one. Here’s a quote from Jeffrey Friedl (an author of lightroom plugins with SmugMug integration, and an O’Reilly author of Mastering Regular Expressions) on a thread that started when deprecation came into play

Considering that there’s no answer nor even reply to the first two posts in this thread, no answers nor even reply to messages sent to api@smugmug.com, and no answer nor even reply to various other threads in this forum, you’ve already cemented a very strong impression.

I’ve worked with SmugMug as a developer for over a decade, and in the old days, communication between SmugMug and developers was quick, fluid, and mutually beneficial. What happened to you?

To be fair, the response from SmugMug was largely encouraging:

You’re not wrong. I hope you’ve known the kind of company we strive to be and have been. The poor communication you’ve outlined is not what we want to be. We’re not afraid to admit when we’ve made a mistake and this is one of those times. I’ve hopped onto this thread as a step towards improving that communication. Our COO, several engineers, our Director of Ops, and countless others have been brainstorming today on how we can avoid the lapses that have occurred. While we have the best of intentions for turning off older API endpoints, we certainly could have done better. Kaydin, one of our Account Managers had been in close contact with our top API consumers but we obviously missed reaching out to you. We’re working on some changes so that doesn’t happen again.

But reading through the thread, I didn’t get a feeling that SmugMug picked up the ball from there… It felt like empty promises.

Lots of similar back and forth on this thread (I recommend reading it rather than taking my word for it), but the impression I’m getting is of very poor communication and support coming from SmugMug, despite self-proclaiming that their support staff are “Heros”. The last post on this thread (from a day ago, 11th Dec, 2018) sums things up nicely regarding the v2 API in my opinion, and this is coming from someone who took the plunge to v2 (I’m guessing on their own, with no language binding):

As a partner that has successfully migrated to the 2.0 API, I would like to chime in and say that having the only two options for a SmugMug API be ‘deprecated’ or ‘beta’ is very scary from an integration perspective.

2.0 has been in beta for over 4 years now. Although the beta tag may not have an impact on how the API actually functions day-to-day, what it says to me as a partner is that you are reserving the right to break or change things with little or no notice. I would ask you to either promote the 2.0 to ‘stable’ as soon as possible, or provide a better explanation of why it still has the beta tag.

I would add that from my experience, even when API v1.2 and v1.3 were stable, there were breaking changes.

Way forward?

So how should SmugMug solve this?

Maybe they shouldn’t. But then at least admit it and be upfront about it. Publish only actively maintained, working integrations on the Third-party uploaders, downloaders, migration tools, and utilities page. State clearly that the API is still in beta, and that the company has no concrete idea as to when it would become stable. Or maybe even remove the API altogether and keep it internal.

Or if they do want to build a thriving developer community, then please put your money where you mouth is. Treat developers with respect. Give them the access they need, without having to go begging once a year. Build the language bindings, or sponsor some open-source developers who are willing to do this. Maybe even hire some developers, evangelists, outreach or whatever you want to call it, dedicated to the community. Treat deprecation seriously, and avoid backwards incompatible changes fiercely (API versioning is tough, but done right it’s a life-saver for avoiding legacy breakage).

Dear SmugMug, there are lots of people, myself included, who want to see you thrive and succeed. People who are spending their free time, resources and energy on sharing their tools with the community. People who can build great things on top of SmugMug, and can make SmugMug even more successful than it currently is. Please don’t forget us. We are the potential evangelists, multipliers, and we do this for free. Please treat our free gifts with respect. These gifts might be free, but they are precious. They should be cherished, rather than ignored, or discarded.