Flex has a capable group of alpha testers and I'm sure they represent the most technically competent of current users. Unfortunately, they don't always see things from the perspective of average users. Given the complexity of 1.4, maybe it would be better to give testing another phase. Once 1.4 is working reliably with the alpha testers, release it to a beta with the general population. This would allow users who don't have to have the latest and greatest or are less "cutting edge" the comfort to sit it out and wait for the final release. This would hopefully prevent a surge of support issues and generally make the release of this major update easier to manage. It might also make it easier for management to get it out the door by removing the pressure to chase down every single issue or optimize every line of code.
I know I would sit on the side for a while to see how things are going. I would love to be reading about beta users experiences with 1.4 instead of all the speculation and frustration that is filling the forum of late. Once things were settled with 1.4 I would probably upgrade and get ready for what I'm really waiting for...1.5.
Jon - That actually not a bad idea, IMHO.
Many of the video driver (Nvidia) sites have posted their current "stable" release, but if you want to try the bleading edge beta, you can. They don't support it in terms of giving response, but certaintly take input.
I've upgraded and downgraded smartsdr several times. It takes a few minutes and is pretty simple, but you need to know a little about what you are doing. For those not used to the un-install process, they might not want to be out there on the bleading edge.
Example, on my work computers, where production is important, I only have "stable" releases. Ocassionally at home if I feel like expermenting, I give beta a try.
So as a flex user, if he just want to operate, I might be better with the stable release. If you want to experiment (in the true ham fashion) then I might jump out there!
There is certaintly a distinction between Alpha and Beta. If you are a Alpha tester, flex is depending on you to test and report back promptly. If you are a Beta user, there is less dependency on you by the company, but as a "enthusiast" you will report discovered anomilities. However as a beta release the company is not obligated to waste time "supporting" issues.
Thanks for your thoughts. You are correct that this release is one of the largest undertakings since the beginning of SmartSDR. LAN remote is the basis for WAN remote and requires very sophisticated system level integration to make it work right for multiple receivers/panadapters/waterfalls. All this happens in a real time, client/server, multi-threaded, five processor signal processing system over an unknown network.
In many ways I like the idea of beta releases but I also have some bad experience form the earlier days with PowerSDR. We did exactly what you were suggesting on PowerSDR until we got burned so many times by customers publicly grumbling about problems with beta software. It created the perception with potential customers that all our software was in beta, which was not true. We eventually quit releasing beta on PowerSDR and went to the process we have now for that very reason.
Frankly, I would love to do as you suggest but I don't know if the general ham population is sophisticated enough to understand the software development process. I would love to be proven wrong.
as a software developer I agree with you, but as a user of SSDR I think that the release period between two versions is a bit long.
I think also, that, after the 1.4 SSDR version, it could be helpful reviewing the process you release new software.
I would like you stop using the traditional setup process, that often require uninstalling the previous version, and that require users to become very skilled os users. (we all know Windows uninstaller is not a perfect machine).
I would like you adopt a lighter setup module, to be installed only once, and being able to deal itself whit SSDR updates. Just as it already happens with the rig firmware.
In this way developers could release, even daily, small software updates eliminating long waiting periods and requiring little skill and effort from users.
As you use to say these are "just my two cents" :)
Anyway I like too much my new Flex and I thank you very much for giving us constant updates about your products.
Been quiet on this subject until now; some observations:
There will always be complainers. It changes with the weather between "It takes too long between updates", "You promised ...", "Updates are buggy", "When is function ... coming".
(From my days with an IBM multi-national assignment on "problem rediscovery reduction") It is much better to get fixes in the field to reduce support overhead (the rediscovery problem) and especially to have solid tested code as a development base. We had one set of fixes that customers didn't install for two years and in the interim had several new products that were developed on a faulty base. An extreme example.
Two options may be:
1) A restricted Beta with your week-end development version made available to the Beta Subscription List group for their optional install. This Beta program would start after the Alpha level completes until public release of the product. It would be identical to the Alpha process with a different distribution list.
2) An early version (e.g. 1.4.0) made public with the statement that a maintenance release (e.g. 1.4.1) will follow after an early deployment window. A statement near the top of the announcement notice stating this is an early deployment and some users may wish to delay deployment until the .1 version is available.
Option 1 carries more support deployment overhead but my experience in problem rediscovery shows that duplicate problem reports drop significantly when timely fixes are made available. With higher deployment numbers actual field support hours are reduced.
That said, I would participate in an optional Beta program that runs between Alpha end and public (or maintenance .1) release.
Stan Williams - VA7NF
I have to say: Given the customer base, the product, and the size of the s/w staff... I think Gerald's team has got things just about right:
- The have a small, private, test group that "beta tests" the releases and provides them feedback that they would not get from the devs themselves.
- They hold their releases until what they say will work actually works.
- They take a step-wise approach to implementing functionality: They obviously strive to implement a broad range of features, and refuse to let perfecting one feature exhaust all available engineering time to the exclusion of doing other features. Engineers hate this, but it's the right thing for the product. For example, Flex could have a dev spend months getting the ATU to work to 100% of its potential... which would mean we'd have a working ATU, but no implementation at all of a bunch of other features.
Of course, for Flex to do this, they'd have to add two or three support engineers to deal with the questions, comments, issues, problems, and complaints. Most of the time would be spent telling folks "Yes sir, you're using the LATEST build... to avoid crashing during the CQ WW DX context you probably should be using the latest RELEASE build." And then take the pile of complaints from folks who THINK they understand, but don't REALLY understand, the difference.
Yup... I think Flex has things about right.
Beta testers should not be overskilled technicians or engineers. Beta version should be used to test all disparate user profiles and should be distributed to a wide audience on the Web. Only in this way you could have a real world test of the software.