The Flex Radio Systems response seems correct to me. For a myriad of reasons.. The SDR ecosystem (across all brands) is fertile ground for development of 3rd party apps. And Flex has released developer API kits. The endless stream of "reasonable" software feature requests by users are often thoughtful and imaginative. But software development is expensive and time consuming. ( Even now, many flex community members are eagerly anticipating 1.4's release).
Flex should stay focsued on the Core App functionality and connectivity in the near term. If they do engage in "non-essential" development then I believe Flex should charge for such features inside the upgrades as is common in Enterprise level Software (vendor/customer) relationships. My "essential" features and another Ham's "Must have" functionality will diverge. I'd much rather see a lean SSDR with emphasis on a more elegant User interface and a higher uprgrade price. Optional add-ons are of value to some and not to others.
Paying a 3rd party or perhaps FRS if they bring add-ins to market makes sense.
I've purchased K6TU's app (and am giving the XYL a new iPad Air-2 so I can have her old one to use with the app on a dedicated basis) as my first add-in.
Huge potential for more parts to be integrated!
Integrated features are one thing, but adding capabilities that don't have anything to do with the radio, or that can be more effectively accomplished through outboard programs just bogs down the program. Look at WIndows - how many times have you used WordPad or Paint? Most of us buy a word processor or a graphics editor even though Microsoft included these useless programs.
As to using 3rd party external tools such as FLDigi. FRS via DAX has made 3rd generation digital mode programs (such as FLDigi) accessible with their 5th Generation Radio Server. However, the Flex 6000 series begs for complimentary 5th Generation digital mode solutions to coincide and match their ground breaking radio. Imagine digital audio data modes such as CW, PSK, RTTY, Olivia, etc. totally encoded and decoded internally within the radio! Such a design would only require that the ASCII text be passed over TCP/IP to/from the SmartSDR client and not any high bandwidth digitized audio. DAX, a relative bandwidth hog, could be turned off while using these internal modes. This will dramatically reduce bandwidth requirements for SmartSDR while utilizing these modes. Lower bandwidth requirement are a boon when remotely accessing your radio from the internet.
There are many good reasons for developing internal digital modes for such a WAN enabled Radio Server. Other developers, via the API will no doubt be able to create wonderful internal solutions. However, in my opinion, no one will likely be able to do it better than Flex themselves.
Seriously though, it's great to know that discussions like this one are read and pondered by the company that builds our radio. I can't think of another manufacturer who has as much user input and interaction.
So there is no right and no wrong just a great platform with unlimited potential. I can only imagine what the future hold who know duplex video over the 6500????
Keeping the MS analogy going, for this idea to make sense, FRS should build digital mode software in a different division of the company, or sub contract it. Separate accounting will reveal if there is enough market out there for it to make sense financially. If there isn't, then the unit cost to the customer will be very high. Hams, in general, are cheap -- it won't sell.
Splitting the difference, FRS could approach FLDigi and encourage them to do a better job of integration, although what we have now isn't bad at all. The complaint about the FLDigi UIX is certainly valid. It is free software with the emphasis on the modem components (which IMHO are quite good) but suffers from an individual's notion of what a good UIX looks like, unencumbered by sales figures.
I speak with some level of experience. Over the last few weeks I have built experimental installations of FLDigi, DXLabs and HRD on virtual machine systems (all over SSDR) and experimented with them. My conclusion was:
1 FLDigi is far and away the best modem software. The UIX is drab, the configuration system is messy, but it works well.
2 HRD is a poor value -- the software is buggy, and non-intuitive to me. It also had a heavy feel. I don't mind paying money for good software, but I could not see that HRD was all that good.
3 DXLabs has the best logging software of this bunch, but like FLDigi, a clumsy UIX. WinWarbler is not competitive. DXLabs components do not have a uniform UI presentation, and all have peculiar UI layouts that go against the current norms.
With more study I learned that FLDigi has a weak logging package because they expect and encourage you to use something else. By the same token, DXLabs expects and encourages you to extend their work with other packages. I surmised that they are not very concerned with WinWarbler because packages like FLDigi exist.
Finally, I found a gateway program that allows me to use FLDigi over DXLabs. This works well enough, although it is minimal.
Where does this leave us? IMHO, SSDR is far and away the most complete, stable, professional looking, well maintained and supported of the bunch. Good software is hard to design and write. Getting the UI details right is very time consuming and painstaking. FRS is getting the job done. We help by pointing out bugs and making suggestions about the UIX. I hope they make money on the software, but I doubt it.