Hacker News new | comments | show | ask | jobs | submit login

I find it irritating when people look at some of my projects on Github and consider then "abandoned" because they haven't had any commits in a year or two. They're not abandoned: they're finished. They do what they're designed to do, and I use them regularly.

Outstanding issues may exist for feature requests that I don't need, or for minor bugs that won't occur in anything but obscure edge cases that don't apply to the primary use case. I welcome high quality patches but otherwise have no interest in pursuing them.




Then at the top of your readme you should absolutely write [[Project feature complete and stable]], or something to that effect.

You just can't look at a repo and discern its completeness in an easy way. Also explain why you think it's complete.


See I never assume a project is abandoned unless there are open issues regarding bugs (or possible bugs) that the owner never commented on. That combined with commits a long time ago is usually a pretty good tell in my opinion.

Simply just not having in a commit in a year isn't a tell but it is concerning; I haven't come across tech stable enough that even very minor commits don't become necessary within even a few months.


If it's anything you expect other people to use, then I'd consider anything that hasn't been updated in the past year "abandoned", yeah.

If it's your personal projects though, I don't make that assumption.


I have several projects that haven't been updated in more than a year which are still maintained in the sense that if there are bugs, I fix them. They are rarely touched for a simple reason: They do what they're meant to, and they still work.

I wish more software took that approach. Far too often software quality drops after a while as developers keep piling on the features.


Abandoned or stable? If it has no dependencies and a small feature set, it may just be done. "Stable" is a good thing.


Let me give a more concrete example: if something was developed in Rails 3 but was not updated for Rails 4, then I assume it won't work (I'm on Rails 4.1).

This doesn't mean the entire project needs to be re-written. Often times, a simple note that says "compatible with Rails 4" would be satisfactory.

But if even the readme is not updated, that makes it difficult for me to put any faith in it. And unfortunately there are tons of projects like that on GitHub.


That's a fine example. It has dependencies, the dependencies change quickly, so the project needs updating.

Let me give a counter-example. PriorityQueue is a data structure implementation published as a Ruby gem in 2005: https://rubygems.org/gems/PriorityQueue/versions/0.1.2. It has not been updated since, because it doesn't need to be. It just works. (It could use better docs, but even that would be a one-time change.)

Similarly, I have a gem that helps build searches with ORMs - https://github.com/nathanl/searchlight. It doesn't directly depend on any ORM, just the "chained method calls to build queries" interface that they implement. That means I don't need to update it when ActiveRecord or Sequel or Mongoid gets a new feature. Which means I commit far less often. I consider it feature complete and only make bug fixes, which should eventually stop.

At that point, it may look abandoned, but it won't be. Just stable. Which I consider a good thing.


The Gemspec should have an upper limit on major Rails versions as a general best-practice.

But yeah, this happens all the time in this space.

Unfortunately, Rails APIs change a lot more than the time-trusted POSIX APIs.


Maybe your README intro should communicate this? Most of us are not accustomed to something on Github being "finished", so a project where there aren't current commits is unsettling.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: