6 ms·

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

• alain94040 12y ago
  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.
  • Moto7451 12y ago
    Indeed. Additionally if you loose interest in the project you can also see if someone who contributes back would be interested in taking over the project as well.
  • zzzcpan 12y ago
    Exactly. Some people just don't get it. Personally I enjoy maintaining other people's abandoned projects. They free you from any obligation to keep up with new features, new bugfixes and so on. It feels more like a gift, than an abandonment.
• svisser 12y ago
  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.
• jrochkind1 12y ago
  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).
  • wowaname 12y ago
    Yeah, the Issues function of a repository can be disabled, most useful for if there is already a way to report issues with a system such as Bugspray.
    • jrochkind1 12y ago
      looks like pull requests can't be though?
• johncoltrane 12y ago
  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.
  • svisser 12y ago
    Open sourcing does not imply future maintenance. That's why everyone should evaluate the state of a project before starting to use it.
    • duskwuff 12y ago
      There is one good point made, though: if you don't plan on maintaining a project, you might as well disable issues and pull requests on Github. Leaving them on gives the (false) impression that you'll respond to them.
    • johncoltrane 12y ago
      Putting the site on a social site and setting up an issue tracker implies future maintenance. Making it clear in the README that no maintenance is guaranteed and disabling the issue tracker should be enough to send the message to would be users. If the OP doesn't do that he is actively implying future maintenance.
      • dalke 12y ago
        It does not imply future maintenance, any more than having an account on Facebook means that you'll reply to anyone else's comment, pokes, or app requests, or that you'll even log in again. Having an account on Twitter doesn't mean there's an obligation to respond to every tweet directed your way. In dating web sites there's no obligation to reply to every "hi, I'm interested in you" message. In fact, in no social site I know of has an obligation for future engagement. Why is code different? You also assume that "social" => "with the world." If I want to work on a project with friends in California and New Zealand, why not set it up as a public account on github? We're being social, just not social with you. Our obligations are towards each other, not some stranger on the internet.
• josegonzalez 12y ago
  You can turn off issues and wikis on github repositories and force people to file pull requests to fix issues if you'd like.
• DanBC 12y ago
  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.
• qwerta 12y ago
  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.
• stonogo 12y ago
  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.
• deleted 12y ago
  [deleted]
• ripb 12y ago
  >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.
• jijojv 12y ago
  Please don't turn off issues so people wanting to try your code are aware of bugs. Just say it's unsupported.
• thomasfoster96 12y ago
  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.
• Mikeb85 12y ago
  You have no responsibility. If people want bugs fixed, they can fork it and do it themselves...
• thibauts 12y ago
  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.
  • durango 12y ago
    With golang that problem goes away :) but if you're stuck on Node, there's always several different implementations to linking libraries (although, a pain in the ass, but this isn't the fault of the open source author -- complain to Isaac for making an incredibly useless packaging system [nicest to play with though hence the popularity]). Don't get me wrong, I love Node, but blaming an NPM problem shouldn't place blame on an open source author. None of these solutions works for you? Time to be an open source contributor :)
    • thibauts 12y ago
      Golang's stance on this struck me when I saw it. "Of course". URLs have the answer embedded in their name from the beggining. There of course are pros and cons but it seems to me much saner to have URLs as package names and registries as mere search engines leveraging package metadata. I think you're a bit rude to NPM though. It had many things right and finding defects in retrospect is always an easy task. Regarding my involvement in open source, I have no clear picture of a solution to this problem at the moment so I will refrain, following the spirit of my previous point. I tend to publish only what I know will be firm ground for others to build upon.
• kazinator 12y ago
  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.
  • nesu 12y ago
    http://choosealicense.com/licenses/ http://choosealicense.com/licenses/ All open source licenses are not liable for damages arising from the use of open source code
    • _puk 12y ago
      Interestingly that page doesn't include the WTFPL [0] As that licence doesn't include a "no-warranty" statement, and copyright is automatic in most countries (from your link), there must be a fair few open source repos on Github etc that could be liable for damages arising from the use of open source code (or at least fall into a nice grey area I'd personally rather avoid). [0] http://en.wikipedia.org/wiki/WTFPL http://en.wikipedia.org/wiki/WTFPL
    • kazinator 12y ago
      That is simply not the case; only perhaps the ones listed on that page. People sometimes release code without properly licensing it. For instance I have seen code accompanied by a statement like "this code is in the public domain; anyone can do anything they wish" (without any disclaimers of liability).
• username223 12y ago
  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).
• warp 12y ago
  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.
  • chrismcb 12y ago
    No, actually you don't have the responsibility to transition the project. It would be the nice thing do. But not a requirement
• egonschiele 12y ago
  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.
• nodesocket 12y ago
  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.
• ams6110 12y ago
  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").
• dustinfarris 12y ago
  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.
• deleted 12y ago
  [deleted]
• nirvdrum 12y ago
  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.
• miohtama 12y ago
  http://thefirstruleofopensource.net/ http://thefirstruleofopensource.net/