
Ignoring pull requests discourages open-source contributions - luu
http://danluu.com/discourage-oss
======
hrjet
A part of the problem is that GitHub makes it difficult to find forks. If a
project is not being maintained in the original repository, and somebody else
is maintaining it, it should be made easier to discover those other forks.

Right now, when you click the "forks" link in Github it shows a pretty graph
of commits across branches and repositories, which although useful in some
cases, is very hard to navigate and doesn't help discover active forks.

Moreover, for the maintainer of the alternative fork, it would be nice to be
able to clone the pull-requests too from the main repo. They will be able to
merge any new PRs into their own fork quickly and also to automatically inform
the PR's watchers.

~~~
ansible
_Moreover, for the maintainer of the alternative fork, it would be nice to be
able to clone the pull-requests too from the main repo. They will be able to
merge any new PRs into their own fork quickly and also to automatically inform
the PR 's watchers._

Yeah, that would be cool. The only thing you can do right now it's to just
watch the original repo, and send messages to the PR submitters to open a new
PRs against your own fork.

~~~
maccam94
You can just fetch the PR's on the command line and merge them to your fork.
But being able to do it in the web ui would be nice too.

~~~
ansible
I think a lot of people like using the web UI because you don't have to add
another remote just to pull from it maybe once.

I'd definitely want to contact the creators of the PRs anyway so that they are
aware of my fork.

------
HashNuke
I found a simple solution to opensource burnout: when someone contacts me
about a project and wants to improve it, I give them access to the repo.

I do this when:

* I don't have the time/interest on the project

* The person seems genuinely interested in maintaining it

Most people I've come across in the opensource world are polite. So I just
assume that the ones I grant access to repos are nice enough for other people
to interact with.

~~~
Matumio
Same here, but I don't even care if the person is interested maintaining it. I
have observed twice now that the interest of somebody submitting an almost
trivial patch flamed up after I granted push access. The project suddenly got
a burst of life again, and commits started to become more and more ambitious.

~~~
HashNuke
I am going to try that from now on. Giving people access to repos and then
letting them pass on the baton when they are done. That is a very novel idea.

P.S: Yes I upvoted you and I wish I could do it once more :)

------
InformalRelief
OP argues that the presence of the 'Pull Requests' tab is encouraging people
to create pull requests, and therefore the project owner is somehow
responsible for reacting to pull requests.

There's also a 'Fork' button, which is kind of prominent, so by OP's logic,
people should feel encouraged to fork the project.

"But when I looked at the mailing list for the project, I saw a wasteland of
good patches that were completely ignored, where the submitter would ping the
list a couple times and then give up. Did it seem worth spending a week to
disentangle our IP from the project in order to submit a set of patches that
would, in all likelihood, get ignored? Of course not.

If you have commit access to a project that has this problem, please own the
process for incoming pull requests." (from the article)

Ok, so if the mailing list is dead and your pull requests aren't the only ones
being ignored, why not just fork the project and 'own the process' yourself?
You could even try to contact people who tried to contribute and got ignored,
and let them now that you will 'own the process for incoming pull requests'?

And if you don't have time or energy for that, why demand it from other
people?

~~~
MoOmer
To that end, the author also suggested that it may serve the project (and
subsequent forks) well if the project owner disabled PRs.

~~~
masklinn
You can not disable PRs on github. The wiki yes, issues yes, but it's not
possible to disable PRs, that simply isn't an option.

At best you can add a note/contribution guideline saying you don't accept PRs,
and close them as soon as they're created, but it's not possible to prevent
them.

------
sciurus
Although the author tried to obfuscate the project he used as his example,
people on Reddit quickly figured out that it was linguist. This is a library
Github maintains that they use for detecting what language a file is written
in. There is a special irony in Github employees encouraging then ignoring PRs
that would improve their own product.

[https://www.reddit.com/r/programming/comments/1pczpr/how_to_...](https://www.reddit.com/r/programming/comments/1pczpr/how_to_discourage_open_source_contributions/)

[http://danluu.com/everything-is-broken/#github](http://danluu.com/everything-
is-broken/#github)

~~~
memset
We have no idea why the people at github did not merge this PR. Maybe several
people on the team left the company. Maybe they were pulled into a project
which will have higher revenue. Maybe so few people have this problem that
this improvement isn't a priority. Maybe it breaks some other internal
functionality that someone uses.

We have no idea whether this "would improve their own product" because we
don't know what their product is, their product roadmap, their staffing, their
budget, or any of the innumerable factors which affect whether a company
chooses to spend time and energy and effort and money when implementing a
feature.

So why do we presume?

~~~
sciurus
We should not have to presume. Since Github is soliciting contributions to
linguist [0], they've created an obligation to engage with outside
contributors and explain their decisions. When the author wrote his blog post,
there were over a hundred PRs and apparently no acknowledgement of many of
them from Github. In his "How to destroy your community" talk [1], Josh Gruber
refers to silence as "the most effective community destroyer of them all".

I'm not actually trying to call out Github, by the way. It's great that
they've written up guidelines for contributing [0], and a glance at the PRs
shows much more engagement now.

[0]
[https://github.com/github/linguist/blob/master/CONTRIBUTING....](https://github.com/github/linguist/blob/master/CONTRIBUTING.md)
[1] [https://lwn.net/Articles/370157/](https://lwn.net/Articles/370157/)

------
dpweb
Couldn't you charge people to look at their pull requests? The contributor's
fix may seem very important to them, but in actuality may or may not be of any
value at all.

They are using free software but asking the maintainers of it to spend their
time to review their pull request. Some entitlement there. The justification,
my fix is important. Well, we don't know that, and to determine it costs time.

I would think a fee system where people pay to have their pull requests
prioritized. I know it goes against this misguided idea that everything free
is a virtue, but there is a good reason why some things have an associated
cost involved.

~~~
Thrymr
I seriously doubt that a financial incentive would change most maintainers'
attitude towards pull requests. What is an appropriate piece rate for a PR
review? There are plenty of highly paid developers who are doing a side
project for free, for whom an hourly consulting rate <$100 would be well below
their market rate. Well paid professionals doing a labor of love are not
likely to be motivated by $5-10 here and there. Not all package maintainers
are in this category, of course, but most are volunteers who don't expect
financial compensation for it. Offering me $5 (or whatever nominal amount) to
review a pull request is more likely to insult me than motivate me.

This is my problem with Gittip/Gratipay as well, the amounts are not enough to
make a self-sustaining project, and even if it becomes a standard expectation,
when someone else is willing to do it for free it would breed resentment. Open
source should not be a service economy dependent on the gratuities of others.

Note that I'm not arguing that developers _should_ work for free, just that
small sums aren't likely to change their behavior. Sustainable business models
for open source projects are difficult, and I suspect that tips are not often
going to provide one.

~~~
dpweb
I wouldn't be too US centric in your assumptions. India will soon overtake the
US in software devs and the average Indian dev makes approx. $5400/yr.

[http://www.glassdoor.com/Salaries/india-software-
developer-s...](http://www.glassdoor.com/Salaries/india-software-developer-
salary-SRCH_IL.0,5_IN115_KO6,24.htm)

Now, even on the high end if the Indian dev makes $7k a year or $3.50/hr. And
I'm a relatively high paid US developer who depends on their project and I
offer $50, that's 14 hrs. of work. Not insignificant.

~~~
known
Cloud services will destroy Indian IT services viz TCS/Infosys/Wipro/TCS/HCL

------
skybrian
If you have no plans to maintain hobby code, you should _discourage_ usage.
Say it right up front:

"TagTree is unsupported and not meant for use in a production Dart
application, unless you're willing to fork the code and fix any bugs you find
yourself." [1]

Or if a project is widely used but difficult to contribute to, you should say
so up front, like this:

"Contributing code is one of the more difficult ways to contribute to Guava,
and is almost never what the project really needs most [...] We know it's
tempting to submit code before the feature is accepted, but this is not always
a good use of your time." [2]

People tend to over-promise because that's what they see other open source
projects doing. But you don't have to be an evangelist just because everyone
else is. If you're not committed to doing something, don't sell it. Real
leadership is about being respectful of other people's time.

[1] [https://github.com/google/dart-tagtree](https://github.com/google/dart-
tagtree) [2] [https://code.google.com/p/guava-
libraries/wiki/HowToContribu...](https://code.google.com/p/guava-
libraries/wiki/HowToContribute)

------
zackmorris
When I first heard about open source in the mid 90s, I thought "that can't
possibly work with no leader" because I thought that writing to the repository
was open to anyone. I wondered if maybe then someone would stress test a
revision and if it was good enough, sign off on it as the most recommended
version to download. So basically there would be no "current" version, that
one would be this evolving hodgepodge out ahead of the one most people used. I
guess I envisioned it working kind of like evolution, so the best versions
would split and merge again like reproduction and the most fit version would
rise to the top.

So on some level I think open source has actually failed, because it didn’t
work out that way. Instead there seems to usually be a handful of maintainers
who allow certain patches to go in, but if there’s too much of a disagreement,
we end up with a fork, never to be merged again. The burden on that handful of
people is so high that on some level I'm amazed anyone ever takes on the
infinite support liability of starting an open source project in the first
place.

Just out of total curiosity, does anyone know of any other ways of organizing
open source, I mean from decades ago when it was first getting started? Were
there ever any successful projects that were more organic, where a greater
portion of the contributors or even all of them could make changes? Did they
devolve into anarchy or did they work?

Update: I didn't expect this to be down voted, perhaps it was my poor choice
of wording. What I meant to say was "So on some level I think open source has
failed to live up to its original vision of open contribution leading to
viable software".

~~~
jdumblauskas
good post -- I think you really got to the core issue -- "that can't possible
work with no leader" \-- or at least a "benevolent dictator". I guess I'd like
to see evidence of an old open source project that has withstood the test of
time. None come to mind.

------
Animats
Back in 2012, I ran into a similar problem. The Python standard library has
"isoformat()", which converts Python datetime objects to
"2012-09-09T18:00:00-07:00" format. This is the format used in emails and RSS
feeds. But there was no standard function for the inverse, parsing such
strings, that got all the cases, including time zone offsets, right. Others
had discovered this problem and tried to fix it. The Python repository, PyPi,
had four different versions of such parsers, each broken in a different way.
Because there's no way to fix anything in PyPi (it's just a list of links; it
doesn't host the source), each person who had found a problem had forked the
code and hosted their version somewhere else. People have been posting bug
reports about this since 2008.

Further discussion unearthed _seven more_ different Python implementations.

[https://groups.google.com/forum/#!topic/comp.lang.python/Q2w...](https://groups.google.com/forum/#!topic/comp.lang.python/Q2w4R89Nq1w)

Two years later, there's been little convergence. There's a currently
maintained version on Bitbucket at
([https://bitbucket.org/micktwomey/pyiso8601](https://bitbucket.org/micktwomey/pyiso8601)).
It has four forks.

So there are now 15 different versions of this little function. A function for
which there is a well defined spec, an RFC and an ISO standard, for what it is
supposed to do.

That's the open source process.

~~~
pgeorgi
Python has PEP to extend the base system including the standard library. Maybe
it should go through that instead of being third party code in some
"repository"?

The closed source market of (say) third party win32 controls (GUI widgets) is
also messy - just look at how many calendar widgets are out there, but nobody
complains there. That's "market forces at work" ;-)

~~~
maxerickson
Stuff like adding a single function to a library doesn't warrant the PEP
process.

Fixing this is moving forward:

[http://bugs.python.org/issue15873](http://bugs.python.org/issue15873)

(Perhaps it's fair to say, slowly moving forward)

~~~
Animats
Ah, yes, I put that issue into the tracker two years ago.

------
scoot
I contribute to an open source project that actively solicits contributions.
The README asks for PRs in preference to issues (but issues are okay), and
there is even a CONTIBUTING.md that describes the process.

After being active on the project for a while I was granted commit rights. I
have done everything I can in that role to support the project - responding to
issues, merging other's PRs after code review & testing, updating
documentation, and, in response to issues creating PRs that are: coded in the
same (slightly idiosyncratic) style as the original code, don't cause
regressions, have their own tests, and are well documented.

In the interest of good practice I haven't merge my own PRs, but left them to
the project owner to review. There they languish despite in some cases
resolving issues that the project owner himself opened issues for.

So, while I don't agree with the tone, I do sympathise with the author's
position. It can be demoralizing when an open-source project owner actively
solicits contributions (not just a fork or create PR button, but requests and
instructions), then ignores contributions that may have taken many hours (or
in some cases days) to get to the point where the PR is submitted.

------
ninkendo
The obvious solution for owners of such projects is to grant more people
commit access so more people can handle outstanding PR's. A single person
being responsible for all pull requests doesn't scale.

But the issue is that owners don't like giving up that much control, because
it can lead to the project being taken in a direction they didn't originally
intend.

This is an issue for any open-source project, which is why the biggest
projects tend to have a structure where there is a dictator, a hierarchy of
core contributors, and everyone else should stick to mailing lists or pull
requests to contribute code.

But for small projects it's difficult because it's tough to make that kind of
hierarchy work on GitHub.

I'm starting to think there needs to be a boilerplate "Contribution Guidelines
for Small Open Source Projects" meta-guideline that small Open Source projects
(on the size of things like gems or small utilities) can adopt, similar to how
projects can adopt SemVer or a particular OSS license.

Some simple tenants of such a guideline system (or basically, an example
thereof:)

1) Contributions to this Open Source project shall adhere to this projects
MANIFESTO.md, which shall define the goals of the project, its scope, what it
aspires to be, etc.

2) The owner of this open source project shall grant commit access (promoting
them to "Core Contributors") to developers who show a consistent drive to make
enhancements and fixes that fall within this well-defined manifesto.

3) Only the owner shall make changes to the manifesto. Changes to a project's
manifesto should require a fork of the project. Manifestos can be designed by
consensus but it should ultimately be up to the owner to commit the change.

4) Core contributors should be able to merge other developer's pull requests,
and even grant commit access accordingly. If any commits get merged which fall
outside of the manifesto's guidelines, the commits can be rolled back by the
owner, or the core contributor can make the case for changing the manifesto,
or they should fork the project to keep the commit.

I don't really have the clout to be able to develop such a meta-guideline (I'm
not active in any OSS projects), but I think it would be really cool if
someone would.

------
bjz_
As somebody who maintains a decent amount of Rust libraries, I do try to keep
on top of my PRs, but sometimes Github's notification system makes it easy to
forget that some PRs have been sitting around for a long time. For example if
you click on a notification in your inbox, it automatically gets marked as
read - you can't keep it around as a reminder.

What would be really nice is if you could have some sort of dashboard to let
you know the status of your outstanding issues and PRs on all of your
repositories - how long they have been open for, whether they are stale or
not... etc. It's just too hard to go through each repo individually to check
on its health.

~~~
pwg
Another issue is that github's "merge a pull request" system is completely
broken.

Most projects on github, by virtue of being based on git, will have several
branches within the repository. The regular contributors to the project will
know branch 1 from branch 2 and will submit their PR's against the projects
"dev" branch (whatever it happens to be).

But irregular contributors, or out of the blue contributors, will invariably
choose a branch that is not the projects "dev" branch upon which to base their
patch, and then submit their pull request.

And for the project receiving the pull request, the github "handle it"
interface is all-or-nothing. You either put the patch in, against the branch
the requester used, no matter how wrong that branch might have been, or you
simply can't merge it via. github's web interface. And if you don't merge it
by github's web interface, you can't mark it accepted. Your choices are
"accept and merge patch" and "refuse".

So there's a very good chance that some number of those outstanding pull
requests shown have actually been merged, but were merged by the maintainer
pulling a patch out of github manually, and applying the change manually via
git to the correct branch and not the branch the submitter picked. And since
the patch was in fact merged, poking the github "refuse" button in the web
interface would seem wrong, so the outstanding pull request just hangs around,
forever, because github can't be told "I did merge this, just outside of your
view".

------
memset
Something about this post does not sit well with me, though I have many
colleagues who have expressed a similar sentiment.

Overall, the OP seems to be suggesting that, _merely by posting code on
github_ , we have now been conferred with the responsibility of "maintaining
an open source project."

In fact, I find the first couple of screenshots kind of awful. "Why this is
ignored?" Ugh, I think I'm going to go back to bed.

When I make a blog post, I'm not expected to respond to every comment. Or
respond to every tweet. It's reasonable to not respond to every email. So what
is it about posting code on the internet which mandates that people read,
review, respond to, engage with, and eventually merge your code? And I do say
mandate, because this blog post is basically a take-down, of which many have
been written, of some poor project which has a bunch of outstanding pull
requests.

I'm sorry that individuals feel that, by not spending their time to review
code, they feel that it creates a "hostile" environment in open-source.

If the author had, instead of using github, simply posted a .tar.gz file on
their personal home page, this wouldn't even be an issue. If you wanted to
make a change, you'd download the source, modify it, and get on with your day.
But somehow github (and probably the fact that everyone's dependency
management system depends on "official" releases, often from github) keeps
people from doing what they used to do, which was just change the code and
continue on their way, and has bred some sort of animosity towards the very
folks who provided this code in the first place.

My must-read on this topic is from Armin Ronacher, who says:

"I found it quite hard this year to work on my own projects because the bug
trackers were full of things I personally did not really care about. The
things I wrote over the last few years all work so well for me, that I don't
need to fix problems or add things. When there is something that needs fixing,
I will work on it, but otherwise I don't necessarily get the motivation to
work on it." [1]

Armin does take steps to improve this, but to me it is important to say that
_he didn 't have to_.

I maintain several OSS projects. I have often gotten poorly-tested pull
requests and merged them without reading, understanding, or testing code. It's
the OSS maintainer who gets the heat, in the form of hundreds of emails, when
things break, not the person who made the PR.

So I agree with the central theme that too many open pull requests is
discouraging, and for projects which want to grow, there must be a process for
managing it. But I think this is completely at the discretion of the
maintainer, that we should take advantage of our ability to fork and modify
code (since when did the definition of OSS become "they must also accept
patches") and it is frankly rude for us to publicly knock a a project because
they haven't chosen to accept your patch.

Here is a productive idea: make it easy for me to use `pip` to install my
forked version of a library. That way I won't have to care whether it is
merged into master. (In fact, pip already lets you use git as a repository
source, but you can apply this to all of the other dep managers for other
languages.)

[1] [http://lucumr.pocoo.org/2013/11/28/emotional-
programming/](http://lucumr.pocoo.org/2013/11/28/emotional-programming/)

~~~
freshhawk
I think this is the result of people not recognizing two very different types
of open source code.

There's the friendly dump of useful stuff. It's not an open source _project_ ,
but it's code people know would be useful and are nice enough to share.
Obviously there is no responsibility to maintain it, everyone can just fork it
and it can diverge freely and no one cares.

Then there are actual projects. A person or group saying "Here is a problem we
all share. Let's stop reinventing the wheel and work together on this. I will
do some management work on this in return for your contributions and my name
being prominent. Forking this for no reason is considered rude. Please
contribute to this project instead of starting your own clone of it with your
name on it."

Those are both good things, but they are different. People should be clear
about what kind of project it is.

~~~
dalke
I think you're describing project governance rather than something about open
source code.

Me, I'm in a third group. I write commercial open source. Only people who pay
for my software get access to it, under the MIT license. Is it sharing if it
costs money? ;)

~~~
sciurus
If you give people your software under the MIT License, they can give it to
anyone they want to.

"Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so"

[http://opensource.org/licenses/MIT](http://opensource.org/licenses/MIT)

~~~
dalke
I'm confused. Could you explain your point?

Yes, that's the MIT license I use. My customers can share the code if they
want. But I sold them a copy of the software, I didn't share it with them.

~~~
sciurus
You said "only people who pay for my software get access to it". I was
pointing out that anyone your customers choose to share your software with get
access to it.

~~~
dalke
Sorry, I let out the words "from me" because I thought it was implied. I don't
share this open source software. I sell it.

freshhawk listed two categories: 1) a "dump of useful stuff" with "no
responsibility to maintain it" by people who are "nice enough to share." I
don't fit in that because a) I include a year of support in the sale, and b) I
don't share it, I sell it.

2) "Then there are actual projects. A person or group saying 'Here is a
problem we all share. ... I will do some management work on this in return for
your contributions and my name being prominent'". I don't expect trade in
kind, I expect money. Just like proprietary software vendors (especially those
who distribute sources).

Thus I consider myself as a member of group #3.

------
Karunamon
The solution to this "problem" is remarkably simple from a repo owner's
standpoint: Verbiage in your README along the lines of "This is an unstable
project and pull requests will not be honored - you are welcome to fork the
project, however!"

This makes it appear on the very front page of your project and is hard to
miss. (How to deal with people that contribute without reading first is an
exercise for the reader)

The attitude I'm seeing in here is really quite disgusting. You've put your
code up on what is basically the Facebook of coders - you _really should not_
feel put-upon when the unspoken social contract of a _collaborative code
editing platform_ is acted on by someone else.

Every culture has one, and GitHub's is shared collaboration on code bases. If
you want to violate that norm, fine, it's your project, but then kindly call
it out ahead of time and stop whining that the community that's made GitHub
awesome is the way that it is.

------
jhasse
I'm in a similar situation:
[https://github.com/JuliaLang/julia/pull/7714](https://github.com/JuliaLang/julia/pull/7714)

Can someone help me what would be the polite way to do? I really don't want to
annoy anyone, but also wouldn't want my work to be only on my local branch ;)

~~~
StefanKarpinski
Bumping the issue by posting something is probably the best way to go. I
promise we won't get annoyed and it's easy to miss things like this. I suspect
that what happened here is that all of the people who commented didn't feel
like they had the "authority" to just go ahead an merge it, while everyone
else (myself included) wasn't following the conversation (July was a really
busy month) and didn't feel informed enough to pull the trigger. From a quick
scan just now, this conversation looked to me like there were unresolved
issues still, but upon more careful reading, that's not the case. It can be
helpful to say something like: "I believe all the issues people have raised
have been addressed. This should now be good to go." This change is quite nice
and I'm testing it out right now. Sorry this languished for so long and I hope
it won't discourage you from contributing – it is very much appreciated.

Update: this is now merged into Julia master. Thank you!

~~~
jhasse
Cool! Thanks :)

I guess Hacker News rocks and also Dan Luu is right about "Props to OpenBlas,
Julia, Rust, jslinux-deobfuscated, and np for being incredibly friendly to new
contributors."

------
yesimahuman
The reason many PRs get submitted is that many of them just aren't good. Over
time, having to deal with formatting issues, way too many commits in a PR that
change random files, solutions to things that are really important but not
done in a foward thinking way. Great PRs when done right are a wonderful
thing, but the reality is that the majority of them are not great and this
takes a tax on the developer.

What us OSS devs can do to help fix this is be very clear about PR protocol:
ONE commit, change ONE thing. Code changes should have a unit test. And then
make sure we are either merging or closing PRs for active projects.

------
hesdeadjim
I've had a similar experience and I found it to be equally frustrating.

I contributed some minor enhancements to a simple helper script, one that just
made a small part of development a little smoother. I created a pull request,
added a good description of what I had done, and sent it off. The author got
back to me pretty quickly with a few changes he wanted done, I happily
obliged, and then sat and waited for a week.

Then over the following few weeks he proceeded to nitpick and ask for changes
that really just amounted to over-engineering for some future possibility he
imagined for his 200 line script. I will also point out that beyond the
initial commits he had made six months ago, he hadn't touched the project
since.

Regardless, I obliged, made every change he asked for. That was almost a month
ago and he has now gone completely silent, the pull request sitting idle.

What I learned from the experience is that beyond the points the author made,
the balance of power in these projects is often an insurmountable barrier. For
instance, if I say something that pisses this guy off, he simply ignores my
pull request and it sits in limbo forever. Or I fork his project and other
users are forced figure out which version is the best (great example of this
is the shitty state of AWS libraries in the Go language).

All in all, this experience isn't enough to turn me off to contributing to
open source projects. It does however make me think twice about when it's
worth trying and when I might just let my private forked copy stay that way.

------
al2o3cr
Funny, you could write an article entitled "Why open-source maintainers quit"
and have the sole text be a hyperlink to this article. The whole piece is a
long whinge about "why won't maintainers do free work for MEEEEE!". Maybe they
aren't using the project anymore, maybe they're busy with life, maybe they
just got tired of triaging for a while - whatever.

The final story in the piece really sums it up: "But when I looked at the
mailing list for the project, I saw a wasteland of good patches that were
completely ignored, where the submitter would ping the list a couple times and
then give up. Did it seem worth spending a week to disentangle our IP from the
project in order to submit a set of patches that would, in all likelihood, get
ignored? No."

This sounds like a great situation for somebody else to step in and pick up
maintenance of a clearly-neglected project. Hell, if your company is using the
software for critical-enough things to devote "a couple months" to fixing bugs
it seems like it would be in your company's interest to start maintaining the
project publicly, if _everybody 's_ patches are being ignored. It would
certainly be more productive than complaining that somebody else won't QA and
then support _your_ fixes FOR FREE, FOREVER...

------
andyidsinga
> But when I looked at the mailing list for the project, I saw a wasteland of
> good patches that were completely ignored, where the submitter would ping
> the list a couple times and then give up. Did it seem worth spending a week
> to disentangle our IP from the project in order to submit a set of patches
> that would, in all likelihood, get ignored? No.

Sounds like the OP should have checked activity levels first ...then decided
not to spend the extra time.

When I look at using open source for something I often use the following to
determine if I should use it:

a) does it have the functionality I need today

b) is it active and being maintained ( through frequency of updates, active
mailing list, sometime a financial sponsor (bigco who uses it))

------
the_af
The title of this article is unfortunate in my opinion; I clicked it expecting
a diatribe against open source. But in fact, it isn't.

To me, the relevant part is this:

> _" This behavior, eminently reasonably reasonable on the part of any
> individual, results in a systemic failure, a tax on new open source
> contributors. [...] It doesn’t take egregious individual behavior to create
> a hostile environment."_

So the causes aren't necessarily hostile behavior, and in fact there may be
both permanent and temporary solutions to this problems. Therefore, a better
title would be "How to _encourage_ open source contributions" :)

~~~
EdwardDiego
> The title of this article is unfortunate in my opinion; I clicked it
> expecting a diatribe against open source. But in fact, it isn't.

I was expecting a rant against shitty builds, my biggest contribution to
contributing to an open source project.

------
phaer
Thanks for your post and for not picking on one project in particular, but the
obfuscation of the projects name in your last screen shot doesn't really work.
It's trivial to read the projects name there.

------
egonschiele
In my experience, most pull requests I open have been merged quickly. When
they don't, it's because the repo is part of a large company/organization and
there's no owner for the github repo.

Also, what are these magical projects getting hundreds of PR's? Most of mine
seem to just get bug reports instead.

I have to sympathize with both sides. It sucks to have a PR ignored, but I
also don't want to open source projects if it just means something else I have
to maintain. Theoretically, if I don't merge PRs, the community chooses a new
fork as the "canonical" fork. I've seen this happen with small communities
(its happened a few times with Haskell). I think it's tougher when it's a
popular project.

------
StylifyYourBlog
I agree with the point that many a times when a person sends in a pull request
, that might be their first time doing so and their experience with you might
be how they would perceive the whole open source community in the time to come

------
hysan
A fairly important point that was left out is the license. If the original
developer puts some form of license on the code, then people may be afraid to
fork and maintain the project on their own because no one wants to try and
understand the murky waters of licenses/copyright/etc. This mentality puts the
onus of maintaining the repository on the original dev despite their
intentions on making the code open source. In my opinion, if you are going to
open source your code but with no intention of maintaining it, then make a
fully open license in plain English that says anyone can take ownership of the
code.

------
hw
I've contributed bug fixes to open source projects on github and have had my
share of ignored pull requests, sometimes they are for valid reasons like the
project owner being on vacation or a business trip, but often enough the owner
just didn't have enough time to manage the project.

I feel that in the latter case, it should be the responsibility of the owner
to delegate more project administrators, or hand a project off to someone else
to maintain. It's often hard to do so, and hard to find someone you trust that
would take the project and maintain it well.

------
vorg
If an open source project doesn't merge in pull requests, then that's the
business of whoever created and/or runs that project. When a project's
managers let a pull request or Jira issue sit there but create their own
request or issue to do exactly the same thing often with code copied from the
original, however, then that's behavior that should be exposed.

------
res0nat0r
Another great fix for this problem if you don't have time to work on issues,
or users are becoming more of a burden than a help...go to your github repo
settings page and disable them.

~~~
Anderkent
You can't disable pull requests.

------
curiously
I also open sourced a project I was working on.

Basically the benefit to me has been net negative.

It has taught me to never give things away for free, especially code.

License it, sell it, do anything but open source it on github unless it is
javascript or any program that is easy to just look at the source.

