I want to fork everything
My favorite speaker at YCombinator was Kevin Hale, the founder of Wufoo. He taught me that everybody in a company should be doing personalized support so that you can identify (and fix) the most painful user experiences. He called this “support driven design” and emphasized how important it was to his company’s success. He also showed off the internal support tools he built. I thought they were amazing: no canned replies, customer information directly inside Gmail and common actions at your fingertips.
That was almost two years ago.Since then, I’ve used dozens of tools to handle support for Minefold, a company I founded with Dave Newman to make simple game servers. As our service grew to nearly 80,000 players, we discarded tool after tool, frustrated with difficult interfaces, terrible email integration and limited APIs. Each tool ignored crucial parts of Kevin’s vision of support-driven design. I didn’t want to build a competing product, I just wanted to improve the software I already used.
This isn’t an uncommon feeling for a software developer. After using and contributing to open-source libraries, I have high expectations: I find myself itching to fork the projects I use every day. Imagine all the little tweaks I could make to help software suck less. Then how amazing would it be if everybody could help out too! Dave told me that he would have loved to help Amazon AWS add CORS support to S3. Matt (a friend from YC) described how he would fork Mixpanel’s funnels.
My need to fork everything became infectious.
I started dreaming about a world where I had the opportunity to change every product I touched. In this world there would be three core principles:
- Everyone can contribute.
- Everyone can make good contributions.
- Everyone is incentivized to contribute.
Everyone can contribute
For anybody to be able to contribute, a product can’t ask for a resumé or need you to sign an employment contract. It can’t matter whether you went to Stanford or who your father plays golf with. Open source code is the epitome of availability: work can be accepted based on it’s impact, not on who wrote it. Contributing shouldn’t be any different from working on an open-source library: just fork, commit and merge.
This flies in the face of traditional business practices—conventional wisdom preaches that a company should clutch its intellectual property close to its heart. Ask yourself this: do customers pay for source code or do they pay for the whole service? Facebook’s source code was leaked in 2007 yet that incident barely marks as a blip in its history. There are already large commercial products being built with public code. WordPress, RedHat & MongoDB come to mind.
Everyone can make good contributions
Quality is subjective, but if the perfect person wanted to contribute to a project she should be able to make the perfect contribution. Everybody needs to be trusted with as much information as possible to do so.
For contributors to be informed, all team communication have to be stored and searchable. Anybody should be able to see a current financial ledger. Product design should be clear and decisions shouldn’t surprise anyone. When people are empowered to make insightful contributions to an open product, everyone becomes partners, not workers.
Everyone is incentivized to contribute
I wish benevolence could put food on the table. The fact-of-the-matter is that money enables and motivates people to work. However, fair compensation is an age-old problem. Marketplace dynamics could be used to effectively value work. In fact this is how co-ops have operated for centuries. I think the best bet for this is to rely on the other contributors: everyone votes on each other’s work and the profits are split based on where those votes flow.
An outlandish experiment
Dave & I teamed up with Matt. With those principles in mind, we created a platform that lets anybody build open software services and apps. We’re calling it Assembly. As of today, you can come to Assembly, submit an idea and start working on it with other people in the community.
We’re starting off by green-lighting one new app every month. We (Assembly) don’t control which app gets built: that’s up to the community. There’s already a bunch of fantastic ideas for you to vote for and you can even submit your own.
We even went back to Kevin Hale and asked him to submit his idea for what’s going to be the best support tool ever: Support Foo.
The idea with the most signups and pre-orders by the end of November will become the first “Assembly App”. Once an idea is greenlit, everybody will be able to use the tools we’ve built, contribute and earn a stake in it’s profits. Again, Assembly doesn’t control what gets built, that’s up to us all. Every app will be available on GitHub for you to fork.
This is going to be wild. We’ll learn a lot. Things will change, but we’ll listen to feedback and will keep the process very open.
It’s like we just formed a band with 7 billion people… and everybody has a chance to play. It could sound like garbled noise, but I’m quietly confident that Assembly will harmonize into something beautiful and totally unique. The best bit: everybody has stage access.
