As a result, Herskowitz suggests, this increases their reluctance to invest themselves in Spotify, because they fear they could lose their music data if
something happens to the service — i.e. a bankruptcy or acquisition — or in the event that they switch to another one. They also can’t play song links
shared by friends who use a rival service, which can often make music sharing so cumbersome that they just stop clicking on them.

Herskowitz, who is known for his open-source contributions to Tomahawk and his role in product development at Official.fm, talks with sidewinder.fm about
the need for a musical babel fish and how this translation layer could shift the landscape of the online music market.

—

What are a few examples where lock-in has proved to be a successful tactic? Why did lock-in help these technologies or products grow their user base?
And what do you think is the main difference between these examples and online music services?

Jason Herskowitz: To go back to the mobile carriers as an example, they successfully used phone numbers as a lock-in tactic for a long time. That was until the FCC
established the Local Number Portability rules that ensured that users could maintain their phone number when they switched carriers (as long as they were
in the same geographic region). The point to note is that the lock-in didn’t help the technologies and market grow... the portability did.

On the other side of the coin, email addresses are successfully used to lock users into a provider. How many of your parent’s generation are still using
their original AOL address because “that’s the one everyone knows”? What you are starting to see is the creation of abstraction layers that obfuscate the
underlying providers. For example, domain names and numbers let users maintain their outward identity but can easily switch between providers like Tumblr,
Wordpress, or Blogger.

"with free services, lock-in is tolerated for a longer time and you see people slowlyweanoff the service if dissatisfied."

I think with free services, lock-in is tolerated for a longer time and you see people slowly wean off the service if dissatisfied. That being said, they
generally leave the door open for themselves to re-engage with the service at a future time... so they technically stay a “user”, although a dormant one.
For paid services, once a certain pain threshold of dissatisfaction is met then you see people ripping the proverbial band-aid off and subsequently
swearing off the service for life — never to return.

Kyle Bylin: One
major criticism
of your thesis came from Matthew Tomaszewicz, the co-founder of Thrillcall. He essentially argued that Apple would never play ball with Spotify or any
other service, for that matter, because they have little incentive to do so.

Interoperability among music services is a “grandiose and fantastic vision,” Tomaszewicz says, but a rather “utopian” one at that. To which, you responded
that we don’t need the current players to participate to make this a reality; it’s merely within their best interests to do so. Your argument being that
interoperability could grow the online music market and possibly be a catalyst for innovation.

What are the greatest consequences for continuing to use a lock-in strategy? Why might Spotify and rival companies recognize the need for
interoperability, but never integrate it? What do you think it would take for them to follow suit?

Jason Herskowitz: The biggest consequences are for the users, and consequences inflicted on users generally come back to haunt those that did the inflicting. Music fans have
continually invested in building and curating libraries and playlist to only see them disappear time and time again. Imeem, Project Playlist, Napster
(2.0), and MySpace... the list goes on and on. After being burned so many times the users just stop engaging at the same level.

I think all services recognize the need for inbound interoperability — the ability to easily onboard users from competing services is a
no-brainer. They just don’t want to be exposed to the risk of them being the one that’s being abandoned. But, you need to take the good with the bad and
compete on something other that holding the user’s data hostage.

I think there needs to be a standard for music data that everyone supports. And there are: .XSPF, for example, is a great
start for playlists.

I don’t foresee each service doing the work to support every competitor’s links, but I do see the opportunity for each to enable an independent third party
(or multiples) to do so.

Kyle Bylin: What Tomaszewicz may not have realized, it seems, is that you have already made interoperability possible with Toma.hk. As you described the big idea
behind the web app in a recent blog post, it creates a “single,
universally playable, URL for a song” that enables anyone on nearly any service to share music with each other and have the link play music the moment they
click on it. The promise of Toma.hk is rather spectacular to the inclined and definitely needed for curators, artists, and record labels.

Has the launch of Toma.hk given us an illustrative example of what interoperability makes possible? Who are the early adopters? What are the next steps
you will take in developing the web app or features that you have considered adding?

Jason Herskowitz: Toma.hk started as a hack to illustrate how the power of the approach and technology in the Tomahawk desktop player could be leveraged on the web. Not only
does it work like a simple meta-search engine (across multiple services) for playable music, it also enables new experiences where curation sources get
seamlessly woven with multiple content sources.

For example, it is pretty trivial to pull in charts from Billboard, iTunes, We Are Hunted, and more, and have them play from whatever music sources a user
has available. It also works the other way, and lets content be dynamically inserted into curation sites. For example, there is a Tomahawk bookmarklet that can parse out song information from dozens of different sites and inject an
playable music right into the page for each visitor, independently. And, similar to Instapaper or Pocket, with a single click you can take those songs with
you by saving them within the desktop app.

"Instead of the onus being on a single entity to license all music for everywhere, [Toma.hk] creates a 'bring your own' model where the visitors is leveragingthe content rights and access they already have."

We have also seen people using it ways we didn’t even imagine at first. The current global marketing campaign for the videogame Resident Evil 6 is
leveraging our embedded players. Not only does it let users interact around virtually any song, it also liberates the advertiser to create new campaigns
and ideas that weren’t previously feasible or realistic. Instead of the onus being on a single entity to license all music for everywhere, it creates a
“bring your own” model where the visitors is leveraging the content rights and access they already have.

One of my other favorite hacks I’ve seen is John Peel’s album collection presented as Toma.hk links. Also, one of my favorite music blogs, DrownedInSound, has been begun using Toma.hk players (and the bookmarklet) to enable multi-source playlists that
can both reduce the amount of work required for them to embed music and has the promise to keep readers engaged with their site longer.

Kyle Bylin: If online music services developed a translation layer — a musical babel fish, as you call it — such a solution would “remove the complexities and
roadblocks to creating a global sharing, curation, and discovery network,” you write. “Just as importantly, it would also open up new opportunities for
more niche music providers that could focus on going deep, instead of broad, on their catalogs.”

What type of new opportunities do you believe would open up for niche music providers? How would they be able to differentiate themselves by going
deep, instead of broad, on their catalogs? What would the user experience be like?

Jason Herskowitz: One of the major challenges for the mainstream music services comes in the form of their content acquisition strategy. There are millions of artists and
thousands of record labels. As most position themselves as a single-source music destination, they need to make sure they have the most popular, mass
market, content. Thus, their entire consumer offering and pricing model can only be as innovative as the rules for their most popular content allow.

eMusic is a great example of this. By originally only focusing on independent labels they were able to create a more compelling offering that was rich with
hard-to-find content. It was a fantastic offering for fans that weren’t interested in the “expensive” content from the majors. When eMusic signed the
majors, they had to give up everything that made them interesting in the first place (pricing, credit model, and singular focus on surfacing indie
artists).

With Tomahawk, you can maintain the user value proposition of having everything available in a single “place” by providing a single interface into a myriad
of services. So the niche services aren’t penalized by the fact that users have to travel to a different destination to find and enjoy the content they
offer. Users could easily subscribe to a number of small niche providers instead of the single broad one that may not best meet their needs.

"Drip.fm is a great example of a provider taking this approach where an individual artist, label (or consortium of labels) offer a subscription exclusively for their content."

Drip.fm is a great example of a provider taking this approach where an individual artist, label (or consortium of labels) offer a subscription exclusively
for their content. There is a premium paid for these subscriptions, but the offering goes much deeper than the mass-market all-you-can-eat services. They
provide exclusive content, early access and other perks for their subscribers.

Kyle Bylin: Another interesting criticism
asked if you should have disclosed how closely the vision outlined in your essay aligned with your desktop and web app, Tomahawk. This person went as far
as to call the practice “distasteful.” Such pushback is understandable, as the essay appeared on several news publications and there is certain baggage
that comes along with that.

However, the comment brings about a challenging aspect of public writing for startup founders and product developers. Oftentimes, they’re the biggest
opponents of the problem they’ve created a solution for. In many ways, this makes them biased in their views, but that’s what strong belief does.

Does a product vision often make you biased? How do you acknowledge bias and maintain belief when it comes to expressing your views? What opinion about
music and technology do you strongly hold, but forget may not be widely adopted?

Jason Herskowitz: I believe the bias should create the vision, not vice versa. The bias enables you to focus on building products that scratch your own itch, instead of
generalizing and creating something you think the public at large may like. If you can do that, you will then discover other people have the same itch.
Approaching it the other way often leads to blind over-generalizations of what “people” like or do, only to realize that the aggregation of a group of
people’s behaviors doesn’t mean that any one person actually acts the way the aggregated view led you to believe.

"if you are building music products or servicesthat demand all of a user’s attention, you’re doing it wrong. The beauty of music is that it doesn’t require all of your attention."

One of my (not widely adopted) positions is: if you are building music products or services that demand all of a user’s attention, you’re doing it wrong.
The beauty of music is that it doesn’t require all of your attention. I think interfaces for music and discovery need to get out of your way and not try to
be a panacea. I believe that discovery is something that happens when you are going about your everyday life... not somewhere you go. So that leads to an
approach where it’s more important to support capturing those discoveries, not just presenting them.

Unfortunately, I see many fall into the trap of trying to create ways to demand more of a user’s attention. It is not uncommon for music experiences to
find themselves rationalizing this approach to themselves due to the licensing and royalty dynamics of the industry. For example, to make the economics
around any ad-supported music experience to work, you have to generate higher-than-average ad revenues. This lures people into building experiences where
they need higher-than-average engagement around music to ensure ad impressions. I’d argue music fans’ abandonment of liner notes is less about the move
from physical to digital and more a product of the attention economy we all now live in.

Comments

You can follow this conversation by subscribing to the comment feed for this post.

C'mon Kyle, why am I the villian. :>
Howdy Jason.

First, really like Toma.hk; have liked the initiative since I saw it a music-tech conference in SF a few years ago.

That said, you bring up the sname Project Playlist, essentially a service that grew quite rapidly off a--broadly-speaking--a MySpace hack. Once they got consequential enough (and thumbed their nose at the labels for a brief moment), they were essentially litigated out of business.

More broadly you look at companies like Facebook or Twitter. One could argue that communication is better if it were shared between those two platforms and say email or voice for a specific user. Essentially enabling the most personal of media to appear everywhere -- beautiful.

What have these companies does recently? Facebook moved to lower the newsfeed exposure of messages posted to it by third-parties. Twitter clamped down with rate limits on companies accessing both it's read and write APIs.

Toma.hk is probably about, I would surmise, 300K downloads or so at this point. It's not worth the time or effort (or certainly revenue recovery) to litigate. And, like I said (somewhere, forgot where), it's a grandiose and fantastic vision that I hope can expand and navigate the landmine of the music space.