DXLab Does Not Support SmartSDR v 3

First, I'd like to say it's always possible to do more work and provide more support than we've provided to our third party developers.  Dave's comments, while harsh listening from the inside of FlexRadio and also unique in their voracity, are not the only comments that we've received saying that we could do more to support developers over the years.  

As a young ham in college I purchased a Kenwood TM-721A, a dual-band VHF/UHF FM transceiver.  I really loved that radio, especially the inverted color LCD display technology used.  From my standpoint, that radio was ahead of it's time and it was a great seller for Kenwood.  Even today, I still find that radio "beautiful."  Writing code was my passion as a young man and I wanted badly to **** open the case and add my own capabilities to that radio.  I wondered why, in a hobby like ham radio where we're all learning and experimenting, the radio could not provide ready access to the guts to let me play with it.  I didn't expect Kenwood to make the radio available for me to play with in this manner, but I didn't forget what that felt like either.  After we'd developed the API for internal use at FlexRadio, I pushed hard to open it to the world and provide it so others, like myself, could expand its capabilities, experiment and learn about radios.  And I knew the investment would bring capabilities and pleasure to our customers.  From my perspective and from a company perspective, I'm very glad we did this, it was the right thing to do and I'd do it again.

But like any business decision, opening the API comes with a cost and we've not always invested as heavily in the API as we could have.  When we first opened it, I and the other engineers spent many late nights and weekends updating the Wiki that houses the TCP/IP API and Eric wrote documentation to support the Windows side of the API.  Our team has worked to keep both of these sets of documentation current.  When we first released the API the Wiki had only a portion of the commands in it at launch.  This is no one's fault but mine.  It's probably fair to say I drug FlexRadio into the API world and FlexRadio took me at my word that it was the right thing to do without knowing the cost of maintaining the API for all time and as a result we've occasionally struggled to keep up.

As an engineer, I know what's hard and what's not so hard in the software world.  Generally, getting started in something new is what's really hard.  Once you have your first program running, adding capabilities and experiencing how they work, you can incrementally add and test and the mental work load goes down and the fun goes up.  As a result, I wanted to make sure the basics were well documented and that there were tools to find out everything else.  More than once, I told someone interested in developing for the platform that they could "get the basics from the Wiki on how to connect and communicate to the radio and then literally anything else you want to do can be discovered simply by running WireShark and watching the traffic between the client and the radio."  For the uninitiated, WireShark can display all the commands between the radio and any client.  To discover how to do something, you can watch the communications and press the button in SmartSDR then watch what command we send.  This is not ideal, but to an engineer like myself the message is clear: you can do anything we [FlexRadio] can do because we are layered on the API ourselves.  It's not something "separate" that we have to keep up to date.

Knowing for some that this would not be enough, we also created a community topic for the API that encourages sharing information and an email help line just for developers.  This email, devhelp@flexradio.com, goes straight to the desk of the engineers.  We are committed to answering 100% of the emails that come in this way, in part because we know that everything is not always documented as well as we would like, but also because we love engineers just like we love customers and we yearn to help them experience the fun of writing software in and along with radios and we know that what they do is for the benefit of our mutual customers.

With SmartLink, we needed to use cryptographic techniques for a number of reasons related to security and the protection of our customers and their equipment.  This, necessarily, made understanding what we did with SmartLink harder without documentation.  We were asked to write a comprehensive guide on how SmartLink works for developers.  We're a small shop with a few engineers and we did what we felt like we had time to do -- we wrote a guide that would get developers jump-started and had what we felt like were the necessary details.  We've provided this now to a number of fellow developers who have coded to SmartLink.  With multiFLEX, it was a whole other world.  We changed the guts of the radio to support multiple clients at the same time and this work was non-trivial.  We actually wanted to do this when the radio first shipped but it was hard enough we had to shelve it and only now had the time to implement.  We discussed how to make the API backward compatible since we'd done this every time in the past.  Making it backward compatible would allow a companion program to use either command set (v2 or v3) and it would work -- of course without using the v3 commands, no multiFLEX capabilities would be possible.  As we discussed it, we realized that the API would be less understandable and would look awful over time.  I could go into detail on this, but suffice it to say that we wanted to avoid confusion and make it easy to understand moving forward.  Right off the bat we developed a migration guide that explained the API differences and showed examples of old and new code to assist developers with the migration.

Since that time, we've had several developers take what we've written and adapt their code.  We're asking a lot -- for the engineer that wants to support both v2 and v3, they have to have their code spit out different versions of the commands and parse different responses based on whether v2 or v3 is running.  It's not ideal, but it's not always an ideal world.  We looked at what other engineers have done and felt like it was a greater error to "bastardize" our API rather than force developers to support two API calls depending on version.  Our customers reading this should give developers that have chosen to go along with us on this a pat on the back.  These guys are troopers.  In a way, what we've done is unfair -- we've asked them to update their API when it was convenient for us or their software will no longer work with ours.  Was this something we wanted to do?  Of course not.  Could we have done it differently?  Yes.  Do we feel like we made the best choice we could?  Yes.

I'm proud that FlexRadio, in the spirit of ham radio, opened our API to the community.  I wish we had time to do everything asked of us in this regard, but we do what we feel we have time to do.  We answer every question posed by developers and like Dave has said, when developers call or ask for help we drop what we're doing to help them.  Dave is a nice guy -- I've met him at several hamfests.  While I disagree with his approach of calling us out publicly, he writes good code and his application is well loved by the amateur community.  Dave is, in a sense, right to criticize us.  I would like to do all the things Dave and other developers have asked of us.  At the same time, we have a large customer base that is also asking us to add features, repair defects, stay the leader in SDR technology and work capabilities in their particular niche of the amateur world.  We want to do all of these things, we really do.  We regularly look at the list of all the things we could do and make those choices.  We are often not happy making those choices -- we want to do everything.  Let me say that again: every engineer we employ wants to do everything our customers and developers ask of us.  We can't, but we do listen to the feedback and we do what we are able to do.  

We are passionate about what we do.  We know that some will look at what we've done and celebrate the decisions we've made and what we've created.  We also know that others will malign us for our choices.  Neither group are every entirely wrong.  In Star Trek II, The Wrath of Kahn, (sorry I'm a bit of a trekkie), Captain Kirk asks Spock how a new crew on the Enterprise will respond in a crisis.  Spock's response, "As with all living things, each according to his gifts," tips a hat to what we all know: each of us has gifts and capabilities that we can bring to bear on a problem, but there are limits to the capabilities of all living things.  The same goes for abstract entities composed of those living things: companies.  We do the best we are able, but we also provide several easy ways for developers to reach us if you feel we've not done enough.  We'll always want to do more and if you ask nicely and we're able, we'll drop what we're doing and help because that's what hams do.