Hacker News Reader

You make it sound like GitHub being a graveyard is a bad thing. Does this mean that you rather had Croniter not exist at all?

It is simple, you see a project you like. If it has a bug you fix it in a fork. You use the fork until the project lead responds to your pull request. And if the project leads response doesn't suit you, you just continue to use the fork, you can pull from the original project whenever you like.

I guess I did make it sound like that. It is frustrating to find a project that on the surface works, but under the hood has issues all over the place. However, you are right, it is good that the project exists in the first place. Otherwise, I would have spent a day instead of an hour trying to solve my problem.

The issue I have is with project ownership. Forking a project is great. That's why there are 14 forks of Croniter. The issue is that when there are two divergent forks, it is not easy to tell what's going on. When a useful project gets abandoned, we typically don't have a way to deal with the consequences. Your method of forking and pulling changes only works if I am making really minor changes. However, if my changes conflict with the upstream in a major way (say I went about solving a design flaw differently than the newly awoken upstream author), I cannot proceed. Now if I want to use the upstream version I have to re-write my own software. Or I could continue with my own version, but without the benefit of upstream. Both choices are evil.

Instead, perhaps a good way to say "I officially abandon this project. Someone please inherit it." would be good. This could be done at GitHub level, where if I search for croniter I could get a suggestion for "Did you mean this fork of croniter that is significantly more active?" The issue is that then I want to install the code via PyPI, Ruby gems, etc. and the same problem arises there.

I can relate with your frustration. Sometimes it's important to you, and just having something exist is awesome. But sometimes it's not so important, and I was going through my life fine without it, and seeing the project made me try it out[1]. Then one can feel sucked in if it mis-sets expectations.

Perhaps if both hackers and users took some pains to set expectations and investigate codebases in advance (respectively), there'd be less frustration all around. I've been on both sides of this divide.

[1] Yesterday's fuzzy-autocompleter for vim is an example: https://news.ycombinator.com/item?id=5169062. I don't really consider autocomplete to be that useful (mild payoff in small codebases; being laggy 1% of the time negates all benefit), but it still seemed cool enough to be worth trying out. I was self-aware that it might lead to frustration (because it did a good job setting expectations), but to its credit the documentation was excellent.

I agree, it is very important to check whether a given library is maintained and the quality of the code before relying on it. You should also check for how quickly the project is evolving. Using the cutting edge in production means either never upgrading or re-writing your codebase to suite what the library is doing with the new release all the time. For example at my previous company I advocated for using the "boring" Django over Pylons/Pyramid/etc. The latter went through a number of merges and evolution over the time when we enjoyed Django's painstaking attention to reduce backwards incompatible changes.

But back to setting expectations, yes you are right. Perhaps being honest in our README's would be good: "here's a piece of code I used. You might find it useful, but I don't plan on maintaining it;" or "This thing was a one time script. You will have to modify it to use it" a la GitHub's Hubot.

The biggest issues come back some time later, when you start relying on a library, build a business around it, then realize that it has a glaring issue, but the upstream maintainer has disappeared. You can't always anticipate this. For example, I believe the following is still a bug in Python's MySQL driver:

  c.executemany("INSERT INTO breakfast (name, created_on) VALUES (%s, DATE(%s))", list_of_name_dates)

(The issue is that MySQLdb has a regex which matches the first closing parentheses to repeat the parameters.)

The above is an issue that's bitten many people, yet everyone continues using MySQLdb.

As a community, I think we need to do more encouraging people to do "pick up and fix the existing project for thing X" rather than "build a brand new project for thing X."

Right now it's much sexier to do the latter -- hey, you might have the next RubyonRails!

Hasn't it always been much sexier to invent your own thing? I agree, picking up existing projects should be encouraged. The problems with this approach are:

1. The original owner is not there to give you commit access, so you have to fork the project. This means that if the project had some number of users you cannot bring them with you. Imagine if there was a better version of Django out there, made by a group of talented hackers but you never heard about it because GitHub never told you that out of 1,500+ forks of Django one is really pretty awesome and actively developed.

2. The original owner is not there to give you access to distributing the software. This means that even if you create and maintain a fork of the original project, you now have to distribute it under a different name, once again losing popularity to the "standard" version.

Don't get me wrong, I'm not advocating that if a project is abandoned it be given to the next runner up automatically. The above issues also serve as a negative feedback loop preventing all sorts of bad software from cropping up. It just means that large projects like ImageMagick can effectively become zombies. You develop your code against them, then realize they are no good and have to re-write your code against a fork or evolution of that project.

What's worse is when an author abandons their project, when it has active users, AND when it has active problems. Some projects just need a big sign that says, "DO NOT USE."

I learned for myself a few key signs that show when a project is abandoned:

* The author never comments on or closes issues.

* Issues continue to be opened, but users begin to report bugs in more basic functionality as time goes on.

* The author has a Twitter feed or blog (or other source of life signs) which he updates. This provides a signal which shows that the author is actively focusing his efforts elsewhere. A lack of public activity is not a signal, because it leaves room for speculation. Activity elsewhere likely means the author has moved on.

All of these signs taken together indicate that a project is abandoned. Here's an example of such a project: Brian Noguchi's everyauth [1]. There are 163 issues open, and all recent ones have no trace of comments from Brian (sign 1). One of these issues is mine. The example code in the repository is broken, and one of the OAuth modules has a showstopper bug (sign 2)[2]. Brian's Github activity shows he is working on the admittedly more important derby.js project (sign 3)[3].

I am not focusing on Brian because I want to shame him, but everyauth is a good example of an abandoned project, and all of its users should pack up and move on.

[1] https://github.com/bnoguchi/everyauth

[2] https://github.com/bnoguchi/everyauth/pull/367

[3] https://github.com/bnoguchi?tab=activity

If only everybody used http://stillmaintained.com/.

Yep. I think out of all the reports I've done on github, probably between 5-10% have gotten any answer, even if it was, "piss off!"

It may be as easy to ignore a pull request, but at least the pull request is public whereas you have no idea how many emails a project maintainer has ignored. JPlayer, for instance, does have an issue tracker and it has many open pull requests. So it probably isn't worth your time to submit another one.