Hello fellow “Bancorians” (can we adopt that term? It’s cute 
). I’ve expressed several times that I think we should do one thing and do it well. I think it’s high time I fully explain mysmellf, and lay it out (for anyone with an interest) why I say that. As one of the core pillars of my mind, I’ve adopted the UNIX Philosophy; this has helped me greatly in my work, as it encourages narrow scope by default.
Firstly, what is the “UNIX Philosophy”? In a nutshell, it’s exactly what I’ve been saying; do one thing and do it well. It’s a tools-oriented philosophy that essentially boils down to, build primitives that you can combine in myriad ways to complete a task. If you find that you use a particular pattern or workflow often, package it into a “higher-order primitive”.
How is this useful? Building highly composable primitives confers several advantages to a system, among them:
- It allows developers and users to experiment with different compositions to complete different tasks or suit different purposes, share the best ones, and even package them into full programs.
- It saves the hecc out of developer time by abstracting away functionalities and dividing up the work; a developer of a primitive only has to worry about accomplishing one thing and optimizing the hecc out of that, whereas a higher-level developer doesn’t have to worry about lower-level implementation, it’s just there and it does its job and they can focus on their one thing.
So how does this relate to Bancor? Well, we are a highly composable primitive that does exactly one thing: swap one token for another while preserving maximum value, now.
- We allow DEX/dApp developers to abstract away the issue of dealing with market inefficiencies.
- DEX/dApp developers allow us to abstract away the issue of handling trades directly; in my ideal world, we wouldn’t need to have a swap function on our web interface; I think that function should be handled by someone else’s dApp working as a frontend, and our web interface should exist solely for the purposes of staking BNT/vBNT/TKN and viewing live data about the protocol.
- This attitude would prove to be profitable, as just getting plugged into the backend of many DEXes exposes us to many, many times more users than we could ever hope to attract in and of ourselves, even with marketing, and offloads a lot of development time and resource expenditure.
- We can compose other protocols into our DAO’s systems and build amazing functionalities, such as rewarding voting, with very little effort at all. The DAO could even hold a stake in other protocol’s DAOs.
The Bancor protocol express a simple relationship:
A >>= B >>= C
Which is to say, "A binds (aka maps) to B binds to C", where A is the input token, B is the Bancor Network Token, and C is the output token. Let’s not spend resources burying that simple, core functionality under a heap of detail-related fluff that we could easily let someone else handle. In my ideal world, we wouldn’t really need to have devs; the protocol would be automated to the point that governance decisions would just happen and the DAO would be totally self-contained and would just exist.
That’s not to say I don’t like devs! But a developer’s job is to automate, and we want to spend as little time (and money) automating as little as possible, and that means keeping a narrow scope and making that our sole, laser focus.
I’d like to have some discussion on this topic of philosophy, so please share your thoughts.