Burn It All Down: The Open-Source Communities Unholy Hypocrisy

"Furious about Node.js' blatant favoritism. It takes months/year for innovation to trickle down because of gatekeepers & haters in the open-source community."

Burn It All Down: The Open-Source Communities Unholy Hypocrisy
Photo by Dmitry Bukhantsov / Unsplash

I recently came across an eye-opening development in the Node.js community, and I couldn't help but feel a mix of emotions: disappointment, frustration, and ultimately, anger. It's astonishing how something can be done, but only when someone from the "chosen" group does it. The fact that it takes months or even years for others to benefit from the work is unacceptable.

even when it's months later or as in this specific case 4 whole years later. All because too many gatekeepers and haters exist in open-source community. We've all heard the saying, "those who can, do; those who can't"... gatekeep, hate, and complain. And often times, those who can do still throw salt into the little girl's/boy's eyes and wounds such as to keep them down and most importantly to keep the status quo as has recently been demonstrated by long overdue recognition that Google is a monopoly.

The Fat Loner: Hey, look what I did. Everyone else: STFU

The following is a GitHub commit to my project Node.js (v8) --inspector Manager (NiM for short) made FOUR WHOLE YEARS ago wherein a feature was added to resume the debugger stepping up until the first debugger statement in the code. This was useful because often times when using the --inspect-brk flag the intention of the developer was not really to stop at the very beginning of the code but rather to stop at the very beginning of what was important at the time (i.e. what is one debugging at the moment). One way to make the debugger "break" or stop in V8 runtimes (node.js, Deno, Bun) is to insert a debugger statement directly inside your code. However, depending upon the speed at which the debugger is connected to by whatever frontend your using (Chromium DevTools, VSCode, ...) the debugger statement may get skipped, thus you would use --inspect-brk instead of just --inspect because the former will wait for a "manual" resuming of the code processing. I say "manual" because it's really just waiting for a message from the devtools protocol to say something along the lines of "okay, I'm ready, keep stepping through the code". And that is essentially what the aforementioned commit did, AUTOMATICLY resume stepping up to the first debugger statement! Again, that was FOUR WHOLE YEARS ago...

Updated tippy/popper deps. Added new feature to resume debugger afte… · june07/NiM@5ff4721
…r inspect-brk flag.

So, I recently saw this (please note the date 2024-05-15)

Which first of all, jest aside, kudos to https://github.com/cola119 for making the change to Node.js core and to all involved. I don't know him/her but I'm sure they're a great person. We're all developers in the end, after humans of course. Anyway, that was me trying to not be completely bitter. Let me move on...

So, let's analyze things a bit more shall we. If you click on the PR for above work, you will see:

Most notably to me is the 11 rocket emojis that follow the introduction to this PR... part of the benefit of not being ostracized by the core Node.js powers that be. Developers appreciate solutions that work, and rightly so.

But I would also argue that this PR didn't introduce, but rather, RE-introduced a feature that another developer put into existence 4 years prior. Were it not for being blackballed by the Node.js committee many more developers might be aware of such facts including cola119. Maybe cola119 could have instead spent their time on an even greater feature.



Yeah, yeah, I know the haters are chomping (or IS IT champing?... so what if it is... I like CHOMPING better!) at the bit... but no one has to install your email collecting extension and since it's in core it is more widely available... to which I would respond, S. T. F. U. Yes, there is some validity in the later point as far as being more "widely" available since it doesn't matter what workflow the developer might be using as long as they are using Node.js... however I would also argue that since NiM is a cross-runtime tool (i.e. Node.js, Deno, and hopefully Bun) that wideness argument loses some steam... and the first part, well it's just nonsense as it was years and years ago when it was first brought up, as history and the lack of any nefarious actions being done with emails! In fact, they have been used by myself less than a handful of times and most users likely have never received an email from me. But I digress, I'll save that for another lovely blog entry... I know you the reader cannot wait!!! Yee haw! As I was saying...

Milton from Office Space

In the end, the developer should be the one to choose which tools they want to use vs those that they don't... not any overarching body just because some ass hole was hot and bothered over their funky email address. You have multi-billion-dollar corporations doing who knows what with all manner of your private data and yet you choose to crucify this guy... well figuratively speaking at least. WTF?!

Rest assured... I'm not going to burn your whatever down. Not yet.