
My condolences, you’re now the maintainer of a popular open source project - donnemartin
https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/
======
impostervt
I'm the creator of a just-mildly popular OS project (~700 stars on GH) and I
had to give up being the main maintainer. Too many "issues" were just people
who couldn't debug their own code, or "issues" where the person would describe
some weird edge case but be unable to provide any example code. After enough
of those, and getting busy with other things, I just couldn't keep up with it.

Luckily, one of the contributors stepped up and is now the main maintainer. I
still read through the issues that come in and he does a great job of
responding and keeping cool. I don't know how he does it.

~~~
adekok
Having maintained an Open Source project for almost 20 years now, there are
some ways to deal with bad users.

One is to not take it personally. Annoying people should get ignored or
banned. They're just not worth the effort.

Two, is to recognize that your time is limited. If the person filing the bug
can't (or won't) help track it down, well... too bad. Maybe no one else runs
into the bug, and your best response is "works for me". (Note that this is the
approach taken by most commercial software vendors in my experience)

Three, is to recognize that there are idiots out there, and you can't help
them all. It's OK to be on the lower end of the bell curve, but sometimes it's
like the kids rides: "You have to be THIS TALL to go on this ride". If the
user can't comprehend something, perhaps he shouldn't be using it. And perhaps
you shouldn't waste your time trying to get him to understand something he
just can't understand.

My general approach is to be nice to people who ask good questions, and who
_try_. When people ask terrible questions, and make it clear that they have no
interest in lifting a finger, but demand that _you_ do all of the work...
well... they get told in no uncertain terms to shape up, or get banned.

You don't owe these people anything. If they had an ounce of human decency,
they would understand that they got the software for free, and that they don't
_deserve_ anything. And that _they_ need to put some effort into it on their
end.

The main response I have with these people is _If you 're too lazy to help
solve the problem, then I'm too lazy to help, too._

~~~
Bahamut
Agreed - all of this is necessary to keep sane.

I maintain UI Bootstrap (over 12k stars on GitHub), and I have to make
decisions on bugs and feature requests. I prefer erring on inaction of
response if I am not sure of how to decide, and I make it a policy to close
support issues on the repository.

Ultimately, if someone really cared about a particular issue, the person would
make an attempt at a pull request to help contribute. I will even often help
give most of the important abstract information needed for a contribution too
to assist in the general implementation, but I can only do so much work for
people.

I am also inclined to help bad attitude people the least - it is the quickest
way for me to take longer to reapond & implement, so be nice to your friendly
open source maintainers people!

~~~
rkangel
> if someone really cared about a particular issue, the person would make an
> attempt at a pull request to help contribute

That's not _always_ true. They may not have the necessary skills. That's no
excuse for laziness in reporting problems though.

~~~
Pxtl
Ultimately, that's still laziness.

Learn the necessary skill.

~~~
stinkytaco
Really? I might be able to report a bug in any number of roles (perhaps
designer, perhaps administrator, perhaps user) and I may not have the
knowledge or experience necessary to fix the problem, but certainly enough to
report in a detailed way. If knowing software development is not my job, I
can't be a user? What if I am a developer but not familiar with the code?

Dismissing users because they do not have the skills to fix every problem is
absurd.

~~~
Pxtl
I'm not dismissing the users, I'm just saying that nobody owes you a bug-fix.
If they prioritize your bug, that's great, but if they don't - either submit a
pull request or live with it. The knowledge developers put towards their free
hobby-projects is hard-earned and shouldn't be treated like public property.

------
jordigh
The most important thing about releasing free software (open source) is that
_you don 't owe anything to anyone_ by doing so.

Virtually all free licenses actually codify this. If you read the SHOUTY CAPS
part, it says exactly that: no responsibility from the author.

People can come and ask for you to fix something or support them or accept
their patches. That's fine, and if you want to engage them, you can. But
_there is no obligation to do so_.

Once I accepted this, the growing pile of bugs/issues/support requests on the
Octave and Mercurial bug trackers become a lot less anxiety-inducing. I'll try
to help, but if I couldn't... sorry, it's not my responsibility!

------
kmfrk
Is there a good reason GitHub doesn't support (issue) "moderator" roles
instead of "contributors", which also gives write access? So much could be
solved with better moderation tools.

~~~
rincebrain
The only reason I can see is that Github doesn't have any notion of users that
are not developers.

------
fagnerbrack
Yeah, just how I feel, see
[http://github.com/impress/impress.js](http://github.com/impress/impress.js)
and
[https://github.com/impress/impress.js/issues/435](https://github.com/impress/impress.js/issues/435).
Luckily the activity doesn't match a number of stars, although still, it is on
the top 30 on Github.

~~~
jordigh
This seems like a perfectly reasonable issue? I think if someone is unable or
unwilling to spend time maintaining a project, designating a successor is the
right thing to do.

Or are you saying that we shouldn't even have to ask the maintainer to
designate a successor, we should just find one without the maintainer's
involvement?

~~~
bllguo
I don't entirely understand what the commenter is trying to say, but from his
username it seems like he _is_ the successor.

~~~
fagnerbrack
> but from his username it seems like he is the successor

That's correct, I thought it was obvious but I was trying to say that if more
experienced people did this the open source ecosystem would be in a much
better state.

------
sotojuan
Many have started adding collaborator status to any user that makes a non-
trivial commit to both show appreciation and lighten the load.

~~~
akerro
So they are also able to push directly to master, push bad changes,
backdoor/add malware to your projects and make a release. I would be careful
with this.

~~~
diggan
I'm one of the people who do this, if anyone is doing more significant change
than just updating the readme/fixing a typo, give them collaborator status
after checking out their profile.

I think the benefit of people feeling proud of being a collaborator and trust
from me, is bigger than the risk of someone ruining their own reputation by
adding a backdoor.

But, most of my projects are tiny-ish and not even close to big, so I guess I
have a bit more flexibility in this.

EDIT: Just remembered that you can activate "Protected Branches" on Github
(and I'm sure something similar exists for Bitbucket and Gitlab as well) that
disables pushes straight to master.

------
andy_ppp
There needs to be a filtering of issues down to maintainers.

Github should think about how to build this IMO, it would make things much
better if there were levels of involvement:

-1) Asked for help before and NOT valid

-1) Pull request not valid

-1) Noisey user (might have positive Karma but often creates irrelevant issues).

0) Not asked before

1) Asked before and valid

2) Asked before and committed fix

3) Pull request valid

4) Pull request merge

5) Complex feature merged

6) Contributor

7) Maintainer

Now each of these can be discussed how to get there but if you could by
default only see one level above and 3 levels below that would help a lot.

The default count of issues and view of maintainers/contributors on github
should not include anything below level 1.

~~~
mcguire
You're bringing back memories. I was an AIX sysadmin (among other things) when
IBM added a new layer of tech support because too many issues were making it
through to the developers.

You had the script readers, someone to read the man page to you, then the new
layer, that I never reached because I don't like yelling and we only had 8
servers. Then, I think, you got to someone who could triage issues.

~~~
andy_ppp
>>> someone to read the man page to you

If it's in the docs/easily googleable could be another minus.

------
franciscop
I discovered another way of getting contributors with Umbrella JS [1] (500+
stars), using up-for-grabs [2][3].

In total I'd say it's similar or even a bit more of effort per issue, however
many people contribute and sometimes they step up and continue with more
things.

Not sure how useful it is for projects that are more monolithic though, I was
lucky with this one as Umbrella JS has many small modular parts.

[1] [http://umbrellajs.com/](http://umbrellajs.com/)

[2] [http://up-for-grabs.net/](http://up-for-grabs.net/)

[3]
[https://github.com/umbrellajs/umbrella/issues?q=is%3Aissue+l...](https://github.com/umbrellajs/umbrella/issues?q=is%3Aissue+label%3Aup-
for-grabs+is%3Aclosed)

------
jordigh
A lot of those 80% projects on github without licenses are simply not meant
for public consumption. Think things like bash or emacs dotfiles or class
notes scribbled into a txt file or a very personal project that has no hope of
working anywhere but on the author's machine. I think people overstate how
"post-licensing" people view open source (née free software). For everything
important, people still mostly slap free licenses on their projects.

~~~
isxek
...which is probably why it's a better idea to keep those projects in private
repositories outside of Github. Yet somehow, people keep forgetting there are
other project hosting options (Bitbucket, Gitlab, etc.).

~~~
nathan_long
> which is probably why it's a better idea to keep those projects in private
> repositories

Not necessarily. Public dotfiles are easy to link to in conversation, and
"users" are likely to be people who just copy and paste some interesting
lines. A license is probably irrelevant for, eg, vim configuration options.

------
ManlyBread
Question: why people seem to be so affected by unpleasant contributors? I
mean, no one forces these people to use an open source project and no one has
an obligation to support it at all, yet I see articles like this popping up
pretty often. What's the harm in ignoring the unpleasant contributors and
focusing on the ones that provide actual value to the project?

~~~
shados
It gets really hard sometimes. Take the following issue as an example:
[https://github.com/reactjs/redux/issues/1528](https://github.com/reactjs/redux/issues/1528)

Later in the issue, someone jumps in the discussion and trashed all over
everyone. That same person hopped on every blog post, ever medium post, every
discussion, gitter, everything. It was bordering on harassment. I don't
maintain that project so it's easy for me to ignore, but for the people
involved, it must have been pretty rough.

------
tropo
Dealing with users is nothing compared to dealing with Linux distributions.

The distribution will patch your code. You are powerless to stop this. They
will add bugs. They will add ill-conceived and/or incompatible features that
the users will come to rely on. Fedora adds a -Z option, and Debian adds a -Z
option, and SuSE does too, and all of them are in conflict with each other and
with the purpose for which you had reserved the -Z option.

Of course, the users will blame you.

------
Keyframe
I salute you, open source maintainers. You are our heroes we don't deserve.
I'm pretty sure I would become a murderer if I had to deal with what you deal
with on a daily basis.

------
cyphar
Can we please stop using the term "open source" when referring to free
software? Especially in the discussion of benefits of free software over
proprietary software. What you're contrasting here is the bazaar model over
the cathedral model (though the book itself is horrible).

------
orionblastar
There are a lot of beginners who try to learn programming by using GH. They
might not know how to make an example, or how to reproduce the bug by giving
directions.

When I worked as a programmer, I had coworkers and other employees I worked
with who couldn't tell me how to reproduce a bug, or give example code, and I
had to train some other programmers in the language to help them learn more to
work with a team. You can't just WONTFIC an issue, and yes it is harder to
work that way.

You cannot block or ban people who are annoying or ignorant in a corporate
environment. You have to find a way to help them out, by educating them, or
just trying to fix the bug as best you can even if you can't reproduce it.

I made a debug version of the program that trapped for errors, and wrote them
to a log file and displayed a custom error message so I can tell what part of
the program it had the error in. You have to learn how to innovate and work
with annoying and difficult people who don't even know they are annoying or
difficult. Yeah it is stressful, but that is the difference between an open
source project on Github, and working for an employer as an employee or
contractor.

------
makecheck
This could also be viewed as a challenge to develop better tools.

For instance, maybe there is data mining to be done on issues to auto-
aggregate them so that you can still make some sense of the list without
manual tagging and without relying on each submitter to choose sensible
categories.

Maybe there need to be open-source libraries aimed at unclogging issue
systems, such as a system for in-app bug reporting.

Maybe issue-tracking systems should auto-upgrade priorities on stale issues,
or auto-close them based on lack of activity from the submitter.

------
kzisme
Another presentation that is in line with the thoughts of this discussion:
[https://www.youtube.com/watch?v=UIDb6VBO9os](https://www.youtube.com/watch?v=UIDb6VBO9os)

------
nicolasMLV
Let's hope Github will find a way for users to be able to 'tip' maintainers. I
concede it is very hard to find the solution (Who? When? How much?)

~~~
fudged71
I assume this is already possible with ChangeTip. I don't think it would ever
be built in as a feature.

There is also Patreon. I have seen people fund project maintainers this way.
Enough for a full income
[https://www.patreon.com/foosel](https://www.patreon.com/foosel)

------
Jedd
This is one of those articles that reminds you why we should prefer the term
'free software'.

    
    
      > First, a conclusion from the 2015 Future of Open Source survey:
      > “Seventy-eight percent of respondents said their companies run 
      > part or all of its operations on OSS and 66 percent said their
      > company creates software for customers built on open source. This
      > statistic has nearly doubled since 2010.”
    

The 2015 survey on this website was responded to by 1500 people. (0.0000002%
of the population)

They don't provide numbers for the 2010 response set.

    
    
      > Second, Nadia Eghbal, who is doing really great research into
      > the economics of open source, calculated that “open source was
      > worth at least $143M of Instagram’s $1B acquisition.”
    

Likely wrong, but my feeling is most HN readers aren't thinking Instagram
valuation is the best way to judge the _value_ of free software.

    
    
      > I think there are a few reasons for this Cambrian explosion of
      > open source usage:
      >
      > 1. Open source is free to use, which means a company can spend money
      > on people (aka innovation) instead of software licenses.
    

Everything I've read in the past 15 years suggests that free software's value
proposition isn't founded on capex (in fact it's probably misleading to look
at these numbers)

    
    
      >  2. There are now a critical mass of reliable open source
      > components, which accelerates your product’s time to market.
    

Assertions without evidence. Plus a lot of us probably have thought a critical
mass was achieved a long time ago.

    
    
      >  3. Open source produces quantitatively better software.
    

Assertions without evidence, despite popularity of opinion.

    
    
      > 4. Near and dear to me personally, open source permits
      > companies to collaborate on common problems without
      > complicated business agreements.
    

In my experience some of the most exhaustingly complicated licence discussions
have been around the various free (or similar) licences on various lumps of
code. At least with non-free licenced code you know nearly precisely where you
stand.

    
    
      > "Open source" now means two things.
      >
      > Clearly, there’s the official definition, a permissive
      > license which grants certain freedoms to the end user.
    

Clearly? No citation provided. Worse yet, 'open source' was _clearly_ a
rebellion by esr against the idea of emphasising the freedoms to the end user.

Eric's related rant at [http://www.catb.org/esr/open-
source.html](http://www.catb.org/esr/open-source.html) is often provided ...
but read it critically and you realise there's very little of substance there,
other than negating the extant 'free software' position, and a call to
authority fallacy.

    
    
      > But when people use "open source" today, they’re probably
      > referring to building and collaborating in public. In fact,
      > they may not care about the license at all — over 80% of
      > projects on Github don’t have an explicit license.
    

80% of github projects don't include a licence ... qed ... 'open source'
equates to building and collaborating in public?

    
    
      > Why are so many people involved in open source? Well, for
      > all of the business reasons covered before. I also think it’s
      > joyful to get to work with people of a variety of cultures
      > and backgrounds. Additionally, open source has given me a
      > sense of permanence to my career, where the job I’ve taken
      > from year to year has not.
    

I'm empathetic, but this sounds like a plea for help.

More importantly it precludes the more common, and nuanced, reasons that
people generally provide for why they spend so much time and energy
contributing to the free software movement.

The rest of the post feels a bit facebooky, with lots of 3-8 word pithy
aphorisms encoded in a 1024x576 pixel image.

~~~
zerohp
> over 80% of projects on Github don’t have an explicit license.

I wish more people understood that this is a bad thing. These projects are
ones that every business should fear more than the GPL3. Copyright is the
default in the US, not public domain. Without a license you have no right to
redistribute it, or to distribute works derived from it.

~~~
Jedd
I concur, and the biggest challenge I see, in this case, _is_ the regional one
you cite.

Happily it's relatively easy to resolve for 99% (a number I just made up) of
these 80% of github projects that lack licences -- by either opening an issue,
or emailing the author, and seeking clarification.

In defence of these unnamed persons, I _suspect_ that if you're about to work
with a project that hasn't fielded this type of query previously (and resolved
it within their repo) then you're in some troublingly unchartered waters on at
least two fronts.

------
smegel
> Open source produces quantitatively better software

As someone who mainly uses open source software for most of my work, I'm not
so sure about this.

~~~
scardine
As someone who have to deal with crappy proprietary software for some of my
work, all I can say is that with open source at least I can fix a problem or
implement a feature that is lacking - instead of bang my head on the wall
waiting for the good will of the vendor (even when I want to pay well for a
hotfix).

~~~
maze-le
I (and I think we all) have worked with crappy open source and good
proprietary, as well as good open source and unusable proprietary software.
But one thing you said stays true: _" at least I can fix a problem or
implement a feature that is lacking"_. And I think _that_ is the main reason
people stick to open source.

~~~
mamon
And I think that it's the main reason why some open source projects remain so
crappy: main contributors are mostly interested in development of cool new
features and users are treated as both beta-testers and maintainters, and are
expected to find and fix bugs themselves.

~~~
spriggan3
> And I think that it's the main reason why some open source projects remain
> so crappy: main contributors are mostly interested in development of cool
> new features and users are treated as both beta-testers and maintainters,
> and are expected to find and fix bugs themselves.

If these projects were crappy no one would bother using them.

You're not entitled to anything as a user of open source software. Open source
is about collaboration, not entitlement,it's not one dev having to maintain
everything for other developers.

~~~
afarrell
> open source is about collaboration... you're not entitled to anything as a
> user of open source.

It is true.

However, this is why Proprietary software will always be around and why there
are many markets where Free Software won't take over. There are many people
that don't want to be a collaborator because they don't enjoy dealing with
software. They just want to exchange money and have a problem solved for them.

Free Software is, for some people/organizations, more expensive than
proprietary software because they would need to hire somebody to solve their
problems. You're right that they aren't entitled to someone else's labor for
free. However when they pay someone's salary (by buying proprietary software,
or a support contract), they are entitled to something: as much support and
hand-holding as they can negotiate for given that they have the BATNA of
paying a different company. For people/organizations that need that hand-
holding, it is necessary to make some tool useful at all, so it ought be
considered part of the cost when telling someone "you should use Open Source!
It is Free as in Beer!" If you think that those folks are wrong about the cost
of Free Software, then either tell the sales folks at Red Hat or do the
arbitrage yourself.

Ive seen arguments involving someone advocating Free Software for economic
(rather than ideological) reasons and just not getting it, so I apologize if I
sound like a broken record.

(oh, and a tool can be useful enough to work, but crappy enough that it makes
someone feel frustrated and stupid while using it.)

~~~
lsc
>However, this is why Proprietary software will always be around and why there
are many markets where Free Software won't take over. There are many people
that don't want to be a collaborator because they don't enjoy dealing with
software. They just want to exchange money and have a problem solved for them.

So, uh, while it's certainly true that it makes a lot of sense to exchange
money for goods and services, in this case, working software, my experience
has been that a lot of times? proprietary software is worse at this than open-
source. See RedHat, for instance, for an example of pretty good support (well,
compared to what you get when you pay money for proprietary software)

In fact, i think there are structural reasons why buying support from someone
who supports an open source product might be better than buying support from a
company selling proprietary software. The main reason being that the open-
source software provider has competition. People other than RedHat can
reasonably support RedHat software; this can't really be said for closed-
source software.

Considering the huge pain in the ass that switching business critical software
packages usually is, well, my personal experience is that if you get something
closed-source from IBM, you are going to be way more disappointed in their
support than if you get something open from RedHat.

~~~
afarrell
I don't mean to argue wholesale against F/OSS, but against a certain approach
to it. You are absolutely right that there are some domains where the Open
Source software available is much better than the proprietary software.
<insert rant about oracle's developer experience compared to PostgreSQL>

Another related structural reason is the lower cost and lower risk for a
professional of educating oneself on open source, reducing hiring costs. This
only applies to domains where the things you're buying aren't turnkey
solutions, but that is many domains.

~~~
lsc
Hmm? I suppose I was unclear. I wasn't making a comment about the relative
quality of the software itself- I was pointing out that once you have decided
you want to pay for support, for some domains, the for-pay support available
for the open-source product is better than the for-pay support available for
the closed-source product.

Really, "what level of support do I want to pay for?" is a question you have
to answer separately from the "should I use open source or not" question. You
can often buy closed source software without support, just like you can often
buy support for open source software. The quality of the available support
varies quite a lot, and really should be evaluated primarily on the reputation
of the company you are buying the support from, but in my experience?
proprietary software is not the clear winner in the paid support department.

I actually think that a lot of managers are sold a bill of goods with the
"someone to blame" line- The software being closed-source and paid for doesn't
automatically mean that the support is any good. I've been in so many
situations where we end up needing to call support because something broke, we
don't have the source... and a lot of times? well, I (and just about any other
sysadmin) could give you really long stories of incompetence.

------
lyra1337
i can count 16 wp-cli

------
ashitlerferad
Hmm, neither of those definitions of "open source" appear to be correct. Great
post otherwise.

