The 100:10:1 method: my approach to open source | Hacker News Reader

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

blog.fogus.me

256 pointsdgellow58 comments

> 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 contract with those who chose to use it for their own purposes.

Not to disparage the 100:10:1 method, but I do disapprove of this implication. I don't want people to refrain from putting things out there, just because they don't want to feel obligated to support them.

I have a public blog, where I try to maintain quality, and a semi-private blog where I try to allow myself to post stuff I'm not sure about, stuff that's not interesting to anyone other than me, stuff I don't necessarily want associated with my public persona, and so on. I know others do similar things.[1]

I think there's no particular mechanism to do that with open source, but it might be valuable. Perhaps I could have two github accounts, one where I'll put anything I feel like, and one where I put stuff I'm proud of and want to remain proud of. If something's on my "real" github, I'm saying that if you ask for support I'll try to help you, if you report a bug I'll try to fix it. If it's on, let's call it my shithub, there's no social contract. Take a look if you want, and feel free to report bugs, but I might just say "yeah, that's a bug". Or even just "not interested in that project any more, I'm not going to bother confirming this".

Then, if you want to follow this method and also want to make most of your code public, you can write down the 100, put the ten on your shithub, and publish one to your github.

[1] E.g. http://slatestarcodex.com/ versus http://slatestarscratchpad.tumblr.com/

Aside: given that my github name is chickenprop, the obvious name for my shithub would be chickenshit. Sadly, it was registered a couple of weeks ago.

If you're reading this, chickenshit, I hope you make good use of that name.

chickenshittier, chickenshits, chickenshitz, chickenop ? granted, chickenshit is pretty good github name

> I do disapprove of this implication. I don't want people to refrain from putting things out there, just because they don't want to feel obligated to support them.

I agree, anything I put out comes with one expectation on my part, I may be contacted regarding it. I do not feel any obligation to support it, I have no relationship with someone randomly contacting me over something.

Though, I put anything I want to be kept private is on bitbucket.

You may disapprove, but the belief that "you should only release what you're willing to maintain" is still there, and broadly held by leaders and shakers in our community.

http://blog.codinghorror.com/responsible-open-source-code-pa...

"As Markdown's "parent", John has a few key responsibilities in shepherding his baby to maturity."

https://plus.google.com/+TomDale/posts/CkmmbjmvebM

"And if you release, don't release more than you can realistically maintain."

https://opensource.com/business/11/7/responsibility-open-sou...

"open source project leaders [...] have an on-going responsibility to make it easier for community members to contribute"

The Markdown story is out of context: the issue was not John's alleged lack of involvement in the project per se, but the fact that he disapproved of other people doing so under the same name. Im not sure if it ever came to a trademark threat, but he definitely wasnt happy.

That is not what was being discussed, here.

Those others felt compelled to contribute because John refused to specify MD with anything other than a incomplete blog post and a buggy perl implementation. If this isn't an example of community involvement exceeding maintainer willingness to advance the project, I don't know what is.

This is not about community involvement, but about the maintainer's responsibility to stay active:

"you should only release what you're willing to maintain"

The Markdown story was not about that. Nobody demanded John's involvement; all people wanted was for him to let the project go. That's a far cry from "willing to maintain."

> all people wanted was for him to let the project go

Why should he have to do even that? It's his project to do with what he pleases. Work on it, horde it, release it under the AGPL... it's his, nobody else's. Of course, that's not their impression. Their impression, and the general expectation, is that if someone open sources code, they do so expressly for the good of the community of developers.

You see this quite a bit in GPL discussions as well.

I'm not sure I disagree with those specific examples as much as it may seem.

I do think that if you're not shithubbing, you have a level of responsibility which perhaps[1] Gruber and TJ (the maintainer in the second link) weren't taking. And it's not clear to me how much you can claim to be shithubbing if you have lots of users and are discussing the project direction and taking pull requests. (It looks like TJ has since handed over maintenance of n to someone else, which I'd say was the right decision.) The third link also seems to be talking mostly about projects which can't be described as shithubbing.

The main thing I want to get at, is that you should be able to put something online without having to take responsibility for it. (Perhaps we need to distinguish "online" from "released".) That doesn't mean you never have any responsibility.

[1] To be clear: I don't know much about these two incidents, but the actual details aren't particularly important right now. I'm discussing them to bounce intuitions off them, not to pass judgment on anyone.

You can start on github just by being clear what sort of repo you have in the readme. There's all kinds of projects on there, from "I accidentally the fork button" to production grade stuff, and it's often hard to guess which the author thinks they have.

Yeah, I really think this is all that's needed.

For instance, it's enormously helpful, in the aggregate, that people have repos that are simply "example of an application that uses Foo with a Bar adapter."

This is a really important hint. Put a note in that describes what people can expect from you and what not. Maybe there even should be some "standard" for this info, and a place to put it (either in the repo, or in the description), so you could easily find it.

Also, don't forget to update those notes if things change.

Github could use the 1-alpha, 5-production system.

At least you'd get a hint at the intention behind the release.

I really wish there was tagging and categorization - I have so many little repos, and now recruiters look at my GitHub as part of my resume. Is hitting the Fork button going to have impacts on my future employment?

I think this is a good idea.

I will add as a side note, if you can't maintain something anymore, put a big heading on the README.md saying so. If it's popular, point people to a maintained fork.

(Nothing I write is extremely popular but I'm going to go through and "deprecate" a few things of mine tonight)

I think one way to signal that something isn't likely to be maintained, is in the licensing choice. Public Domain isn't a very good licence because of it's questionalble legal status, but in my mind, somehow, CC0 is more of a "do whatever you want, just don't blame me" than eg: a simple BSD/MIT license.

But I think perhaps the core isn't just the license, but also the readme, and guidelines on naming/"trademark": eg: when it comes to markdown, the issue (as mentioned in a sibling comment) was more one of "I don't think what you want do do deserves to be called 'markdown' -- that named was coined for my vision of 'rich plain text'".

I'm generally in favour of strong copyleft licences, because of the need to maintain user (as opposed to, in addition to developer) freedom. But when it comes to stuff that's basically just some ideas that maybe someone else might want to run with -- I think it's important to give them away as unrestricted as possible. Technically trivial snippets of code aren't under copyright -- but with how hostile the "intellectual property" climate is -- I think it's important to be clear when sharing something unfinished that if someone else builds on it, one will not retain any ownership of/claim on the result (beyond what copyright law forces one to keep, hence CC0 etc).

If it's on, let's call it my shithub, there's no social contract.

Have a just witnessed the moment of inception for a fantastic new word?

"Team, we've got to stop all this shithubbing and really start properly testing and documenting our code."

Anything that I think "may" be useful to someone I put up on github. Sometimes to my surprise people use it. I remember putting something up (not even one star/issue or anything ever), then 1 year later getting a random email saying "this is great, thanks." Yeah, no problem, anytime.

I went the opposite direction (kinda) from the author. I realized that people assuming I would fix what I put up didn't matter to me. Sometimes I would make fixes, or check issues, sometimes I wouldn't. Some people got mad, some understood, some were drive by so they never checked back in anyway. Whatever, it's up there, if it really bothers them enough, they can fix it, or use it. It's up to them, not me.

However, I'm still a little like the author. I have a bunch of projects that are "good enough" for my use, but definitely not for someone else (for example, I wrote a password safe[1] cli program because I needed something that would work on FreeBSD. It only handles the features I use and may croak on a file that uses all field types). I keep these off my github.

[1] https://pwsafe.org/

I find it somewhat mindbending that he advises working on a MVP for 10 projects simultaneously when it's all I can do to work on 1 plus, you know, my real job that pays the bills.

More power to anyone who has that sort of energy!

Maybe it's less about having lots of energy, and more about expending it lazily and efficiently.

For many ideas, an MVP can be a five-line CGI script in bash. Or even a static HTML page. Minimal means minimal.

The MVP is the most trivial thing you can do that will still give you useful information and guide future development. The purpose is exactly to be able to try things without investing significant energy.

What you're describing, to me, sounds like a mockup or prototype. I think of an MVP as something that could be put in the hands of an end-user.

You can put a static webpage with an email form in the hands of an end-user.

https://en.wikipedia.org/wiki/Minimum_viable_product

http://venturehacks.com/articles/minimum-viable-product

> We thought we were taking the minimum viable product approach because we had only spent two weeks on it. Right? Where we had made a very early prototype and put it out there.

> But, if you think about it, going back to the definition of the minimum viable product, which is the minimum features that are required to learn what customers want, we had spent way too much time on it.

> What we should have done, and what we did for a lot of features thereafter, is started with a landing page that promised people that product. Then we should have taken out the AdWords we were planning to take out, drive traffic to that landing page, and offer people to buy the experience that we are talking about.

> What we would have found out if we were doing that experiment is 0% of people would have clicked through, which means it doesn’t matter what is on the second page.

I agree with you. My interpretation of MVP is weighted by my interpretation of the words Product, and Minimal. A product should be something which really solves a real world problem, and is built with the appropriate level of quality. Good enough is not good enough, the bar should be very high. Minimal in this context therefore applies only to the scope if the problem(s) being solved, not to the effort put into execution or the level of quality.

Put another way, I won't call something a product unless it's something I'm proud of and something that I believe solves a problem in a way which approaches the best way (at least in my opinion at the time, there are obviously always improvements to make based on feedback). If it's minimal, this just means the scope of the problem it solves is very small, so that not too much effort has to be expended building it, even though what it does do it does at a high level of quality.

Anything which falls outside this is to me not an MVP, because it's not a product, it's a prototype of a product or a way of testing an idea the product may eventually be built to implement 'properly'. It's rarely something you're proud of, or would be comfortable charging for. When you'd be comfortable charging for it, that's probably the point where it becomes a product.

I think there might be two valuable ideas, that are somewhat at odds, lets call your model the MVP - Minimal Viable Product, and the other one MVC - Minimal Viable Commodity.

The Minimal Viable Commodity is the minimal thing that you could successfully market. It can often be an idea+web page with an email form. It is the sales/business persons idea of an MVP: The technical aspects are entirely uninteresting - it's the business case that's being tested/evaluated.

Consider the case of a product idea for translating in some special domain, eg: contents declarations for food stuffs. The MVC is a web page with a form to submit the text. What happens after that (spend a week gathering samples, manually translating, whatever) isn't part of the MVC. It's market research. Maybe you manually translate the things and deliver results back.

The MVP for machine translation of the same idea is considerably more involved. Even just connecting some machine learning legos and training on a few million samples is much more (technical) work, than setting up a static web page.

I think both ideas are good -- but it can get confusing when both concepts are termed MVP.

> The technical aspects are entirely uninteresting - it's the business case that's being tested/evaluated.

I find a lot of these tests provide junk data though because it is obvious the site has no product and is just fishing for information. People have wiser up a fair bit and will just hit the back button.

I think you're not supposed to take away the absolute numbers, but only the ratios: so 10 MVPs really means only make MVPs for 1/10 of all your ideas. So one MVP at a time follows the guidelines if you have around 10 ideas!

I agree that any OSS developer should recognize their toy projects will likely not go anywhere and keep a few projects in mind to work on. Keeps things in perspective, keeps one interested, and so on like author said. Doing 10 projects in parallel makes less sense to me. One can accomplish the same thing sequentially while focusing on only a few projects. Just bounce back and forth.

If I went with a rule, I think Google's 80/15/5 rule is worth further exploration. Many of the best projects start with a clear need to solve a problem. Picking one of them and making it happen should be 80% as others will appreciate the problem being solved. Especially true if author understands that domain. A significant step out of the domain or re-application of an effective concept to new domain might be a 15%. A 5% project might be a wild idea with potential but high risk and/or way outside author's domain expertise. The main energy will go into 1-2 80% projects while the 15% and 5% projects are a mental break from that.

This model seems more productive while still letting a person screw around on side projects that might be fun, good learning experiences, or time-wasters with a limit on the waste.

This resonates with author's famous blog post about reading [1]

In that blog post he recommends reading several books simultaneously and abandoning boring books with no regret.

[1] http://blog.fogus.me/2012/02/22/reading/

Simultaneous reading is definitely great.

At any given time, I have 2 books, one fictional and one technical, open (made some progress in reading it, maybe not literally open ;) ). I probably could handle an extra technical one.

If I was reading only one book, some evenings I'd be like 'meh, don't feel like reading it tonight'. But when I'm reading simultaneously, I have no excuse to read a bit every single evening, which evolves into a habit and it is definitely a nice habit to have.

I'm really trying to finish one book (fiction), but I tend to fall asleep before finishing a chapter, :p. Mind you, I read billions of words a day (may be a slight exaggeration), and closing tabs when they're boring is common enough. Can't really do that with code though, I need to understand / write / finish those.

TL;DR as a software developer, I find my primary occupation is reading, and not just code. Secondary is typing. I should get a better keyboard.

I've written probably a hundred open source projects in my short professional career. But only two of them do I actually use every single day: a simple OS X window manager [1], and a hybrid command-line/native-GUI fuzzy string matcher [2] (you'd be surprised how many ways/places this can be used). The rest of them didn't serve well as practice like I'd hoped, they were mostly just a waste of time I could have spent better elsewhere.

So lately I have new criteria for how and when to write open source projects: (1) when I realize that I have need to automate something, (2) and it won't take more than a weekend to get a basic functioning version up and running. Anything else, and I nope on out of there. I've got too little time and too many things to do already, I'm not about to waste it creating more unnecessary software. The world has enough of that already.

EDIT: adding links as requested

[1]: https://github.com/sdegutis/AppGrid (note: I started to rewrite this in Swift locally, because Accessibility API sucks without generics, and the Objective-C version is a bit buggy)

[2]: https://github.com/sdegutis/choose (note: I started to rewrite this in Swift, but the Objective-C version gets the job done just fine)

If you want people to be less surprised, or maybe even help them understand what you're talking about, links to those projects would have been handy. :)

Thanks for the idea.

There's a tangential problem I've been thinking about a lot recently: the long tail of open source projects on GitHub.

There are 20M+ repos on there. Which leads to a serious discoverability + signal/noise problem around 'true' open source projects. As someone who wants to put up an open source project for collaboration (with willingness to maintain), it's hard to get the right eyes on it. Too often, it seems like no one cares. Conversely, as someone who wants to contribute to open source projects, it's a little hard to find small early ones where I feel like I can make a meaningful contribution (yes, the big ones maintained by well known companies are easy to find, but I much rather work on something put up by an individual programmer).

How do you cut through the noise on GitHub to find projects you actually want to work with (and want you too)?

Sounds like a good idea for a better unofficial open source search engine. I would be interested in contributing. It could do intelligent search of Github, Bitbucket etc for projects which might be interesting (programming languages, objectives etc).

I was thinking of something maybe even simpler - a place for people to post projects they're actually interested in maintaining as open source projects. A subreddit could be the mvp.

Or go the other way, and train a searching algorithm based on a data set of actively maintained open source projects on Github, with things like commit history/contributors/etc as features.

Using a subreddit, you basically have a marketing problem and no way to seed the marketplace. One would need to do both. You are trying to restart http://freecode.com/

How about a README badge?

You could crawl github and bitbucket, make a public dataset available. Others could slice and dice.

I think this is a great idea.

Having access to the data set itself could unlock a lot of new, creative ideas and applications beyond the expected ones. That's one great thing I've learned from the open source community.

It could not only be used for search, but some data analysis, and what not. I think it would be fairly beneficial for github to do it, actually. Easy to work with, up to date dataset -> interesting projects -> github brand value++.

If I would reply to all the emails, pull requests, issues, people send me about my OSS code, it could be impossible for me to write a single line of code every day. Eventually I believe the solution is to take what you get from the community, and to provide replies and feedbacks, by spending a fixed amount of time, and trying to sharpen the sensibility to focus on the most promising interactions, pull requests or whatever. It will sound gross to many that expect a reply that does not arrive, but it's better than to stop doing what you love which is writing OSS.

I hope one day I write something that's half as popular as your code!

I think your blog posts do a good job of answering lots of questions for a lot of people at once - isn't this a more efficient way than answering emails one-on-one?

IMO if you've got enough projects that get that kind of attention, it's time to do as any good manager should do, and delegate. Allow others to sift out pull requests and issues, pre-filter emails about the project, so you can do higher-level things (or just write code because you seem to prefer that over dealing with issues)

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:

http://www.jamesaltucher.com/2014/05/the-ultimate-guide-for-...

http://www.jamesaltucher.com/2012/04/how-to-have-great-ideas...

http://www.jamesaltucher.com/2015/07/the-magic-of-idea-math/

I really like this idea. I don't actually have the problem that people are bashing my door down to have me support old code, but my github account has accumulated a huge amount of cruft. Much of it, while quite beneficial for me for playing with something, is completely useless for others. I tend to use Github as a backup system... I'd really like my Github account to be useful for others and not swimming with half finished ideas. I think it's time to clean house...

I have maybe five ideas for decent projects, and I work on two. Why should I bother starting with a huge list and whittling it down?

Maybe you shouldn't. The post is a description of one person's method and should not be taken as prescriptive.

Because you don't know beforehand what projects will keep your attention and what will make you bored.

Or maybe you know. If so, you are better not following his advice.

Strangely this sounds like it might work. I've been thinking about a lot of different projects, and end up doing absolutely nothing. There's also a lot of small stuff that, if I did an MVP, would actually be close enough to ship and be useful. Though I'm not sure about the projects I'm most interested in; they are fairly big and getting to MVP could be many months (so doing even 3 would take a couple of years).

I'm gonna try writing these ideas down. Thanks for the idea!

I personally couldn't succeed with this approach. It's only suitable for polygamists. I'm more of a one codebase kind of guy. I know how to treat my codebase right.

Just publish and put some clear indicator right there in the README of the status/purpose/scope of the thing. I have bunch of them marked 'experimental', more rarely something gets all the way to 'minimally useful' or 'used in production'. Arbitrary example: https://github.com/jonnor/agree

It is not for me to decide whether something will be useful for someone else or not, that is up to them. Just give people enough facts that they can make an informed decision.

I'm doing something similar where I publish all main and side-projects (good and bad) and judge interest from retweets, stars and forks https://github.com/heri

However working on 10 projects simultaneously is not feasible imho. 3 or 4 is more realistic, more maintainable and worthwile in the long-term.

I am this way as well. I eventually go back through my Github and delete the projects I am not willing to continue but I put 90% what I do on Github as MIT. Maybe I should add comments to the readme like use at your own risk or some other warning.

How do you gain any popularity at all? Most of my stuff is little hacks, but they have zero visibility. I'm sure something I wrote is useful to someone, but how do I know?

Actually I'm not planning to be popular. I'm doing it for myself and to develop interesting projects. Of course, it would be cool if it becomes popular.

In terms of popularity, if I see something is interesting, I make sure to add it to Twitter, facebook, send to friends, add to reddit, add to awesome lists and encourage participation (clear license, clear contribute.md) etc.

I find it a bit strange to write down 100 ideas of what I could develop. I think it would be much better to just develop some missing software or make a better version of something existing. But just collecting ideas without a real, deep interest in it sounds a lot like the beginning of abandoned projects.

ain't nobody got time fo dat

Reply on news.ycombinator.com