[aprssig] APRS roadmap planning proposal

[Joshua Smith]

Speaking from an off-and-on APRS user and long time participant in the “free software” community perspective I agree with the framework outlined by Scott. 

The governance of the APRS protocol should occur in the open and an open source license model for the spec seems appropriate. 

As for how to organize the governing body I’d suggest taking a look at how the python project (python.org) as well as the FreeBSD (FreeBSD.org) governance are organized as they both seem to be organized for sustainability. 

I’d be happy to help to ensure APRS continues to prosper in any manner I can. 

Thanks,

--
Josh Smith
KD8HRX 

Sent from my iPhone. 

> On Feb 13, 2022, at 13:03, Scott Howard <showard at nd.edu> wrote:
> 
> 
> Hello everyone,
> 
> I'd like to take a stab at synthesizing discussions on the multiple threads into actionable items, with the goal of coming up with the 3 month goal with > 50% likelihood of success as was suggested. Below is a summary of the conversations (IMO), and I think goal #1 below is reasonable to aim for in 3 months.
> 
> In order of apparent priorities:
> 1) Maintenance of APRS as written.
> 1.1) Take inventory of all the documents (1.0, 1.1, the proposed 1.2, all the other notes on aprs.org). Create a public repository of these documents maintained as a team on something like github. This is a community resource (not gatekeeping) and a place where several people in a team have commit access to the new "home" of the APRS specification documents.
> 1.2) Create a mechanism for assigning and publishing new tocalls or any other thing that needs active maintenance. (This includes machine readable version of tocalls.txt). Probably simply github issues/pull requests with someone verifying that it hasn't been used before.
> 
> 2) Make APRS as written clearer/easier.
> 2.1) Possibly publish APRS 1.2 that clearly synthesizes all the errata and features that are currently in practice. This should be done in an open and transparent way. IMO, this spec should be published under an open-source license and essentially be non-controversial (i.e., no changes to practice).
> 2.2) Organize APRS 1.2 spec documentation around encapsulation based on OSI layers. This makes it easier to understand, to write software for (separate libraries/classes/modules for each layer), and to help future innovations/iterations consider changes to one layer (e.g., new radio modes) in a way that won't affect others. Such encapsulation makes it easy to articulate how one is experimenting with FX.25 alongside AX.25, for example.
> 2.3) Investigate potential depreciation candidates in the current spec. Depreciation does not mean "no longer supported." Deprecation just means "if you're making a new application, please don't use this feature. But your application should probably be compatible with someone else with legacy hardware/software using this feature."
> 2.4) Possibly create a "best practices" guide that is seperate from the specification document that covers both digipeaters and individual stations/users.
> 
> 3) Make APRS extensible in a backwards-compatible way (both on the physical layer and the presentation/application layers). Rather than trying to "pick a winner" as to what we should do next (what bands/modes? should we use something like protobuff?), come up with how APRS can be experimented with in a way that's compatible with the network. Bob made a huge innovation getting APRS up and running. Let's keep that legacy moving forward by allowing others to use APRS as the tool in driving innovation.
> 3.1) Figure out how to make the physical layer extensible
> 3.2) Figure out what an extensible presentation/application layer looks like.
> 3.3) Is this a new APRS 1.3, or is this just built on top of and using the existing spec?
> 
> I propose that we start off with just #1 above, but keep a list of future things to think about on the roadmap so they are not lost.
> 
> To get this done, we'd need a team of volunteers and someone to organize them. Volunteers are needed from the software, hardware, and end-user perspectives (we have had a bunch step forward covering all of that already!) Since the goal is to serve the community, IMO everything should be done in the open with opportunity for public feedback - so there's opportunities for people to casually inspect what's happening.
> 
> For coordinator (at least for #1), I'd nominate Hessu because of his perspective and expertise in the APRS ecosystem. However, I don't want to volunteer him if he's busy with all the work in maintaining a bunch of the APRS infrastructure. If no one else is interested, I'd volunteer to coordinate #1 above. (I put my background below as an introduction). But if there is anyone else that is well positioned to coordinate, then I'm happy to help out any way I can - I don't want to step on any toes.
> 
> What are people's thoughts about the above roadmap and beginning coordinating #1?
> 
> Cheers,
> Scott (KD9PDP)
> 
> Background: university professor in electrical engineering. Presented at DCC in 2020 on packet based image transfer that's robust to packet loss (compatible with APRS, but not intended for use on the APRS network). Faculty advisor to the student club developing a cubesat. As part of that I have helped them with 2 HAB launches and designed the software and hardware for APRS telemetry during flight (modified lightAPRS to include custom telemetry payloads, and designed+fabricated fast key-off digital mode PCBs so students could use low-power HTs to test APRS with direwolf.)
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20220213/928adcd6/attachment.html>