Hello Facundo,
HamAlert is currently receiving requests from various sources to add support for new, emerging outdoor/award programs. I suspect that Agentic Coding has been a major driving force behind this trend because it has lowered the technical barrier to entry.
While it’s nice to support everything (at least from the point of view of the concerned users), there are also disadvantages, like UI clutter, reference designator conflicts and maintenance issues. Sometimes there are even multiple (rival) programs for a given entity category. Each of them comes with their own reference structure, entity list and spotting platform, all using bespoke APIs.
I think before adding more of them, we need to define objective criteria for such programs to be supported by HamAlert, to avoid overloading the UI and codebase with niche things that are of interest only to a handful of users.
I’m still not sure which objective criteria to use when deciding whether adding a particular new program to HamAlert would be warranted. It will likely have to be a mix of maturity (e.g. been around for at least a year), user base (e.g. at least 1000 active users) and spot activity (e.g. at least 500 spots per month). Discussion welcome.
See also:
That said, the issue of adding a “Grid Square” condition (not related to any specific award program) comes up often, and I totally understand that. The challenge there is where to obtain accurate grid square information for a station even if the particular spot source (DX cluster etc.) does not provide it. See also:
73,
Manuel HB9DQM