14 Years, 2 Million Installs, and a Fascination with Lightning

Blitzortung.org is a remarkable community project: thousands of hobbyists around the world build and operate their own lightning detection stations, assembling a worldwide, community-powered lightning location network in their spare time. I was fascinated by the idea — and by thunderstorms in general.

Back then, the live data was only accessible on the project’s website. So I decided to write an Android app to visualize it on a map. Android itself was still young. The first versions were simple: a map, colored strikes, an alarm when a storm was approaching. But people started using it. And once people use your software, you’re responsible.

If you want to feel how much a platform can change in 14 years, maintain one app for that long. Just some of the things that broke — or were rebuilt — along the way:

The biggest technical lesson: you never stop migrating. An app that survives is not the one with the best architecture at launch — it’s the one that can be continuously refactored without breaking. 1,456 commits and more than 200 releases later, almost nothing of the original code remains. And that’s exactly how it should be.

Not every migration was driven by technology alone. In 2019, the app still ran on the long-deprecated Google Maps API v1 — a proprietary dependency that had to go for two reasons: it was effectively unmaintainable, and as long as it was in the app, F-Droid — the free and open-source app repository — could not distribute the app at all.

So I rebuilt the map layer on OpenStreetMap. It was the right decision: the app became fully free software, independent from proprietary licensing, and available to a community that deeply cares about openness and privacy.

It was also the moment I learned what a map means to people. The new one looked different, behaved differently, and initially missed some beloved details. The reaction was one of the roughest phases of the whole project: a wave of one-star ratings and harsh reviews from users who felt their app had been taken away. Some of that criticism was fair — and the map steadily got better because of it. But it was a strange experience to be publicly pressured over a change that was technically necessary, and made precisely to keep the app free and open.

One design decision shaped the app from the very beginning — and I have been explaining it ever since. Together with the maintainers of Blitzortung.org, we agreed that the app should not display full-precision lightning locations. Instead, strikes are accumulated on a data grid — counts in squares of a few kilometers.

On paper, that sounds like giving users less. In practice, it turned out to be one of the best decisions in the project’s history: the grid keeps the app responsive even during the heaviest thunderstorm activity, it drastically reduces network usage, and it is what made the animated history view possible in the first place. Precision that a phone cannot render smoothly is precision nobody benefits from.

And yet, some users resent "not getting the full information." The irony: the point representation they long for is itself only the result of a statistical calculation, with a lateral error that varies from strike to strike — a dot on the map may sit far from where the lightning actually struck. What looks like an exact position suggests a certainty that physically isn’t there. The grid is more honest about that truth, and it took me a while to fully appreciate that overcoming the convenience of apparent precision was not a compromise — it was the better model, all around.

Operating my own backend on a hobby budget came with an early lesson in cloud economics. In the early days, the backend ran on one of the big hyperscaler cloud platforms — and as soon as the first monthly bills arrived at more than $100, it was clear that this would not be the way to go. Since then, the backend runs on two redundant virtual servers as part of the hosting.de offering: without a single issue, and for a fraction of the price.

The hyperscalers' flexibility is real — but for a steady, predictable workload, boring traditional hosting wins on every metric that matters for a side project.

The most recent chapter deserves its own mention. In the last year, LLM-assisted coding has changed the game for this project — as it has for so many others. Features that once consumed whole evenings now take a fraction of the time, and refactors I would previously have carefully avoided suddenly became affordable. It even enabled something I had long postponed: porting the original server backend to a modern Rust implementation, bo-srv-rs.

For a one-person project, that is more than convenience — it’s a second wind. But I’ve also learned that the tools don’t decide what is worth building. That part still takes the 14 years of scars.

That episode put a longer-standing tension into words. Two million installs is a cumulative number — the app’s active user base today is around 150,000 people. Either way, this project deliberately has no business model: no ads, no tracking, no premium tier, no income. It is a hobby, built with enthusiasm in stolen evenings.

The vast majority of users understand that wonderfully, and their appreciation is what keeps the project alive. But some treat a free app as if it were a commercial service they had paid for — and use one-star ratings as leverage to demand features or instant fixes. Early on, that genuinely hurt and gave me more than one headache. Over the years, I’ve grown much more relaxed about rough communication. An angry review contains information like any other feedback: take the content, leave the tone. And I’ve come to see the anger as attachment — people only got this upset because the app matters to them. That doesn’t make the one-star rating a fair verdict. But it makes it possible to read it calmly.

From day one, the app has been open source. That decision shaped everything.

Over the years, contributors have sent translations, bug fixes, and improvements I would never have thought of — or gotten to. Users wrote reviews that were often more useful than any QA process. F-Droid packaged and distributed the app to an audience that cares deeply about open source and privacy. And the Blitzortung.org community kept extending the network’s coverage across Europe, the Americas, Asia, Africa, and Australia — my app is just a small window onto the data they collectively produce.

A one-man project became something owned by many. That’s the quiet superpower of open source: it turns users into co-owners.

A few things 14 years of a side project taught me:

One realization took me longer than it should have: documentation is a feature, too. An app can only be used for what people know it can do — and over the years it became clear that a good documentation helps users discover exactly that. So the project grew a dedicated documentation, hosted at blitzortung.tryb.de, with its sources in the open blitzortung_apps repository. Explaining what the app is for turned out to be almost as valuable as building it.

This milestone is not mine alone, and a few thank-yous are overdue.

To TNG, my employer back then: the app’s very beginning traces back to your TechDays. Using that time to dive into the Android ecosystem was the seed from which everything else grew — a reminder that letting engineers explore new technologies during working hours pays off in ways nobody can plan in advance.

To the users who became contributors: everyone who contributed a translation, sent a pull request, or took the time to write valuable feedback — encouraging and critical alike. You turned a one-person side project into something owned by many.

To the station operators of Blitzortung.org, whose data powers every map this app has ever drawn — and to everyone who trusted a free, open-source, privacy-friendly app with a spot on their home screen.

I’m curious what the next 14 years will bring. The storms, at least, are guaranteed.

🔗 Blitzortung Lightning Monitor — free on Google Play and F-Droid, open source under Apache 2.0 on GitHub, with the full documentation at blitzortung.tryb.de.

#AndroidDev #OpenSource #SideProject #Kotlin #Blitzortung #Thunderstorms #Community