4 ms·

If you've ever tried to configure ESLint for a preexisting style guide, or to maintain a configuration's consistency across successive ESLint releases, you may

If you've ever tried to configure ESLint for a preexisting style guide, or to maintain a configuration's consistency across successive ESLint releases, you may have some idea what's involved. If not, take a look at the kinds of rules those files are invoking, the extent of change they've undergone across time and language versions, and their interactions. Whether it's a code file or a configuration file doesn't accurately predict complexity. Von Neumann and all that. As for the maintainer, we're friends. He's been involved in JavaScript and Node.js development since very early on. Standard is not by any means his only work, or his only popular work. He's also the only one I'd trust to maintain it right now---technically and design-wise---and I know he has many other demands on his time. He goes out of his way to acknowledge that he's not alone on many projects, but by any measure, Feross has done the vast majority of work on Standard thus far, for the past five years or so. If it took him five days to get v14 out the door, it took five days. I'm not going to go and try to second-guess his hour-by-hour through amateur GitHub forensics. But I'd expect a fair amount of the labor came not just from the code itself, but from issue management, changelog, repo hygiene, and associated joys of maintaining a developer-facing tool with name recognition that's first point of contact for lots of folks who don't contribute in kind. All software, done well, looks easy from the outside. Standard is not the Linux kernel, but it's good software that users interact with constantly. It's been carefully maintained primarily by just one dev for several years. It has been one huge, reliable constant in a language ecosystem with a lot of churn.

Klathmon 7y ago
I completely agree with everything you said. We pay managers salaries even though they often don't write any code, why is management of a widely used OSS project not deserving of funding on its own? I've used standard for years, and I've never once had an issue with breaking changes. They've added features, fixed bugs, and even made changes that fixed issues that I personally raised with the project. It's good software, and even though it looks trivial at a glance it took a LONG time and a lot of effort to get there, and every time I'm working on a project that doesn't use standard I'm quickly reminded of just how many of those edge cases they have handled for me. I'm happy about the parts of this discussion that are about the way they are funding the project (and I don't actually like the specific way funding is being managed for this project), but all of it seems wrapped in dismissive comments about the library itself.

Klathmon 7y ago

I completely agree with everything you said. We pay managers salaries even though they often don't write any code, why is management of a widely used OSS project not deserving of funding on its own? I've used standard for years, and I've never once had an issue with breaking changes. They've added features, fixed bugs, and even made changes that fixed issues that I personally raised with the project. It's good software, and even though it looks trivial at a glance it took a LONG time and a lot of effort to get there, and every time I'm working on a project that doesn't use standard I'm quickly reminded of just how many of those edge cases they have handled for me. I'm happy about the parts of this discussion that are about the way they are funding the project (and I don't actually like the specific way funding is being managed for this project), but all of it seems wrapped in dismissive comments about the library itself.