Why Urbit?

Search…
Why Urbit?
Whenever we talk about building Uqbar on Urbit, two questions tend to arise:
1.What do we get by using Urbit? 
2.Can those effects be achieved in another way?
These are extremely reasonable things to wonder, particularly given the twin tendencies of programmers to 1) invent their own tools rather than use proven solutions, and 2) proselytize their latest language/framework obsession as some kind of silver bullet.
With that in mind, let's dive into our answers, treating both questions with the respect they deserve.
What Urbit Buys Us
We want to program in a unified environment. We don't want to glue our programs together out of myriad SaaS pieces, whether those pieces are centralized or decentralized. We want to address other machines on the network as permanent identities. We don't want to deploy a new database or access a new service just to store app state.
Blockchain programming, perhaps more than any other form, suffers from the lack of a coherent system in which to write applications. That absence is variously referred to as a lack of "middleware", "composability", or "tooling". None of these terms fully captures the problem, but together they point to the need for an operating system to seamlessly connect all of Web3's disparate elements.
Urbit is not perfect, and it is very much a work in progress. However, it is by far the closest we have to this type of system, and it is improving rapidly. Urbit is currently the only off-the-shelf OS that abstracts over all the pieces of a computer we require: authentication, networking, identity, database, software distribution, and versioning. In a very real sense, we use Urbit because it exists and works. 
If Urbit didn't exist, we'd create it. 
Because it exists, we want to use it and improve it, not re-invent it.
Why We Don't Do the Same Thing Another Way?
Of course, Urbit's creation has taken significant time, and off-the-shelf solutions already exist for certain of its capabilities. If one accepts the premise that a unified OS is desirable, it's tempting and reasonable to look at available alternatives and ask how they could be modified and improved to achieve our goals.
So let us look at them.
Non-Urbit Approaches
Without Urbit, there are three basic paths forward for web3 programming:
1.The status quo,: iterate different pieces of the stack forward on an ad hoc basis, patch whatever holes arise, improve isolated tools, and glue it all together. This is the most likely path the blockchain industry will take, and it is very much a local maximum in our view. This approach does create some cool primitives, but it punts the hard work of coherently combining these elements into a whole. We believe the result will fail to achieve escape velocity.
2."Based Web2", or "Web2 with a Web3 soul": significant cloud architecture, run by one company, resistant to regulatory pressures via jurisdictional arbitrage, and providing access to permissionless assets on a public blockchain. This would feel something like "Twitter goes all-in on crypto and integrates it with all aspects of the platform." Such a service would act as a kind of OS for its users and likely provide a generalized API that third-party programmers could use to create apps. Binance and OpenSea can be thought of as weak versions of this approach. 
3.Copy Urbit: make a VM that can run in browsers, connect it to a PKI living on Ethereum, add filesystems and databases, and create the operating system software to sync infrastructure and updates. Likely the creators of such a system would refer heavily to Urbit's existing design. It may attempt to gain market share by appealing to people who think Urbit's codebase is "weird".
Problems with these Approaches
We clearly don't think much of the status quo. However, both "Based Web2" and "Copy Urbit" deserve attention.
Web3-ified Web2
The failed efforts in Web3 to produce "Web2, but decentralized" have highlighted many of Web2's inherent advantages. It has become clear that it is impossible to simply replace cloud services without acknowledging the useful OS-like functions that they perform. It's great to tackle "decentralized social" until it becomes clear that Twitter and Facebook are providing full networked operating system for their social applications. If you don't replace the OS component (devops in the cloud), things get very ugly, very fast.
The challenges for Web2 are always going to be regulatory systems and programming permissionlessness. 
The first challenge is well-known: any time a centralized system provides access to financial products, it becomes an attractive target for regulatory action. As a result, the system would probably have to be provided by a new company, whose leadership and employees lived outside of major countries. It's not impossible to imagine such a company existing, or regulatory conditions changing sufficiently in a country like the U.S., but these futures face a significant headwind.
The second challenge is more mundane, but more fundamental. One of the most beautiful, freeing elements of Web3 is the ability to write software and deploy it without permission. Programmers don't need to ask companies to open their API, approve apps, or add features. They can just write what they want and publish it. That ability is lost when interacting with a Web2-type cloud app, even one managed with the best intentions. In a very Darwinian sense, we don't think that a permissioned system is fit enough to outcompete the permissionless alternative.
Copying Urbit
Copying and improving Urbit requires admitting that Urbit is doing something useful by attempting to unify the full computing stack. This thesis must convince more than one person—a substantial team or group of investors—without their choosing Urbit itself along the way.
To improve upon Urbit, this new project would either have to invest significant time and money to catch Urbit or always lag behind Urbit's core development as they added features and improved the product. 
Finally, it is likely that, beyond purely cosmetic features, the underlying product would independently re-derive many of Urbit's architectural choices. In that case, such useless reinvention would likely suck talented developers to Urbit itself or other more creative projects. 
These problems aren't theoretical: several projects have tried to copy Urbit and have run into one or more of the problems detailed here. This doesn't mean no other Urbit clone will succeed in the future. Were another group to seriously attempt to create a new and improved Urbit-like system, we would be very excited to follow their work and even invest in their system if it offered potential. 
Currently, nothing promising is on the horizon.
Conclusion
This is a developing field and we expect the next few years to substantially impact our thinking and product design. For now, we are loving our initial bet on Urbit and are excited to continue learning and developing as we move forward. 
Web3, Unified
Next - Uqbar and Urbit
What is Urbit?
Last modified 1mo ago
Copy link
Outline
What Urbit Buys Us
Why We Don't Do the Same Thing Another Way?
Non-Urbit Approaches
Problems with these Approaches
Conclusion