Blockchain Development: backing a protocol vs. supporting a standard

In the world of blockchain development it is difficult to be protocol agnostic. If you are going to be developing in this space you need to be building somewhere… and because everyone is still figuring this out there are no clear boundaries on what solution/language/platform is the best for each application. The developers that work with Ethereum, Lisk, HyperLedger, EOS, Tezos, Hashgraph, etc will each tell you that their doctrine is the best doctrine - the articles, blogs, and message threads are filled with biases (or sales pitches). It is early days, and the bake-off has only just started; but this doesn’t mean we should just wait for the dust to settle before figuring out how blockchain will change our business - we should be shaping the blockchain so that we can best take advantages of it's attributes in the most straight-forward and simple as possible way.

Aside from competing protocols there are two other very important things that are happening:

1) Organizations are conducting blockchain experiments to understand how this new tech can make their business processes more effective

2) The blockchain community is developing standards around how to handle certain types of transactions 

In both cases this requires one to pick a protocol (or create your own) in order to do any kind of development, and this introduces the question of “which horse do you want to bet on?” - to some extent, they are all a gamble and odds are even the most adopted protocol today will look very different two years from now. In my opinion, it doesn't really matter - the core of what makes distributed ledger technology work is the same regardless of the protocol - it is for this reason that some developers can claim their DAPPs can work on multiple platforms. The important part is figuring out how to translate business processes and workflow into transactions and smart contracts; if we solve a problem in one protocol today we can likely apply the same logic to another protocol tomorrow. Further - because the protocols are open source with increasingly more democratic processes for governing how they evolve it is generally assumed that if something really good is developed in one, it is only a matter of time before the others incorporate it.

It is for these reasons that I don’t feel contributing to the development of a standard in one protocol is the same as same as proselytizing for that protocol - it is simply trying to solve a problem with the tools at hand. For example, there is some fantastic work going on in the Ethereum community around the development of the ERC-721 standard for non-fungible tokens. This work is setting the tone for how real-world assets will be tracked and transferred on a blockchain. Building the core functions for authorizing and executing transactions, aggregating/de-aggregating product, and monitoring inventory levels is something that any protocol is going to need if you are going to apply it to supply chain.

So in absence of a crystal ball that can tell us which protocol(s) will win out it becomes critically important that we understand, and document, how our functions actually interact with our current protocol of choice; and that we do this in the spirit of open source development so that whatever advancements are made can be picked up by others for the greater good, and more importantly that we are getting our use cases and requirements out there now, while the standards are being forged. This is how the learning from the experiments we are doing today will be used to shape how we rely on blockchain in the future.