OpenDrone map is a toolchain, not really a SFM system by itself.
See here: https://github.com/OpenDroneMap/ODM/tree/master/SuperBuild/cmake They are using OpenSFM.

So if we want add it I would consider it under system and explicit write this is a toolchain.

And OpenSFM uses OpenCV, as far as I'm aware. It's hard to draw a boundary in my feeling.

By "under system" you mean "a subsystem", right? Maybe it would make sense to add a "dependency" column to the table indicating whether the software offers an original implementation or exploits existing one available in another project.

OpenSfM depends on many libraries but they have developed their own SfM chain (https://www.opensfm.org/docs/building.html#install-dependencies). OpenCV is used to manipulate images, and OpenGV is used for model estimation, but their implemented their own SfM pipeline (https://www.opensfm.org/docs/reconstruction_module.html).

I would classify OpenDroneMap as a toolchain/subsystem - using existing pipelines rather implementing SfM algorithm.

As you said it is hard to draw a boundary line, that's why I have added only library that implement a complete system that is reliable enough to perform large scale reconstruction (100+ to 1000+ images). OpenCV SfM toolchain has not been really used by the community and that's why I did not include it here. Does it make sense (Proven SfM project)?

For OpenDroneMap, I guess the controversy stems from the different ways one can read the "OpenSource SfM" header. You interpret it narrowly, which is fine, and I'm interpreting it broadly. How about renaming "OpenSource resources", above, to "OpenSource algorithm implementations" (or something like that) to make your interpretation more explicit?

With OpenCV, I'm less convinced. I don't think that popularity should be a factor. That said, I'm not going to pursue this issue further.