TenTec
[Top] [All Lists]

Re: [TenTec] Ten-Tec Survey, open source

To: Discussion of Ten-Tec Equipment <tentec@contesting.com>
Subject: Re: [TenTec] Ten-Tec Survey, open source
From: Rick Denney <rick@rickdenney.com>
Reply-to: Rick Denney <rick@rickdenney.com>, Discussion of Ten-Tec Equipment <tentec@contesting.com>
Date: Thu, 17 Apr 2008 17:39:10 -0400
List-post: <tentec@contesting.com">mailto:tentec@contesting.com>
ron writes...


> I think we are missing the boat.

> There are those who want to write the code and share with anyone who 
> also wants to improve it, and there are those (like Perry maybe) who 
> only needs to download the open source application and use it. There are
> versions fully tested and there are versions in beta (testing).

> Look at N1MM application for example.

There will always be those with the skills, time, and desire to
develop code for their purposes, and some of those will do it well
enough that others will want their products. That doesn't mean it's
the appropriate solution for those who want a radio to operate. The
question I was addressing is: How do you obtain highly valuable input
from those not interested in or capable of doing the programming? The
answer is to capture their operating activities and needs, and the
resulting requirements. I would hate for the software to be limited to
the operational vision of only those who have that level of
programming skill. They may be broadly representative of potential
users but I rather doubt it.

I manage large systems implementation projects for a living, and the
tension between programmers and users (or domain experts and systems
engineers, if you prefer) must be balanced for the system to fulfill
its mission. In amateur radio I have not seen much implementation of
systems engineering approaches that are the stuff of daily existence
in many development industries, and maybe that's why we have so many
people thinking the firmware in the Orion and Orion II is not
fulfilling its potential. But they have to define what that potential
is, and the best way to do that is in terms of how they will use the
radio.

For example, I use DXlabs software, but I really have no interest in
helping to program it--that's too much like work. It is not my perfect
solution, and some of its features are more in my way than helpful. I
don't want to be the sort who posts a list of complaints on an email
reflector without being willing to pitch in. So, I work around its few
faults and deal with it. I suspect that describes many Orion, Omni
VII, and even K3 users.

No expert me on programming a software-based radio. But I think I can
describe what I want to do with a radio, and I think that's true even
for those highly experienced operators who have no interest in
computers whatsoever. I would hate for them to be left out of the
process because they want to talk about AGC and S-meters instead of
algorithms and code. For incorporating expert users into a development
process, these systems engineering approaches have proven themselves.

And if the development process is also open, it's a lot easier to
marshall resources in support of a widely supported set of functional
requirements, rather than have designers arguing not over designs but
over the *purpose* of their designs. I have seen too many development
resources wasted on those sorts of discussions. The purpose of the
design should be known before the design is undertaken. I'm not
arguing against open development by any means, but I do not think
that's the solution to software products that don't fulfill their
mission fully.

Rick, KR9D

_______________________________________________
TenTec mailing list
TenTec@contesting.com
http://lists.contesting.com/mailman/listinfo/tentec

<Prev in Thread] Current Thread [Next in Thread>