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.
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.
 E.g. http://slatestarcodex.com/ versus http://slatestarscratchpad.tumblr.com/
"As Markdown's "parent", John has a few key responsibilities in shepherding his baby to maturity."
"And if you release, don't release more than you can realistically maintain."
"open source project leaders [...] have an on-going responsibility to make it easier for community members to contribute"
That is not what was being discussed, here.
"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."
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 do think that if you're not shithubbing, you have a level of responsibility which perhaps 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.
 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.
Also, don't forget to update those notes if things change.
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."
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)
At least you'd get a hint at the intention behind the release.
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.
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."
If you're reading this, chickenshit, I hope you make good use of that name.
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).
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 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.
More power to anyone who has that sort of energy!
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.
> 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.
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.
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.
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.
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.
In that blog post he recommends reading several books simultaneously and abandoning boring books with no regret.
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.
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.
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
: 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)
: https://github.com/sdegutis/choose (note: I started to rewrite this in Swift, but the Objective-C version gets the job done just fine)
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)?
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++.
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.
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?
You can see some of his posts on it here:
Or maybe you know. If so, you are better not following his advice.
I'm gonna try writing these ideas down. Thanks for the idea!
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.
However working on 10 projects simultaneously is not feasible imho. 3 or 4 is more realistic, more maintainable and worthwile in the long-term.
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.