4 ms·

This post didn't resonate with you, and so you just trash the author's work without offering any real criticism? For shame.

saurik 13y ago
I see a very concrete and specific criticism that both goes to the core of the article it critiques and is backed up by argument. It is harshly worded, but on the other side these kinds of "cheap metrics" lead to situations with high emotions, so I have a difficult time blaming people for reacting strongly to them.
- benatkin 13y ago
  It's only relevant to the title. The article isn't saying that all unmaintained projects suck. The article gives specific reasons why unmaintained projects can't be used anymore, like depending on old versions of programming languages. I suspect that the commenter didn't even read the article, and I wonder if you comprehended it.
  - saurik 13y ago
    The article provides such reasons, but those reasons do not apply to every project. I have been very happily been using software, such as ncurses, that hardly ever sees a new version released, for many many years. > In fact, this is such a big concern for me, that when I am evaluating new software, I judge it on two criteria. Firstly, how actively maintained is it? And secondly, how well does it do what I need? This statement is the core of this article, and it demonstrates a fundamental naiveté regarding the value of software. To try to put this problem succinctly: if you come across software that has an army of people constantly fixing it because for some ungodly reason it keeps breaking you should run for your life, not somehow be content that there is currently an army of people bailing water from a sinking ship. He can thereby provide tons of reasons as to why software that isn't maintained might break, but if he fails to address the assumption that those reasons apply to software or at least demonstrates an understanding that that is the first thing you should be checking for, it doesn't really matter. > I suspect that the commenter didn't even read the article, and I wonder if you comprehended it. (I am pretty certain you are the one being needlessly insulting here, not mattgreenrocks. He provided reasons to back up his points, and now in two posts you've simply asserted that you are correct :/.)
    - benatkin 13y ago
      > The article provides such reasons, but those reasons do not apply to every project. I have been very happily been using software, such as ncurses, that hardly ever sees a new version released, for many many years. The article doesn't say it applies to everything, but if you read the title as a thesis statement and not simply a title, the title implies it. Article titles are short and don't capture everything. > I am pretty certain you are the one being needlessly insulting here, not mattgreenrocks. OK fine, you have more karma on HN than me, so you're right. Are you happy now?
    - nslater 13y ago
      The most important thing I wanted to communicate was that active contributors are very important for a healthy project. And that if you add people to a project, the project stands a chance of outliving your individual contributions to it. If a project required constant fixing because, say, the code was very bad, then yes, I agree that would be a bad sign. But I was primarily thinking of dependency maintenance. I took a look at ncurses to see if I could learn anything about their success. I count 18 contributors in the README file, which is exactly the sort of thing I was thinking about really. Seems like the package has been passed from one maintainer to the next as people's situation changes. This sort of thing is important! If ncurses had met with the same fate as most GitHub repositories, nobody would use it any more. It would be forgotten about. I took a look through the configure.in file too, and it looks like ncurses has very few dependencies beyond requiring a sane build environment. And I see that ncurses releases once every few years, and has been doing since the 90s. Oh, and the mailing list seems alive and well. All in all, ncurses seems to be exactly the sort of healthy project I was thinking of. Regular contributions, shared maintenance, very few dependencies, and a predictable release cadence.

saurik 13y ago

I see a very concrete and specific criticism that both goes to the core of the article it critiques and is backed up by argument. It is harshly worded, but on the other side these kinds of "cheap metrics" lead to situations with high emotions, so I have a difficult time blaming people for reacting strongly to them.

benatkin 13y ago
It's only relevant to the title. The article isn't saying that all unmaintained projects suck. The article gives specific reasons why unmaintained projects can't be used anymore, like depending on old versions of programming languages. I suspect that the commenter didn't even read the article, and I wonder if you comprehended it.
- saurik 13y ago
  The article provides such reasons, but those reasons do not apply to every project. I have been very happily been using software, such as ncurses, that hardly ever sees a new version released, for many many years. > In fact, this is such a big concern for me, that when I am evaluating new software, I judge it on two criteria. Firstly, how actively maintained is it? And secondly, how well does it do what I need? This statement is the core of this article, and it demonstrates a fundamental naiveté regarding the value of software. To try to put this problem succinctly: if you come across software that has an army of people constantly fixing it because for some ungodly reason it keeps breaking you should run for your life, not somehow be content that there is currently an army of people bailing water from a sinking ship. He can thereby provide tons of reasons as to why software that isn't maintained might break, but if he fails to address the assumption that those reasons apply to software or at least demonstrates an understanding that that is the first thing you should be checking for, it doesn't really matter. > I suspect that the commenter didn't even read the article, and I wonder if you comprehended it. (I am pretty certain you are the one being needlessly insulting here, not mattgreenrocks. He provided reasons to back up his points, and now in two posts you've simply asserted that you are correct :/.)
  - benatkin 13y ago
    > The article provides such reasons, but those reasons do not apply to every project. I have been very happily been using software, such as ncurses, that hardly ever sees a new version released, for many many years. The article doesn't say it applies to everything, but if you read the title as a thesis statement and not simply a title, the title implies it. Article titles are short and don't capture everything. > I am pretty certain you are the one being needlessly insulting here, not mattgreenrocks. OK fine, you have more karma on HN than me, so you're right. Are you happy now?
  - nslater 13y ago
    The most important thing I wanted to communicate was that active contributors are very important for a healthy project. And that if you add people to a project, the project stands a chance of outliving your individual contributions to it. If a project required constant fixing because, say, the code was very bad, then yes, I agree that would be a bad sign. But I was primarily thinking of dependency maintenance. I took a look at ncurses to see if I could learn anything about their success. I count 18 contributors in the README file, which is exactly the sort of thing I was thinking about really. Seems like the package has been passed from one maintainer to the next as people's situation changes. This sort of thing is important! If ncurses had met with the same fate as most GitHub repositories, nobody would use it any more. It would be forgotten about. I took a look through the configure.in file too, and it looks like ncurses has very few dependencies beyond requiring a sane build environment. And I see that ncurses releases once every few years, and has been doing since the 90s. Oh, and the mailing list seems alive and well. All in all, ncurses seems to be exactly the sort of healthy project I was thinking of. Regular contributions, shared maintenance, very few dependencies, and a predictable release cadence.