Hacker News Reader

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

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."

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