I would wait to see that API implemented, running, and documented before leaping in. There's a very small population of customers who actually would use it, so it's more likely that development effort will focus on the non-API parts of the software, and on new features for the 95% of users, before features like an API for the 5%.
I'm pretty sure that Flex will want as many people building applications for the new radios as
they can get. The more "cool" stuff that is out there for the radios, the more they will sell.
Completely closed, no 3rd party applications would be a mistake in my opinion.
Maybe, but the ham world is very small. The number of people who can develop for the platform is small. It's not like an Android or iOS device, where you can get what's needed for development (the phone and dev kit) for fairly cheap.
The previous Flex radios had published source code with minimal documentation, but there were maybe half a dozen people doing things (other than within Flex). There was a fair amount activity with things to drive the CAT interface, but that's not really an API.
As for the API
that is something they would want for their own developers as well. What will be interesting to
see is, how much of that API they expose to outside developers. Microsoft was well known for
not documenting a lot of functionality to outside developers in their various API's for Windows years ago. (and probably still leaves a lot out) There was a lot of complaining over that too.
Not necessarily. I don't know anything about their current internal software development practices, but in the past,that's not how they worked. They had a couple folks who provided the DSP core (dttsp) which had a DLL style interface. Then they had some folks doing UI in VC to call the DSP.
At no point did flex ever publish any design or interface documentation, other than for the CAT interface, which essentially emulates the serial port style interface for conventional rigs. Their answer was "look at the code", but the code doesn't really have many comments in it. You have to reverse engineer it.
I am sure that they are working on the internals of the software for the hardware itself. And
the Client software too. (saw some of that in the recently released video of SmartSDR)
But, again, if they limit 3rd party development too much, "I think" that the new radios will be an even tougher sell.
Actually, I don't think most hams care if the API is published. It's something that some fraction (maybe 10%) say they would like to have, but an even smaller percentage would actually use it.
And the costs to provide adequate API documentation, example code, test cases, and user support are enormous. For an internal only team, your documentation is "ask Bob in the next office" when the API call returns something weird.
The other aspect is that the API is likely to only be for "display and UI" type functionality. If you're expecting to get into the signal processing, that's even less likely. It's harder to design a good API for this, and Flex has some legitimate concerns about keeping the FCC happy.
