or learn more

The 100:10:1 method: my approach to open source

Nov 4, 2015

For many years I was whole hog into the open-source movement and at the time I rarely wrote a stitch of code in my free time that didn’t find itself in a public Sourceforge/GCode/Github repo.1 However, over time I came to learn that the burden that came with publicly offering code to the universe, to put it mildly, sucked. Aside from the fact that much of the code that was “released” was sub-par, the very act of putting code out into the world implied (whether intentionally, or not) a willingness to participate in a social contract2 with those who chose to use it for their own purposes. Granted I’m not necessarily against that social contract per se, instead my eventual change of heart around releasing code became such that I was more reserved in my approach. The approach that I now use for releasing code into the wild is governed by an approach called the “100:10:1 method,” a term coined by Nick Bentley.3

What even is the 100:10:1 method?

I won’t belabor the details of the method, you can read more about it from the perspective of a talented game designer, but I’ll try to frame it in the context of my approach to open source software development.

The 100:10:1 method has three parts, each described below.

Write down 100 wacky ideas

The first step was to find a notebook and a pen and just write down 100 ideas for interesting open source projects. These project ideas ranged across all manner of topics, depth, and quality. I thought of wild language ideas, new features in existing projects, system designs, protocols, missing documentation, interesting forks, golfing code, games, prototypes, implementations of paper ideas, second-systems, whatever.


Prior to incorporating the 100:10:1 method, I had always had a notebook filled with wacky ideas, but they tended to be hither and thither and never in one place. Laying 100 ideas out on a few pages let me really focus my attention on them all at once, allowing me to weigh them against each other for the purposes of the second step.

Make a MVP for 10 of those ideas

Having 100 ideas laid out in front of me let me really get a grasp on the ideas that I not only felt interested in pursuing at that time, but also those that I felt could benefit not only myself, but others as well.4 Of the original 100 I picked 10 projects that I was certain I wanted to dive into and explore. For lack of a better term I picked the 10 projects that I wanted to write a minimum viable “product” for all — concurrently.


Now you might be thinking that 10 concurrent projects is in itself a burden. This would not be an incorrect assessment. However, I realized that minimum viable implementations for most of the projects that I chose would probably never see the light of day and if they did it would be months to years before that time. You see, at one time I had viewed releasing open source software as a method for putting a potentially useful tool into the hands of others. Sadly, over time that view had degenerated into the idea that releasing code into the wild was in itself good — the method had supplanted the original goal. My view now is that it’s highly likely that the code that I’m working on in my spare time is only an exploration that may or may not bear fruit — and that’s OK.

A nice benefit of working on 10 concurrent projects is that when I feel that one has stagnated I can simply move on to another that motivates me more. As a person with a rich hobby, community, and family life outside of mere coding, it benefits me immensely to use the power of a bevy of choice to battle fleeting interest. Having 10 concurrent projects means that there’s always one that can grab my immediate interest. I’ve learned (the hard way) that when my full interest is directed on a task I’m much more efficient in my production. Eventually however, one of these projects will bear fruit5 and when that happens I’m ready for the final stage.

Fully develop one of those ideas into a legitimate software release

At some point during the 10-stage, one of the projects will inevitably turn into something valuable.6 When that happens I then take that one project and really work to turn it into a quality software artifact.7 This means to go all the way and ensure a robust system with solid examples, tests, documentation, stable API, blog posts and/or talks, and even a web-presence perhaps.


Up until this point the code for said project was for my own purposes and would likely need a lot of work to make it into something that I’d be proud to share with others. It depends on the complexity of the software of course, but it’s likely that the final stage takes the longest amount of time to realize. Likewise, it’s at this final stage that I’m most likely to scrap a project entirely. I’ve found (again, the hard way) that if I can’t bring myself to turn a codebase into something that I’m willing to write documentation, examples, and tests for then there’s zero chance that I’ll be willing to maintain it for the next X years.


I’ve used this method for some time now, and prior to that I followed something similar and have found good results so far. That is, both Zeder and Patagonia were developed using the 100:10:1 method, or some facsimile of it and I have a Clojure library named “Tathata” that’s in the final stages right now. Perhaps one of my 10 current projects9 will bear similar fruit, but if not that’s OK, I’ll just pick 10 more.


I’ve got plenty of time — a lifetime indeed.


Thanks to Carin Meier, Rich Hickey, Justin Gehtland, and Paul deGrandis for reading and providing feedback to a draft of this post.

  1. As it turns out, my other hobbies (game design, Sabremetrics, writing, etc.) followed a similar trend in the past, but like open source coding they too have fallen into the 100:10:1 ideal. 

  2. And unfortunately there seems to be a tendency to view open sourcing as a moral statement as well. 

  3. The name “100:10:1 method” comes from a post by Nick Bentley describing his game design approach. While my own views on open source coding had already become somewhat similar to Nick’s, it was his post that gave me a name and base structure to my ad hoc approach. Thank you Mr. Bentley, wherever you are! 

  4. Because if we’re not creating open sourced code to benefit others, what’s the point. 

  5. And sometimes a project will rot on the vine. In this case I have no qualms about trashing it and promoting another from the list of 100. Indeed, the list of 100 is a living list and things drop off and come on all the time. 

  6. Or not… what me worry? 

  7. When that one project surfaces, I still work on the other 9 concurrently, just at the more superficial, MVP-esque level. If the fancy strikes me I might even pick another from the list of 100 to elevate… there are no hard and fast rules about this method of course. 

  8. As you can see, I apply the 100:10:1 method to other creative hobbies as well. From coding to music to writing to game design, it works for any number of creative activities. 

10 Comments, Comment or Ping

  1. I’m right here! You’re welcome! (and I’m delighted)

  2. Bob

    when your in the 10 mvp stage you might look at building some marketing collateral and reach out to potential users to get feedback. working on something that already has users waiting could help with the motivation factor.

  3. Great article, thanks for sharing.

    This makes a ton of sense and could be applied to starting out on any new project. I’m curious if you have any insights into how this could be applied to maintenance of existing projects?

    My first instinct is to apply the 100:10:1 to all the bug reports, feature requests and random ideas that accumulate over time in an Open Source project. Any other insights would be much appreciated!

  4. Excellent post!

    This reminds me a lot of the idea strategies that James Altucher promotes and uses. They are mostly related to business ideas rather than OSS, but the concept remains similar.

    You can see some of his posts on it here:

  5. Reuben Thomas

    “And unfortunately there seems to be a tendency to view open sourcing as a moral statement as well.” ← What sort of statement, and why is this unfortunate?

    I agree that merely supplying code encourages the idea you’ll support it, but I think one has to learn to ignore that, and instead realise that for maybe 1 out of the other 9 MVPs that one does not develop into a fully-functional system, someone will find it just what they need to get started.

    Also, the flip-side of this approach is that it’s dangerously close to 100:10:0, where that 0 can be the result of commercial hoarding (I’m talkin’ ’bout source here), or simply thinking “it’s not good enough yet”. See for example , a multi-year publically-funded project by some of the best minds in computer science, including legends like Alan Kay, which produced some amazing demos, but (with a couple of honorable exceptions) utterly failed to release the MVP fruits of their work, even though there was an entire community clamoring to be let loose on it. The result? The same as before, we’ll go on reinventing the stuff less and less badly for the next few decades.

  6. Oh man, why haven’t I been applying this method to my writing?

  7. Andrew Jorgensen

    Awesome article!

    One followup question I have is when do you decide to repeat the cycle over again. Lets say you picked 10 things and non of them are panning out, what are the signs that this is true and when do you go back to the beginning? Or do you simply discard the ones you don’t think are going anywhere and then pick another n from the old 100 list you still have? Or am I making this process more rigid than it needs to be :)

  8. Hunan Rostomyan

    Thank you for the very useful post!

  9. Would like to know how many hours a day you work if you work in 10 projects concurrently?

  10. @Simon,

    I think you’re taking the word “concurrently” too literally.

Reply to “The 100:10:1 method: my approach to open source”