Like W4ZV, I was a beta tester for that other SDR. Bear in mind my post of a few weeks ago in which I cautioned about avoiding "groupie-ism" and holding manufacturers to high standards. Here's my 2-cents on the subject:
1. I agree with W4TV that Elecraft should update the approximate delivery dates for all backordered K3s. I'm as anxious to get mine as anyone, but I was aware that I wouldn't be getting instant gratification when I placed the order and was prepared to wait. The main reason I need this information is not to relieve anxiety. I need it for planning purposes. As a busy guy with lots of work and family demands, I have to schedule time to build my K3. Also, my SO2R contest station is pretty complex, so I need to know whether the K3 will be available for certain contests. It makes a difference in terms of configuration changes I'm planning. I don't see any reason why Elecraft can't publish a real shipping status table indicating week of order and approximate delivery date (early <month>, mid <month> or late <month>), with plenty of disclaimers. However, if they perceive something proprietary about this information, Joe's suggestion for privately notifying those with outstanding orders makes sense. Many companies inform customers with backordered products when the expected ship date changes. It's a common courtesy and an excellent business practice. Building it into Elecraft's order process now would be a good investment for the future. The worst way to deal with it is silence or, "It's going to be later than the date we told you -- figure it out from small bits of data gleaned from others on the reflector." 2. On the Sub-RX, I'm mighty impressed with how Elecraft has informed us of the status, including details on the issues they're addressing. I've not seen another manufacturer of ham gear disclose so much about hardware development (at least, not in the era of solid-state transceivers.) I encourage Elecraft to keep doing this, despite the backlash from disappointed customers who expected the Sub-RX sooner. Disclosure was my main beef with the other SDR manufacturer. For example, they wouldn't tell us when they discovered and fixed hardware problems. We never knew when a hardware update was released, except when a repair workorder included the mysterious "updated such-and-such board". In the case of critical flaws, I expect the manufacturer to replace/update boards free of charge (i.e., issue a recall.) For performance or reliability enhancements, boards should be replaced/updated free of charge if the unit is under warranty. If the unit is out of warranty, the customer should be offered the opportunity to have the board replaced/updated at a reasonable price. I would gladly have paid for replacement boards to keep my radio up to date. But the most important aspect is disclosure: tell us what's going on. I don't see this as significant proprietary information that can benefit a competitor. I can understand withholding the information until an approximate delivery date is known, but total silence isn't acceptable. Like I said, Elecraft has done a nice job on the Sub-RX issue and I encourage them to continue the open discussion. It helps them far more than it hurts them. 3. I think it has been well-known that the K3 is a brand-new product that will initially lack certain features listed in the spec sheet. Those who ordered the radio last May should have understood this. I, for one, was planning on waiting for at least one to two years before buying a K3 so the bugs would be shaken out. I ordered a K3 sooner than planned because I've given up on any further improvements to that other SDR I keep referring to, and I'm willing to put up with some inconvenience to get a K3 sooner rather than later. What pushed me over the edge was observing how Elecraft has been handling hardware and firmware issues for the K3. I have to tell you folks that it's *way* better than that other manufacturer. 4. Posting the bug/enhancement list is a tricky issue. I've been in the software business for about 30 years, and have dealt with this as a technician, manager, CEO and board member. There can be a lot of proprietary information in such lists, especially planned enhancements. Further, it's risky to set expectations of when certain bugs will be fixed or enhancements implemented. Murphy rules the world of software development like no other engineering domain. It's business-as-usual for unforeseen problems to be encountered over which you have limited control, such as bugs in a compiler from another manufacturer. Sometimes, despite the most careful design and implementation, a bug may be so engrained in the software architecture that it will take a major rewrite to fix it. It's not unusual for this to be discovered only after significant time has been spent investigating the cause, and an initially optimistic forecast for a fix has to be thrown out the window. So, what to do? My feeling is that, at a minimum, reported bugs must be acknowledged, along with a statement as to whether it will be fixed or not, along with a priority number. There's nothing more frustrating to a customer than reporting a bug and being stonewalled by the vendor. I think a priority assignment is important because the manufacturer may not have a realistic understanding of how a bug affects users, so if a low priority is assigned the customer will have an opportunity to plead his/her case for a higher priority. Often engineers don't know what customers actually do with their products, so this is very valuable feedback. Beyond that, I would be reluctant to publish the target release or release date. The risk of setting expectations too high is great when you do that. However, once the developer has had a chance to review requirements for fixing the problem, and perhaps has already mapped out what to do, then I think there's somewhat less risk in publishing an expected release and/or release date. 73, Dick WC1M _______________________________________________ Elecraft mailing list Post to: [email protected] You must be a subscriber to post to the list. Subscriber Info (Addr. Change, sub, unsub etc.): http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/subscribers.htm Elecraft web page: http://www.elecraft.com
