I'm a full-stack developer, who's been following the cryptocurrency technology evolution for the past few years. I did some development on Bitcoin-forked-altcoin clients, and alternate language client implementations originally, and more recently have delved into Ethereum and DApp development. After learning enough about that to write my own guide series on getting started in Ethereum, I now find myself with several options for what to learn about next in the cryptocurrency/blockchain environment.
A few major frontrunners are:
EOS
A project to take the idea of "smart contracts" and extend from what Ethereum has done in that space with several fundamental infrastructure changes that could make development more like traditional software development (application code changes for bug fixes, account lockout options, human-friendly names for things, etc.)
Blockstack
A "layer-two" project that doesn't have a blockchain of its own, but instead rides on top of an existing blockchain (Bitcoin currently) with a "virtual blockchain" (its own metadata hidden in data blobs in the Bitcoin transactions), and provides the glue to user repositories of data (give the user control over their own data) to augment the data in the blockchain.
Status
A mobile Ethereum OS; taking the idea of a DApp being something that has access to the Ethereum blockchain, and wrapping it into a local ecosystem of many DApps all interacting with each other to break down the barriers between DApps, and make closer integration with ether transfers.
After looking at all of these as a developer interested in getting involved in new projects, I've arrived at the conclusion that they're all very young projects, and while the infrastructure developers of each project are working hard getting the "bones" working, all three need another layer of developers to make applications for those platforms, and all three have really high barriers to getting started, which has stymied me to a point where I'm here writing a blog post rather than developing on any of them.
To better illustrate what I think all three of these projects need, let me give two examples of projects that have done it well. Given a situation where you have a developer who's well-versed in 1-3 languages, has a few years experience developing, they probably know Git, and have frequented GitHub and StackOverflow and know how to use both of those. To get those users onboarded developing apps on a specific platform, here's what's needed:
Ethereum
In order to get started developing an Ethereum Smart Contract, open Remix, and in the top-right, pick the "Run" tab, and make sure the "Environment" is set to "Javascript VM". Now in another tab, open up Ethereum.org's token-creation tutorial and step through that (and the crowdsale and DAO tutorials it leads to). That's enough to learn the basics of Solidity and do some basic contract interaction within the Remix VM. I didn't have to install anything, and I'm already creating working contracts!
To transition from this "development mode" to real contract deployment, install the Metamask browser plugin, and switch Remix's environment to "Injected Web3". Fund your Metamask account with some ether to pay for gas, and you can publish your contract right from Remix. The hardest part of that transition for a new developer is likely the "fund your Metamask account", if they're not familiar with Ethereum yet.
Pebble Smart Watch
To get started developing for a Pebble watch, head over to CloudPebble, create an account and log in. Pull up their basic tutorial in another tab and step through it. CloudPebble has a built-in virtual version of all Pebble's watches, so you can test your application on all models right in the browser.
To publish the final application, you can do that directly from within the interface. You don't even need to own a Pebble watch to develop for one!
If you do own an actual Pebble watch, the companion app on your phone (that you need to have already to communicate with the watch) can handle requests from CloudPebble to deploy development snapshots of your application right to your personal watch. Click a button on CloudPebble, and it compiles your C code into binary code, sends the binary code from Pebble's servers to your phone, and from your phone to your watch and launches that app.
So, what did these two projects do? Both were introducing developers to potentially a brand new language for them (Solidity for Ethereum, C for Pebble) that also needs to be compiled before its run, and is an application that needs interactivity to test.
So, key things that made it an easy onramp for me as a developer:
Web-based IDE: When I don't have the install anything to get started, I can get started now, whether I'm on my 16-core workhorse with three monitors, or my Chromebook in a coffeeshop. Being able to start typing in a new language and at least have syntax-coloring to help me go, and tab-completion to save me from my own typos helps a bunch.
Web-based Virtual Environment: Being able to emulate the whole environment in a web browser is a great plus. Yes, as a developer, I probably have Vagrant and Docker already installed, and it's not too much trouble to simply provide a Vagrantfile and/or docker-compose.yml file and have me spin up my own private environment, but you'll always have a few edge cases with that setup (I've already got that particular port mapped to a different project, or my version of Docker is too old, etc.), and it makes my code a bit less portable (if I'm jumping back and forth between my laptop and my desktop, it's up to me to set up a git repo and keep my code changes up-to-date on both, and I have to create virtual machines on both my workstations) and harder to share with other non-developers to preview as I'm developing. Having no web-based environment and no Vagrant nor Docker setups (instead requiring installing some client software and running with different flags for development or whatnot) is a lot more opaque and difficult to onboard.
Containerized compiling: My history with C (from the first few times I tried to learn it, to trying to install other people's applications "from source") has shown that the compiling step is a place where new users can get completely turned around. Is my code bad for throwing error X or is my compiling environment set up wrong? Having a reproducible build environment is very helpful in narrowing it down to "it must be something in my code", and not "I thought I installed library X; why is it saying it can't find library X?"
Hello World!: I know, writing documentation is often the least-fun part of a project, but having tutorials that go beyond "Here's the API" to "Here's a template for starting a X-type project" are very helpful in getting past the initial boilerplate to start from a place where at least it compiles into something.
Given those things that I've seen work well, my suggestions for these projects from an experienced developer but new to their project are:
EOS
Choosing to use WebAssembly/WASM as the core bytecode I think is a great choice, in that there's already VMs built into bleeding-edge versions of major browsers. Creating a virtual environment that emulates an EOS blockchain within the user's browser should be easier to develop, since the WASM VM is already done for you.
Give me an IDE that already links to the eoslib standard library files, so I can focus on what I want my smart contract to do, and a way to send messages/transactions to that contract (in isolation, in the WASM VM) and that would be an amazing platform for getting started.
Blockstack
Given that your blockchain is "virtual" built on top of other blockchains, having a development version that fakes out the bottom-most blockchain layer for development would be useful.
Having Javascript be the key programming language for applications developed for this platform is great; I and many other developers already know Javascript and could dive right in! But needing to have a real, running Blockstack server on the same network for it to talk to hampers that. It seems this project needs something like Metamask; a browser plugin that acts as a light Blockstack node (holds user accounts and can store user data in the browser local storage) to inject the needed javascript hooks without further work by the DApp.
Having Yeoman templates is good for an initial "here's a working example", but as part of the "okay, now here's how the magic works", your tutorials don't link to the actual source code online, so there's not really an option for me to just read through it without installing anything; I need to be on a workstation I can yo blockstack on, because you haven't linked the generator project to an open-source repository for me to just view the source code online.
Having Dropbox as an initial implementation of the back-end for user storage is okay for me, since I have a Dropbox account, but others may not. And I only have one Dropbox account; I don't have a "development" and "production" Dropbox account, so keeping track of which garbage data I generate through the development process is up to me to go clean up later.
Status
Their app is a souped-up web browser for mobile, which does the web3-injection for DApps to hook on to, but how to test interaction before publishing? Until recently there were no distributed binaries and you had to compile your own Android APK yourself and figure out how to add it to your own real Android hardware. Recently they added an Alpha-version to the App Store for developers to participate with, which is a step in the right direction, though you still need your own real Android hardware to develop with, and the limited-size test group is full, so no new developers can join in. Being able to emulate the chatbot functionality outside the Status app would be a great help in developing applications against it.
Status supports "DApps on their own webpage", but their goal is for DApps to support Swarm also. But Swarm is also under development and is a moving target to try and hit. Documentation seems very thin on how to create a Chatbot app, a single-page app, or a Swarm app; it's assumed developers have created one of those for somewhere else, and are just porting it in, rather than building it specifically for Status. Working examples of those three to use as a starting point for developers just starting out would be much more helpful.
So, there we are; these are not show-stoppers, and I'll be continuing to learn bit by bit how to develop on these platforms, but hopefully other developers who know more about the underlying infrastructure can help create these glue pieces that can help adoption. I'll be seeing if I can get some standard Docker configurations working for Blockstack and maybe see if I can figure out how to create a development/temporary/local user data repository as well!