Why new platforms soar or sink, and where Neutron stands

How does a platform succeed?

Working on the Neutron platform, I’ve had to ask myself this question a number of times. As well as look at the other side of the coin, what makes a platform fail? My worst fear is to put all of this effort into building Neutron only for it to fall flat on its face when compared to the otherwise much more mature and resource-laden ecosystem of Ethereum and the EVM. How does a new platform compete against a relatively huge incumbent platform? To try to get a feeling on this, I studied many existing platforms, on blockchain and in the tech space in general. One of the most clear things I’ve learned is that technical advantage does not guarantee a platform will be a success, a hard truth. There’s already many arguably more technically competent smart contract platforms than the EVM. However, none have been able to even get close to replacing it in other non-Ethereum projects, much less Ethereum itself. With more thought and studying though, I believe I have at least an idea of how to answer this question beyond simply saying “well it depends”.

There are many subtle reasons behind each question, but I want to just cover the broad strokes here. There’s likely many aspects I neglected to write down as well. This is a blog and not a research paper after all.

What can help make a development platform succeed

1. First Mover Advantage

This is the biggest reason, and one which we can not address with Neutron. First mover advantage means the first to actually tackle and handle a problem directly. For the blockchain space, the first mover in this case would be Ethereum and the EVM. Outside of blockchain though, Javascript is a famous example of this. Javascript was the first real programming language supported in browsers without plugins. Looking at developer sentiment around the language, it’s often at best misunderstood and at worst outright hated… but it continues to be the most popular language in web pages. The only thing on the horizon that might replace it, and only for niche applications, is WASM (WebAssembly). This is because Javascript is in many ways a terrible language for precision computing and high performance computing. Precision is often a stumbling block because of a strange floating point system unique to Javascript, while high performance computing is inhibited by Javascript’s interpreted and difficult to optimize language design.

First mover advantage is not a guarantee of success. It can be squandered by mismanagement of the product or due to lack of capability to cover future use cases.. however, it is a major advantage that can not be discounted, and is often quite long lasting.

2. Massive First Party Backing

It is possible to buy your way into market support, but this is often extremely expensive, and requiring an extremely extensive “first party” ecosystem. There is also no guarantee that the market will ever accept it. A famous example of a success using this is the .NET ecosystem. .NET initially came out as a competitor to Java in a time when Java was extremely popular. Clearly .NET has survived, but it required god knows how much funding from Microsoft and internal support for 10+ years before it became a “first class” development environment, and even still has fairly limited exposure outside of the Microsoft ecosystem (ie, Windows). Microsoft even came close to squandering this advantage with the Windows RT debacle which saw .NET become 2nd class to native C++ and COM APIs, but they reversed that stance quite quickly.

The programming language Go also has this advantage to at least partially thank. There’s many complaints that Go, despite having strong ecosystem support, is not really developed with a public community mindset, but rather is driven by Google’s own development process. Despite this, Go is overwhelmingly a success as a development platform.

3. Community First

The programming language Rust is an example of this aspect. Despite being developed by Mozilla primarily, after the early few versions of Rust, it has had a much more community focused development process. This saw an extremely enthusiastic early adopter community which continually fed back to the development team and drove design discussions. The end result is that once Rust hit that magical 1.0 milestone, it was already a mature language with its own paradigms and development patterns. There was ample discussions on the internet for people to search through when they had problems, and overall this led to a successful, even if not yet mature, platform.

4. Covers an underserved niche

The programming language Rust is yet another example of this as well. Rust covers a niche previously only filled by C and C++ imperfectly. Specifically, writing low overhead and closer to the machine, high performance code. C and C++ are notoriously troublesome languages which are difficult to write safe and correct code within. Rust took the former niche, and incorporated designs which strongly enhance correctness and safety aspects.

Another example of this is Java, at least in the early days. In the 90s the burden of writing cross-platform code was quite high. There were far less abstraction layers available, more native code, and other issues. This meant that supporting a new platform, sometimes even just to support both Windows 98 and Windows 2000, meant writing a lot of custom code, and needing staff on hand to understand the intricacies of writing programs for each platform supported. This was obviously quite expensive, and so writing a program using Java seemed to be much more ideal. Write once, run everywhere, without concern of what the differences between each platform was.

5. “Drop in” compatibility with incumbent platform

This is a platform which basically can be ran on top of another platform, typically an incumbent and well established platform. Examples of this are things like Typescript being transpiled into Javascript. This is honestly only a minor advantage though. It by no means guarantees success. The biggest gains are by being able to instantly inherit a wide ecosystem of existing tooling and libraries. However, it is in some ways only an “implementation detail”. By using a drop-in compatible platform, the platform can not do anything more innovative than the existing platform.

There is another form of this where rather the incumbent platform is “drop in” compatible with the new platform. This is where things get more interesting in my opinion, but also much more technically difficult. A good example of this is the Android ecosystem. For those that are unaware, Android is basically a very specialized and new platform. It is compatible with Java by compiling Java code into their own VM called Dalvik, rather than by handling Java bytecode directly. This allows for Android to push forward with innovations in the form of stronger code optimizations etc, but comes at the cost of this platform mismatch at times leaking through. The most obvious examples of this is that Android lacks some of the “standard” Java APIs, a few Java language features (especially those around dynamic code) can not readily be used within Android, and likely many more subtle details. Regardless, it still means that the Android platform had a huge advantage in that developers had a much smaller learning curve in order to start using the platform, and a lot of existing code could be ported to Android with minimal amounts of effort.

Now, let’s look at the other side of the coin. What can help to make a development platform fail?

1. Fundamental security problems

The demise of both Flash and Java within the browser has this issue to blame at least partially. For Flash this was more mismanagement by Adobe (and previously Macromedia), but for Java this is a much more fundamental design flaw. The same issue extends to Silverlight (Microsoft’s attempt at .NET applets). One thing realized in the late 2000s and early 2010s is that the browser is a fundamentally hostile environment and any code written in it should be written in a way to closely guard against that hostility. When your platform is on the news as “lead to X million people getting a computer virus”, consumers will begin to look at any product built against it with skepticism. This in-turn discourages developers from relying too heavily on the platform.

2. High cost of entry

Part of Microsoft’s early failures with .NET and likely what stifled its growth in the early days is that .NET in the 2000s had a fairly high cost of entry. It didn’t cost anything for users to actually use .NET programs, but writing .NET programs almost always required Visual Studio. Today there is “community edition” of the full Visual Studio, and of course .NET code can be easily written using VSCode, a free and open source editor. However, back then it cost $500+ for a license of Visual Studio. This directly discouraged smaller programmers from developing within the ecosystem, and overall led to a “pollution” of the ecosystem in some ways, giving a very corporate and enterprise feel which further discouraged smaller developers and startups from joining the ecosystem. A similar demise was the downfall of the Delphi programming language. As far as I know they never sold a free compiler and so couldn’t compete as more powerful free programming languages popped up. It seems to be stuck as a “legacy” platform to tolerate, rather than an ideal platform to build new things on top of. The lack of incoming development ecosystem and community ultimately only gets worse as time goes on.

There many more historical examples of this as well with extremely expensive development platforms which did not end up lasting into the modern era. An obvious example of this is Linux. At the time Linux was first released, open source was a rather novel concept and the Unix systems of the time were extremely expensive, costing nearly $100K worth of today’s money for a single “copy” tuned for a specific machine, with no particular guarantees of support or bug fixes.

3. Assumptions of very specific use cases and environments

Languages and development platforms which assume they will be used only for very specific use cases or within very specific environments are subject to this potential downfall. It is sometimes just “a problem” rather than the cause of a downfall, but there’s plenty of this to go around across the tech ecosystem. A good example of a downfall is the failure of ActionScript. This was the programming language used in Flash animations and games. It has been praised quite widely as being a well designed and easy to use language, yet as of 2021 it is effectively dead. The downfall is that it was used almost exclusively for Flash animations (as far as I can see) and was designed specifically around that use case. Flash is dead, so now ActionScript practically is as well. Adobe tried to keep it alive using their AIR platform, but ultimately that platform never really took off and only saw one popular product that exposed consumers to the platform (TweetDeck)

Another less niche example of this aspect is actually Javascript. Even today, despite being a popular platform, it has had some significant growing pains when moving into the server-side space with NodeJS. Javascript’s core design assumed a number of things which are blatantly not scalable, and working around those design issues has tended to introduce significant amounts of complexity to its usage in high performance applications.

Where does Neutron stand?

So where does this leave the purpose of this article, Neutron’s positioning? We need to analyze the which of these categories Neutron falls into.

• We of course missed out on the first mover advantage to Ethereum. Nothing can be done about this.
• We do not have a massive first party (ie, Qtum/Earl Grey Tech) that we can rely on to “force adoption”. Although we have plenty of resources, we do not have Fortune 500 level resources that could make this possible for the extended amount of time that would be required.
• Taking a community first approach is difficult, but we will be attempting it. We will soon announce a call for partners with required information to start contributing to the Neutron design and to help shape the early ecosystem. We believe Neutron can only be a success if it is adopted into blockchains and platforms beyond just Qtum. However, doing development fully open is something we’re still going to be learning, so there will be some stumbling blocks here. Regardless, we are looking at radically opening up our development process. This could include making our project management system (Trello currently) publicly viewable, holding development meetings so that anyone can join and listen along, providing transcripts and meeting notes to the community, and having scheduled community calls to take questions and concerns directly from the public. We are going to be trying some of this, and likely a number of other things, but it will take some time and pain as we navigate this new process.
• Neutron is designed to serve an underserved niche. Specifically blockchains and layer 2 models which simply do not “mesh” with how Ethereum is designed, and thus where integrating the EVM is difficult to reconcile with the blockchain’s underlying model, or would require great complexity to expose the features of the platform to. Neutron is designed as “The smart contract platform for everything that’s not Ethereum based”. In this way we avoid “competing” against Ethereum on its own turf, but rather we want to put Neutron in places where Ethereum technology just doesn’t work or makes little sense.
• Neutron will not be drop in compatible with the EVM in terms of you won’t be able to write a Neutron smart contract and immediately run it on Ethereum. However, the opposite is planned to become true. Specifically, writing an Ethereum smart contract, compiling it with standard Solidity etc tooling, and then running it directly on a Neutron platform via Neutron-EVM. The exact design of this is still very far in the air due to how many more features Neutron can expose compared to what the EVM is capable of easily expressing, but this is an aspect we will begin looking at more strongly after the core of Neutron is established.
• Neutron is being designed with a low cost of entry. Specifically, we are aiming the platform to be as simple as possible for blockchains and L2 providers to integrate with. This includes the extensibility to handle decentralized soft-fork and hard-fork options, and semi-centralized no-fork methods. These exact methods will be fully described at a later point
• Neutron makes as few assumptions as possible for a smart contract platform. At its very minimal core, all Neutron needs from a blockchain/L2 platform is a method of loading smart contract bytecode. It is however designed to be extensive enough to cover the wide variety of features available in these platforms in a logical and consistent manner, with no architectural changes.