4 ms·

Another rant about the dangers of software rotting away if it (gasp) hasn't been updated within six months. It appears people are really bad at assessing maturi

Another rant about the dangers of software rotting away if it (gasp) hasn't been updated within six months. It appears people are really bad at assessing maturity of software, so they choose cheap metrics (like # of commits / last commit), rather than examining the actual quality of the code and design. Eventually some smaller open source projects achieve feature-completeness and no longer need any more features. It is healthy for them to declare themselves done. This is distinctly different from maintainer apathy, though the symptoms may be similar.

nslater 13y ago
It is possible to reach feature-completeness. TeX is probably the most well known example of this. It was feature-frozen at 3.0, and the only changes made now are bugfixes. The problem arrises when the things your program depends on go away. For example, if you have a project that is written for Ruby 1.8.7, after June of this year, that version will receive no more updates. If there's some particular feature of 1.8.7 that you depend on, or some bug found, or some security vulnerability discovered, users might eventually find themselves in a spot of bother. The web of dependencies for most projects is bewilderingly complex. The stacks that we write for are moving targets, and unless your software is moving to keep up, eventually there's a good chance that they just wont run any more. This sort of thinking is why the IETF publishes Internet Drafts as ASCII-only text files. They've limited the dependency chain to ASCII, because they are hoping that isn't going away any time soon.
utoku 13y ago
Andrea: Unhappy the project that breeds no coders. Galileo: No, Andrea: Unhappy is the project that needs a coder.
coldtea 13y ago
>Another rant about the dangers of software rotting away if it (gasp) hasn't been updated within six months. It appears people are really bad at assessing maturity of software, so they choose cheap metrics (like # of commits / last commit), rather than examining the actual quality of the code and design. I've found that those shallow metrics, especially "last commit", are quite telling for a project's health. Sure, a small project can achieve "feature-completeness". Still, if it's not being touched at all for over 2 years, I wouldn't want to depend on it. Especially if it also has several year old issues in the bug tracker. The thing is, I have zero guarantees that the maintainer even cares about this project, that it will be updated when something breaks of changes (e.g it needs some fixes to compile on a new OS release) etc. That the project is Open Source and "anybody" could do that theoritically is not much of a guarantee. There are tons of open source projects that languish with no one updating them. Including some I unfortunately had to rely on, but don't have the time/knowledge/etc to jump in and contribute. Case in point, wkhtmltopdf.
benatkin 13y ago
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 :/.)

nslater 13y ago

It is possible to reach feature-completeness. TeX is probably the most well known example of this. It was feature-frozen at 3.0, and the only changes made now are bugfixes. The problem arrises when the things your program depends on go away. For example, if you have a project that is written for Ruby 1.8.7, after June of this year, that version will receive no more updates. If there's some particular feature of 1.8.7 that you depend on, or some bug found, or some security vulnerability discovered, users might eventually find themselves in a spot of bother. The web of dependencies for most projects is bewilderingly complex. The stacks that we write for are moving targets, and unless your software is moving to keep up, eventually there's a good chance that they just wont run any more. This sort of thinking is why the IETF publishes Internet Drafts as ASCII-only text files. They've limited the dependency chain to ASCII, because they are hoping that isn't going away any time soon.

utoku 13y ago

Andrea: Unhappy the project that breeds no coders. Galileo: No, Andrea: Unhappy is the project that needs a coder.

coldtea 13y ago

>Another rant about the dangers of software rotting away if it (gasp) hasn't been updated within six months. It appears people are really bad at assessing maturity of software, so they choose cheap metrics (like # of commits / last commit), rather than examining the actual quality of the code and design. I've found that those shallow metrics, especially "last commit", are quite telling for a project's health. Sure, a small project can achieve "feature-completeness". Still, if it's not being touched at all for over 2 years, I wouldn't want to depend on it. Especially if it also has several year old issues in the bug tracker. The thing is, I have zero guarantees that the maintainer even cares about this project, that it will be updated when something breaks of changes (e.g it needs some fixes to compile on a new OS release) etc. That the project is Open Source and "anybody" could do that theoritically is not much of a guarantee. There are tons of open source projects that languish with no one updating them. Including some I unfortunately had to rely on, but don't have the time/knowledge/etc to jump in and contribute. Case in point, wkhtmltopdf.

benatkin 13y ago

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 :/.)