Two years ago, this month, I wrote an article here called “Understanding Music and Blockchain Without The Hype“. As with any nascent technology that shows a great deal of promise, there’s generally a tremendous amount of hyperbole as to what’s possible. A lot can happen in two years and frankly a lot has happened since my original piece ran. I felt this would be an excellent time to revisit that article and see where we are. This is a long one, but if you really want the skinny, no BS on music and blockchain, you’ll stay until the end.
As a blockchain pragmatist, I’ve always been a supporter of many ideas proposed (better data/improved efficiencies), but skeptical of whether or not any of them actually improve the current situation, exacerbate it, or are in fact possible. Every study I read has clearly been approached from the foregone conclusion that blockchain is the future, without any critical pushback. For two years I’ve been trying to dispel some of the hype.
We’ve seen the hyperbole hit new seemingly impossible heights, promising unicorn dreams of fantasy technologies, improbable cost savings, impossible business models, and instantaneous payments direct to artists without any “middlemen”. Ah the dreaded all encompassing, yet nebulous middlemen. Financial death by a thousand cuts.
The idea that’s been pushed from Day One is that with blockchain we can eliminate all those parties in the middle that take their commissions and cuts and replace it with a world computer using “smart contracts” that automatically just make money, and know who to pay…instantly. Huzzah, problems solved!
Detecting a theme here
Granted, there are many layers of third parties who create inefficiencies in systems, but there are also many useful middlemen, like service providers, the people who build and run things so stuff works. But what I’ve seen proposed the past two years for blockchain is actually the elimination of one set of middlemen for another set of middlemen.
Blockchains are not autonomous god computers that just do your bidding. They require service providers to make things happen (core programmers, hosted nodes, miners, wallets, etc). You can’t just eliminate companies that provide services and expect there to be some universal user interface that will handle all of your needs. Someone needs to build and run this stuff, and they will surprisingly want to be paid. As for cutting costs, those costs can only go so low. There’s this perception that blockchain companies provide cheaper solutions, but we’re talking fractional cost savings. These savings may eventually cost more, not less over time. Building world class technology and then running it costs money. If your royalties vanish in a hack, you’ll want to be able to call someone, not talk to a bot.
Ideal, but unlikely
Back in my original article I said that those working in the blockchain space would have to solve five critical issues for creative industries, or the whole exercise would be a complete waste of time and money. Those included Authority, Immutability, Scalability, Legacy, and Privacy. I’m going to touch on a few, and ad two new ones. Let’s recap with some commentary:
Immutability: this is one of the most misunderstood, yet more actively promoted ideas of blockchain, the idea you can and should write a permanent record of data that no one can alter ever, into a giant sky god database. It is an idea being pushed and sold because it isn’t fully understood. I’ve yet to see one single necessary music data use case for this.
Except the music industry isn’t a trust-less system
Ask yourself, is immutability really the most important aspect for data or better yet a fluid, yet documentable series of committed changes (history) backed by a proven authority? Because the later can still tell you everything about an asset, as well as who owns it and how to pay them “instantly“.
In the raucous arena of blockchain debate, immutability has become a quasi-religious doctrine – a core belief that must not be shaken or questioned. And just like the doctrines in mainstream religions, members of opposing camps use immutability as a weapon of derision and ridicule.
In blockchains, there is no such thing as perfect immutability. The real question is: What are the conditions under which a particular blockchain can and cannot be changed? And do those conditions match the problem we’re trying to solve?
To put it another way, a blockchain’s transactions are not written into the mind of God (with apologies to Augustine above). Instead, the chain’s behavior depends on a network of corporeal computer systems, which will always be vulnerable to destruction or corruption.
Gideon Greenspan PhD Computer Science
CEO Coin Science
Ever since this idea popped up, I’ve been saying that the problem with immutable data is that human beings are illogical and therefore business logic tends to change rapidly based on the nuance of human behavior. This isn’t just because people fight over money, territory, or credit for something…it is because the behavior of how citizens interact with technology changes so fast, you need something flexible and fluid that can always change with the immediacy of how we change our habits. Especially when it comes to media.
Devices like Alexa, Google Home, and Apple’s HomePod have seemingly come out of nowhere to become digital hubs, and their long term impact has yet to be felt, but markets are already moving. And in 3 years, we’ll have something new. Therefore there’s zero practical logic for immutable business logic, especially if we consider that we’re just beginning to start a digital journey into a future where we don’t know how we’ll be interacting with media or the systems that will exist 5-10 years from now. This is why locking things with DRM is a bad idea. You can’t plan for obsolescence these days because it comes at you fast, so seemingly good ideas turn horribly bad when suddenly 1B people can’t access things they legitimately paid for because an app goes out of business.
A lot of blockchain development is trying to force blockchain what it isn’t designed to do, what it was never intended to do. Square peg, round hole.
The Zen approach is to build systems that aren’t rigid, but can bend. Systems that are rigid are systems that break. You know whose really good at dealing with stuff like this? Programmers!
Instead of thinking about metadata and ownership information of creative assets as just this data/file problem to solve when we release them, perhaps in our current world, we should be taking a cue from programmers and thinking about dealing with media in the way programmers write and deploy code, particularly what’s called version control systems:
“In computer software engineering, revision control is any kind of practice that tracks and provides control over changes to source code. Software developers sometimes use revision control software to maintain documentation and configuration files as well as source code.”
For example, let’s look at something called Git, a very popular system of revision control that was created by Linus Torvald, you know, the guy whose code is the foundation for some things you may have heard of, like Linux and Android.
Projects that have thousands or millions of lines of code with many people contributing to that code from all over the world requires a way to track the changes made to the project, who made those changes, and be able to see all of this historically (see branches). Sound familiar?
If we were to think about the release of a creative work (like an album) in the Git Model, you’d find that much of what’s desired to solve the music industries issues of data, negotiations, contracts, ownership, regulation, laws, rates, regions, etc. are things that have already been worked out before, for massive software projects that run on billions of devices. The data necessary to describe a piece of media is tricky, but no more tricky than the code in your average iPhone app. Git is scalable, battle tested (12 years), can have many authorized and trusted parties, has elements of immutability, and is fluid enough to allow for the nuance of business logic and human behavior, while also allowing for the verifiable truth of data. For example, let’s look at how Git handles changes to data:
Cryptographic authentication of history
The Git history is stored in such a way that the ID of a particular version (a commit in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. The structure is similar to a Merkle tree, but with added data at the nodes and leaves.
This history of changes and all of the related data and files can be distributed, so you have mirrored repositories of the same data. Every clone of this repository is a full back up of all the data, so if one server fails, you can access others, while using the mirrors to restore the failed copy.
When “the industry” (labels, publishers, artists, PROs, DSPs, etc.) ask for a global database, besides the practical issues of the identifiable metadata and who to pay, they don’t necessarily want a global database, and actually that’s okay. What’s not okay, as has been reported here (see Shiv Act) is trying to force a singular truth on a system and a planet that can’t have a singular truth. What “the industry” really wants and needs is potentially infinite different versions of the truth. This sounds counterintuitive to what everyone is screaming about these days, so let me explain.
There are basic core truths that should be consistent across the world, like what is this file and who is connected to it? Yet beyond that, whoever you are and wherever you are in “the industry”, what you really want is to have Deal A with one party and Deal B with another. Those two truths must be able to co-exist at the same time, and it would be helpful if they weren’t simply trapped in paper contracts. In a Git model this is possible, and therefore Deal A and Deal B can both be true, but would never meet anywhere else than in the view of the deal maker. This means the identification of the asset may remain a constant, but the details of ownership, regions, rates, etc. can always be fluid and changing, because that’s the world we live in. You don’t need a blockchain and smart contracts to express all of these truths. In fact, managing these truths with smart contracts would be a nightmare and could cause cascading failures in mission critical media systems. No matter what anyone is telling you about how we’ll just have “smart contracts” that know how to do all these things, that is a level of complexity I don’t think anyone has ever seen before and it will open up entirely new security risks. We’re already seeing exploits in smart contracts that have lost over a hundred million dollars.
All around the world, everyone, programmer or not, uses revision control every day. You, yes you reading this, you are already familiar with it. Every word processing document, spreadsheet, collaborative web document, blog, and even Wikipedia page history uses version control technology. It’s how we can collaborate and commit changes to documents locally and remotely, while also knowing the history of the who, how, where, and what.
You know who also uses revision control systems? Blockchain developers.
So do not release music…deploy it.
Scalability: Can you run a robust music industry on any of the current blockchain technologies? The answer is no. Don’t just take my word for it, let’s hear from John Palfreyman, Director – Blockchain – National Security CTO at IBM, in his May 2017 blog entry “Ten Things Blockchain is NOT”.
Blockchain is not (yet) mature: Gartner stated in their 2016 report that blockchain is at the peak of inflated expectations on their hype cycle. They say it’s some 5 to 10 years from the plateau of productivity, which I regard as conservative for some use cases. Problem is, with all the hype, it’s easier to think blockchain for business is more mature than it is. A sense of reality must be maintained, especially when seeking out the use case for a blockchain first project.
Blockchain is not a distributed database replacement: blockchain complements distributed database technology, with appropriate information partitioning between the two.
Blockchain is not usually suited for high volume, low value transactions: as blockchain for business matures, fabric developers will turn to non-functional requirements including transaction throughput. In the near term, the technology remains better suited to low volume high value transactions
I could say more, but I think that encapsulates it well.
Now on to the new issues:
Legal: My company employs one of the best legal firms in the UK when it comes to media and technology, and the legal issues surrounding running a “normal” technology company dealing in media is incredibly complex. Now take that up a notch with decentralized or distributed companies that don’t care about regions or borders or rights. Frankly, I see a lot of these blockchain startups ignoring these facts (See Opus below). The current SEC ruling on Initial Coin Offerings (ICOs) is really a global red flag towards other regulatory shoes dropping. If the SEC and other government agencies around the globe can force compliance on ICOs, it is a short hop to privacy and data security issues. Regulation (like winter) is coming, and blockchain solutions will have to be compliant with these laws, and none are ready because they thought they could operate outside of it.
Disruption: Blockchain proponents seem to think they are the answer to giant corporate control of data and technology services, capable of disrupting the dominant players (Amazon, Airbnb, Uber, Google, Microsoft, Facebook, etc.), but the reality is that giant corporations aren’t always the first to jump into a marketplace until it is established. Sometimes they get caught up in the hype phase, jump the gun, and it goes sideways. What’s likely to happen is that blockchain companies will begin to offer services that have lower costs than giant centralized providers. However, corporations like Amazon (Amazon Web Services), are not likely to just let you take their business from them, so they’ll first begin by cutting prices to match blockchain startups, but providing a more mature service (maybe losing money to outpace competition) with more features (compete on value). Then, after these startups have established the blockchain marketplace, they’ll step right in and compete by offering more for less, or buying up these smaller companies one at a time. Meet the new boss…
Blockchain data storage vs traditional. Pretty sure Amazon could shave off $.07 just to win
Remember, we thought the Internet was going to be the great equalizer. Maybe we should remember the past and learn from it if the belief is that blockchain will be the great equalizer, Part II.
So Where Are We Now, Anywhere, Nowhere?
As I see it, if we look past the multi-million dollar losses from hacks and exploits (imagine they were your royalties), the infighting, the rip offs, and the ICO’s for dumb ideas at crazy valuations, I would say the scalability and legal aspects alone are likely going to be the anchor that weighs the whole thing down. From a cursory glance, if blockchain is the future for the music business, we are many many years from realizing this.
Hacks, ICO’s, Infighting, Exploits, Rip-Offs. I think we were better off two years ago with fantasy vs reality.
That means if you are planning to jump in head first now, you might want to rethink and check to see there’s water in the pool before you go all mission critical. Things are a bit of a shit show at the moment.
One of the Ethereum blockchain projects lead developers
What I currently see is a lot of “Me Too” solutions. In fact, as of writing this, I count no fewer than 20 blockchain music data/streaming solutions all vying for their position as leader in a market no one is ready for and frankly, consumers (the ones who drive the market) don’t want it. It’s like being homeschooled and running for Class President. There’s a lot of pitching and giving talks at conferences with lots of promises, by many people who have limited understanding of technology, or more importantly, the history of it. Yet so far, there’s nothing of real value. Many of the “Me Too’s” are based on whitepapers with the promise of building a new music industry, seemingly with no idea that what they are building is sometimes immoral or at the very least definitely illegal. Some of them are jaw droppingly dumb.
Look, I don’t expect any of these blockchain issues to be worked out over night. In fact I’ve been saying that on panels and in articles and interviews for two years. Many of the people I highly respect who are working on these projects and pushing these ideas are 100% coming at this from the right place and for that reason I hope they succeed. The music industry is a enigma wrapped in another enigma wrapped inside a ball of rubber bands. This is going to take some time, so some slack needs to be given. But we are in a nascent stage where there are going to be a lot of ideas floated, and a lot of technology pitched, and frankly most of it will fail. Benji Rogers, founder of dotblockchain, and a huge proponent of blockchain technology, was recently quoted as saying:
“If you’re in the music industry and you’re not looking at how this is going to affect your business, you’re going to be in trouble. But we can’t rush this. It’s worth getting right rather than just blundering into it.”
I could not agree more. You should be thinking about how it could affect your business, because it could in fact destroy the entire music business (my next article – piracy perfected). I also agree with the that last part, and it is why I’ve been pushing against this rapid jump to step onto a new world without any forethought or planning as to how we’ll adapt and survive there. You can’t just go to Mars without a supply of potatoes. We need to be asking much tougher questions, and frankly I’ve been very easy on these ideas without even touching on Authority and Privacy issues.
The questions we should all be asking ourselves when we’re being sold something so hard is, are there other possibilities we’re not exploring? Could we be approaching this incorrectly? Are there other options and ideas? If we aren’t asking those questions, then we’ll fail to transform the old creaky machine we have now, into the sleek machine we need for the future. We have little time to fix this, but that doesn’t mean we should fail to really think through where this may take us in 2-5-10 years. And on that note, I’ll see you in another two years.