Building an open-source community at HOTOSM: a thank you

I’m deeply embedded in the open-source humanitarian software space by now. This post is a retrospective of my time spent here so far, and a highlight of the successes from the open-source community at HOTOSM. I apologise in advance if its overly long and bit rambly. Where This All Began I started working with HOTOSM as a volunteer in Feb 2022. They needed urgent assistance with developing a new tool called the Field Mapping Tasking Manager, in response to the Turkey / Syria earthquake crisis at the time. Having worked on open-source tools for the preceding two years, I was pretty keen to volunteer my time. After speaking with their senior humanitarian advisor (and now a great friend), Ivan Gayton, I was quickly convinced about the potential for the tool, and took a week off work to push forward developments. Fast forward a few years and I am now the senior technical lead at HOTOSM, coordinating and assisting the development of our entire suite of tools. Governance HOTOSM mostly operates on a no-nonsense do-ocracy model. Whoever contributes the most has the most sway over a project! Of course, this doesn’t always hold true, particularly when hiring contractors to assist with the development of our tools. But HOT does try to be extremely transparent with it’s approach, working in the open, and actively encouraging input from the community. The Community Community has always been HOT’s strongest asset. I am by no means the expert on this topic. But I do know that the community largely formed around Tasking Manager, responding to humanitarian activations for disaster response and resiliance. Sub-communities formed around procuring and processing base imagery, in-person mapathon events globally, country-wide communities deeply rooted in OpenStreetMap and other open communities such as OSGeo and YouthMappers. The global reach of the community is truly astounding, with ~5000 users registered onSlack channels alone. HOT also has a large network of software development collaborators, with names such as DevelopmentSeed and Kontur frequently stepping in to assist. While our mapping and data volunteer network is strong, we still struggle to cultivate a sustainable open-source software development community. Why is that? Would a different governance model help? Note HOT may be joining the Cloud Native Geo Foundation in the near future, a development that I am particularly excited to see! Software Development Skills Are Truly Global A degree from a top university doesn’t automatically make someone a great developer. Real-world problem-solving, especially in humanitarian tech, demands a broader skill set — one that prioritizes practicality over algorithmic challenges. Sure you can produce exceptionally crafted algorithms, but are the end users needs best served by this? Having rarely lived through hardship or a humanitarian crisis, is our mindset suitably aligned to meet the multi-faceted requirements? (Of course, I realize the irony here — this probably exposes my own biases too). This is especially prescient in an often resource-constrained humanitarian sector. I have worked with a mixed bag of developers, many of which don’t immediately grasp the bigger picture of what they are developing. When funneling $$$ into AWS isn’t always an option, thinking outside the box may be required. Sometimes simple (and low resource, low budget) is best. It also often requires understanding the full stack implications of what you are developing: delivering tools from end to end, considering development time, ease of understanding and maintainability, plus hosting costs in the long term (factoring possible scaling too). Where I am going with this is that the top coding talent need not be constrained to the talent pool from software engineer grads from the “Western world”. Hiring for projects in this sector has been an eye opening experience. The rest of the world is getting on fine with some excellent software developers. You just need to know where to look. Case in point to this is the burgeoning geospatial software industry based in Kathmandu, Nepal. One of the most talented and ‘going-somewhere’ engineers I have met is my friend and colleagueKshitij Sharma, who graduated from the excellent Institute of Engineering at Tribhuvan University. HOT’s biggest tech partner is the organisation NAXA, an organisation that is truly a pioneer of the geospatial development industry, working alongside many, many international partners to achieve theirs goals. From this partnership, DroneTM was conceived, a tool for community driven drone imagery collection - with the vast majority of the technical challenges being solved by the team based in Nepal. Notable Contributions Since working with HOT, I have had some excellent community contribution experiences regarding software development. Here are a couple of examples. HOTOSM UI Joe has been invaluable to the te

Mar 9, 2025 - 05:58
 0
Building an open-source community at HOTOSM: a thank you

I’m deeply embedded in the open-source humanitarian software space by now.

This post is a retrospective of my time spent here so far, and a highlight of the successes from the open-source community at HOTOSM.

I apologise in advance if its overly long and bit rambly.

Where This All Began

I started working with HOTOSM as a volunteer in Feb 2022. They needed urgent assistance with developing a new tool called the Field Mapping Tasking Manager, in response to the Turkey / Syria earthquake crisis at the time.

fmtm-call-to-action

Having worked on open-source tools for the preceding two years, I was pretty keen to volunteer my time.

After speaking with their senior humanitarian advisor (and now a great friend), Ivan Gayton, I was quickly convinced about the potential for the tool, and took a week off work to push forward developments.

Fast forward a few years and I am now the senior technical lead at HOTOSM, coordinating and assisting the development of our entire suite of tools.

Governance

HOTOSM mostly operates on a no-nonsense do-ocracy model. Whoever contributes the most has the most sway over a project!

Of course, this doesn’t always hold true, particularly when hiring contractors to assist with the development of our tools.

But HOT does try to be extremely transparent with it’s approach, working in the open, and actively encouraging input from the community.

The Community

Community has always been HOT’s strongest asset. I am by no means the expert on this topic.

But I do know that the community largely formed around Tasking Manager, responding to humanitarian activations for disaster response and resiliance.

Sub-communities formed around procuring and processing base imagery, in-person mapathon events globally, country-wide communities deeply rooted in OpenStreetMap and other open communities such as OSGeo and YouthMappers.

The global reach of the community is truly astounding, with ~5000 users registered onSlack channels alone.

HOT also has a large network of software development collaborators, with names such as DevelopmentSeed and Kontur frequently stepping in to assist.

While our mapping and data volunteer network is strong, we still struggle to cultivate a sustainable open-source software development community. Why is that? Would a different governance model help?

Note

HOT may be joining the Cloud Native Geo Foundation in the near future, a development that I am particularly excited to see!

Software Development Skills Are Truly Global

A degree from a top university doesn’t automatically make someone a great developer. Real-world problem-solving, especially in humanitarian tech, demands a broader skill set — one that prioritizes practicality over algorithmic challenges.

Sure you can produce exceptionally crafted algorithms, but are the end users needs best served by this? Having rarely lived through hardship or a humanitarian crisis, is our mindset suitably aligned to meet the multi-faceted requirements? (Of course, I realize the irony here — this probably exposes my own biases too). This is especially prescient in an often resource-constrained humanitarian sector.

I have worked with a mixed bag of developers, many of which don’t immediately grasp the bigger picture of what they are developing. When funneling $$$ into AWS isn’t always an option, thinking outside the box may be required. Sometimes simple (and low resource, low budget) is best.

It also often requires understanding the full stack implications of what you are developing: delivering tools from end to end, considering development time, ease of understanding and maintainability, plus hosting costs in the long term (factoring possible scaling too).

Where I am going with this is that the top coding talent need not be constrained to the talent pool from software engineer grads from the “Western world”. Hiring for projects in this sector has been an eye opening experience. The rest of the world is getting on fine with some excellent software developers. You just need to know where to look.

Case in point to this is the burgeoning geospatial software industry based in Kathmandu, Nepal. One of the most talented and ‘going-somewhere’ engineers I have met is my friend and colleagueKshitij Sharma, who graduated from the excellent Institute of Engineering at Tribhuvan University.

HOT’s biggest tech partner is the organisation NAXA, an organisation that is truly a pioneer of the geospatial development industry, working alongside many, many international partners to achieve theirs goals.

From this partnership, DroneTM was conceived, a tool for community driven drone imagery collection - with the vast majority of the technical challenges being solved by the team based in Nepal.

Notable Contributions

Since working with HOT, I have had some excellent community contribution experiences regarding software development.

Here are a couple of examples.

HOTOSM UI

  • Joe has been invaluable to the team in the past few years.
  • Not only did he hash out the design choices taken for the hotosm/ui project, a web component library that will be integrated into all of our tools into the future.
  • But Joe has also contributed many large patches to both Tasking Manager and FieldTM, overhauling our build tools, migrating the entire Tasking Manager codebase from JavaScript --> TypeScript, and more