How Side Projects Take Over The World
Every once in awhile, I’ll get a question from a Panda about whether we’d be interested in this or that product or open source idea. The answer is generally yes. I’m not a big believer in asking (or demanding) that Pandas give us personal time for free. In fact, I don’t even think it’s healthy to live and breathe work.
At the same time, side projects can be incredible for a company. You can get a lot of mileage out of a good idea.
It doesn’t even have to be a big idea. For instance, I’m very excited about Fairmont right now. It’s our new family of JavaScript/CoffeeScript libraries for functional reactive programming. It’s a big idea. But it didn’t start that way.
Fairmont started out life as a place to put utility functions that didn’t have a home elsewhere. It was basically a junk drawer, which grew into a functional programming library along the way. And then the reactive stuff came out of trying to come up with a more hackable asset pipeline.
There was no grand vision. The closest thing to a grand vision was an idea for an experimental blogging engine, not a set of FRP modules. To make the blogging engine happen, we needed a better asset pipeline. Like Gulp, this asset pipeline regarded assets as streams, so I added better functional programming support to Fairmont. But then Fairmont took on a life of its own. Its approach to FRP opens up new possibilities for JavaScript. So it’s OK to start simple.
Recognizing Opportunity When It Knocks
But say you’re not satisfied just building something and seeing what happens. Say you want your side project to take over the world, or some slice of it, like Rails or GitHub did. There are a few things to look for when thinking about avenues for exploration: inflection points, synthesis, and impact.
Inflection points are dramatic shifts or changes. Synthesis, in this context, refers to taking two or more things that are amazing and packaging them up together. And impact here just refers to solutions that have a big audience or are extraordinarily meaningful for a small audience. If you combine these three things, you’re usually onto something. Let’s take a few examples.
Case Study: Rails
The inflection point for Rails was likely the growth in the demand for simple Web apps. It was a brilliant bit of synthesis, taking best practices for building Web apps and packaging them as Ruby libraries. Ruby, of course, was itself the product of a decade-long language research effort, and had only recently become viable for Web development. (For example, when Rails was first released, database drivers for Ruby were still a bit sketchy.) DHH didn’t establish those best practices (they were based on a whole industry’s ten years’ of experience building Web apps) nor did he have anything to do with the development of the Ruby language. But he packaged them together and made them available to a rapidly growing audience of Web developers.
How Small Teams Can Make A Big Difference…
Node is another similar example. Ryan Dahl synthesized an embeddable JavaScript compiler (V8) with a cross-platform library for evented I/O (libev). Heroku synthesized Rails and AWS. Docker basically just wrapped Linux container technology in a more developer-friendly package. YouTube, Facebook, Twitter, GitHub… most if not all of these applications have these three characteristics:
- None of them would have been practical even a few years earlier. That’s the opportunity of an inflection point.
- None of them, by themselves, at least not initially, were based on massive engineering efforts. That’s the importance of synthesis.
- None of them required aggressive marketing or “growth hacking” to break away from the pack. That’s why impact matters.
So go explore. Start simple. And, along the way, think about how inflection points might affect the problem you’re trying to solve. Think about how you might be able to synthesize emerging technologies to improve your solution. Think about the potential impact it might have.