This is bad for "independent developers", but good for hourly types if there is budget left and a cost benefit ratio that won't leave them unemployed.

They try to attack anything that appear to be exclusive. Programming is only exclusive because not many people are suited to it, but if you throw enough streetshitters and diversity other-kin hires into the mix it has the appearance that anyone can do it.

They are poisoning it to suit their ideological insanity.

I like to take things on my own schedule rather than be "surprised" one day and have to act quickly.

If I had FreeBSD installed anywhere, I would purge it now. SJWism is cancer.

Black hats do indeed get paid, but some end up in prison, some have to be careful where they travel, and some work behind the shield of a state.

Companies survive mostly from sales ability leading to cash flow, not actual performance. Plenty of so called white hat hacker companies just hire pajeets to run scripts, and people are fine with that because it was just a "cover your ass" step anyway, there is no actual desire to have security problems found except for the most egregious. Plenty of room for SJWs.

Segment selectors sucked ass.

The difference between real interest and bullshit. Dev tools also used to be a lot harder to come by and if you had problems you couldn't just hit up stackexchange. That isn't to say that no good devs will surface today, of course they will, but it will be a lot harder for them with a billion pajeet hello world coders scratching for a job.

Be careful you don't end up writing something like this abortion: https://www.hooktube.com/watch?v=aDthslQMVsU The "programmers" thought the same thing, and as a result it has wicked lag between user input and actual drawing.

Performance matters a lot for some things and not very much at all for other things. Don't be stupid.

More than one camera can help reject false positives like rain drops or blowing snow.

When it comes down to intelligently rejecting movement, the probable identity of the object needs to be determined, and it's so difficult even a human watching can reject legitimate movement or needs a double-take to figure out wtf it was that changed. For some things thermal imaging can help. I don't think conventional deep learning is the way forward, I lean towards making progress on nested pattern recognition.

I made a system for networked H264 cameras, with realtime tracking of multiple targets that works well.

So, some comments from my experience that might be helpful:

Where these things usually fall down, particularly with multiple HD streams is from the load on the CPUs.

I highly recommend reading and decoding the full resolution stream into a framebuffer (looks like you get jpegs) (generally you want the full frames saved for the record if motion is detected anyway), make a lower resolution copy of the frame buffer to run your motion detection/tracking algorithms on (cubic or linear interpolation). Multiple passes of gaussian blur with a running average frame subtracted from the live image, combined with a hole filling algorithm will produce blobs that cover anything moving. You can measure the blob sizes to discard blowing leaves, or massive shadows from moving clouds, and finding the center of the blobs for targeting/tracking purposes is trivial. Use a mask image the same dimensions in concert with your highly optimized gaussian blur algorithm to avoid calculations on pixels outside of your interest.

Reduce your stream buffer size to a minimum to keep tracking lag to a minimum.

I haven't open sourced it, but maybe one day.