Also, can you offer any constructive criticism to the Bts project? Advise? Help in any way? Will you participate in the referral program? Do you own any Bitshares? If so, wouldn't it be in your interest to grow the value of those shares?
When I left the project, I wasn't given any incentive for further participation. Over time I did provide some advice such as the need for smart contracts to fully realize DACs and also some comments on consensus issues, but my biggest concern has always been academic in nature. The concept of building a value stable currency is incredibly compelling and deserves proper modeling and research. Despite raising millions of dollars, the Bitshares project never retained any talent capable of formal modeling of BitUSD and other mechanics and discussing it in a game theoretical or systems theory perspective.
There certainly are critics on the lack of development methodology or test driven development, the physical location of Bitshares development in Blacksburg, VA (chosen for convenience to the founders rather than location of talent), the idiocy seeking to spend all the Angelshares funds rather than conserve them to avoid end of year taxes (why didn't you found a holding company in a jurisdiction with no taxes?). But there really isn't anything that can be done for prior mistakes. You just have to move forward.
If I had to offer any advice, then I'd strongly recommend examining the project from three perspectives. One is technological. One is from an adoption viewpoint. One is from a project management perspective. In terms of technology, bold claims need to be documented and properly communicated. Bitshares is notorious for saying things and having nothing to back them up outside of trust the developers to build it. Demos, source code and whitepapers really go a long way and it requires a lot of foresight. These systems are in the category of mission critical software, not lean agile systems. You're not shipping a cell phone app. You're shipping the Mars Rover. Once you launch it, super hard to change it. So plan ahead and have lots of conversations about how things ought to be done.
In respect to community building, Fuzzy and others have done a good job working hard, but you need to think about the core mission, values and goals of the project (MVG) and distill them to a single 1-2 page handout. Then ask ok, who will be most receptive to our MVG? Meetup groups are wonderful relays and pay enormous dividends for the investment it takes to bootstrap them. Conferences have the absolute lowest RoI. Also you're really not going to win the Bitcoin community. Ignore them and move on to different cliques that have a lot more bang for your buck. Make Bitshares the entry point for someone in cryptocurrency.
In respect to that point, it's really about ease of use and overall experiences. In what ways do you imagine people are going to use Bitshares? Who are natural platform partners? Bitshares 2 is taking a very big pivot it seems to the enterprise market and there is definitely money to be made there, but let's be clear that it comes at a terrible price. Enterprises have AML/KYC requirements and also have to play nice with governments. Ripple Labs learned this the hard way. Thus there will be a likely strong demand for increasing the level of attribution on Bitshares transactions as has happened with Ripple. You simply cannot avoid this pressure because your consensus system uses a federated topology via delegates. They will not be distributed enough in practice to avoid pressure. Second, exchanges using the tech
HAVE NO CHOICE but to comply or go to jail.
So the takeaway along these thoughts are that different groups have different needs and it's impossible to satisfy them all. Bitshares has to decide if it's a consumer product or an enterprise product. Understand your community accordingly.
As for project management, best practices include using Scrum with test or behavior driven development, rapid 2-4 week releases with a QA testing phase, some sort of CI process and a dedicated infosec expert involved in the releases. The common CC model is having a testnet and a mainnet. I would strongly collaborate with Blockstream to build a sidechain between the testchain and the mainchain. They are entering your space, a partnership serves a proactive nullifying role as much as it does a technological benefit of having a robust test chain ecosystem. The choice of C++ as the primary language is really bad. From my experience with Ethereum, Go turned out to be a wonderful ecosystem to work in and it was easier to find open minded talent. Elixir is also promising as the hyperledger guys found out.
In all honestly about languages however, frankly Bitshares would work a lot better being built in something like Java or on the .Net platform. Its really about can I find great talent, are there wonderful tools to work with, is this code going to be easy to manage and update, can I avoid technical debt better in this ecosystem? If I'm doing rapid prototyping, I love python. If I'm building mission critical systems, then I need to significantly reduce the things I have control over to as small as a set as possible and leave the rest to predictable and well vetted behavior. It means you need strong typing, great testing tools, automated memory management, certainly compiled alongside access to certain DSLs that can facilitate specialized testing methodologies. For example Coq proofs are great for modelling consensus and can be written in the JVM ecosystem via Coq->Scala->JVM. .Net has a great family of cryptography verification toolkits written by Dr. Blanchet. While a lot of good crypto code was written by Wei Dai in crypto++ as C++ code, it's important to understand he's a world famous cryptographer, the Bitshares developers are not. If you have to customize things, then do it in a sandbox that holds your hand.
The last points are examples of philosophical differences. Reasonable people can disagree with me. But the lack of formalism for concepts like BitUSD and also utter lack of documentation for pretty much every piece of the protocol are not excusable as a philosophical disagreement. It's laziness or incompetence. Your community is making extraordinary claims about things. They have to be backed up with theory and code. You will not get respect until that's done.
Topic: My interview on XCP Weekly About the Entire Cryptocurrency Space (Read 6395 times)
