H Y P E R S P E C I F I C I T Y

Moment

I was messing around with my Obsidian config using the Linter plugin today. This introduced me to Moment.js, the datetime library used by the plugin to maintain and format updated / creation dates by Linter.

Moment is an interesting example of a complete, community-centered software project. It lives, but sans updates. The developers unambiguously dissuade its use unless people have familiarity with the API or dependencies in existing projects. People still seem to use it and the devs plan to keep it in maintenance mode with no new features. It serves a simple, specific purpose, does it well, and doesn't add any bells and whistles.

The other cool thing about Moment is that it treats its datetime objects as mutable types. This design decision is often contested by maintainers and contributors. This blog post by one of the devs offers interesting insight into why Moment was never changed from its original, mutable design. They acknowledge that if they were to make a new datetime library today, they would make objects immutable, but a pivot from what they've already built would add overhead:

We’re actually not concerned about the time it would take to write the code for a new major version of Moment that was immutable. [...] What we are concerned about is having two forks to maintain. From the outside, it’s easy to say ā€œuse SemVer, end of life the other fork, and move onā€. We have too many users for this. The bottom line is that we can make as many ā€˜end of life’ and ā€˜end of support’ announcements about 2.0 as we want, and we can set as many timelines as we please. It won’t change the fact that Moment 2.0 will be in hundreds of thousands of code bases, if not more, for years to come. [...] What this means is that we will still be getting GitHub issues, bug reports, Stack Overflow questions and possibly even pull requests on the 2.0 fork for (potentially) years. And unlike jQuery , we don’t have a foundation backing us to help us have the time to answer these.

The devs pretty directly ask people to use a different library if they need immutability. It's a very pragmatic trade-off, one based in prioritizing stewardship and care for an existing community (and it still gets the job done) over something that's technically superior and modern. A lesson in satisficing in software development.

#link-notes #online-communities #open-source #satisficing #software-development