
Ask HN: If you open source some code, are you responsible for maintaining it? - egonschiele
This is something I have been wondering for a while. 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.<p>At the same time, I have a lot of projects that I open sourced but have no desire to maintain. Here&#x27;s an example: http:&#x2F;&#x2F;github.com&#x2F;egonSchiele&#x2F;mdpress<p>This is a simple Ruby script I wrote that is now one of my most starred projects. I haven&#x27;t used it in a while (I don&#x27;t make many presentations) but I still keep getting and responding to bug reports. What&#x27;s my responsibility here? I am happy to open source my code, but I don&#x27;t want the extra work of maintaining something I rarely use.
======
jrochkind1
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
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
looks like pull requests can't be though?

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

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

In retrospect, NPM was a bit rude to it's userbase. We've asked for support on
custom, multiple, and private registries. PRs have even been made for them and
Isaac explicitly shut them down only to later (much later) come out and talk
about NPM Inc. NPM is a great tool, and the community for building upon it is
absolutely fantastic and wonderful, but the leadership and advisory board
behind it are pretty terrible for something as good as NPM.

May be I am a bit harsh, and I may be a bit biased coming from "the old crowd"
in Node before it was the cool thing on the block (funny to think back on
Rubyist snickering at me for mentioning node to them :))

At least NPM has git URLs which is nice, and may be NPM can do these things
(I've abandoned it for much saner practices other than cloning a 50+gb
registry, pointing to a registry that falls back to an official registry [big
security no-no, at least allow checksums], etc).

Thank you for the perspective though, less whining and more typing
(contributing to NPM). My anger is more so towards the leadership of NPM
rather than the toolset itself and I didn't express that in my OC ^

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

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

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

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

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

------
warp
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
No, actually you don't have the responsibility to transition the project. It
would be the nice thing do. But not a requirement

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

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

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

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

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

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

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

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

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

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

------
kazinator
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
[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
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)

------
miohtama
[http://thefirstruleofopensource.net/](http://thefirstruleofopensource.net/)

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

------
johncoltrane
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
Open sourcing does not imply future maintenance. That's why everyone should
evaluate the state of a project before starting to use it.

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

