HamBus Interopt Project looking for open source developers

Discussion in 'Amateur Radio Software' started by WA1GON, Jun 14, 2018.

ad: L-HROutlet
ad: l-rl
ad: Subscribe
ad: Left-2
ad: L-MFJ
ad: Left-3
ad: MessiPaoloni-1
  1. WA1GON

    WA1GON XML Subscriber QRZ Page

    I have been thinking about doing this project for many years and now I think I have the time to make it happen. This is just getting started, so it very much work in progress.

    The group is called the Amateur Radio InterOpt Foundation(ARIF). (http://www.hambus.org) Everything that comes from the foundation will be open source under either the Apache license or the MIT license. These licenses allow developers of software to use ARIF software and libraries in their products without fee or changing their license. Also, all software will be written to run on Windows, MacOS, Linux, and OpenBSD when possible. There will be some cases that it won't make sense to try to write it other OS. For example, OmniRigBus has to use Microsoft COM objects which aren't supported by MAC or Linux.

    While ARIF will create some reference applications our goal is not to compete with commercial Amateur radio software application.

    HamBus suite is ANYs. When completed it will allow any radio, interoperate with any logging software, on any system, any radio, any programming language, anywhere. It will do this using a combination of ReST HTTP API, UDP, and TCP protocols on microservices. Applications no longer will need exclusive access to a serial port to send and receive CAT commands.

    The number of microservices buses is fairly unlimited. There can be logBuses to add QSOs to databases, DXBuses to spot DX, RigBuses to control rigs, etc.

    Who we need!

    First and foremost we need developers. I have been writing software for 45 years and I have a good architecture that will work.

    Second, we need a board of advisors. These should be amateur radio application developers that like the idea of being able to inter-operate to advise on needs, pain points, demands, etc.

    Please consider joining! You can join any of our mailing list from our website.

    Thank you and 73
    Darryl Wagoner DE WA1GON
    Founder ARIF
  2. AA6YQ

    AA6YQ XML Subscriber QRZ Page

    Please post a reference to a description of your architecture.
    Last edited: Jun 14, 2018
  3. WA1GON

    WA1GON XML Subscriber QRZ Page

    The architect is fairly simple, but still evolving. Resources (radios, databases, rotors, etc will be middleware microservices called buses. Each bus will have a versioned API using Representation State Transfer (ReST) HTTP protocol. Each microservice will also provide its real-time API spec via swagger (see swagger.io).


    In this drawing, the logbooks and digital applications are the clients and the log database, radio and dxCluster is microservices buses.

    I am an agile developer, as such hard documentation is kept to a minimum. Most of which will be what the API will require as our target bus.

    If you are expecting waterfall type architecture documentation, that is not going to happen, as it is generally outdated before the first line of code is written and ends up being a paperweight.

    My plan is to focus more on Agile and best practices and less on documentation no will read. I work for a fortune 1 company doing a major mission-critical development and our architecture documents are generally 1 or 2 pages long and normally read once by the development team.

    As a developer, I encourage you to join us.

    Darryl WA1gon
  4. AA6YQ

    AA6YQ XML Subscriber QRZ Page

    One PowerPoint slide with 6 high-level components is not an architecture. An explicit architecture is essential. See, for example, The “4+1” View Model of Software Architecture.

    "We're doing agile, so we don't need no stinkin' documentation" has been the death of too many projects. You can't refactor your way to the correct architecture, and you can't maintain alignment among multiple geographically-distributed developers by telling them to keep reading each other's source code. Every microservice provides a contract that must be made explicit.

    You've evidently learned little about modern software engineering since your unfortunate contribution to the initial development of LoTW, where there were few comments in the code and even less as-built documentation that developers later joining the project could use to shorten their learning curves and reduce their rates of defect insertion. The absence of as-built documentation and automated testing remains the primary component of LoTW's technical debt, but at least the LoTW development team has been able to resume adding functionality, e.g. support for the CQ WAZ award.

    Join you? I'll pass.


    Dave, AA6YQ (member, ARRL-LoTW Committee, 2012-2017)
    K3DCW and K6CLS like this.
  5. AA6YQ

    AA6YQ XML Subscriber QRZ Page

  6. AA6YQ

    AA6YQ XML Subscriber QRZ Page

    To be clear, "explicit" does not mean "cast in concrete". Evolving from an initial architecture to an effective architecture resolves one of the largest risks facing any significant software project, and should be one of the primary objectives of early iterations.
  7. WA1GON

    WA1GON XML Subscriber QRZ Page

    I have seen just as many projects die on waterfall, maybe more. None of the problems LoTW had involved me. I didn't write a single line of code. Yes, I started the TrustedQSL project, but my personal life took a bad turn and I couldn't continue. Even if I had continued, it would hardly be proper to blame all of the LoTW issues on the TrustedQSL issues and design. Its sole purpose was to turn QSOs into TrustedQSLs.

    I am not saying we don't need any stinky documentation, important documentation is important, unimportant is a waste of time and money. I can also tell you that for the last 7 years, I have been working with and leading developers across the world to successful project completion with only a few pages of documentation for each epoch. The company as a whole went from waterfall to Scrum and Kanban. This isn't a small company, it is the largest company in the world. So yes, Agile does work and it works in a geographically, culture and language distributed environment.

    As far as every microservice having explicit contracts, of course. Not only will it have explicit contracts it will be documented in the service. This is also not rocket science. A RigBus microservice will do one thing. I.E. communicate with a radio. LogBus will do one thing manage the backend database. Except for a few cases, HamBus will not interact with each other and that will be minimal. Even with something that simple, we will get some of it wrong. However, we won't have to live with those mistakes forever as the HamBuses will have versions on the contracts.

    This seems personal, every encounter I have had with you, you have been hostile and insulting. It goes deeper than just professional differences and I really don't understand why. I would really like to know why you are throwing insults at someone you "professionally disagree" in a public forum" instead of private contacting me or just shaking your head and thinking that will never work.

    On the other hand, you could be on the advisory board and point out the areas we are screwing up. I would welcome that, not that I believe for a second you will take me up on it because of whatever you have against me personally, you are welcome and I think we could benefit from your experience and I like the idea of having someone I know will call me on legitimate issues.

    Note, I have said anything against you either professionally or personally. Waterfall methodology has its place and I am glad you are comfortable with it.

    Darryl DE WA1GON
  8. AA6YQ

    AA6YQ XML Subscriber QRZ Page

    Darryl, you ignored my (impersonal) critique of your TrustedQSL design, responding then in a manner similar to your response above. LoTW suffered for it; however, it must be said that TrustedQSL was far from the worst decision made during LoTW's development.

    Suggesting that you develop an explicit architecture is not an endorsement of Waterfall. Typical...
  9. WA1GON

    WA1GON XML Subscriber QRZ Page

    I didn't ignore your "critique". At the point of your critique, there was no design for TrustedQSL, except it would sign QSOs on the client side. That was at that point before the first line of code or any other documentation which for the original LoTW design document. Shortly after that, I removed myself from the project because of family issues. So all the insults that you are slinging at me are misdirected blame. Everything you have said about me, therefore, has been a personal attack, which you still haven't explained.

    Just wondering as I had no direct involvement in the implementation of either TrustedQSL or LoTW, what is the issues you see with LoTW and TrustedQSL? I agree that from a UI aspect a lot of work is needed and the way TrustedQSL was implemented seemed a little outdated even for the time, but it works.

    I am not saying there will never be architecture documents. The project is really just starting an I am just doing prototyping now. Most of the HamBus doesn't need an explicit architecture, as the function is well known. ie: RigBus controls the radio. What is needed is an explicit service contract.

    Darryl DE WA1GON
  10. KD2NOM

    KD2NOM XML Subscriber QRZ Page

    Great - so instead of having a constructive conversation about the development project being proposed, we get to once again watch two Ham's (for the moment) have a pissing contest in a public forum. Typical.

    Thanks David, Thanks Darryl.

    Here's a thought - David, why not join the team and help craft the document you are asking about?
    KB1NXE and AA7QQ like this.

Share This Page