Overall it has gotten much easier to report bugs and submit patches to open source projects, and I give that credit to Github.
It comes down to friction: even if your system is better, it still means I need to learn your system before I can usefully contribute. If you're using a well-known system I'm much more likely to bother contributing back.
There is nothing major in those pull requests/issues, but they are ignored. This project is great for what it does (lets you parse cron schedule input and gives you a datetime of the next execution), but the author seems to have abandoned the project. Now I am left with a difficult choice of using the project as is, or forking it and and making my own changes. If I fork it, I then have to monitor whether the upstream author shows up again and then I have to figure out what to do about his/her changes.
If anything GitHub makes it easier for someone to half-ass a project and then abandon it as it is starting to get popular. Places like SourceForge had some vetting that may or may not have prevented this type of thing. GitHub works well for projects that have lots of contributors, but for a "small library that does X" it becomes a graveyard.
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.
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.
Except friction is exactly what he's talking about. What's wrong with email (besides spam)? Many high profile OSS projects have had email+web bug reporting+tracking systems for ages. No, twitter is not acceptable, and neither is Facebook (nor is web only for that matter). Often times the builtin automatic crash reporter (or OSS bug report tools) will simply send an email or do a POST or PUT to a web server.
Github, while nice, isn't exactly a bug reporting tool either. It's more a "if you have a patch (whether feature request or bugfix), post it and I'll decide whether or not to integrate it." I like how it encourages people to hack on source (just clone, hack, and send a pull request!), but, much as I hate to say it, that doesn't work for everyone.
Especially in the case of JWZ. While it would be fantastic to have him contributing patches, he just doesn't have the time (and chooses not) to do that anymore. The thing about JWZ is, caustic though he may be, he's very often right, and extremely insightful, not a clueless newb. If he files a bug report on a project, it would well behoove the maintainers to take notice.
You really don't want a list of what is wrong with email.
I agree that facebook seems a little silly to use for something like that, but if the author is young then that may be his primary (or only) contact with the world that he regulary checks.
As for web-only? That would be the way I would go, if I had to -- very little spam issue and you can put a captcha on it if it becomes a problem.
But honestly you sound like an whiny complainer in that comment -- people have given you some very useful software for free, do they also owe you a bug reporting tool of your choice?
Git-hub is awesome in that regard, because it enforces 'put-up or shut up', you have to provide a patch if you want to get the issue fixed.
Overall it has gotten much easier to report bugs and submit patches to open source projects, and I give that credit to Github.
The thing is, to most people who aren't geeks, Github sounds like somewhere you want to avoid, where nasty hackers meet to compare notes on their cyberstalking victims or something.
The geek community seems to have an almost comical ability to come up with such terrible names for projects and not even realise it.
(And I write that while posting on another site that sounds like somewhere nasty hackers would meet to discuss writing viruses or something.)
I think it's very telling that many of the comments in this discussion speak positively about OSS because you can fix things yourself or there's an open system for submitting patches. I wonder whether the people posting those comments have even considered that the overwhelming majority of people using big name OSS software like Firefox or LibreOffice today aren't programmers and aren't going to report bugs like a programmer.
I think github has made it worse.. its great if the project has gotten started there, but when they move from another tool, like SourceForge, most of the time, they don't bother to shut down the old one, or say "hey, this site was moved to here->".
I have seen several projects where both SF and github host files for a project, and are both kept up to date (as a way to offload the downloading of the project, I guess) but tons of unanswered questions in both projects trackers..
look at the open source project for zenoss.. they host their own bug tracker, (makes sense, its a commercial company with an open source product) but they don't put any notice about it on sourceforge or github where different files/code are located. (and the sourceforge one is full of spam).
It comes down to friction: even if your system is better, it still means I need to learn your system before I can usefully contribute. If you're using a well-known system I'm much more likely to bother contributing back.