TLF, open source contest logging SW, and contest logging SW future

[Drew Arnett]

I think asking what is in the future is a great question.

Is it continued innovation and features for the top contesters?  You
know, the ones who need 2 or more radios to keep from getting bored
during a contest and are doing 400+ QSOs/hour.  Is there room for
innovation for more average contesters like me?  Is it some specific
new feature or modification to tlf?

I think it would be very interesting, and perhaps challenging, to try
to compile a document describing all of the features everyone would
want, even when those conflict.  (It's software, and, within reason, I
think it is good to accommodate different preferences different people
have.  Sometimes this can be done well in a single program; sometimes
this means having several different programs.  The open source
ecosystem is a good example.)  Writing a second product specification
document from that would be interesting as well.  Not going to tackle
this myself, but would be fascinating reading.

For me, the future of contest logging software is having an open
interoperability specification for networking contest loggers.  I
think this is the highest priority.  If we had it, then when operators
get together for multi-op contesting (from Field Day or CQ WW),
everyone can bring their own SW to use with whatever customization it
has that suits their preferences.  And can bring whatever operating
system compute device as well.

The src directory for tlf (in debian stable) looks to be about 35 KLOC
(kilo lines of code).  I wanted to find out how much python it would
take to write a (like tlf) TUI contest logger.  (And I wanted a
vehicle for experimentation.)  1 KLOC was enough and not a lot of
hours were required, either.  This did *not* have assistance (spotting
network), live score tabulation, mults needed, bandmap (that is no
realtime analysis or guidance).  This did have cwdaemon and rigctld
client capability, serial number generation, highlighting when fields
have valid content, country file, super partial, and call history
support, dupe checking, macros, and enter-send-mode.  The TUI API is
so similar to a GUI API that porting to a GUI like Qt5 would be easy.
And the TUI and python code should run cross platform as is.  Yes, a
large portion of the code is UI and UX.

I think the only limitation is imagination or that requirements
gathering and product specification exercise.  (Networking is the only
feature missing to either have my friends use my software or for my
software to interoperate with N1MM or whatever they use when we get
together for multi-multi contesting several times a year.)  But still,
I'd like to see an open interoperability specification for networking
contest loggers even before an elaborate specifications doc.

I'd be very interested to read what others think about the future for
tlf and contest loggers in general on a large or small scale.  And I"d
find it very interesting to read about features and functionality
people want or just want to try out.

Fun stuff.

Drew
n7da