Sam Woodcock

Why many 'tech for good' software projects fail

Sam Woodcock — Sun, 20 Sep 2026 00:00:00 +0000

I lead technology at an NGO working on humanitarian and global development causes. I’m reasonably new to applying software skills in this space, so lately I’ve been trying to read more widely.

Recently I read Tim Unwin’s Digital Inclusion in an Unequal World (ict4d.org.uk), which promptly sent me down a rabbit hole. To further elucidate this dense topic, I gathered a corpus of ICT4D - information and communication technology for development - writing into an archive: github.com/spwoodcock/ict4d-archives, spanning twenty-plus years of reports and field accounts.

I then ran a small LLM-assisted synthesis over the corpus to identify the recurring patterns. What follows are my findings.

On using an LLM for this

Following on from my post on using LLMs ethically, this feels like one of the genuinely good use cases: qualitative synthesis of existing knowledge, in service of ICT4D.

The harms from about 10 minutes of running Opus 4.8 are relatively low, while the upsides - not wasting scarce resources on projects nobody needs, and not building on communities - are high.

I should caveat all of this by saying I’m reasonably new to the sector, so take it with a pinch of salt. But there are some pretty clear patterns worth writing down - and these are by no means novel ideas. A recent scoping review corroborates the findings here, with evidence that common failure modes are much the same as what follows.

A recurring story

Reading about failed projects in the development sector can really fill you with cynicism.

The failures I read about seemed to fall into two broad categories:

Well-intentioned people who either fail to capture what communities truly need or are unable to keep things self-sustaining when their enthusiasm wanes or funding is cut.
Institutional failings, where the whole project isn’t really about serving communities, but the interests of the organisation itself (or its wealthy corporate partners).

The canonical example of the first is the Roundabout PlayPump.

With regard to “tech for good” software, the most important thing I took away is this: working software is rarely the primary challenge.

Five common failures

Most of the following failures are structural to the system and repeat time and time again.

1. Growth over equity

“Tech for good” is often measured by growth: users, downloads, countries worked in, cash transfers.

But the people who most need help are often the least profitable and hardest to reach.

While it’s true that from a utilitarian perspective the most efficient and expedient way to reach as many people as possible can make sense, this systematically missed out the true victims of the global systems that are not designed with a concern for their needs.

2. Institutions captured by whoever pays

Follow the money and you often get to the heart of true motivations.

This is a problem the world over for NGOs. Funders’ priorities best community priorities. When money defines the mission, incentives are not aligned and communities lose out.

3. “Me” over “we”

Awards, keynote speaking, “founders’ stories”, glossy apps, release events, and circle jerking.

The sector tends to reward individuals and institutions, but doesn’t focus as strongly on day-to-day efforts to maintain known and needed technology and efforts to hand over power to the people that actually use the tools.

4. The innovation fetish

Short project cycles plus a bias toward novelty produce a permanent pursuit of the newest thing. Yesterday it was blockchain. Today it’s AI.

Hype outpaces learning, and decades of reports on failed projects go unread. Wilful blindness is a useful tool in the search for new funding, but doesn’t favour well-tested and proven tech.

5. Extraction and dependency

This one is intrinsically linked to a world caught in the grips of surveillance capitalism.

Value - especially data - flows out of communities, often in exchange for something “free”. Dependency flows in: a system only the original vendor can change, risk of enshitification and rising costs, and a soft lock-in that makes a mockery of any open-source licence (open code is not the same as local ownership).

As an example, take UNICEF Giga’s work connecting schools across developing countries. There are some genuine benefits - lower connectivity costs, government leadership, measurable reach - but connectivity is an output, and it’s easily mistaken for an educational outcome. A regional UNICEF case study praises government ownership of the project, while also flagging donor dependency and the need to transition further toward it as a future risk (not to mention government ownership is not the same as community ownership, either).

It’s always worth asking: who ends up owning the infrastructure, the contracts and the connectivity data - and who pays to keep it running once donor support ends?

The path to success

Not everything fails. Some ICT4D systems have run for fifteen or twenty years and genuinely serve their communities.

Specifically for software projects (my main wheelhouse), some tools I’ve had the pleasure to work with have lasted and been used widely: ODK, Ushahidi, CKAN, RapidPro, and CommCare. Generally these projects only sustain if some people find them useful (that isn’t to say that every application of them necessarily improved people’s lives).

Across the wider archive, including the comparison of 19 long-running ICT4D projects, the same patterns recur in their histories, governance, funding, implementation and evaluations. It’s not a guaranteed recipe, but it does give us six useful questions to ask, before you write a line of code:

Solve a real problem. Who experiences the problem, and have they actually asked for it to be solved? Write down how the work happens today, the institution responsible for it, and why an existing tool or a non-digital approach isn’t enough.
Share decision-making power. Who can propose, prioritise, reject, fund and release changes? If the people affected can only offer feedback that we’re free to ignore, we’re consulting them, not sharing power with them.
Fund transitional ownership. Name who will own the data, operations, budget and outcomes. Cost the unglamorous work - hosting, security, support, upgrades and training - and fund it beyond the end of the grant. True community ownership (not neo-colonial lip service).
Design for the people most likely to be excluded. Test with people facing constraints around connectivity, cost, language, literacy or disability, and keep an assisted or non-digital route open. Work out how the data could hurt someone, and who is accountable for consent, correction and appeal.
Measure outcomes, not activity. Before launch, define the change that should follow from the software - not users registered, app installs or data collected. Check who benefits and who remains excluded, and publish the result even if it is null or disappointing.
Reuse before you build. List the tools and previous attempts you investigated, speak to the people who used or maintained them, and explain why adapting one isn’t the answer. If something new is still justified, make sure people can export their data and walk away from it.

A simpler way to think about it

You can boil all of this down to a simple rule:

Build with people, not for them, and never on them. (idea adapted from Tim Unwin, mentioned above)

“For” sounds generous, but it’s usually paternalistic. “On” is what happens when people become test subjects for someone else’s idea. “With” is the only one that survives for the long term - because the community helped decide what gets built, and has a stake in keeping it alive.

A small case study: Ushahidi

After Kenya’s disputed 2007 election, Kenyan developers and bloggers built Ushahidi - Swahili for “testimony” - in a matter of days. People could report violence by web or SMS and see it mapped in near real time. It began with people living through a crisis, using simple technology to solve a problem they had named themselves. Nearly two decades later it is still maintained and used around the world. The reach came later; it was never the point. That origin did not guarantee success: later evaluations also found weak feedback loops, training and coordination. The point is not that Ushahidi was perfect, but that it began with a real problem rather than technology in search of one.

The cheapest improvement available to this whole sector is still the same: stop reinventing the same failure, build on what already works, and start with the people the software is meant to serve.

Postscript: tools I try to build in this spirit

A few tools I’ve been lucky to work on that try to put these ideas into practice:

Drone Tasking Manager coordinates the collection of up-to-date imagery. The intended outcome isn’t the imagery, but the decisions that can be taken by communities, once they better understand the structure of the areas where they live.
Field Tasking Manager prevents overlap in field-mapping campaigns. It takes existing, well-established tools, such as ODK and QField, and solves a problem around coordination that has been reported by many communities globally.

While I think they both tick some of the boxes, there is definitely room for improvement. They should be held to the same six standards above, and of course, changed or even abandoned if they fail to over time.

Intro to photogrammetry

Sam Woodcock — Sat, 29 Aug 2026 00:00:00 +0000

Note

Big disclaimer up front: the maths behind this stuff is far from my area of expertise. I’m writing as a photogrammetry layperson that got interested in this topic after processing a tonne of projects using OpenDroneMap. Excuse any ignorance you may observe!

How I ended up here

I recently had a call with someone worried about the future of OpenSfM - the engine at the heart of OpenDroneMap (ODM), which turns drone photos into maps. Their idea: “why not use COLMAP instead? It’s come a long way and has a big community”.
At the time I thought OpenSfM was essentially dead upstream, leaving the ODM team to maintain their fork forever. So I went digging into whether COLMAP could replace it.
And in doing so, I got completely sucked into learning how photogrammetry actually works.
Plot twist: OpenSfM turned out to be very much alive - a bunch of major upstream improvements started landing right as I began poking around. More on that later.
But the exploration taught me a lot, so let’s dig in. This post is my attempt to demystify photogrammetry for the layperson (i.e. past-me), then weigh up COLMAP vs OpenSfM for drone mapping specifically.

Note

If you didn’t know, I’m the tech lead @ HOTOSM, where we use drone imagery and tools like ODM to produce open geospatial data for humanitarian response. My lens is “what works for community drone mapping”.

What even is photogrammetry?

Photogrammetry is the art of turning a pile of overlapping 2D photos into a 3D reconstruction of the world.

In the context of aerial imagery, you can imagine it more like this:

The trick is the same one your two eyes use for depth perception. Each eye sees a slightly different view, and your brain fuses them into a sense of distance.
Photogrammetry does this with many “eyes” - dozens or thousands of photos spread out over space (in our case, snapped by a drone flying a grid).
If the same physical point shows up in several photos taken from different positions, a bit of geometry lets us work out where that point sits in 3D, and where the camera was for each shot.

The pipeline splits into two big stages, worth understanding separately:

Sparse reconstruction (Structure-from-Motion): find the camera positions and a rough skeleton of 3D points.
Dense reconstruction (Multi-View Stereo): use those camera positions to fill in a detailed surface.

Then downstream tools turn that into the things we actually want: orthophotos (a flat, top-down, distortion-corrected map image) and elevation models. Let’s take each stage in turn.

Stage 1: Structure-from-Motion (the sparse bit)

We hand over a folder of photos; ideally we get back every camera’s position, its lens settings, and a sparse cloud of 3D points. It happens in three steps.

1. Feature detection - find distinctive little landmarks in each photo: corners, textures, anything recognisable again elsewhere. Think of spotting the same chimney or road marking in shot after shot.

2. Feature matching - work out which landmark in photo A is the same landmark in photos B, C, D… This is what links the photos together.

Note

We match features across overlapping photos, so this is why we need to make sure to fly with good photo overlap!

3. Triangulation & bundle adjustment - the big number-crunch. Here’s the catch22: to place a 3D point you need to know where the cameras were, but to know where the cameras were you need 3D points. So the software solves for everything at once - all camera positions and all 3D points together - nudging them until the whole scene is as consistent as possible.

The output is a sparse point cloud - the scene’s skeleton - plus every camera’s pose. Not pretty yet, but the difficult geometry is done.

Incremental vs global

Two strategies for this are available.

Incremental - add photos one at a time, re-optimising as you go. Robust and accurate, but takes a long time on large image sets.
Global - solve for all camera poses at once. Scales far better and is dramatically faster. It used to trade away some accuracy, but recent work (GLOMAP, now part of COLMAP) has mostly closed that gap.

COLMAP vs the OpenSfM fork

This was my original question. For drone mapping specifically:

OpenDroneMap’s OpenSfM fork

👍 Fast, with ~2× lower memory use - great for the low-spec devices our communities actually use.
👍 Loads of drone-specific georeferencing baked in: camera angles, Ground Control Points, flexible coordinate systems (huge credit to YanNoun).
👎 Looked dead upstream, meaning maintenance responsibility for the ODM team (since changed!).
👎 No real GPU acceleration at the time.

COLMAP

👍 Healthy, actively developed, well tested.
👍 Global SfM built in, and strong GPU support.
👍 Very robust in awkward scenes - ODM is tuned for nadir (straight-down) shots, so COLMAP does better on oblique angles.
👎 No native drone georeferencing - all the stuff Yann already solved.
👎 Its global pipeline estimates camera parameters differently, and those numbers feed straight into the final map’s accuracy.
👎 Real integration effort into the ODM stack.

Stage 2: Multi-View Stereo (the dense bit)

Once SfM has nailed the camera positions, dense reconstruction fills in the detail - going from a sparse skeleton to a dense, photorealistic surface.

Above is the the sparse skeleton from SfM with the dense result below.

In ODM this is currently a separate tool, OpenMVS.

After this, it’s rasterised into the final orthophoto and elevation model.

Could OpenMVS be replaced?

The most exciting recent OpenSfM news: it’s growing its own dense reconstruction, plus direct orthophoto + elevation output. That could make OpenSfM a single framework for the whole chain - no separate OpenMVS step.
It’s also gaining OpenCL GPU acceleration. Unlike CUDA, OpenCL supports AMD, Intel and Nvidia, with graceful fallback to CPU when there’s no GPU at all - which matters hugely for mixed, low-spec community hardware.

Where COLMAP falls down here

COLMAP can also do the dense step, in theory replacing both tools at once.
But its dense reconstruction is CUDA-only - useless if you don’t have an Nvidia GPU. That rules it out as a general ODM replacement.
So even in a COLMAP world, it’d only ever replace the sparse step; we’d still need OpenMVS (or future-OpenSfM) for the dense.

Wrapping up: what’s best for what?

For drone mapping in the ODM/HOTOSM world: the newly revived official OpenSfM is the right tool right now - the drone-specific georeferencing, low memory, CPU fallback, and renewed upstream momentum works across our community of mixed spec devices.
For difficult, oblique, or non-drone scenes: COLMAP is genuinely excellent and battle-tested. Outside the drone-nadir sweet spot, I would definitely try it out.
The COLMAP question isn’t dead, just weakened by OpenSfM’s revival. It could still be a future successor - once the georeferencing and camera-parameter issues above are solved. But honestly, I can’t see CUDA being replaced any time soon.

What to watch for

OpenSfM’s dense + direct-ortho work maturing, potentially collapsing the whole sparse → dense → map chain into one framework.
OpenCL acceleration landing properly - a big win for anyone without a fancy CUDA card.
Old-hardware support - I initially worried that moving to pre-built packages would drop support for very old CPUs (no AVX/AVX2). A maintainer kindly set me straight: the Conda packages compile with -march=nocona (a ~2004 baseline, even older than ODM’s old nehalem target) plus -mtune=haswell, which lets newer chips grab some optimisations without breaking backwards compatibility. A couple of forked libs still cap the effective baseline at nehalem - the same as before. So very old hardware should keep working.

How to fix the eSIM eUICC on a Google Pixel running GrapheneOS

Sam Woodcock — Wed, 05 Aug 2026 00:00:00 +0000

Pretext: broken firmware

I have been running GrapheneOS for some years now, and recently bought a second hand Pixel 9.

After doing a full migration and installing apps, I realised the eSIM capability was broken. I spent a while having to hotspot from my old phone as a compromise. Not ideal.

Note

All of this was done on a Pixel 9 (tokay), GrapheneOS 2026080500, P24 (ST54L). Other Pixels need different strings throughout.

After some digging it seems that the cause might have been:

The device was enrolled in the Android developer programme by the previous owner.
Google pushed out some updates that broke the firmware on the eUICC for the eSIM capabilities.
There have been genuine reports of some Pixels being shipped with the eUICC broken on the hardware level, but the reports of broken eSIM capability were so wide-spread and across models that I was suspicious if this was actually firmware related.

Finally, a recent post on the GrapheneOS forums thread I have been following confirmed that suspicion.

A user posted a fix on a similar Google issue tracker thread and users started reporting a 5th August OTA update also came with a fix.

I subscribed to the GrapheneOS beta channel and updated to the 2026080500 update that should include the patch. No dice.

Note

You can confirm you have the issue by dialing *#*#4636#*#* on your phone. In ‘Phone Information’ you will see eUICC info: { Available memory in bytes:-1 }

The Fix

I started writing a guide on how to apply this fix using GrapheneOS entirely and Magisk, avoiding the need to flash LineageOS. But the attempt failed due to missing ‘Network’ permissions on the eSIM updater utility on GrapheneOS.

See full details by expanding below:

The failed attempt to use GrapheneOS only!

This excellent XDA forums post has a guide to fix your vanilla Pixel eUICC.

I had to tweak this a little to work with Graphene, where root capability is a bit more of a pain:

1. Root Graphene

Update to the latest GrapheneOS via OTA.
Download the matching .zip image for the release image of your device model from the releases page
Extract the contents and save the init_boot.img file inside.
Use the Graphene web installer to unlock the bootloader (ensure OEM Unlocking is enabled on-device).

Warning
This will wipe your device!
Reboot the wiped device, follow setup, then copy the init_boot.img into your Downloads dir on the device. Also make sure you connect to an internet source for the chip flash later.
Download the latest Magisk release APK, and also copy this to your device Downloads.
Install Magisk, open. Install --> Select and Patch a File --> your init_boot.img file. It will output a magisk_patched-XXXXX.img to your Downloads dir. Copy it to your PC.
Ensure USB Debugging is enabled and you have platform-tools or similar for both adb & fastboot on your PC. Run the following:
```
adb reboot bootloader
fastboot flash init_boot magisk_patched-XXXXX.img
fastboot reboot
```

You are now rooted.

2. Fix The eUICC

Run the following:

adb shell
su                              # grant the root prompt on-device
resetprop ro.build.type eng
resetprop ro.build.tags eng
resetprop ro.debuggable 1
setenforce 0
stop && sleep 2 && start

Keep the adb shell open, wait for the framework to restart (the screen will bounce, this isn’t a full reboot), then:
```
am start -n com.google.euiccpixel/com.google.euiccpixel.ui.OtaUpdateMenu
```
Find your config key in the linked XDA forum post or elsewhere. For a Pixel 9 it is P24 (ST54L).
Click the ‘Upgrade Firmware’ dropdown on your phone and select the GGL_P24_ST54L_GSMALIVE_534-1.1_DVT_CG7_v2 option. Note the xxx_P24_ST54L_xxx. DO NOT PROCEED if you get a warning, as it could brick your eSIM.
Then …

I got to this point in the writeup & found the eSIM updater app doesn’t have network permission on GrapheneOS.

Using some adb logcat I found that it gets to the point of the image handshake from the secure element, then dies the instant it does Sending HTTPS POST with “Unable to resolve host,”.

This means any attempt to update using this app is doomed to fail, and we can’t update the app permissions retroactively…

(I did a fair bit of debugging to confirm this was the case and it wasn’t firewalls, faulty internet, DNS resolution issues).

I decided to pivot and simply follow the XDA guide by installing LineageOS and MindTheGapps.

Warning

This wipes your device twice (bootloader unlock, then the Graphene reinstall). Back up somewhere that isn’t the phone.

1. Install LineageOS

I flashed back to a clean public build using Google Flash Tool
Use the Graphene web installer to unlock the bootloader (ensure OEM Unlocking is enabled on-device). It’s just a fastboot flashing unlock frontend, so using it here is fine.
Install Lineage, making sure to install Google Apps via official instructions.
Boot Lineage. Connect Wi-Fi. Toggle USB debugging & Rooted debugging.

2. Update The euiccpixel Package

I had to update to vD.2.0.22 for this to work.

Download the official Pixel build for your device from Google.

Then get the pkg while keeping my filesystem clean:

docker run --rm -it -v "$PWD":/work -w /work ubuntu:24.04 bash

apt-get update -qq
apt-get install -y -qq android-sdk-libsparse-utils e2fsprogs git python3 aapt unzip

unzip -o tokay-cp2a.260805.005-factory-9b3ac3f4.zip
cd tokay-cp2a.260805.005
unzip -o image-tokay-*.zip

for P in system_ext product; do
  rm -rf out_$P && mkdir out_$P
  debugfs -R "rdump / out_$P" $P.img >/dev/null 2>&1
done
find out_* -iname "*euicc*.apk" | grep -vi overlay | grep -vi EuiccGoogle | grep -vi Permissions
# out_system_ext/priv-app/EuiccSupportPixel-P23/EuiccSupportPixel-P23.apk
aapt dump badging out_system_ext/priv-app/EuiccSupportPixel-P23/EuiccSupportPixel-P23.apk | grep versionName
# package: name='com.google.euiccpixel' versionCode='20225' versionName='D.2.0.22 (15551270)' platformBuildVersionName='D.2.0.22 (15551270)' platformBuildVersionCode='20225' compileSdkVersion='29' compileSdkVersionCodename='10'

# Not ideal! The Google thread above suggests that people managed to get D.2.0.23
# But I inspected the cert and it's valid until Jan 2027.
# After testing, this version worked fine, see below.

As this was a huge pain in the ass and wasted hours of my life (trying to find D.2.0.23 unnecessarily), I have attached the EuiccSupportPixel-P23.apk extracted from tokay-cp2a.260805.005-factory-9b3ac3f4.zip for you to simply install and save the faff.

Unmodified, but verify it anyway:
```
sha256sum EuiccSupportPixel-P23.apk
# 14b99f90faed25c23284a6008fabea4e6a2bdc583b8709a04b47859d007ad9a7
```

3. Fix The eUICC

Run the following:

adb install -r EuiccSupportPixel-P23.apk
adb root
adb shell
setenforce 0
getenforce
am start -S com.google.euiccpixel/.ui.OtaUpdateMenu

Find your config key in the linked XDA forum post or elsewhere. For a Pixel 9 it is P24 (ST54L).
Click the ‘Upgrade Firmware’ dropdown on your phone and select the GGL_P24_ST54L_GSMALIVE_534-1.1_DVT_CG7_v2 option. Note the xxx_P24_ST54L_xxx. DO NOT PROCEED if you get a warning, as it could brick your eSIM.

This should succeed! Check *#*#4636#*#* again for a positive memory value.

4. Reflash GrapheneOS

Simply use https://grapheneos.org/install/web to re-install as normal, then re-lock the bootloader.
Add an eSIM. Profit!?

Automate the setup of Garage S3 standalone mode

Sam Woodcock — Tue, 03 Mar 2026 00:00:00 +0000

Why Garage?

Minio was a great open-source S3-compatible API until late 2025.
However, they slowly shifted to a paid model, eventually ceasing development of the open source tool.
Full details of the history can be found here.
In the linked blog, there is reference of a community fork of Minio, but I have had my eye on an alternative project for a while now: Garage.

Is Garage a good replacement?

It actually has a different primary focus to Minio.
While Minio was an ‘enterprise’ replacement for AWS S3, providing a replicas + quorum setup.
Garage is a developed to handle geo-distributed servers, running on low-spec hardware.
It focuses on resilience across sites and simpler operations rather than classic consensus-driven design.
That said, it’s still possible to run Garage as a standalone node - what we plan to do in this post.

Automating the setup of Garage via Compose

I use docker compose to run local software stacks during development.
Garage typically requires a bit of command line config to work for the first time, plus as of 3rd March 2026 doesn’t have a mechanism for local container healthchecks.
Below is the config I used to make this work for a local development setup, entirely replacing Minio:

volumes:
  garage_data:

networks:
  net:

services:
  s3:
    image: docker.io/dxflrs/garage:v1.3.1
    volumes:
      - ./deploy/garage.toml:/etc/garage.toml:ro
      - garage_data:/var/lib/garage
    networks: [net]
    restart: unless-stopped
    # https://git.deuxfleurs.fr/Deuxfleurs/garage/issues/1354
    # healthcheck:
    #   test: ["CMD-SHELL", "/garage node health-check"]
    #   start_period: 5s
    #   interval: 5s
    #   timeout: 5s
    #   retries: 10

  s3-init:
    image: docker.io/alpine:3.23
    depends_on:
      s3:
        condition: service_started
    network_mode: service:s3
    pid: service:s3
    environment:
      GARAGE_ADMIN_TOKEN: garage-admin-token
    restart: "on-failure:2"
    entrypoint:
      - /bin/sh
      - -eu
      - -c
      - |
        # chroot into the s3 container's filesystem so the garage binary runs
        # with its own libs/linker, while the shared network namespace keeps
        # 127.0.0.1:3901 pointing at the live Garage server
        G="chroot /proc/1/root /garage -c /etc/garage.toml"

        # Wait for server
        for i in $$(seq 1 20); do
          if $$G node id -q 2>/dev/null; then break; fi
          echo "Waiting for Garage RPC... ($$i/20)"
          sleep 3
        done
        $$G node id -q || { echo "Garage RPC not ready"; exit 1; }

        # Init garage nodes
        if $$G status 2>&1 | grep -q 'NO ROLE ASSIGNED'; then
          NODE_ID=$$($$G node id -q | cut -c1-16)
          $$G layout assign "$$NODE_ID" -z local -c 1G
          $$G layout apply --version 1
        fi

        # Create S3 bucket
        $$G key import --yes -n fieldtm-qfield \
          GK3515373e4c851ebaad366558 \
          7d37d093435a41f2aab8f13c19ba067d9776c90215f56614adad6ece597dbb34 || true
        $$G bucket create qfield-cloud || true
        $$G bucket allow qfield-cloud --key fieldtm-qfield --read --write --owner || true

        echo "Garage initialized."

for reference: garage.toml

metadata_dir = "/var/lib/garage/meta"
data_dir = "/var/lib/garage/data"

db_engine = "lmdb"
replication_factor = 1
compression_level = 1

rpc_bind_addr = "[::]:3901"
rpc_public_addr = "127.0.0.1:3901"
rpc_secret = "1799bccfd7411eddcf9ebd316bc1f5287ad12a68094e1c6ac6abde7e6feae1ec"

[s3_api]
s3_region = "garage"
api_bind_addr = "[::]:3900"
root_domain = ".s3.garage.localhost"

[s3_web]
bind_addr = "[::]:3902"
root_domain = ".web.garage.localhost"

[admin]
api_bind_addr = "[::]:3903"
admin_token = "garage-admin-token"

Using LLMs ethically

Sam Woodcock — Fri, 27 Feb 2026 00:00:00 +0000

The bigger picture

A small digression, before we dig in.

Insofar as possible, this blog isn’t overly political, normally focusing on technical topics and implementations. But caught up in the zeitgeist of the times, the subject of LLM usage is inescapable.

Most people seem to care about how they can use them effectively, to maximise productivity, automate away labour, and other things. The angle of this blog is different: I want to talk about ethics.

But before we get there, we need to zoom out a little.

Can we live life virtuously?

Sure, if you can afford it.

I can choose vegetarianism on moral grounds because of extremely fortunate positions:

I was born in a liberal democracy.
I am not living in abject poverty.
I have time and education to read about animal welfare and climate science.
I have access to varied food options.

A child born into extreme poverty in South Sudan does not have the luxury of philosophising about the suffering of livestock. Survival comes first.

Ethics is often downstream of privilege. This raises a difficult question: should we hold everyone globally to the same ethical standards? If ethics requires surplus time, energy, money, and education, then it is unevenly distributed by default.

We should remember at all times that our moral judgments should be tempered with humility.

Which hills are we willing to die on?

We all make ethically dubious choices constantly.

Saying we “care deeply” about climate change while booking another short-haul flight.
Buying from Amazon while knowing about the treatment of workers and market control issues.
Using social media platforms we know are harmful to teens.
Scrolling past news of a humanitarian crisis because we feel overwhelmed.
Eating food we know was produced in ways we wouldn’t want to witness.
Not acknowledging a homeless person that just spoke to you.
Using “I’m busy” as a shield against civic responsibility.
Buying cheap clothes that were probably not produced under great labour conditions.
Staying silent in a conversation when speaking up would be socially costly.

How can we live with ourselves?

Because we are deeply human and life is inherently tragic.

No one can optimise for every moral dimension simultaneously. Philosophers from Aristotle to Herbert Simon have argued that the reasonable standard is not perfection, but deliberate satisficing: making the best available choice given real constraints, and owning it.

What can we realistically strive for?

So what remains?

Awareness.
Deliberation.
Intentional trade-offs.
A willingness to accept responsibility.

We just do our best given the circumstances. Nobody is a saint.

This framing matters when we start talking about LLMs.

Creating an ethical usage framework for LLMs

We need a way to reason about LLM usage that acknowledges trade-offs instead of pretending they don’t exist.
While working within the tech team of an NGO, we have been deliberating this dilemma.
Full details can be found here: https://github.com/hotosm/docs/pull/21

Getting crushed in the wheels of the hype train

There is enormous pressure right now.

If you don’t use LLMs, you’re:

Inefficient.
Old-fashioned.
“Falling behind.”

This narrative is powerful, especially in tech.

And to be fair, there’s something to it. Defenders of aggressive LLM adoption have a reasonable case: these tools can meaningfully reduce time spent on low-value repetitive tasks, free up human attention for higher-order work, and (in resource-constrained organisations) stretch limited capacity further.

The ethical question isn’t whether benefits can be found. But these tools can be used (i) deliberately (ii) compulsively (iii) through acquiescence.

I am advocating for more thoughtful and reflective consideration of our actions (a tough sell, considering this isn’t the default state of humanity).

Energy usage: a red herring?

Energy consumption is frequently cited as the core ethical issue.

There is something to this, as data centres consume significant power. Companies like OpenAI, Google, and Microsoft operate vast compute infrastructure to train and serve models.

But we need proportionality.

If you:

Fly multiple times per year,
Own and regularly drive a car,
Heat a large home,
Consume meat frequently,
Participate fully in consumer culture,

…then your LLM usage is probably not your largest environmental impact.

It doesn’t make this irrelevant, but there are deeper concerns (listed in the framework discussion linked above).

Genuine concerns

I won’t dive too deeply into this, as the linked framework doc covers in more detail.

The digital divide is perhaps the most structurally troubling issue. Access to these tools is strongly unequal. Wealthy individuals and organisations in high-income countries gain productivity advantages that compound over time, while communities without reliable internet, hardware, or the educational background to use these tools effectively fall further behind.

This isn’t a new dynamic, as it mirrors historical patterns of technological colonialism, but LLMs accelerate it. For those of us in privileged positions, benefiting from these tools without any consideration of that asymmetry is a form of indifference worth highlighting.

Other major concerns, explored in depth in the linked discussion, include:

IP theft: both the legalities and ethical position, with neither having easy answers.
Extractive contributions: fracturing open-source communities through disingenuous contribution, and real burn-out risk from maintainers.
Exploitation: exposure of communities to labour exploitation through low-paid data labelling and content moderation work that underpins the entire industry.

The least bad option

If you are using LLMs to further maximise productivity and shareholder returns and are ok with that, that’s your call to make. I’d only ask: have you made a conscious decision, or did it happen by default?
If you are coerced to use LLMs by organisational pressure or market forces, then I’m truly sorry that the world is structured this way. Learn the facts: perhaps there is scope for reasoned push-back.
If you are in the tricky position of working on software that are digital public goods, yet can see that LLM usage may be beneficial to the project as a whole, then make your own assessment. There is a chance that the work you do is impactful enough to offset the potential negatives engendered.

The key point here is that it’s all about choosing the least bad option you can justify, and being honest about why.

Contribute to the discussion

Open source communities around the world are hotly discussing this topic currently.
If you genuinely care, and have a perspective to share, then your input is duly welcomed.
There couldn’t be a more important time to weigh in on the topic.

A coders approach to storing recipes

Sam Woodcock — Sun, 22 Feb 2026 00:00:00 +0000

Sometimes I like to cook things

This is a very short blog about something I recently discovered: Cooklang.

‘Cook’ isn’t some coding jargon, nor a confession that I have gone full Walter White.

I mean literally cooking. Food.

Finding the best option to catalogue recipes took a bit of research, but I finally landed on a solution I’m happy with.

Hosting your own recipes

When evaluating this, I cared about:

Plain text formats
Git-friendly
Self-hostable
No mandatory mobile app
Longevity / open standard

There are a few options available:

Mealie

Seemed like best full integrated app out there to store recipes.
It’s full database, Python API, Vue frontend solution - longevity concerns for something so simple.
Seems a bit heavyweight, but probably be best option if you need multi-tenancy / logins.
It also keeps the approach super simple and non-technical for other users.
Tandoor is a good alternative.
Both can be viewed as PWA, or also have third-party mobile app skins.

Nextcloud Cookbook

I already run Nextcloud, so this seemed like an obvious solution.
While I love the simplicity of using something I already have, it does rely on continued maintenance of this installable plugin app.
There is a third-party mobile app to view the stored recipes too, but it’s a bit of a pain to need an app for this…
Perhaps I will return to this if my requirements change, as it does have a pretty neat ‘input URL and store the receipe’ approach - seems simple enough.

Cooklang

I loved the idea behind cooklang, a markdown extension spec and collection of Rust libraries.
The recipes are still human readable markdown, even without a specialised parser. No app lock in. Future-proof.
No app needs to be installed to view them, or catalogue them. Instead, simply host on an existing website (i.e. this blog).
To save time, I have been using an LLM to convert PDF recipes I already have into cooklang format for posterity.

Example for Crème Brûlée:

> > source: https://cooking.nytimes.com/recipes/9039-vanilla-creme-brulee
> > servings: 4
> > time: 1 hour

Preheat #oven{} to 165°C.

In a #saucepan{}, combine @heavy cream{470%ml}, @vanilla bean{1}, split lengthwise (or @vanilla extract{1%tsp}), and @salt{0.8%g}. Cook over low heat just until hot. Let sit for a few minutes, then discard the vanilla bean. If using vanilla extract, add it now.

In a #bowl{}, beat @egg yolks{5} and @sugar{100%g} together until light.

Stir about a quarter of the cream into the egg mixture, then pour the egg mixture back into the cream and stir to combine.

Pour into four #6-ounce ramekins{4} and place ramekins in a #baking dish{}. Fill the dish with boiling water halfway up the sides of the ramekins.

Bake for ~{30%minutes} to ~{40%minutes}, or until centres are barely set. Cool completely. Refrigerate for several hours and up to a couple of days.

When ready to serve, top each custard with about @sugar for topping{1%tsp} per ramekin in a thin layer. Place ramekins under a broiler 2 to 3 inches from the heat source. Broil until sugar melts and browns, about ~{5%minutes}. Serve within two hours.

View the recipes

I added an ‘easter egg’ to this website.

If you click the “bonus-content” button in the footer 5 times, you will be able to view my hosted recipes.

Enjoy!

A second attempt reverse engineering drones: Potensic Atom 2

Sam Woodcock — Wed, 04 Feb 2026 00:00:00 +0000

See the previous blog about hacking the Potensic Atom 1 for full context on this latest update.

The Potensic Atom 2

I was updated by a reader than the Potensic Atom 2 recently received a new firmware upgrade:

In the last blog, I only considered the Potensic Atom 1, as the 2 did not support waypoint missions at the time.
While waypoint missions on the Atom 1 were usable, they had many limitations, such as no gimbal angle adjustment, or altitude adjustments, being possible in an automated way.
I had read that the new Atom 2 waypoint feature was much more capable, so decided to give it a try.

The New Waypoint Format

I captured a few test waypoint missions and discovered:

A directory in shared storage, that is easily accessible (thankfully not sandboxed storage!).
Within this directory, we have a structure as so:

/sdcard/Android/data/com.ipotensic.atom/files/Waypoint/
└── 1770653566867/                  # One waypoint mission (unix timestamp in ms)
    ├── global.json                 # Mission-wide settings (speed, RTH, finish action)
    ├── 1770653566867.json          # Main mission file: waypoints + poi list
    ├── task_1770653542265.jpg      # Mission main thumbnail for Potensic Eve UI
    ├── point_1770653364152.jpg     # Thumbnails for Waypoints in Potensic Eve UI
    ├── point_1770653404823.jpg
    ├── point_1770653417852.jpg
    ├── point_1770653512308.jpg
    ├── point_1770653539697.jpg
    ├── poi_1770653390402.jpg       # Thumbnails for POIs in Potensic Eve UI
    ├── poi_1770653407306.jpg
    └── poi_1770653425134.jpg

Let’s take a look at each file in turn.

global.json

{
  "finishAction": "BACK",
  "globalHeight": 0,
  "globalHeightType": 0,
  "isOrder": true,
  "lostAction": "RETURN",
  "speed": 5.0
}

This is not an exhaustive list of all options, but I have documented the commands I have seen in the JSON:

Field	What does it mean?
`finishAction`	`BACK`, `LAND`, `HOVER`, `RETURN`
`lostAction`	`RETURN` is the only option currently
`speed`	Default mission speed in m/s
`isOrder`	`true` to execute waypoints in forward order, and `false` to run in reverse order
`globalHeight`	Default height, if not specified per-point elsewhere. I doubt we will use this.
`globalHeightType`	Probably 0 = relative to takeoff? This can’t be modified in Potensic Eve, so perhaps a future feature.

<mission_id>.json

This format is custom and a bit weird.

[ WAYPOINTS ] ; [ POI LIST ]

Yes, Potensic concatenates two arrays with a semicolon 😂.
The Waypoint array is as follows:

{
  "action": "START_RECORD",
  "fileName": "point_1770653364152.jpg",
  "gimbalPitch": -90,
  "gimbalType": DEFINE,
  "height": 46.1,
  "hoverTime": 0,
  "lat": 52.4553672,
  "lng": 0.302835,
  "poiHeight": 50.0,
  "poiLat": 0.0,
  "poiLng": 0.0,
  "poiType": 0,
  "speed": 5.0,
  "speedType": "GLOBAL",
  "yaw": -171,
  "yawType": DEFINE,
  "zoomRatio": 1.0,
  "zoomType": DEFINE
}

Field	What does it mean?
`lat`, `lng`	Combined GPS location
`height`	Altitude relative to start point
`hoverTime`	Pause time at waypoint (seconds)
`speedType`	`GLOBAL` = use global.json value, `DEFINE` = per-point
`speed`	Travel speed to next point, if using `DEFINE` for speedType
`gimbalType`	`DEFINE` = adjust per-point, I haven’t seen a global setting yet
`gimbalPitch`	The gimbal angle for the point, between -90 and +20
`yawType`	`DEFINE` = adjust per-point, a global setting wouldn’t be much use
`yaw`	The direction horizontally to capture an image
`zoomType`	`DEFINE` or `GLOBAL`, as with other params
`zoomRatio`	Adjust camera zoom. We won’t use this
`action`	`START_RECORD` (video), `STOP_RECORD`, `PHOTO`, `NONE`
`poiHeight`	Paired with POIs, as described below. Not relevant for us
`poiLat`	Paired with POIs, as described below. Not relevant for us
`poiLng`	Paired with POIs, as described below. Not relevant for us
`fileName`	Points to a thumbnail for the Potensic Eve UI. See info below

Perhaps with further exploration, we might find there are additional settings, such as using the previous waypoint value for gimbal pitch and yaw?
The POI array is as follows:

[
  {
    "fileName": "poi_1770653390402.jpg",
    "height": 46.1,
    "lat": 52.4553676,
    "lng": 0.3028353
  },
  {
    "fileName": "poi_1770653407306.jpg",
    "height": 46.1,
    "lat": 52.4553026,
    "lng": 0.303056
  },
  {
    "fileName": "poi_1770653425134.jpg",
    "height": 46.1,
    "lat": 52.4553901,
    "lng": 0.3025566
  }
]

I believe these POIs simply indicate a fixed target to keep the camera on, so are most useful in video capture mode.
For waypoint missions capturing fixed shots, they don’t seem to be needed (simply having [] for these seems to work).

Photo Thumbnails

The directory also contains many thumbnails - small compressed .jpg images.
These are captured by the camera when the waypoint or POI is captured, simply providing a thumbnail in the Potensic Eve UI for each point.
After testing, they are purely aesthetic, and omitting them does not matter (we can use dummy filenames in the JSON file).
I thought it could be nice to update the main mission thumbnail (e.g. to an image of a task number, for easy identification), however, updating these files doesn’t seem to reflect in the Potensic Eve UI (perhaps they are cached elsewhere on the filesystem, or in the app sandbox storage?).

Note

As a quick aside, there is also an interesting directory present: /sdcard/Android/data/com.ipotensic.atom/files/NoFlyZone/ATOM2/json/dist

Inside this directory, we have a few files, such as CN.json, which contains no-fly geometries in China.

The JSON files are non-standard, containing keys such as type and shape, with their a single lat/lng pair and radius defined, or a polygon comprised of lat/lng pairs.

Presumably, the Potensic Atom 2 is prevented from flying in these areas by the Potensic Eve app?

I wonder if we can configure other JSON files, e.g. FR.json to add no-fly zones in say France?

Pre-Generating Waypoint Missions

So to summarise above, it seems we only really need:

A directory /sdcard/Android/data/com.ipotensic.atom/files/Waypoint/<unix_timestamp>
global.json in the directory, with global flight params.
<unix_timestamp>.json in the directory, with waypoints.

Updating The `drone-flightplan` Python Package

I made a PR here to update the drone-flightplan Python package.

This package is used as part of DroneTM to generate waypoint missions in various drone manfacturer formats.

Testing It All Works

Success! Pre-generating the waypoint missions worked well.
However, the main caveat, as with DJI Fly, is that you must first create a waypoint mission, then replace the JSON files with your new content (being sure to keep the filename the same).
Simply copying the directory to /sdcard/Android/data/com.ipotensic.atom/files/Waypoint/, results in it being deleted when Potensic Eve is loaded.
I believe this is because Potensic Eve uses a similar map.db SQLite file to record the waypoint missions (as with the Potensic Atom 1 + Fly app).
I didn’t bother creating a debuggable modified Potensic Eve in order to inspect the app sandbox storage for this, but I’m sure it’s the case.
While in theory it’s possible to populate the SQLite entries in the sandbox, in practice it’s much simpler to just modify an existing mission (avoiding the need for the user to install a modded debuggable app).

Additional Findings

It’s possible to name a newly created waypoint mission in the app. This likely saves into the SQLite db, and cannot be externally. Handy to mark the mission as your primary replace mission though.
The gimbal angle and yaw cannot be set globally, so must be configured at each point where they need to change.
If using wayline mode in DroneTM, setting the photo internval timer via the mission config is not possible (same as DJI, where it must be manually enabled at the start of the flight).

HOT 2026 Q1 Tech Summary & Roadmap

Sam Woodcock — Tue, 03 Feb 2026 00:00:00 +0000

Disclaimer

I am the current tech lead at HOT. I am using my personal website for this, for the sake of simplicity.

Tech Into The Future

A lot has changed at HOT in the past few years.

HOT’s central mission is to address the development and humanitarian needs of people in vulnerable areas through open mapping.

HOT is building out an end-to-end mapping workflow that is an important component of this mission. The workflow includes local imagery collection (drone, camera imagery), AI assisted processing of that imagery, conducting field mapping and analyzing data for impact.

The user-friendly workflow is aimed at allowing anyone, especially those in vulnerable areas, to collect, access, and use map data.

End-To-End Mapping

A recent example of a blog covering end-to-end can be found here.

In summary, we need a solution to guide users through the many steps required to create digital map data from scratch:

Imagery collection: Drone Tasking Manager | OpenAerialMap
Remote mapping: Tasking Manager | fAIr
Field tagging: Field Tasking Manager | ChatMap
Data insights: Export Tool | uMap

That’s a lot of tools to build and maintain!

In addition to this, we have two ongoing overarching projects:

HOT Portal: a single platform to unify all of the above tools, making for a simpler user experience. More details to come.
Sustainable Infrastructure: migrating all of our software into a more sustainable and resilient infrastructure on Kubernetes

For more details, see an overview of our tech tools and the tech documentation site, including links to roadmaps.

Where Are We Now?

I’m hoping that this series of quarterly blogs will help to shed more light on where we are at delivering the end-to-end solution.

They should inform you about recently released features and future goals for each tool in our suite.

HOT Portal

This platform will provide a unified place to access all of HOT’s tools.
To make them more accessible, a goal of the Portal team is to ensure the same login is used across all of the tools listed below: login once; access any tool.
The Portal website is about to be launched, and will include a summary of ongoing projects for each tool, in addition to a ‘My Data’ section to see projects you are involved with.

Imagery Collection

Drone Tasking Manager

DroneTM is now a stable, widely used platform for planning, uploading, and processing drone imagery in real-world mapping campaigns.
While the primary workflows are capable of collecting and processing imagery, many potential improvements have been identified throughout drone mapping campaigns, giving plenty of potential room for improvement into 2026.
A major goal has been improvements to imagery upload and processing: faster uploads, fewer failures, resumable, and no requirement to divide images into task areas before uploading. The work will be released on the main website Feb/Mar 2026.
A new team member within Tech will be pushing forward DroneTM significantly in the months to come - stay tuned.

OpenAerialMap

A new STAC-based API was released at the end of 2025. While not widely advertised - due to the lack of a nice UI to utilize it - the API is available to developers and power users wishing to get an early start on usage.
Going forward, HOT will be working on a new imagery uploader in 2026, in addition to running a new UI to easily visualize available imagery.

Note

STAC is an interoperable standard that will facilitate serving a much larger catalogue of open imagery, with richer metadata information, and potential for federation (self-hosted imagery from a government, university, individual can all be incorporated into the larger catalogue).

Remote Mapping

Tasking Manager

In 2025, we worked on a significant upgrade to improve performance, stability, and future-proof the tool into the future.
The primary goal has been to freeze the current capabilities of TM, then ensure the stability of the platform as it is now.
The most recent feature to be added was the Super Mapper badge capability.
We are also close to finalising the ability to map within a ‘sandbox’, so the data is not uploaded to OSM in sensitive contexts or private datasets.

fAIr

While fAIr has had many improvements and model iterations over the years, a major shift in its approach is underway.
Instead of HOT being primarily an AI-model generator, instead we will host fAIr as a platform to connect the geoAI community/developer/engineers with humanitarian open mapping community. This will make open GeoAI models usable by the open mapping community, without the need for tech/programming skills.
We have also finalised work on fAIrSwipe: enabling users to validate fAIr generated features and push them to OSM within MapSwipe.
A new team member in Tech will be pushing this forward into 2026, alongside the existing fAIr team.

Field Tagging

Field Tasking Manager

FieldTM has continually morphed in different directions since its prototyping in late 2023.
After many rounds of user feedback and continual iteration, we have settled on a simpler approach to field mapping.
The primary focus will be as a project creator in downstream field mapping tools (primarily QField and ODK Collect). The area can be divided up with FieldTM, but the task assignment and progress tracking will be handled in ODK or QField.
Stay tuned for a major update in the coming months that will bring a simpler user interface and user experience.

ChatMap

ChatMap has gone from success to success, culminating in a very effective response to Hurricane Melissa in 2025.
A re-design is about to be launched in February, including an option to see live map updates as users send messages in the field.
There will also be integration with other tools (e.g. ESRI), user accounts, new options for filtering content, and a feature for saving maps directly into ChatMap (uMap will now be optional).

Data Insights

Export Tool

Export Tool is currently in a feature freeze stage, where no new active development is taking place.
The website is still available and functional for those wishing to export OSM data.
A review is being made of the underlying OSM data export capabilities, and if the tool could be simplified to ensure its longevity.

Quick Summary

Where each tool is heading in 2026

Drone Tasking Manager

Recent achievements

New image upload capabilities, resilient to dropped connections, with some validation checks in place
Addition to QGroundControl and MavLink flightplan output types

What's next

Addition of Potensic Atom 2 (low cost ~$500 drone)

OpenAerialMap

Recent achievements

Release of a new STAC-based API with richer metadata support
Foundation laid for federated imagery catalogues

What's next

New imagery uploader and imagery discovery interface

Tasking Manager

Recent achievements

Major migration to new future-proof foundation
Introduction of the Super Mapper badge
Foundations laid for 'sandbox' mapping, with release imminent

What's next

Feature freeze with a focus on stability and long-term maintenance

fAIr

Recent achievements

fAIrSwipe: integration with MapSwipe

What's next

Shift in strategy toward community-driven AI workflow platform

Field Tasking Manager

Recent achievements

Addition of QField as an option for mapping app

What's next

Simplified user experience with new user interface
Further refinements to the QField mapping workflow, via plugin

ChatMap

Recent achievements

See map updates live as they are collected
Saving maps to revisit later

What's next

Expand support for visualizing in other GIS tools

HOT Portal

Recent achievements

Unified login added to DroneTM

What's next

Dashboard launch and announcement
Unified login for all of our tools

Need webhooks? Just use the Postgres HTTP extension

Sam Woodcock — Thu, 18 Dec 2025 00:00:00 +0000

Reducing complexity

I previously wrote a blog about using pg_notify and a Golang listener to create a webhook based on Postgres events.

I no longer believe this is the best approach, after trying out the pgsql-http extension for this use case.

The http extension is super simple:

Ensure the extension is installed and enabled.
Create an SQL trigger for an event in your database.
Call a function from your trigger that does a http call (GET, POST, etc possible).
You can send a payload to an external webhook, including DB data, and even an X-API-Key header for authentication (or whatever you use in your API).

Now we no longer need an external service / listener running to wait for the events. Everything can be handled entirely in Postgres (a pattern that I am really loving recently, from cron jobs, webhooks, ML embeddings, etc).

How this works in practice

Adding the extension

A custom dockerfile is very simple:

FROM postgres:18 AS pg-18

RUN apt-get update \
    && apt-get install -y postgresql-18-http \
    && rm -rf /var/lib/apt/lists/*

You can use the same logic to add the extension to a Debian server install.
I actually build and publish pre-built images based on this exact logic - simply adding the extension into the official image here

For example: docker pull ghcr.io/hotosm/postgres:17-http

Adding a database trigger

If you manage you own database schema, you can add functions and triggers to your hearts content. Just add a http_request.

PERFORM http((
    'POST',
    'https://some.url.com/endpoint',
    http_headers('Content-Type', 'application/json'),
    'application/json',
    webhook_payload::text
)::http_request);

I was adding this to an existing database schema for ODK Central, so instead opted to build a small Golang CLI for installing and uninstalling the trigger, based on certain events.

For the example implementation, see this repo

The field mapping phoenix

Sam Woodcock — Tue, 09 Dec 2025 00:00:00 +0000

A bittersweet message

This blog is somewhat bittersweet, given my previous blog from 8 months ago. A lot can change in that time.

The NGO sector has gone through a funding crisis of sorts, in the wake of the USAID cuts vis-à-vis the Trump administration.

The Field Tasking Manager (FieldTM) project that I have worked on-and-off for 2.5yrs is in the process of direction shift and reduced funding.

Disregarding internal politics and my initial disapproval of the decision making around this, I have started to see this as a positive shift for the field mapping community, for which I will explore further below.

Existing field mapping tools

In my opinion, the following are the best-in-class for open-source field data collection tools:

QField: very much geospatial focused and is map-first from the start. There has been a big push recently from the team to improve the user experience for less GIS-savvy users, including incorporating a data collection model based on XLSForms. It has over 500,000 active users.
ODK: what we based FieldTM on from the start. With over 2 million annual users, ODK is the current standard for survey based data collection in many sectors. They are undergoing a transition to add options for map-first workflows, instead of form/survey-first workflows. I still love ODK and believe it is a good complementary workflow to QField.

Both tools have a great community and a strong team of active developers.

Scope of the FieldTM project

Under my stewardship, we tried to be ambitious and make a comprehensive all-in-one field mapping solution.
This encompasses the creation of field mapping projects, collection of survey data directly in the FieldTM tool, and then visualisation of submission data in a unified place.
In hindsight, we coupled the solution a bit too tightly to a single tool, reducing the potential for more dynamic integration with other downstream mapping options.
I also failed to appreciate how difficult creating a field mapping tool is, and have since reflected this is best left to organisations with more resources and bigger tech communities. Particularly regarding offline workflows and conflict reconciliation mechanisms.

Where do we go now?

We are reducing the scope of FieldTM: a simple, reliable project creator that configures and hands off to downstream tools: QField, ODK, and potentially others.
At this point in time, we already have most of what we need to add coordination and tasking mechanisms into these downstream tools rather than implementing it ourselves in a layer above.
This shift feels less like a retreat and more like a return to the core purpose of FieldTM: enabling field teams to coordinate, plan, and execute mapping campaigns using the tools they already know and trust.
If anything, a leaner FieldTM will incorporate all of our learnings and missteps to date, emerging as something more resilient, maintainable, and genuinely useful for the community it is supposed to serve.

Stay in the loop

Keep on top of the ongoing changes to FieldTM via Github issues and discussions in the Git repo.
We will firstly be focusing on a solid integration with QField and QFieldCloud as underlying mapping tools.
Call to action: if you are a software developer or field mapper, your input into the project future is very much welcome!

Sam Woodcock

Why many 'tech for good' software projects fail

A recurring story

Five common failures

1. Growth over equity

2. Institutions captured by whoever pays

3. “Me” over “we”

4. The innovation fetish

5. Extraction and dependency

The path to success

A simpler way to think about it

Postscript: tools I try to build in this spirit

Intro to photogrammetry

How I ended up here

What even is photogrammetry?

Stage 1: Structure-from-Motion (the sparse bit)

Incremental vs global

COLMAP vs the OpenSfM fork

Stage 2: Multi-View Stereo (the dense bit)

Could OpenMVS be replaced?

Where COLMAP falls down here

Wrapping up: what’s best for what?

What to watch for

How to fix the eSIM eUICC on a Google Pixel running GrapheneOS

Pretext: broken firmware

The Fix

1. Root Graphene

2. Fix The eUICC

1. Install LineageOS

2. Update The euiccpixel Package

3. Fix The eUICC

4. Reflash GrapheneOS

Automate the setup of Garage S3 standalone mode

Why Garage?

Is Garage a good replacement?

Automating the setup of Garage via Compose

Using LLMs ethically

The bigger picture

Can we live life virtuously?

Which hills are we willing to die on?

What can we realistically strive for?

Creating an ethical usage framework for LLMs

Getting crushed in the wheels of the hype train

Energy usage: a red herring?

Genuine concerns

The least bad option

Contribute to the discussion

A coders approach to storing recipes

Sometimes I like to cook things

Hosting your own recipes

Mealie

Nextcloud Cookbook

Cooklang

View the recipes

A second attempt reverse engineering drones: Potensic Atom 2

The Potensic Atom 2

The New Waypoint Format

global.json

<mission_id>.json

Photo Thumbnails

Pre-Generating Waypoint Missions

Updating The drone-flightplan Python Package

Testing It All Works

Additional Findings

HOT 2026 Q1 Tech Summary & Roadmap

Tech Into The Future

End-To-End Mapping

Where Are We Now?

HOT Portal

Imagery Collection

Drone Tasking Manager

OpenAerialMap

Remote Mapping

Tasking Manager

fAIr

Field Tagging

Field Tasking Manager

ChatMap

Data Insights

Export Tool

Updating The `drone-flightplan` Python Package