Ethereum and similar platforms intend to generalize Bitcoin technology by adding a Turing complete language to the stack. The idea is to have a powerful language at hand with which to implement all kinds of applications - Bitcoin is just the first app, the real technology is the immutable Blockchain and consensus over a distributed system.
Bitcoin, on the contrary, deliberately supports a very sparse, incomplete scripting language to avoid attack vectors. Bitcoin is a platform which enables transactions, and generalizing it towards an application platform can enable many interesting innovations around so-called smart contracts.
Ironically, this defeats the decentralization purpose, because application data and logic will be centralized on the Blockchain.
Smart contracts with code that is shared among all participants, which cannot be changed - unless there is a hard fork, which requires the consent of the community - and data in an immutable ledger can be a powerful platform for certain use cases.
Often, these can be legally relevant contexts - contracts that enforce itself based on input (an oracle from the outside world, claiming, for example, a certain temperature at some place at some time or a payment received) and an effect - such as regulating energy supply or enabling a key for a flat. Cause and effect do not need an intermediary, an agent or a legal system other than the smart contract.
These just execute “unstoppable” - like a vending machine: insert a coin and the mechanics ensure you get your bottle and you don't need a shop in between.
Investigating how far we can push this idea promises to be a fascinating undertaking. Note that this is an important but a rather limited set of use cases, which, so far, we haven’t implemented satisfactorily mainly because we don't have a platform enabling them. Sharing data and rules in an open platform is essential for this use case - rules and actions need to be verifiable, while data and code need to be unforgeable.
Application enabled Blockchains centralize technology
However, this is not the case for the overwhelming amount of use cases. It is a triviality because we implement all kinds of use cases without having Blockchain smart contract platforms. In fact, we even claim that when we have such platforms there is no reason whatsoever, on the contrary, to implement all use cases and applications on top of them, unless they have the very specific characteristics smart contracts attempt to cover. Imagine you decide you “really need” some of the blessings of distributed technology. Yes, you want smart contracts, you want code that cannot be changed once deployed, you have a need for crypto payment and you believe this is the future.
Way to go
You are all ready for decentralization - it sounds like a new and free and better tech utopia to you. But then you realize, you might not be as free as you'd like to be. Because while you can choose in your own box any language you like, any database you like and any UI framework you like - some have been around for years, proven and specialized for some of your needs -, in a decentralized platform you are stuck with solidity, which, someone as part of some community deems to be the “way to go.” All nice and respectable but doesn't it smell an awful lot like a worse choice than, for example, choosing an Amazon platform where at least you can decide on pretty much anything on top of the server time you buy? The most radical form of decentralization seems to just hook on your own barebone server and throw anything you deem best for you on it.
That granted, why would you even need such a decentralized platform then? The answer, in my humble opinion, is obvious. When you investigate the context the platform was invented for with Bitcoin:
“A decentralized “Bitcoin-style” platform is interesting when and only when you want to do transactions with another actor in the network.”
There is no point sharing your data, there is no need for unforgeable data or code unless you are executing transactions with another player. A whole lot of your use-cases can be entirely for yourself, your organization. There is no reason to place them on a Blockchain. Only data that is relevant for a minimum of two players in a network should even get considered for such a platform and whereby you intend to do something with the smart contracts. To speak of examples, when you send a purchase order from a Web shop to a vendor - e.g. a large logistic party - then this order could go on an immutable Blockchain shared between several players.
Data should be immutable and there might be smart contracts in the sense of code that executes automatically like picking the book you ordered from the shelf as soon as a payment was received.
Application enabled Blockchains centralize data and logic
Now, consider this approach of how a decentralized trading platform would look like. You take eBay and re-implement it on an application enabled platform. So, you decide to submit yourself to whatever technology patterns this platform advocates because you want immutable transactions and you want this marvellous DAO concept - no irony, we are referring to the original sense in which Bitcoin is a decentralised autonomous organization, not the Ethereum DAO - re-used to have a more democratic and transparent and a less monopolistic and centralized approach to trading.
There appears an obvious problem and an obvious solution - Blockchains, at least in their original form, share data even though they can encrypt it and we can make smart choices what to share and what anyone should be able to download on the Blockchain. But why would you want your purchases on an eBay Blockchain that is, potentially, shared with the world? You don't, so obviously you shouldn't use a shared platform here. Is your whole application logic even that relevant for the rest of the world to share it? Absolutely not, a part of the transactions can be useful for sharing in a semi-public ledger for verification but certainly this is just a small part of your application and all your other logic - what is offered, how to offer the client the next best product, how to do credit card payments - really has no value on a public ledger. In other words, when you place your entire application on a Blockchain you create a 'honeypot' of data on a shared platform and at the same time you burden the Blockchain with data and logic which is not relevant for anyone else in the network.
The first part of the platform - you expose too much sensitive data on a Blockchain - is addressed often with the concept of a “permissioned ledger.” That is a ledger which is accessible only by a consortium but by no one outside that illustrious circle. Even though “immutability” - less hashing power if the consensus mechanism is proof of work - might be “less immutable,” there can be cases where this scenario is useful. Some might argue in reality that one could just as well use a shared database with advanced auditing and logging to avoid forging. I believe we could even go a step further and say that if you have data that you don't want to be shared, then just don't use a distributed system. No matter how smart and sophisticated your cryptography will be, in a distributed system, at the end of the day, there is some form of data sharing and if you don't want that you shouldn't go for a distributed ledger. Differently put, you should share your data exactly with those for which a transaction is relevant (to execute or verify) and you should share only data and logic, which is relevant for more than one actor in the network. Placing your entire application on a shared distributed ledger will almost always violate this principle and therefore is not an appropriate architecture. What can be useful is to use a permissioned distributed ledger, including smart contracts for transactions between participants in the network, such that you can control who sees what with partial sharing - e.g. hash fingerprint of a transaction - and advanced cryptography.
A decentralized vision
If all of this couldn't convince you and you believe Blockchain is, kind of, the “only” way to go, on the premise that it is so nineties and you can't be serious about advocating centralized clouds like Amazon Web services, consider this point:
“Wouldn't it be natural for a decentralized paradigm to allow as many different technology and governance approaches as possible?”
A decentralized vision should allow as many different technology and governance approaches as there are.
If someone prefers his COBOL on premise or his Amazon cloud platform, shouldn't it be that person’s decentralized choice to use it, regardless if this very application is entirely centralized with him? There might be perfect reasons like: "I must keep most of my data behind my firewall" or "Python on Heroku is simply the best - at least our team is brilliant on this platform" or "I don't like solidity as a language, this presumptuous Ethereum metaphor “world computer,” that DAO drama, etc."
I think the answer, from a de-centralization perspective, can only be “YES! OF COURSE!” We should have as many technology paradigms as possible and those should compete for different contexts, and different stacks will be useful.
Data format problem
Application enabled Blockchains hardly tackle the “data format problem” - but they should!
If you accept this verdict, and you should, the focus shifts and the 'real' problem of decentralization is a well-known problem, usually referred to as “integration.” At its core, it is about solving the problem that different applications often talk, which often concern the same thing - i.e. a client, an order - but have different data formats, different message formats and different APIs to address those when they interchange information. There is no automated way to translate these - usually, humans need to “code up” a solution which can be tedious and it is actually the basis of a large industry helping large enterprises with products like “Middleware” or “Enterprise Services Bus.”
The decentralization ecosystem, for some reason, doesn't even look at this problem. Allegedly, this might be because of a false feeling of “we decentralize enough!” The Bitcoin lent concept of miners, consensus and a distributed system can help make code unforgeable and data immutable, and gives rise to the governance concept of a Decentralized Autonomous Organization - what else?
This, however, is really just “decentralizing from within” - it is as if Google decided to go to the bright side and reorganize their internal departments democratically and consensus oriented and ask users and customers more on their opinions.
It would be a good thing, but it really doesn't mean so much for the user of a platform - if the Ethereum ecosystem decided to be civilized and decided whether we are going for a hard fork or not or what we are going to do to language “xyz” now and learn from our solidity mistakes, then this is good to know, but from the “outside” it really doesn't matter if some top-leader CIO has decided that to satisfy some growth and revenue numbers.
What you want instead is total autonomy of your application, governance and your transaction model. You pick whatever platform you like and to facilitate the transactional part you might want to use a distributed ledger, which is as seamless and has as many benefits - i.e. immutability, unforgeable, rich and secure language to write smart contracts - as possible. Here, for the transaction handling, there is some dependency on the ecosystem. You might prefer your “friendly,” decentralized autonomous organization over a “shark CEO” - but you might still get overruled, so don't use this too often! The good news is, this really just concerns this small, albeit very important, part of your application where you transact with others.
Generalizing Bitcoin the other way
With that in mind, one could take a fresh look at Bitcoin as a transaction platform, as opposed to an application platform, and attempt to generalize which information can be passed between endpoints - we wouldn't be interested in the question so much of what application logic could run on the Blockchain but rather what information we can exchange between endpoints via a decentralized platform. Such scenarios can be useful for trade among parties.
In fact, the difficulty to execute transactions on the Internet between parties serves as an “entry door” for many centralized platforms.
Imagine a world where applications could seamlessly talk to each other, there would be some magic “Babelfish” translating messages between systems - like simple websites from individuals offering and selling - reliably and we could even commit transactions - I order your room for nights xyz for price abc from you - in an immutable transaction log, where some smart contracts - the key to my flat is activated after I received an X amount - performs its magic.
Would we still use Airbnb in this world? Or need eBay? Maybe not, maybe we would.
But undoubtedly, the need to use Airbnb or eBay or Uber as a virtual place where people can “virtually meet” and do business would be much less urgent. Platforms like Airbnb - or Uber or eBay or Facebook - have a similar position like banks in that they enable people to communicate and transact and, via this position as a middleman, dominate an entire ecosystem, presumably taking too “large of a cut” of the transaction.
Recently, there are efforts from consortia and bodies like the W3C to standardize intercommunication formats to standardize communication between Blockchains and applications. The approach is to agree between humans with which data formats will be used to interoperate. This approach is the standard approach - it is basically the only approach to “make applications speak” and is used in any large enterprise internally to connect different applications. Attempts to standardize communication with open standards is laudable but has the unfortunate side effect - with its boards and processes - to stifle innovation. If there is no accepted standard, like SMTP or HTTP, but the market is lucrative enough - sharing your flat or offering a car ride - you see large monopolies establishing standards on their platforms and forcing participants under their rules.
This is the other decentralization problem - how can we make applications talk to each other as seamlessly and reliable, so as that there is no “translating middleman” needed. Decentralized ledgers can contribute to this architecture.