Colony Q4 Update

Colony
Colony
Published in
6 min readOct 17, 2017

At Colony, we use the OKR method for setting quarterly goals and keeping our distributed team of 12 in sync and accountable. Below is our quarterly report on Q3 and a look ahead at Q4 2017.

The end of Q3

Good riddance, Q3

Let’s start with the good.

  1. We published our whitepaper

N of 1. Full stop.

The rest of the quarter? Well, some unexpected things came up.

Our main goal for the quarter was to distribute our tokens. We had everything in place. Whitepaper. Wiki. A beautiful new website. Our token sale contract had been audited by the talented guys at DappHub. The works.

But then our lawyer called. And then this happened.

That changed things.

We spent the better part of a month regrouping and figuring out our next steps:

  • What do we need to do to do a token sale? (A: launch the network first.)
  • What’s the minimum functionality needed to securely launch the network? (A: reputation system + revenue & reward system.)
  • How do we remove the reliance on centralized tech in the client? (A: it’s very complicated.)

We were expecting to do quite a few things in Q3 that were impacted by the not-doing-a-token-sale outcome:

  1. Announce and launch Colony Labs to research and work on the blockchain usability problem
  2. Deploy the initial Colony Network functionality to testnet
  3. Start a second round of beta testing
  4. Hire a handful of additional teammates

All of this was either iceboxed (#1 and #4) or delayed (#2 & #3) due to the token sale fallout.

Oh well. It may seem like a huge impediment, but it’s really not. We’re in this for the long haul and postponing a token sale by ~1-year is not a big deal when you zoom out.

The Colony Whitepaper Release

After initially sharing it with a curated list of reviewers and then incorporating their feedback, we published our technical whitepaper.

It had been a long time comin’.

Our most flattering comment so far:

I’ve had high hopes for Colony since I came across it several months ago, but this White Paper far exceeded my loftiest expectations.

The Colony Whitepaper is the culmination of years of hard work and painstaking attention to detail, but it’s certainly not perfect, and it will be updated as needed.

If you’ve read it and have any suggestions for improvement or clarification, hit us up over slack, email, or by submitting a Github pull request.

We wrote some other stuff, too

At the beginning of the quarter, we open-sourced a document for creating a fair employee equity plan.

Thiago published an illuminating technical blog post on Solidity function best practices.

And our CEO Jack du Rose had a couple bylines on the future of work

Well met, Q4

This quarter is going to be all about building and learning — the Colony Network, the decentralized product, the market.

Our three goals are:

  1. An MVP of the Colony Network is built
  2. 50% of the decentralized backend is complete
  3. 500 completed transactions are completed by beta-II users

The Colony Network: Developing and Learning about a Smart Contract Ecosystem

The whitepaper is a tedious read for a very good reason: It is meant to describe in detail the blueprint for a fully-realized Colony Network.

This quarter (and next), we will be the writing Colony Network smart contracts for:

  • Tasking system (mostly complete)
  • Funding + bounties (mostly complete)
  • Reputation + skills
  • Revenue + rewards
  • Reputation mining
  • Network transaction fee

As we work to implement this functionality we are looking to expand our dogfooding efforts and work with outside contributors.

If you are skilled with solidity, have read the whitepaper, and want to contribute to the development of the Colony Network, get in touch with Elena to learn more.

Beta II: Developing and Learning about the Market

Our first beta was used by 40 teams comprising 175 collaborators, to whom we are eternally indebted for helping us improve our product.

We made some major usability improvements as a result and are now a couple weeks away from deploying an updated task lifecycle workflow which’ll make it easier to incentivize, reward, and track the contributions of your Colony.

Once that’s deployed, we’ll be launching a second round of beta testing. Our goal is to have beta-II users complete 500 transactions by the end of Q4.

The beta helps us learn more about the market and our fit within it. We have a grand vision for the future of work, but we also foresee more iterative steps for startups and enterprises to begin making work more open.

As always, if you’re interested in utilizing Colony, have a use case you think it’ll be good for, and are willing to give us brutally honest and tediously verbose feedback on your experience, reach out to Collin for information about Beta II access.

A True DApp: Developing and Learning about Decentralized Technologies

The Colony beta, as it exists now, is a hybrid app that runs on a private chain and incorporates quite a bit of client-server functionality and other “trusty” features — which have been just fine for our testing purposes!

Nevertheless, the Colony dApp as it exists now can’t be considered a pure dApp, and it isn’t congruent with what we’d like Colony to eventually become: an open, decentralized, trustless network of work.

While we want to aim for a fully decentralized product, the technologies that the dApp would need to be built upon are still immature.

Keeping the dApp entirely based on the decentralized protocol stack (Swarm/IPFS, Whisper, Ethereum) would require substantial trade-offs between decentralization and user experience — and we have very high standards for user experience.

For example, events that occur on-chain such as setting a task bounty need to wait ~15 seconds for the transaction to be mined. When was the last time you felt okay with waiting 15 seconds to add an item on your to-do list — and paying ~$0.05 in the process? That’s pretty poor UX, but these sorts of things are unavoidable in Ethereum dApps today.

There are also some more fundamental issues that the Colony dApp needs to wrestle with. Right now the server dApp relies on the MongoDB for many key features. Migrating database functionality to something decentralized is not a trivial task.

So what happens next? Do we continue to run with our client-server architecture and gradually migrate toward decentralization piece by piece? Do we just wait around for scaling and UX solutions to appear in the ether? Do we solve those UX problems ourselves? Is there something we can do right now to move in the right direction?

We have decided that the best course of action will be to create a new environment for a server-less dApp, and start fresh with decentralization as the primary consideration. This will lead to a product which has limited functionality in the beginning, but which can benefit from new scaling efforts arising in the Ethereum community.

While some work will need to be thrown out, we feel that this is the best approach toward how we envision the final product to be. So starting in Q4, we’re going to move forward without the server, and, using the lessons of the Beta, build a new version of the Colony dApp which is even dAppy-er.

--

--