11 ms·

Good for them. Open Source seems to have an irrational fear of done. Done is good. Done should be the goal. But it’s not. Because if you’re not adding new fea

Good for them. Open Source seems to have an irrational fear of done. Done is good. Done should be the goal. But it’s not. Because if you’re not adding new features and pushing code changes every day, your project is abandoned, dead. To quote another thread from two minutes ago: “I’m quite sad to see the end of Moment.js” I wish the was a way to fix this attitude. So that project maintainers didn’t need to write two page apologies for finishing their thing.

trevyn 6y ago
I have no problem with a project being considered "complete", but the post also says "we would like to discourage Moment from being used in new projects going forward", which sounds more like "dead & done". :)
- jimbob45 6y ago
  I think parent poster’s point was that dead should be considered done in this case instead of adding on more and more features and insisting on backwards compatibility until it ends up looking like modern C++. Dead isn’t necessarily bad.
judofyr 6y ago
> But it’s not. Because if you’re not adding new features and pushing code changes every day, your project is abandoned, dead. To quote another thread from two minutes ago: “I’m quite sad to see the end of Moment.js” In this case, the reason why Moment.js is "dead" and not "done" is because it has fundamental flaws in its design: Mutable objects + huge bundle size which doesn't work well with tree-shaking.
- wvenable 6y ago
  If you fundamentally and incompatibly change it's design then it's an entirely new product. Calling that "Moment Version 3" doesn't mean anything.
  - wruza 6y ago
    Ha-ha, oh dear. From your lips to gulp's (and other "bump major at tuesday" projects) ears.
  - manquer 6y ago
    Brand value is huge. I would trust moment 3 lot more than project I never heard of . I would trust a new projects by core authors of moment almost as much too.[1] Trust is major factor when depending on third party libraries especially in the JS ecosystem. [1] reason libre office or deno gains traction
- throwaway189262 6y ago
  Huge bundle sizes and mutability are JS design flaws. Until very recently it was impossible to make objects immutable in JS. Even now its really only done using third party libraries. Huge bundle size is only a problem because tree shaking is done on a "module" level. Most languages are static enough that it's called dead code elimination and doesn't need to use tree pruning. You can tell statically that the code is not used. Moment isn't compatible with modern workarounds which I don't blame it for. The way JS is, immutability and true dead code elimination will probably show up as built in features in a few years and make all this obsolete again
  - kqr 6y ago
    > Until very recently it was impossible to make objects immutable in JS. Even now its really only done using third party libraries. There's a big difference between "literally impossible to mutate" (only important in the most security-critical contexts) and "designed around immutability as the default" (which is what is desired in most of the real world.) The former not being possible is not a reason to exclude the latter.
    - throwaway189262 6y ago
      With JS, until recently, it was nearly impossible to design immutable API's. Everything takes JSON based objects which have no field accessors. All the objects underneath are just hashmaps with string keys. When all your objects are hashmaps you can't really make fields immutable. Even if you wrote getters, someone can just reassign the function reference. Even if you check your fields in incoming object parameters, somebody can randomly add more fields that you don't know about. Until recently you couldn't stop people from randomly adding fields to your objects Nowadays JS supports stuff like freeze thaw which makes it easier
      - Ndymium 6y ago
        Object.freeze() has been available since IE 9, Firefox 4, Chrome 6 etc. Not really "recently" in web terms.
      - 6y ago
- alexbanks 6y ago
  Just because you disagree with a design decision doesn't change the done/dead debate. It's done, because its maintainers have agreed the project has gone as far as it needs to go, and its current iteration is stable. You (as always) can choose not to use a project you do not agree with; that has no bearing on the project's status.
  - judofyr 6y ago
    This isn’t me disagreeing with the design decision, this was their own explanation for why you shouldn’t use Moment.js in the future. My point was that the reason we’re transitioning away from it is because of technical reason, not because it’s not being updated.
    - kristopolous 6y ago
      I'd been complaining about these issues for years. I kinda hate being vindicated years later, the time in between as an outsider kinda frustrates me. I wish we had a more thoughtful, less packrat culture in programming. Fighting off the pushback is exhausting. It's not even worth bringing things up most of the time. And as a disclaimer to those feeling tempted, I've got zero interest in debating this reality, water is wet.
      - eevilspock 6y ago
        It's the same in all human culture and politics. Every era's mainstream ridicules and dismisses those who criticize it as "extremists". But some of those extremists will one day be vindicated as being on the right side of history long before everyone else came around, and we will look back at that prior mainstream attitude and ask, "How could they be so blind?" The important thing to keep in mind that we don't know which of today's counter-culture takes will end up winning (I don't say "being right" because cultural evolution is, like biological evolution, not teleological). In other words, you had a belief, and in hindsight you were "vindicated". But there were many others who had equally strong beliefs that were not.
      - ufmace 6y ago
tmpz22 6y ago
MomentJS may be an exception but any JavaScript project with a large number of node_modules or testing/distribution pipelines pinned to build systems like gulp or webpack are highly likely to break from year to year as they become incompatible with a version of node or one of the dependencies is taken over by a potentially malicious actor. For this reason any JavaScript ecosystem based project must receive increased scrutiny for this type of stuff. Now give me a golang library that hasn’t been touched in four years and it would be a completely different situation (knock on wood go2 doesn’t ruin this).
- sammorrowdrums 6y ago
  A significant issue though is that timezones change. For example the EU is ditching daylight savings time in 2021[1]. So actually there are many libraries and tools that could be done and just work forever, timezone stuff is much more dynamic than I'd ever realised. FWIW I loved moment and made the move this year to date-fns[2] as I trusted browser availablity of the prerequisites enough to finally switch, and I do like working with it, but its focus on lightweight makes it less "magic" than Moment. - [1] https://www.insider.com/europe-to-get-rid-of-daylight-saving-time-2019-3 https://www.insider.com/europe-to-get-rid-of-daylight-saving... - [2] https://date-fns.org/ https://date-fns.org/ (edit formatting)
  - TJSomething 6y ago
    The article specifically states that they're going to keep Moment-Timezone up to date. Which is important, because the timezone database has changed approximately 4 times a year for the last 5 years (https://mm.icann.org/pipermail/tz-announce/ https://mm.icann.org/pipermail/tz-announce/).
    - sammorrowdrums 6y ago
      Let's just hope no random country decides to use 100 minutes an hour or something one day.
      - 6y ago
xmprt 6y ago
To some extent I don't think this means moment is dead although I don't assume a lot of new developers will be choosing it for their projects. Even starting a few years back I replaced it with Luxon and haven't looked back.
abrookewood 6y ago
I also appreciate that they clearly covered: (i) why you shouldn't use this going forward; (ii) why you might continue to anyway; and (ii) what the alternatives are. All in all, a very well handled response.
nikitaga 6y ago
Is this really what a "done" software is? "Should not be used for new projects" is not "done" imo, it's more like "unfixable" and "obsolete". No prejudice at all against Moment.js or its devs, but this is essentially what they're saying. And the purpose and tone of the article does not seem to be an apology at all, but rather simply setting the expectations for future work so that the maintainers don't have to answer the same questions over and over. Overall, good to see honest documentation of project status.
- Klonoar 6y ago
  ...but there's nothing to "fix", it works as intended. You might want to do things differently nowadays, is all - that's not on Moment. Re: "obsolete"... jQuery is somewhere laughing, having gone through this already.
  - nikitaga 6y ago
    > ...but there's nothing to "fix", it works as intended If there were nothing to fix, they wouldn't be telling people not to start new projects with Moment. They actually do mention a few significant issues that they can't / won't fix in Moment such as bundle size and mutability. I will concede that perhaps Moment was "done" at some point before, some years back. When it was quite complete, yet was still the best way to do reliably work with timezoned dates in JS. But as Intl support improved, and better designed alternatives grew, it got rather obsolete, and will get more obsolete over time. jQuery for comparison, while largely obsolete for rich web app development, is still very relevant to ecommerce, website-development-for-hire and other niches, and it will probably stay that way for a long time because it's the right design for those problems. Moment isn't the right design for any problem anymore, unless, as the article says, you need to support old browsers.
    - remus 6y ago
      I think it's worth making the distinction between "nothing to fix" and "nothing to fix in moment.js". Clearly the problem they're trying to solve is still a real one, and there ARE problems with moment, but the cost of breaking backwards compatibility in moment to fix those problems isn't worth it because the new API would be so dissimilar to the current API it would only confuse users.
jwr 6y ago
I was about to write the same thing. I like "done". The best libraries are the ones in maintenance mode, with long-term stability goals. The worst libraries are ones where the author(s) do a Major Rewrite every year or two. There is a widespread meme/trope about something being "dead". Whenever I hear someone saying that a language/library is "dead", I make a point of checking that person's credentials. It almost always turns out that these are not people who write big applications or well-known libraries, but rather ambulance chasers — constantly looking for the next shiny thing.
- manquer 6y ago
  That would be fine if they didn't recommend not to use it for new projects.
thayne 6y ago
Not adding new features might mean the project is "done" but not fixing bugs is an indication it is abandoned, and I have yet to find useful software that doesn't have bugs. And note that moment.js will continue to get bugfixes, just not new features.
bartread 6y ago
> I wish the was a way to fix this attitude. So that project maintainers didn’t need to write two page apologies for finishing their thing. One of the problems is that GitHub is full of OSS libraries where the last commit was three years or more ago and you have no idea (without forensically analysing commits, issues, etc.) whether it's because the project is done or because the maintainer(s) lost interest, had other priorities, etc. And you have no idea because they haven't said. They haven't told anyone: it's just drifted into an unclear state of unmaintained-ness. I would suggest rather that what the Moment.js team have done here should be the norm: i.e., clear communication of the situation. That situation, as here, might be "done", or it might be "the thing's only half finished but we don't care enough to carry on any more", or something completely different. These are all good reasons to stop working on something even if they're potentially frustrating for users. E.g., in the "don't care" scenario, people have the option to step in and pick up maintenance, fork the project, or simply not use it. Doesn't matter: understanding the state of a potential dependency in terms of maintenance and development is the key factor that will enable people to make an informed decision about whether to use it or not.
- tutfbhuf 6y ago
  > One of the problems is that GitHub is full of OSS libraries where the last commit was three years or more ago and you have no idea (without forensically analysing commits, issues, etc.) whether it's because the project is done or because the maintainer(s) lost interest, had other priorities, etc. I don't think there's any at least medium sized project that is considered to be done but not abandoned/legacy and does not receive any commits. Any non-trivial project that has no commit since the last three years is abandoned. Even in the case a project is considered to be done/finished, in order to not abandon it you have to maintain it: fix security issues, update outdated dependencies, update tooling so that you can still run/compile with non outdated tools and so on.
  - detaro 6y ago
    That really depends on what the project is I think (and I guess what you consider non-trivial). I can easily see e.g. a numerical library not really needing maintenance of that sort.
paxys 6y ago
That's a weird way to think about software. Every released version of every product is already "done". Once you take a dependency there is no obligation to keep updating it, no matter what features the maintainers may add to future versions. In this case, considering the creators are discouraging people from using the package and explicitly saying there won't be future bug fixes, TZ/locale updates etc., it is pretty clear that done really means deprecated.
truthwhisperer 6y ago
I believe this project was done when they posted the black lives matter banner. If you have time for this it means the bigger issues have been solved. Let's take a moment to celebrate this project! Time flies, time matters
uCantCauseUCant 6y ago
Code is a living thing- as is the ecosystem around it. Once its done- and the golemn-creator moves on, the project freezes in time, and over time breaks down. maintenance is keeping the easy to fix fractures from happening, but even then.. If there is no human nearby - then old code is broken.
mhd 6y ago
> Open Source seems to have an irrational fear of done. Older open source was more okay with this, but it's a huge issue with the modern JS/github model, where quality is measured by recent updates, "stars" within the last month etc.
ssdspoimdsjvv 6y ago
Is software ever really done, as long as it's not perfect (and perfection does not exist)? In fact, even Moment.js is not done. They say they will keep releasing security fixes and time zone updates. What if at some point they decide they won't even do that? I am wary to use software that is not maintained, because bugs won't get fixed, and new requirements that will eventually arise won't get taken up. And usually at that point a competitor rises up and releases a better product.
meigwilym 6y ago
I completely agree. It takes a lot of guts to make this kind of announcement. When faced with younger, faster competitors, it's natural to try and fight your corner. This is rarely good for a software project. The devs have put their hands up and called it off. They can move on to more exciting projects. The rest of us can make better decisions now that the thinking behind this decision is out in the open. Congrats, moment.js, on a great project!
lcamach84 6y ago
Not only programmers, many of us tend to look at progress as an end in itself. Progress is the process of measuring if we achieve the objectives, it can not be the objective. Many times we do not achieve 100% of the objectives and that is fine, we need to consider the law of diminishing returns.
z3t4 6y ago
You don't have to rewrite all software every 3 years. After 5 years without any major changes the software is stable, it has been battle tested, all issues and quirks are well known, features and designs has been discussed. It's now time for the software to pay off the development cost. And for a project like this - it's probably saves millions of man-hours every year, time that can be used for other things.
mfru 6y ago
It would seem to be quite easy to do something like: https://img.shields.io/badge/Maintenance-Legacy-success https://img.shields.io/badge/Maintenance-Legacy-success or https://img.shields.io/badge/Maintenance https://img.shields.io/badge/Maintenance Level-Done-success and have that as a convention. Additionally to being easy to implement, it is literally a 3 second task for maintainers to add something like this into their Readme.
- mrw34 6y ago
  https://www.repostatus.org https://www.repostatus.org is a similar idea
jrochkind1 6y ago
"Done" as a goal would maybe mean "mature", "polished", "complete". But in this case they also say they don't actually recommend Moment.js for new new projects, generally. "we would like to discourage Moment from being used in new projects going forward." In this case "done" also basically means "obsolete", "newer better alternatives exist". That doesn't seem to be the kind of "finished" that you are talking about, or that would be a goal of developers. Or is it? Examples of open source projects which are very popular, mature, not obsolete, still recommended by their maintainers for new projects -- but also "done" -- might be closer to what you are trying to compliment. They are definitely few and far between.
- tyingq 6y ago
  They seem to not recommend it solely because it doesn't support immutability or tree shaking.
  - jrochkind1 6y ago
    Another important reason mentioned is that it includes heavy-weight internationalization locale files that are not needed in recent browsers -- "for the size alone." I don't know at what point the adjective "solely" stops being appropriate. Those who have been developing it for years and are most familiar with it, and the alternatives, discourage it's use in new projects, although also outline the exceptions that in their opinion make it reasonable to keep using it. You are going to take a stand to disagree with them, based on superior understanding?
    - tyingq 6y ago
      "You are going to take a stand to disagree with them, based on superior understanding?" Uh, no. I read their list and the two things I cited (from their stated reasons) seemed to be the key drivers.
PaulStatezny 6y ago
> I wish the[re] was a way to fix this attitude. This isn't a universal attitude. Numerous language ecosystems exist where it's completely normal to use dependencies that haven't been updated in a while _because_ they warrant no change. This is a problem with the general attitude of the community of JavaScript developers. And they're too stuck in their JS ecosystem bubble to realize this isn't necessarily "normal" or "the way things should/have to be."
- michaelanckaert 6y ago
  I agree and unfortunately that attitude is spreading beyond the JS community. A great example is the issue newcomers to Common Lisp face. I don't want to get in specifics regarding the Lisp community here but one common complaint is that only "old libraries" are available and no recent releases. Side note: Although I'm not sure it initially started in the JS community, it is by far the most affected community. Besides that issue it also suffers from Not Invented Here syndrome.
duxup 6y ago
> So that project maintainers didn’t need to write two page apologies They don't need to write me an apology, but just a notice like this one is very nice so I can be sure what is up.
hn_throwaway_99 6y ago
I disagree. Software can go into 'maintenance mode', that's fine, but there is otherwise no difference between done, abandoned and dead. For a real example, look at lodash. You could easily argue it's 'done' and that it has better alternatives now, but look what happened: a security bug was discovered, the original author pretty much abandoned it, and it took about a week to figure out how to get a working build while meanwhile many thousands of other projects were failing due to npm audit checks. The fact is even if nothing really needs to change in your project, the ecosystem around it can change requiring updates to your code. It's fine to say "This project needs no new features and is in maintenance mode", but otherwise, if you're not willing to deploy new releases, "done", "dead" and "abandoned" all mean exactly the same thing.
momokoko 6y ago
The issue is that this model of opensource is different than the Linux distribution model of opensource. In the Linux distribution model, Debian, Red Hat, etc maintain older libraries in maintenance mode. Patching them for security or other less glamorous fixes and adjustments. In the Github, NPM model of opensource, the original author also controls the default means of distribution. There is not 3rd party like Debian in the middle to maintain it when the original authors leave. So many thousands of projects will still point to an abandoned distribution channel as opposed to simply an abandoned project. There are likely solutions, and this is not to say that the second model is better or worse. It is only to describe that it is not as simple as a project being considered "done".
notatoad 6y ago
>I wish the was a way to fix this attitude. I think the best way to fix this attitude is to have more examples of "done but not dead" projects in the wild. You can't blame people for assuming they're the same thing when in most cases they are.
rocho 6y ago
As Ajahn Brahm says: "What's done is finished!"
xwdv 6y ago
Done is fine. But Done is the first step to Dead. Times change, and when open source software doesn't change with the times it becomes vulnerable for some newer, shinier, more intuitive thing to pop up and take over. Software simply isn't going to reach some "Done" state and then have people using it for 100 years with no changes. Pretty soon, no one uses the project that is "Done" anymore, because it's old and does things the old ways, and not long after that, it's "Dead". Time to die.

trevyn 6y ago

I have no problem with a project being considered "complete", but the post also says "we would like to discourage Moment from being used in new projects going forward", which sounds more like "dead & done". :)

jimbob45 6y ago
I think parent poster’s point was that dead should be considered done in this case instead of adding on more and more features and insisting on backwards compatibility until it ends up looking like modern C++. Dead isn’t necessarily bad.

judofyr 6y ago

> But it’s not. Because if you’re not adding new features and pushing code changes every day, your project is abandoned, dead. To quote another thread from two minutes ago: “I’m quite sad to see the end of Moment.js” In this case, the reason why Moment.js is "dead" and not "done" is because it has fundamental flaws in its design: Mutable objects + huge bundle size which doesn't work well with tree-shaking.

wvenable 6y ago
If you fundamentally and incompatibly change it's design then it's an entirely new product. Calling that "Moment Version 3" doesn't mean anything.
- wruza 6y ago
  Ha-ha, oh dear. From your lips to gulp's (and other "bump major at tuesday" projects) ears.
- manquer 6y ago
  Brand value is huge. I would trust moment 3 lot more than project I never heard of . I would trust a new projects by core authors of moment almost as much too.[1] Trust is major factor when depending on third party libraries especially in the JS ecosystem. [1] reason libre office or deno gains traction
throwaway189262 6y ago
Huge bundle sizes and mutability are JS design flaws. Until very recently it was impossible to make objects immutable in JS. Even now its really only done using third party libraries. Huge bundle size is only a problem because tree shaking is done on a "module" level. Most languages are static enough that it's called dead code elimination and doesn't need to use tree pruning. You can tell statically that the code is not used. Moment isn't compatible with modern workarounds which I don't blame it for. The way JS is, immutability and true dead code elimination will probably show up as built in features in a few years and make all this obsolete again
- kqr 6y ago
  > Until very recently it was impossible to make objects immutable in JS. Even now its really only done using third party libraries. There's a big difference between "literally impossible to mutate" (only important in the most security-critical contexts) and "designed around immutability as the default" (which is what is desired in most of the real world.) The former not being possible is not a reason to exclude the latter.
  - throwaway189262 6y ago
    With JS, until recently, it was nearly impossible to design immutable API's. Everything takes JSON based objects which have no field accessors. All the objects underneath are just hashmaps with string keys. When all your objects are hashmaps you can't really make fields immutable. Even if you wrote getters, someone can just reassign the function reference. Even if you check your fields in incoming object parameters, somebody can randomly add more fields that you don't know about. Until recently you couldn't stop people from randomly adding fields to your objects Nowadays JS supports stuff like freeze thaw which makes it easier
    - Ndymium 6y ago
      Object.freeze() has been available since IE 9, Firefox 4, Chrome 6 etc. Not really "recently" in web terms.
    - 6y ago
alexbanks 6y ago
Just because you disagree with a design decision doesn't change the done/dead debate. It's done, because its maintainers have agreed the project has gone as far as it needs to go, and its current iteration is stable. You (as always) can choose not to use a project you do not agree with; that has no bearing on the project's status.
- judofyr 6y ago
  This isn’t me disagreeing with the design decision, this was their own explanation for why you shouldn’t use Moment.js in the future. My point was that the reason we’re transitioning away from it is because of technical reason, not because it’s not being updated.
  - kristopolous 6y ago
    I'd been complaining about these issues for years. I kinda hate being vindicated years later, the time in between as an outsider kinda frustrates me. I wish we had a more thoughtful, less packrat culture in programming. Fighting off the pushback is exhausting. It's not even worth bringing things up most of the time. And as a disclaimer to those feeling tempted, I've got zero interest in debating this reality, water is wet.
    - eevilspock 6y ago
      It's the same in all human culture and politics. Every era's mainstream ridicules and dismisses those who criticize it as "extremists". But some of those extremists will one day be vindicated as being on the right side of history long before everyone else came around, and we will look back at that prior mainstream attitude and ask, "How could they be so blind?" The important thing to keep in mind that we don't know which of today's counter-culture takes will end up winning (I don't say "being right" because cultural evolution is, like biological evolution, not teleological). In other words, you had a belief, and in hindsight you were "vindicated". But there were many others who had equally strong beliefs that were not.
    - ufmace 6y ago

tmpz22 6y ago

MomentJS may be an exception but any JavaScript project with a large number of node_modules or testing/distribution pipelines pinned to build systems like gulp or webpack are highly likely to break from year to year as they become incompatible with a version of node or one of the dependencies is taken over by a potentially malicious actor. For this reason any JavaScript ecosystem based project must receive increased scrutiny for this type of stuff. Now give me a golang library that hasn’t been touched in four years and it would be a completely different situation (knock on wood go2 doesn’t ruin this).

sammorrowdrums 6y ago
A significant issue though is that timezones change. For example the EU is ditching daylight savings time in 2021[1]. So actually there are many libraries and tools that could be done and just work forever, timezone stuff is much more dynamic than I'd ever realised. FWIW I loved moment and made the move this year to date-fns[2] as I trusted browser availablity of the prerequisites enough to finally switch, and I do like working with it, but its focus on lightweight makes it less "magic" than Moment. - [1] https://www.insider.com/europe-to-get-rid-of-daylight-saving-time-2019-3 https://www.insider.com/europe-to-get-rid-of-daylight-saving... - [2] https://date-fns.org/ https://date-fns.org/ (edit formatting)
- TJSomething 6y ago
  The article specifically states that they're going to keep Moment-Timezone up to date. Which is important, because the timezone database has changed approximately 4 times a year for the last 5 years (https://mm.icann.org/pipermail/tz-announce/ https://mm.icann.org/pipermail/tz-announce/).
  - sammorrowdrums 6y ago
    Let's just hope no random country decides to use 100 minutes an hour or something one day.
    - 6y ago

xmprt 6y ago

To some extent I don't think this means moment is dead although I don't assume a lot of new developers will be choosing it for their projects. Even starting a few years back I replaced it with Luxon and haven't looked back.

abrookewood 6y ago

I also appreciate that they clearly covered: (i) why you shouldn't use this going forward; (ii) why you might continue to anyway; and (ii) what the alternatives are. All in all, a very well handled response.

nikitaga 6y ago

Is this really what a "done" software is? "Should not be used for new projects" is not "done" imo, it's more like "unfixable" and "obsolete". No prejudice at all against Moment.js or its devs, but this is essentially what they're saying. And the purpose and tone of the article does not seem to be an apology at all, but rather simply setting the expectations for future work so that the maintainers don't have to answer the same questions over and over. Overall, good to see honest documentation of project status.

Klonoar 6y ago
...but there's nothing to "fix", it works as intended. You might want to do things differently nowadays, is all - that's not on Moment. Re: "obsolete"... jQuery is somewhere laughing, having gone through this already.
- nikitaga 6y ago
  > ...but there's nothing to "fix", it works as intended If there were nothing to fix, they wouldn't be telling people not to start new projects with Moment. They actually do mention a few significant issues that they can't / won't fix in Moment such as bundle size and mutability. I will concede that perhaps Moment was "done" at some point before, some years back. When it was quite complete, yet was still the best way to do reliably work with timezoned dates in JS. But as Intl support improved, and better designed alternatives grew, it got rather obsolete, and will get more obsolete over time. jQuery for comparison, while largely obsolete for rich web app development, is still very relevant to ecommerce, website-development-for-hire and other niches, and it will probably stay that way for a long time because it's the right design for those problems. Moment isn't the right design for any problem anymore, unless, as the article says, you need to support old browsers.
  - remus 6y ago
    I think it's worth making the distinction between "nothing to fix" and "nothing to fix in moment.js". Clearly the problem they're trying to solve is still a real one, and there ARE problems with moment, but the cost of breaking backwards compatibility in moment to fix those problems isn't worth it because the new API would be so dissimilar to the current API it would only confuse users.

jwr 6y ago

I was about to write the same thing. I like "done". The best libraries are the ones in maintenance mode, with long-term stability goals. The worst libraries are ones where the author(s) do a Major Rewrite every year or two. There is a widespread meme/trope about something being "dead". Whenever I hear someone saying that a language/library is "dead", I make a point of checking that person's credentials. It almost always turns out that these are not people who write big applications or well-known libraries, but rather ambulance chasers — constantly looking for the next shiny thing.

manquer 6y ago
That would be fine if they didn't recommend not to use it for new projects.

thayne 6y ago

Not adding new features might mean the project is "done" but not fixing bugs is an indication it is abandoned, and I have yet to find useful software that doesn't have bugs. And note that moment.js will continue to get bugfixes, just not new features.

bartread 6y ago

> I wish the was a way to fix this attitude. So that project maintainers didn’t need to write two page apologies for finishing their thing. One of the problems is that GitHub is full of OSS libraries where the last commit was three years or more ago and you have no idea (without forensically analysing commits, issues, etc.) whether it's because the project is done or because the maintainer(s) lost interest, had other priorities, etc. And you have no idea because they haven't said. They haven't told anyone: it's just drifted into an unclear state of unmaintained-ness. I would suggest rather that what the Moment.js team have done here should be the norm: i.e., clear communication of the situation. That situation, as here, might be "done", or it might be "the thing's only half finished but we don't care enough to carry on any more", or something completely different. These are all good reasons to stop working on something even if they're potentially frustrating for users. E.g., in the "don't care" scenario, people have the option to step in and pick up maintenance, fork the project, or simply not use it. Doesn't matter: understanding the state of a potential dependency in terms of maintenance and development is the key factor that will enable people to make an informed decision about whether to use it or not.

tutfbhuf 6y ago
> One of the problems is that GitHub is full of OSS libraries where the last commit was three years or more ago and you have no idea (without forensically analysing commits, issues, etc.) whether it's because the project is done or because the maintainer(s) lost interest, had other priorities, etc. I don't think there's any at least medium sized project that is considered to be done but not abandoned/legacy and does not receive any commits. Any non-trivial project that has no commit since the last three years is abandoned. Even in the case a project is considered to be done/finished, in order to not abandon it you have to maintain it: fix security issues, update outdated dependencies, update tooling so that you can still run/compile with non outdated tools and so on.
- detaro 6y ago
  That really depends on what the project is I think (and I guess what you consider non-trivial). I can easily see e.g. a numerical library not really needing maintenance of that sort.

paxys 6y ago

That's a weird way to think about software. Every released version of every product is already "done". Once you take a dependency there is no obligation to keep updating it, no matter what features the maintainers may add to future versions. In this case, considering the creators are discouraging people from using the package and explicitly saying there won't be future bug fixes, TZ/locale updates etc., it is pretty clear that done really means deprecated.

truthwhisperer 6y ago

I believe this project was done when they posted the black lives matter banner. If you have time for this it means the bigger issues have been solved. Let's take a moment to celebrate this project! Time flies, time matters

uCantCauseUCant 6y ago

Code is a living thing- as is the ecosystem around it. Once its done- and the golemn-creator moves on, the project freezes in time, and over time breaks down. maintenance is keeping the easy to fix fractures from happening, but even then.. If there is no human nearby - then old code is broken.

mhd 6y ago

> Open Source seems to have an irrational fear of done. Older open source was more okay with this, but it's a huge issue with the modern JS/github model, where quality is measured by recent updates, "stars" within the last month etc.

ssdspoimdsjvv 6y ago

Is software ever really done, as long as it's not perfect (and perfection does not exist)? In fact, even Moment.js is not done. They say they will keep releasing security fixes and time zone updates. What if at some point they decide they won't even do that? I am wary to use software that is not maintained, because bugs won't get fixed, and new requirements that will eventually arise won't get taken up. And usually at that point a competitor rises up and releases a better product.

meigwilym 6y ago

I completely agree. It takes a lot of guts to make this kind of announcement. When faced with younger, faster competitors, it's natural to try and fight your corner. This is rarely good for a software project. The devs have put their hands up and called it off. They can move on to more exciting projects. The rest of us can make better decisions now that the thinking behind this decision is out in the open. Congrats, moment.js, on a great project!

lcamach84 6y ago

Not only programmers, many of us tend to look at progress as an end in itself. Progress is the process of measuring if we achieve the objectives, it can not be the objective. Many times we do not achieve 100% of the objectives and that is fine, we need to consider the law of diminishing returns.

z3t4 6y ago

You don't have to rewrite all software every 3 years. After 5 years without any major changes the software is stable, it has been battle tested, all issues and quirks are well known, features and designs has been discussed. It's now time for the software to pay off the development cost. And for a project like this - it's probably saves millions of man-hours every year, time that can be used for other things.

mfru 6y ago

It would seem to be quite easy to do something like: https://img.shields.io/badge/Maintenance-Legacy-success https://img.shields.io/badge/Maintenance-Legacy-success or https://img.shields.io/badge/Maintenance https://img.shields.io/badge/Maintenance Level-Done-success and have that as a convention. Additionally to being easy to implement, it is literally a 3 second task for maintainers to add something like this into their Readme.

mrw34 6y ago
https://www.repostatus.org https://www.repostatus.org is a similar idea

jrochkind1 6y ago

"Done" as a goal would maybe mean "mature", "polished", "complete". But in this case they also say they don't actually recommend Moment.js for new new projects, generally. "we would like to discourage Moment from being used in new projects going forward." In this case "done" also basically means "obsolete", "newer better alternatives exist". That doesn't seem to be the kind of "finished" that you are talking about, or that would be a goal of developers. Or is it? Examples of open source projects which are very popular, mature, not obsolete, still recommended by their maintainers for new projects -- but also "done" -- might be closer to what you are trying to compliment. They are definitely few and far between.

tyingq 6y ago
They seem to not recommend it solely because it doesn't support immutability or tree shaking.
- jrochkind1 6y ago
  Another important reason mentioned is that it includes heavy-weight internationalization locale files that are not needed in recent browsers -- "for the size alone." I don't know at what point the adjective "solely" stops being appropriate. Those who have been developing it for years and are most familiar with it, and the alternatives, discourage it's use in new projects, although also outline the exceptions that in their opinion make it reasonable to keep using it. You are going to take a stand to disagree with them, based on superior understanding?
  - tyingq 6y ago
    "You are going to take a stand to disagree with them, based on superior understanding?" Uh, no. I read their list and the two things I cited (from their stated reasons) seemed to be the key drivers.

PaulStatezny 6y ago

> I wish the[re] was a way to fix this attitude. This isn't a universal attitude. Numerous language ecosystems exist where it's completely normal to use dependencies that haven't been updated in a while _because_ they warrant no change. This is a problem with the general attitude of the community of JavaScript developers. And they're too stuck in their JS ecosystem bubble to realize this isn't necessarily "normal" or "the way things should/have to be."

michaelanckaert 6y ago
I agree and unfortunately that attitude is spreading beyond the JS community. A great example is the issue newcomers to Common Lisp face. I don't want to get in specifics regarding the Lisp community here but one common complaint is that only "old libraries" are available and no recent releases. Side note: Although I'm not sure it initially started in the JS community, it is by far the most affected community. Besides that issue it also suffers from Not Invented Here syndrome.

duxup 6y ago

> So that project maintainers didn’t need to write two page apologies They don't need to write me an apology, but just a notice like this one is very nice so I can be sure what is up.

hn_throwaway_99 6y ago

I disagree. Software can go into 'maintenance mode', that's fine, but there is otherwise no difference between done, abandoned and dead. For a real example, look at lodash. You could easily argue it's 'done' and that it has better alternatives now, but look what happened: a security bug was discovered, the original author pretty much abandoned it, and it took about a week to figure out how to get a working build while meanwhile many thousands of other projects were failing due to npm audit checks. The fact is even if nothing really needs to change in your project, the ecosystem around it can change requiring updates to your code. It's fine to say "This project needs no new features and is in maintenance mode", but otherwise, if you're not willing to deploy new releases, "done", "dead" and "abandoned" all mean exactly the same thing.

momokoko 6y ago

The issue is that this model of opensource is different than the Linux distribution model of opensource. In the Linux distribution model, Debian, Red Hat, etc maintain older libraries in maintenance mode. Patching them for security or other less glamorous fixes and adjustments. In the Github, NPM model of opensource, the original author also controls the default means of distribution. There is not 3rd party like Debian in the middle to maintain it when the original authors leave. So many thousands of projects will still point to an abandoned distribution channel as opposed to simply an abandoned project. There are likely solutions, and this is not to say that the second model is better or worse. It is only to describe that it is not as simple as a project being considered "done".

notatoad 6y ago

>I wish the was a way to fix this attitude. I think the best way to fix this attitude is to have more examples of "done but not dead" projects in the wild. You can't blame people for assuming they're the same thing when in most cases they are.

rocho 6y ago

As Ajahn Brahm says: "What's done is finished!"

xwdv 6y ago

Done is fine. But Done is the first step to Dead. Times change, and when open source software doesn't change with the times it becomes vulnerable for some newer, shinier, more intuitive thing to pop up and take over. Software simply isn't going to reach some "Done" state and then have people using it for 100 years with no changes. Pretty soon, no one uses the project that is "Done" anymore, because it's old and does things the old ways, and not long after that, it's "Dead". Time to die.