I think I can try to answer here without being biased. If you look at the commit history of me and Patrick you will see that we are very active in the QGroundControl communities, by number of commits, saying that we did not approach qgc first is misleading, it’s because we work on qgroundcontrol we would like to use Kirogi as testbed for a summer of code.
Trying to counter some pointed made:
mission planner: it’s c# based, will only work with Windows, maybe Linux and Mac with mono but the effort to make a working binary is too huge, also it would be impossible to run on Android / iOS without a total rewrite. because of this I’ll only focus on qgc.
qgroundcontrol: it’s based on the same technology as Kirogi, so we have a match here, but it’s not just about technology.
QGroundControl is slow to evolve - some patches I delivered where merged two years later. This is mostly to the current maintainers sometimes lacking time for it, which is understandable.
Kirogi has no concept of “owner/maintainer”, the (Kde) community Owns it so if the creator stops doing reviews, any other member of the community can review/merge.
Qgroundcontrol is a single binary with interdependencies: the amount of code right now is huge, and there is no clear separation of libraries and app, the code is quite tangled and that creates a huge learning curve for anyone trying to contribute to it, as it’s not possible to study the source code for “video” without opening the settings, vehicle, camera, app, etc. everything is linked.
Kirogi on the other hand is based in clear separations and clear plugins, making the code easier to isolate, and test.
Qgroundcontrol suffers from the “not invented here” syndrome: it recreates tons of already existing libraries because the developers did not want to use pre existing ones as they tougth this would simplify packaging - being fair they use gstreamer, qt and mavlink.
Kirogi uses libraries to not recreate code, this gives us a slimmer code size for the same goal, and it also improves the development time. This approach makes packaging harder, but after that’s sorted the rest is easier. Also the developers that already know how to use a library we use will get started faster, without relying on reading code, and those libraries have something qgc truly lacks:
Qgc has little to no documentation, it’s really hard to get some aspects of it (for instance the fact system)
All of the libraries used in Kirogi have around 90% of code documented.
Qgroundcontrol is tied to a specific firmware and adding a new one is hard as it was not tougth on having backends as first class citizens, rewriting the core would be needed to accept multiple backends.
Kirogi started with backends, so it’s a no brainer.
“QGC has ties with the industry while kde has not.”
Utterly untrue. KDE has developers in intel, blue robotics, Mercedes Benz, bmw, mbition, sap, kdab, collabora. Developers that actively send code to qgroundcontrol (if you look kde is good né of the 3rd contributors to qgc).
On that regard:
Qgc uses qmake as main build system;
Kirogi uses cmake; industry standard for c++; since it’s inception.
We didn’t proposed Kirogi without examining the current status of drone stations, we are contributing with them for years (my 1st contribution to qgc was 4 to 5 years ago).