> 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.
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.
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.
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.
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.
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)
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 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.
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).
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/