Ask HN: If you open source some code, are you responsible for maintaining it?

You have no formal responsibility. No obligation. If someone complains to you about fixing bugs, they are welcome to fix them themselves. That's what open source is for. Anyone can fix issues without having to wait for the creator.

Open sourcing some code means making it available under a license. That's it. No further promises are made by you.

So you're free to add a notice that you won't maintain it and that people are free to fork it and maintain it under another name.

Or you could maintain it if you think it's good for your career and/or you simply enjoy doing it.

I would just put that clearly and prominently in the readme.

"Released open source in case this code is useful to you, but there will be no support, no further releases, no bugfixes, and no response to issues. If you find this code useful and would like to modify it, please feel free to fork it."

[I forget if Github lets you turn off 'Issues' entirely, but if it does, do so.]

This way people know what they're getting into when they use the code. You have no _obligation_ to do anything, and it's better to share the code as examples for others trying to do the same thing than to keep it private because you don't want to support it.

But people may assume the code is supported, and regardless of what they assume, they can make a better decision on whether to use it or not (and use it how), if they know it's unsupported, and it is the right thing to do to let them know up front. If I found useful code, but knew it was 'abandonware', I might or might not choose to use it anyway, but that knowledge would effect my decision.

If you have code that you released without making that clear, and _have_ been supporting half-heartedly anyway (setting some expectations), well, contrary to what I predict will be the HN consensus, I think you do have some responsibility to your users. But you still aren't trapped forever in indentured servitude. Wind it down gracefully, maybe find someone else to take it over (have you accepted a pull request from anyone ever? if so, that person is a good candidate :) ), maybe keep responding to issues for a little while after you make the announcement that it will soon be abandonware. Or if you're completely burned out on it and just don't have time, then stop cold turkey if you have to, but post in the README what you're doing. (Don't delete the repo, that would be very rude to current users).

If you don't plan to maintain your code what you did is not "open sourcing": it is merely a source code "release". "Open source" means "welcome", if you don't mean it, don't say it.

If you are tired of maintaining your old project just put a tar.gz of the last stable release up on your own site and let it die or be used. Or, at the very least, disable GitHub's issue tracker.

You can turn off issues and wikis on github repositories and force people to file pull requests to fix issues if you'd like.

You can hand it off to other people to maintain if it's something you don't want to do.

Other people can fork it if they are unsatisfied with what you're doing.

Please don't allow it to cause you any stress! Many quiet users are just grateful that devs release stuff.

No, you are not. But it boils down to what you advertise.

Perhaps declare in readme that project is unmantained and disable Issues on such project (no emails). Also declare how much hours/month you are willing to put into maintenance. And finally use separate email for OS activity, public email generates a lot of spam (viagra etc)

I actually build my living around one such abandoned project. Original idea was great, but it needed some TLC to make it usable.

I've never seen a programmer be held responsible for maintaining code.

I've seen them paid to do it. I've seen them do it because they want to. I've never (ever) seen any of them do it because someone else told them they had to.

>At my company, we depend on a lot of open-source technologies. We expect that someone will keep rails up to date, fix security vulnerabilities etc.

That's a pretty terrible, and indeed entitled, attitude to hold I must say.

>I haven't used it in a while (I don't make many presentations) but I still keep getting and responding to bug reports. What's my responsibility here? I am happy to open source my code, but I don't want the extra work of maintaining something I rarely use.

Then don't. Invite others to collaborate and submit patches themselves.

Please don't turn off issues so people wanting to try your code are aware of bugs. Just say it's unsupported.

Well, for that particular repository the README still encourages pull requests, so while that's still there I'd probably expect you to maintain the project. If you turned issues off and put in the README that you had stopped maintaining the project I'd think that would be enough.

Really, I think once you open source something you should be prepared to maintain it for perhaps somewhere between 3-6 months at a minimum. If it's popular, I'd expect you to maintain it while it's still relatively popular and people are regularly sending pull requests and reporting issues.

If the repo is still popular, I'd think that you'd probably have to hand it over to someone else if you're not going to look after it. If it's less popular, a simple note in the README should be fine.

You have no responsibility. If people want bugs fixed, they can fork it and do it themselves...

There's one thing you're responsible for that I don't see mentioned here : potentially wasting a name from the global namespace.

There are too many abandoned projects that took the easy to remember / cool names. At a smaller scale and as an exemple, nowadays if you want to implement a protocol and publish it on NPM there is 99% chances the name is taken and the implementation is poor. Too many people thrown away quick hacks only to leave them die. People willing to work and invest time in proper implementations may end up discouraged and give up trying to publish or even coding them.

Names are the scarcest resource of all. My point of view is that when you take a name you take with it the responsibility of not wasting the cognitive paths associated with it. This is not a small responsibility at all, in my humble opinion.

It probably doesn't apply to the example you gave. Just took the opportunity to voice my concern.

You don't have responsibility to maintain, but the copyright holders of the code are potentially open to liability.

When you open source something, you have to make sure it has a clear license which includes legal disclaimers of warranty and liability. For instance take a look at the disclaimers in the GPL and BSD licenses.

As far as maintenance goes, you have no contractual obligation to anyone to fix anything for them, if you aren't being paid.

You have a responsibility to your own reputation. When you publish some source, are you trying to help other developers, or are you just making a public online backup? If the former, then do so; if the latter, then just be clear what you're doing. Put "I'm just dumping this on the 'net" in the README, and people can take it for what it's worth (nothing, probably).

TL;DR You have no responsibility to keep coding, but you do have a responsibility to transition the project to a new maintainer if someone sufficiently competent volunteers.

As many others have already mentioned, it is very useful to clarify in the README what the status of the project is.

Something I would like to add is that if someone else comes along who offers to take over maintenance, that is a useful thing which you should probably accept, and then you should update your README to point to the new official maintainer. You can also explicitly mention in the README that the project is looking for a new maintainer, which to me always seems a bit friendlier than just stating you've abandoned the project.

Even if you don't officially pick a new maintainer for your project, if a couple of forks spring up on github consider linking to them from your README if they still seem active after a couple of months.

Thanks for the suggestions HN! I added a note to the top of the README and will try to wrap up existing issues. I won't delete the repo from github.

Begin rant:

I'm going to be the one who says it. I am frankly tired of the sense of developer entitlement. We get so much amazing and great work from people, yet it never seems to be enough for some. They bitch about semantic details, style choices, lack of support, and yet refuse to pay for quality services. Instead, they cockily spout "...why would I pay for that when I can just code it myself?"

I think this mentality is what separates these sort of developers from entrepreneurs. Entrepreneurs will pay for services happily that make their lives and business easier and improved, while entitled developers will just "hate" on the technical merits or "poo poo" the language, framework, or design decisions.

On to the OPs question, no you don't have a responsibility to maintain anything you give away to the community.

I would say that if anyone is obligated to maintain the code is is the people who are using it and benefiting from your initial work. (Not using "obligated" in the literal sense, more to mean "ought to").

Mentioning the state of the project in the README is useful. Additionally, you could selectively reach out to some of your users and offer them GitHub's "collaborator" status. This enables them to accept pull requests, push to master, etc.. That way your code can be maintained by people with a current interest in it.

I think it depends on how you go about it. If you just make it available and from the outset make it known that's what you're doing, then I think it's fair game. If, on the other hand, you spent time convincing people to use it and then just abandon it, I think that's kind of a jerk move. I see this happen a lot with freelancers using open source as a means to drum up clients.