Sayonara, Q1
We spent Q1 working towards two things:
- Making Colony more open
- Launching a fully decentralized app on mainnet by Q3
Making Colony Open
Our goal has always been to transition Colony into a fully open sourced project owned by the people who contribute to it — it’s just been a question of when. We’ve begun that transition by:
- Open sourcing our repos
- Making it easier for people to get involved
Open Sauce
There’s a reason we’ve been striving to open Colony up: we have a grand vision of an open, meritocratic, self-sovereign future of work. Together, we will manifest that vision more broadly and effectively than any one team could alone.
To that end, last quarter we open-sourced the backbone of Colony: the colonyNetwork. The colonyNetwork contracts are the basic units of organizational logic, running on Ethereum. They handle the ‘consensus-relevant’ aspects of Colony — things like funding, ownership, and reputation.
However, dApps which hope to achieve mainstream adoption also need great user experiences. A lot of our labor goes into creating strong foundations for these interfaces. To that end, we’ve got some important developer tools ready to go as soon as we finish the docs:
ColonyJS
If you’re a developer familiar with JavaScript, React, node.js, or related frameworks, you shouldn’t have to go back to basics to build your own projects on the colonyNetwork. Using the colonyJS library, you don’t have to! ColonyJS includes all the colony-specific methods for calling functions on the colony network, adapters for your code to interact with Web3/Ethers.js, and loaders that pull contract code from known sources (e.g. our very own trufflepig). Just add colonyJS to your project and start building. Boom.
colony-wallet
While working on the dApp, we realized that there’s really no good, generic set of wallet utilities for developers. We needed one, and figured others might need one as well. The colony-wallet is a set of utilities for developers to create/open Ethereum accounts from a variety of sources (e.g. metamask, hardware wallets, mnemonic phrases, private keys), as well as to sign and pass transactions to an Ethereum-like network provider (e.g. a local node, metamask/infura, or etherscan). Currently the colony-wallet has a feature-set limited to what we need for the dApp, but we hope to polish it to become a universal utility for any developer working with Ethereum.
Get Involved!
We’ve started to make it easier for people to be part of Colony by launching our Contribute page. There are four ways to join in:
1. Contribute to OS Repos.
Since opening our Colony Network repo, we have had two active contributors, Filip and Sebastian. If you’re a dev interested in digging into some really meaty Solidity, join our Gitter, or just go grab yourself a piping hot issue. This one looks tasty.
2. Non-dev Bounties
It’s common to open source your codebase and tap into OS contributions from devs. But what about from non-devs? We want to enable any skilled person to contribute to Colony. To this end, we’ve created a profile on Gitcoin to incentivize non-developer contributions. We’re also experimenting with having others add issues and us, if they are good issues, funding them. We’ll see how that plays out!
3. Paid Internships
Another of our goals, pursuant to having more people contribute to Colony, is to increase the number of people working in this space. We’ve created a 3-month paid internship targeting students and n00bs to the blockchain ecosystem. This is across all of the teams at Colony; not just dev. We believe that this technology will impact our future, and we want to help usher in as many smart minds as we possibly can. So far we have brought on board three paid interns — Jan, Scott, and Nicole — doing tours of brain growth across Dev and Ops. If you are interested in an internship with us, you can apply here.
4. Join the Colony Team
We’ve been actively adding super premium beards to the Colony team. Please extend a warm welcome to the three newest Coloneers:
Decentralize without Compromise
We’re determined to deliver the rich user experience we’ve all come to expect from Web 2.0, but in the completely decentralized manner that Web 3.0 promises. To create that full, personalized experience, our decentralized client will need to handle a greater amount of individual user information than perhaps any other dApp so far built.
After ransacking ‘teh interwebz’ for candidate decentralized databases, we came up with several interesting projects, including OrbitDB, Wolk, and Fluence. We chose to build a proof-of-concept on OrbitDB first, though we hope to support several database solutions in the future.
This simple PoC allowed us to delve into OrbitDB’s internals (logs! snapshotting! Distributed systems! CRDTs!). We also worked with OrbitDB’s variety of databases, and most of the data types we’ll need, and refined an API which will assist us in our future data API (see the preview of Q2 up ahead!).
Product Roadmap
The product team spent Q1 reviewing the learnings from our beta, interviewing users, and designing the next iteration of our product.
Our future-of-work thesis is that work will be more open in the future. We have three verticals for this (in order of complexity, from simple to complex):
- Open Externally
- Open Internally
- Open Globally
Our product launches map onto this. We’ll build tools first to make it easier to tap into external talent (tasks, incentives, reputation), and later to enable granular governance (authority, decision making, dispute resolution, and rewards) of open, and decentralized organizations.
What we’ve learned though our multiple private betas, and customer discovery process, has all informed the initial product which will launch on Ethereum mainnet in Q3. We’re really excited to release something we think is going to be very useful in the Ethereum space. A full product specification will be provided in a forthcoming article.
Thank you to all those who participated in our various rounds of user testing, and gave us valuable feedback on UX and design.️ ❤️
We wrote some things, said some things
This was another heads down, doing the work kinda quarter for us. Nevertheless, we did get coaxed into saying a few things:
Konnichiwa, Q2
ColonyJS Library hackathon; a decentralized database; a launch. Bring it, Q2.
ColonyJS Hackathon!
Not only are we developing tools for end users to create and contribute to open organizations, but we’re also creating tools for developers to:
- Integrate our contracts into your own interface
- Build applications/extensions on the Colony dApp
- Customize the default experience and workflows
- Create integrations with other tools
We’ll be hosting a $25,000 online hackathon this June for developers to Build With Colony. If you’re interested and want to learn more, sign up to our newsletter to be notified.
More Database Decentralization
In Q2 we’ll continue to work with the wonderful team behind OrbitDB to push the project forward. For our current needs, we’re focusing on helping expand database permissions, and a pinning service.
Suppose you’ve started or joined an exciting new colony. You might create a domain to coordinate a particular type of work. You don’t really want just anyone changing information in that domain, but as new members join, they’ll need the ability to change information. That means you need the underlying database to support dynamic permissions: adding and removing permissions for users to write to the database, as appropriate. Adding this feature is a major focus for the Orbit team and for us in Q2.
To understand the pinning service, first suppose you start a colony all by yourself, an ant workforce of one! For someone else to join you, they (or their browser) will need to sync your database. But for a peer-to-peer database to be synced, you’ll have to be online at the same time as your new colleague. And what if you change devices before someone else joins, who’s going to sync with you then? This is the bootstrapping problem, the central puzzle of peer-to-peer architectures.
To ameliorate this problem, we’re building a pinning service, similar in spirit to ipfs-cluster. It will serve as an always-there peer for syncing when someone joins a colony. In due course, we’ll open this repository to the public, so that you’ll have the choice of using a pinning service we’ll (at least temporarily) provide, or running your own for greater control.
We’re also planning to build a data API that could rely on any of several decentralized databases. It will need to integrate information from the decentralized database, from Ethereum through our JavaScript client library, from IPFS, and from user wallet and local data. We look forward to developing our data API into a mature and sturdy example of integrating diverse data sources for a reactive web app.
A Launch
While a functioning mainnet launch will come in Q3, we have a cheeky little somethin’-somethin’ planned for mainnet later in Q2. Stay tuned. 😉
We’re Hiring
We have two open roles right now, with three more to go live as soon as we get around to writing the job descriptions. Check out our job listings on our AngelList page.
Colony is a platform for open organisations.
Follow us on Twitter, sign up for (occasional) email updates, or if you’re feeling old skool, drop us an email.
