I love my radio and one of the things I like the most is that it continues to evolve. Unfortunately, the update cycles seem to be getting longer and longer and are only centered on Remote operation and contesting. I know, lots of behind the scenes stuff is done and bugs are squashed but hey, throw us simple DX chasers and rag chewers a bone. Give us some of the perks that PowerSDR now seems to be getting in spades.
I'm still a happy Flex user and would never trade my radio. I just want to add my 2 cents on what would be nice to have.
PS. If you don't read the PowerSDR thread, Darrin is now working on a background for PSDR that shows a world map with a moving grey line. Great stuff!
- WAN has been promised for a while so I understand why it's a priority.
- Maestro is needed to bring in customers who wouldn't come without knobs.
- Satisfying contesters usually helps everyone in the long run.
While some of us don't really want / need some of those features, the strategy is understandable.
Hopefully during the 2.x series some of the other enhancements (GUI improvements, peripheral control, new features, etc) will be included as well. But IMHO it may be quite a while before we see many of those incremental improvements. There are hundreds of "ideas" on the customer facing list and I'm sure FRS has many more on their internal list. It could easily take several more years to get the one you want.
Regards, Al / NN4ZZ
al (at) nn4zz (dot) com
6700 - HW.................... V 220.127.116.11
SSDR / DAX / CAT...... V 18.104.22.168
I started development on what ultimately became PowerSDR (FlexRadio TM) back in 1999 purely as a hobby project that turned into a business in 2003. The original SDRConsole was written in VB6 and ran the SDR-1000. In 2004, we started over in C#.NET taking what I had learned in the original software. SDRConsole its successor PowerSDR were released as open source software targeting the experimenter market.
FlexRadio invested significant time, human resources and dollars (seven figures) in development of PowerSDR from that time until 2013. In the old experimenter days we would just code and idea and send it to the masses. Since our customers were mostly experimenters in the early days they didn't care about quality control, they just wanted to play with the latest gee whiz feature. PowerSDR had no architectural design - it simply evolved. We called it whack-a-mole because you make a change here and a bug pops up over there. But it was sure fun to make a quick change and throw it out there to see if everything worked or not. I remember taking walks, having and idea, coming back and coding, and then post it to the server for download that evening. Those were days of the wild, wild west.
SmartSDR on the other hand was designed from on a clean sheet of paper to be a long term, sustainable architecture. We don't do any major coding without a peer reviewed design process on the front end. No code gets pulled into a branch without a pull request and timely peer review. Every time we produce a build during the day there is an automated system that uploads the code to each of our radio models and runs a test suite. We do alpha releases to our 50 plus alpha team one or more times per week. The entire software team reviews their issues each Monday starting at 9:30 am and it typically runs until lunch. Every issue is sized, prioritized, assigned to a release plan or to the general backlog. If the issue makes it into the current release plan, it is assigned to an individual programmer or group of programmers.
We have produced over 50 builds on the v1.7 Maestro release alone and still counting. Our goal with SmartSDR is to build quality software based on design solid design and process principles that will provide value for many years to come. That means we will never do daily releases to the masses like we did in the old days of PowerSDR. Darrin is free to do so to his pleasure. I sure encourage people who benefit from his work will pay him for his efforts.
On the other hand, let me reiterate here that we are fully supporting Darrin in his efforts to enhance PowerSDR. We have provided Darrin with each model of our hardware and our software engineers are supporting him in his work.
Jon, we do not plan to give regular public road maps because it would give our competitors too much information. Also, we need to be able to make decisions at the beginning of each release cycle that are based on the best information we have at that point in time. Things change and we learn. We use our best judgement for each release based on building our business for the long haul. We know that is best strategy to serve our customers.
So the bottom line is - you can have it fast or you can have quality but not both. We choose quality. That ship has sailed and there is no going back.
I think you missed my point. I just wish you weren't so focused on your big high quality updates that we never seem to get to the little things. Darrin is doing with PowerSDR what I wish we could have with SSDR. Regular small updates with nice to have features. Something to fill the void between blockbuster updates like Maestro or WAN remote which I don't particularly need.
While I liked the roadmap I understand why it is gone.
@Jon & Steven
I think you both have entirely missed the point of Gerald's posting.
In order to do quality sustainable work you don't do small tiny fixes here and there because these tend to break other things in the process (like they did regularly in PowerSDR).
I would add that software costs money to produce. That money currently comes from new sales. So prioritizing new features has to be done with consideration of how many new sales that those features will bring in.
There is little doubt that both Maestro and WAN will generate a heck of a lot of new sales. The contest features already implemented look to be world class contest tools which will also generate new sales..
Whilst it is marvellous that Flex is working on Maestro and contesting and WAN, I do not care about any of them. Every time I have to get to within an inch of my screen to see the SWR and power bar gauges, I curse Maestro and WAN and contesting.
I have worked with my hands all my working life to a standard at least as high as a skilled surgeon and am annoyed that the slider controls are more difficult to adjust than they need to be from *several* aspects (I am available for hire as it is likely ill-health will preclude my working in my regular day job ever again, hi hi). IMHO the GUI is a big ergonomic fail. Gerald, nobody is asking for 'eye candy' or frequent releases. Personally, I find the use of the term 'eye candy' very telling. One GUI release would satisfy most of us at least to the point where we would not feel as if we were being ignored. Ergonomic improvements would benefit everybody unlike the other things that you mentioned.
It is not good for a company, or anybody else I can think of, to concentrate on the big things to the exclusion of the smaller things. Every time somebody complains about the small things being passed over, somebody posts with news on the next big thing Flex is planning. Whilst the next big thing might make people buy Flex, hearing that the less glamorous things get put on the back burner will similarly make people buy less.
I would like to back up what Jon has said and would also like some effort to be expended on the 'little things'. It is getting more difficult to believe that any GUI improvements will see the light of day in the v1 branch.
I'll get my coat...
Jon: I hear Gerald saying that his resources are limited, and it makes the most sense for him to focus those limited resources on adding features that will expand his user base. Adding users equals sales. Sales equals he stays in business. It's hard to argue with that rationale. Gerald seems to argue that when the major, market-expanding, stuff is finished, there'll be plenty of time for polishing.
Gerald: I hear Jon saying that he doesn't really care about a lot of the new whiz-bang features. He's happy with the major functionality as its exists. But there are a lot of niggling little things that make SSDR less useful or less enjoyable than it he feels it could be. As a loyal and dedicated user, he wishes that Flex would shift the allocation of resources at least a BIT more toward perfecting the existing interface to reward the existing customer base.
It's hard to argue with either opinion, really. They're both entirely valid perspectives.
Running a software organization is all about making these trade-offs. Folks who don't write software for a living often fail to realize that these trade-offs are a zero sum game. If you spend x time on some feature, you've got x less time to spend on something else.
Trade-offs suck, but making the tough decisions is essential to making money in this field. For example, I'm approaching a major release milestone for some software my company is building, and I just did a bug triage. I closed or postponed every bug that had the words "we should" or "it would be nice if" in the description. This removed about a third of the open bugs against the release (the bug count went from 97 to 66). Boy, was our marketing guy pissed off! But guess what? He would have been even MORE pissed-off if we missed the release date (and delayed the revenue from that release) because we spent time adding some cute edge feature instead of fixing a bug that resulted in a system crash.
Zero-sum game. Somebody HAS to make the call.
What is undeniably cool is that Gerald came on the board to explain the trade-off he was making. See that from any other similar company? While I don't LIKE the result of his trade-off, I understand and respect it.
This conversation is no longer open for comments or replies.
This conversation is no longer open for comments or replies.