HamClock è un piccolo pannello informativo pensato per la stazione radio: mostra su una mappa mondiale la posizione dei radioamatori, le condizioni di propagazione, i dati solari, i satelliti e una serie di altre informazioni utili all’attività radio. Nato come applicazione estremamente leggera, sia su Raspberry Pi che su ESP32, è stato per lunghi anni una presenza quasi immancabile sulle stazioni radiantistiche.

Dopo la scomparsa del suo autore, Elwood Downey (WB0OEW), e la conseguente fine dell’infrastruttura che lo alimentava, sembrava destinato a diventare rapidamente un pezzo di storia. E invece, a distanza di mesi, HamClock continua a funzionare: non più grazie a una sola infrastruttura, ma grazie al lavoro della comunità che ne ha raccolto l’eredità.

Info

La morte di Elwood Downey (WB0OEW), creatore di HamClock, ha lasciato improvvisamente senza il proprio riferimento non soltanto un programma, ma soprattutto l’infrastruttura che lo alimentava. HamClock, infatti, appariva agli occhi dell’utente come un pannello autonomo, ma in realtà una parte significativa del suo funzionamento dipendeva dai servizi gestiti da Clear Sky Institute: dati solari, propagazione, mappe, feed e altre informazioni venivano aggregate dall’infrastruttura che Downey aveva costruito e mantenuto nel tempo.

Con la fine del servizio originale, annunciata per giugno 2026, il problema è diventato concreto. Il codice del client non era sparito: HamClock era, e rimane, software open source, distribuito con licenza MIT. Ma avere il codice non significa necessariamente avere anche i servizi che quel codice si aspetta di trovare dall’altra parte della rete. Ed è proprio questa distinzione che rende interessante la storia di HamClock.

Per le installazioni più vecchie il problema è particolarmente evidente: il client originale era stato progettato attorno all’infrastruttura di Clear Sky Institute e non prevedeva un meccanismo semplice e generalizzato per sostituire il backend. Quando i servizi originali hanno iniziato a degradarsi, quindi, il problema non era tanto il programma installato sul Raspberry Pi o sull’ESP, quanto ciò che si trovava dall’altra parte della connessione.

La comunità radiantistica si è trovata così davanti a una scelta abbastanza insolita: abbandonare HamClock e sostituirlo con qualcosa di completamente diverso, continuare a mantenere il client originale oppure ricostruire l’infrastruttura necessaria a farlo funzionare.

Le strade che si sono aperte sono sostanzialmente tre, e sono interessanti proprio perché rappresentano tre filosofie diverse.

OpenHamClock

Se HamClock era un’applicazione scritta in C, progettata per essere estremamente leggera e capace di girare praticamente ovunque, a partire dai piccoli moduli ESP, OpenHamClock nasce invece con un’architettura decisamente più moderna: un’applicazione web open source (licenza MIT) con frontend React e backend Node.js, sviluppata dalla comunità attorno a Chris Hetherington, K0CJH. Il backend funziona da proxy e aggregatore verso le diverse sorgenti esterne, mentre React si occupa dell’interfaccia.

Non siamo più davanti a un piccolo programma che parla direttamente con un’infrastruttura costruita attorno a lui, ma a una vera applicazione web capace di integrare fonti diverse, con le funzionalità ampliate parecchio rispetto all’originale: DX Cluster, PSKReporter, POTA e altre attività di attivazione, dati meteorologici, informazioni satellitari, diversi livelli di propagazione e un sistema di plugin per aggiungere nuovi layer alla mappa. Per chi è affezionato all’estetica originale è stato mantenuto anche un layout Classic, con i pannelli e i caratteri colorati su fondo scuro: il passaggio, almeno visivamente, non è traumatico.

Naturalmente questa architettura ha un prezzo: OpenHamClock non è più un piccolo binario autonomo installabile ovunque, e l’installazione locale è più esigente in termini di dipendenze (il progetto fornisce comunque le procedure che facilitano l’installazione su un PC o un Raspberry Pi moderno). E c’è un’altra differenza importante: OpenHamClock non elimina la dipendenza da Internet e dai servizi esterni, ma la cambia. Il backend continua ad aggregare dati da numerose fonti (NOAA, POTA, SOTA, PSKReporter, CelesTrak, Open-Meteo, DX Cluster e altre), passando così da una dipendenza verticale verso un’unica infrastruttura a una dipendenza orizzontale da una costellazione di servizi indipendenti.

Per chi dispone di un Raspberry Pi o di un PC e non ha particolari esigenze di compatibilità con il vecchio hardware, OpenHamClock è probabilmente la soluzione più moderna e più ricca di funzionalità.

OpenHamClock è disponibile online, con il repository su github.

Ma non è l’unica strada.

HamClock continua a vivere

La seconda possibilità è forse quella più interessante per chi non vuole semplicemente sostituire HamClock, ma vuole continuare a utilizzare il lavoro di Elwood: il sorgente originale di Clear Sky Institute non è andato perduto, visto che il client era stato pubblicato con licenza MIT e la comunità ha potuto quindi prenderlo, conservarlo e continuare a svilupparlo.

Oggi il punto di riferimento è il repository  su github, che si presenta esplicitamente come la sorgente primaria per la manutenzione del client. Il progetto è partito dal sorgente della versione 4.22, l’ultima realizzata da Clear Sky Institute, e mantiene il client originale come frontend compatibile con le specifiche HamClock in evoluzione. È un dettaglio importante, perché consente di distinguere il progetto dal semplice archivio storico delle vecchie versioni: il codice non è stato soltanto conservato (è disponibile online su github),  ma è diventato la base di una continuazione comunitaria del client.

Rimaneva però il problema principale: il client, da solo, non era sufficiente. Serviva un backend, ed è qui che entra in gioco Open Hamclock Backend, abbreviato in OHB. Vale la pena notare che è stato lo stesso Downey, nella release 4.22, ad aggiungere l’opzione -b per puntare il client a un backend alternativo: un dettaglio tecnico che si è rivelato decisivo, perché è proprio questo meccanismo ad aver reso possibile, in seguito, il collegamento a un backend sostitutivo come OHB.

Open Hamclock Backend

OHB è probabilmente la risposta più interessante per chi vuole continuare a usare il vecchio HamClock senza dipendere dall’infrastruttura originale di Clear Sky Institute. Si presenta esplicitamente come un backend open source sostitutivo: mantiene l’interfaccia del client originale generando dati di propagazione, mappe e feed da fonti pubblicamente documentate, e può essere eseguito su hardware relativamente modesto, anche un semplice Raspberry Pi 3B+.

Il punto interessante è che OHB non obbliga tutti gli utenti a un unico nuovo server centrale: il backend può essere installato localmente e diventare parte integrante della propria stazione. È proprio questa possibilità di distribuire il backend tra più installazioni indipendenti che affronta direttamente il problema emerso con la fine dell’infrastruttura di Clear Sky Institute: il progetto dichiara infatti esplicitamente di voler mitigare il rischio di una nuova infrastruttura centralizzata attraverso istanze indipendenti e federate. Esiste anche un’istanza pubblica, raggiungibile attraverso ohb.hamclock.app, per chi non vuole gestire personalmente il backend; ma chi preferisce avere il massimo controllo può installarlo sulla propria macchina e rendere la propria installazione sostanzialmente indipendente da un singolo servizio centralizzato.

È una differenza filosofica non secondaria. Con HamClock originale avevamo un client open source ma un’infrastruttura fortemente centralizzata; con HamClock e un backend OHB self-hosted possiamo invece avere sia il client sia il backend sotto il controllo della comunità o, se vogliamo, direttamente sotto il nostro controllo. Naturalmente neppure questa soluzione rende il sistema completamente indipendente da Internet – OHB continua a utilizzare fonti dati esterne – ma non esiste più necessariamente un unico punto attraverso il quale devono passare tutti gli utenti. Ed è probabilmente questo il risultato più interessante di tutta la vicenda.

Tre modi diversi di raccogliere l’eredità di HamClock

A questo punto le tre strade sono abbastanza chiare. OpenHamClock prende l’idea originale e la reinterpreta completamente, costruendo una nuova applicazione moderna, più ricca e più facilmente estendibile. Il progetto HamClock di Open Hamclock mantiene invece il client originale, conservandone filosofia, interfaccia e compatibilità, ma separandolo progressivamente dal vecchio ecosistema di Clear Sky Institute. OHB interviene sul punto più delicato, quello rimasto scoperto dopo la fine dei servizi originali: ricostruire un backend compatibile e, soprattutto, renderlo distribuibile.

Non è quindi soltanto la storia di un programma che rischiava di morire con il proprio autore, ma anche una piccola lezione sull’open source. A prima vista HamClock sembrava un esempio perfetto di software libero e indipendente: il codice era disponibile, il programma poteva essere installato localmente e poteva funzionare su hardware estremamente economico. Ma il codice aperto non significa necessariamente infrastruttura decentralizzata. Quando Elwood Downey è venuto a mancare, il codice non è scomparso: quello che è venuto meno è stato il servizio che quel codice utilizzava. Ed è proprio qui che la comunità ha potuto fare la differenza: qualcuno ha scelto di riscrivere l’applicazione, qualcuno di continuare il client originale, qualcun altro di ricostruire il backend: tre approcci diversi allo stesso problema, resi possibili dal fatto che il codice era aperto.

Alla fine, quindi, la domanda non è soltanto quale HamClock scegliere. È anche quanta dipendenza da un’infrastruttura esterna siamo disposti ad accettare.

E forse questa è la parte più bella della storia: HamClock non è semplicemente sopravvissuto alla morte del suo autore: ha cominciato a diventare qualcosa di diverso, costruito non più attorno a una sola persona e a una sola infrastruttura, ma attorno a una comunità.

Ed è, in fondo, proprio questo il bello del codice aperto.

Info