** Taps microphone **
Is this thing on?
Ok. Might be dating myself a bit with the title. But I kind of think of the next stage of OpenDroneMap as a Voltron moment. For those who didn’t grow up with Voltron in the 80s, it was American adapted Japanese anime with people piloting mecha robots that could all come together in one big mecha robot that was even better than the individual robots at completing the task at hand.
Via wikipedia (though you might also check the Voltron Fandom for more detail):
Voltron is an American animated television series franchise that features a team of space explorers who pilot a giant super robot known as “Voltron”. This super robot was created when needed by smaller robots joining together, with the process of that unification varying over time. Produced by Peter Keefe (executive producer) and Ted Koplar through his production company World Events Productions, Voltron was an adaptation of several Japanese anime television series from Toei Company.

Types of Free and Open Source Project, by Contributor Groups
In the spectrum of different kinds of projects in Free and Open Source Software, we have everything from individual hobby projects to solopreneur projects where folks make a business out of developing software and make some or all of that software free. There are whole corporate entities which open source some or all of their software. And there are larger aggregate projects with multiple core contributors distributed across multiple organizations.
Each of these reflects the community in the structure of the software in different ways. As Alice Averlong once once wrote:
you know that saying about how a compiler made by N teams will contain N+1 passes?
like every big program contains a replica of the organizational structure that created it?
It’s fun sometimes to see big programs made by one person, because they’re a sort of inverse mold of their brain structure.
How is OpenDroneMap Having a Voltron Moment?
OpenDroneMap has long been a community project. I started it as a fork of BundlerTools, and quickly DK Benjamin and then later Piero Toffanin showed up to work on it. As a result and thanks to them, it’s a full ecosystem of tools. We fairly quickly benefited from Pau Gargallo’s creation of OpenSfM and continued work on that with a whole team at Mapillary.
But, in truth, with Mapillary becoming part of Meta a few years back, it’s been difficult to find more than one person to work on core. Part of my task, leading OpenDroneMap, has been to find a maintainer for OpenSfM and then subsequently ODM, the processing engine at the heart of the OpenDroneMap ecosystem.
It felt impossible for a long time, until I thought to ask the right people for help. Sometime around the middle of last year, I reached out to Yann Noutary, long time OpenSfM contributor, occasional and epic ODM contributor, and he tapped Leonardo Urena-Fuentes, who agreed to come on as maintainer for both OpenSfM and ODM.
Yann, as his last act before heading back into the corporate world, put together a pull request titled Better and Faster with the following improvements:
- Better GCP handling (revamped weighting scheme in BA, and triangulation consistency)
- Better export to GCP CS : we now use the full transformation and not a rigid approximation
- Proper OPK angle reading
- Rerun export for viewing the scene and quality report together
- Speed and memory optimisations : 7K images dataset now passes in less than 2 hours on a Core Ultra 9 285K. Before it was more than 24 hours.
Have fun, and thank you for keeping the open-source torch bright !
Enter More Lions
Leonardo quite quickly started gathering community feedback on problems/limitations/challenges with the ODM engine and in an act of fantastic team building, tagged in Michael Johnson on the CI/CD side of the house as well. He’ll be introducing himself on the forum shortly.
Charles Milette has been helping on the Windows build side of the house, Sashin Ranasinghe has shown some real potential on the web interface side, and we have a few more folks queue up to help out on the interface side.
In short — we’ve got quite the development team. The future is bright.
Types of Labor
LibreOffice recently had an interesting blog post entitled Our sense of meritocracy which details the importance of recognizing the wide range of labor that goes into software communities, including:
“
- The authors of the documentation who made the software accessible to users who would otherwise have given up on using it.
- The localisation team that involved entire linguistic communities in the project.
- The reviewers who transformed rough bug reports into reports ready for resolution.The community moderators who kept the project welcoming to newcomers at the cost of considerable personal effort.
- The people who spent years building relationships with media, institutions and the political sphere, creating the conditions for the software’s widespread adoption.
Before I close this post out, I really want to recognize the labor of those who have put in the labor to maintain OpenDroneMap’s documentation and community forum, especially our very own Community Manager, Saijin_Naib / Brett, who is an indefatigable advocate for people, a deep thinker about photogrammetry and mapping, and a rock of our community.
We are so fortunate to have such an amazing community of contributors.
To put it another way and quote mhoye:
I believe, very strongly, that this is the whole why of software. That the real product of software is a group of people with a shared understanding a difficult problem space, and the code is an important artifact of that understanding, but only incidental to the Actual Why. The code is an embodiment of and an accessibility tool towards the collective understanding, but it is not the collective understanding, and it is not the ultimate goal of the process. The team is the goal.
Activate interlock! Dynotherms connected! Infracells up! Mega thrusters are go! LET’S GO VOLTRON FORCE!