[amsat-bb] Re: HB9DRV

Lynn W. Deffenbaugh (Mr) ldeffenb at homeside.to
Thu Sep 29 05:53:28 PDT 2011

WONDERFULLY STATED!  I have been agonizing on whether to decloak and 
write something similar to your essay, but you said it very well.  I'd 
only add one more point to ponder.

Many of us developers don't lean toward open source code simply because 
of time constraints.  We'd rather take our time and work on the code and 
the functionality than to take that same time (and more) to explain 
what's already been done, why it was done that way, why another way is 
(or is not) better, and to review the proposed changes to consider 
adopting them into the baseline.  And, if the implication of "thousands 
of eyes" interested in my pet project is true, that could easily swamp 
all available time for the original developer to the point that s/he 
throws up hands and walks away from the project because it's just too 
demanding and nothing is actually being DONE!

Thanks, but no thanks.  I'll continue to be open to suggestions (and 
sometimes insistence) for new features/functions to be added to my own 
project, but that's about the extent of it.  When I die or become no 
longer interested or capable of continuing development, I plan to find 
another dedicated developer (if any are available that are willing to 
put up with G4ILO's picture of such development at 
http://blog.g4ilo.com/2010/10/advice-to-amateur-programmers.html) or 
I'll be posting the whole enchilada to a source code repository and let 
it be Open.

So, it's not quite "Open Source over my dead body", but almost.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 9/29/2011 8:17 AM, David Moisan wrote:
> -----Original Message-----
> From: amsat-bb-bounces at amsat.org [mailto:amsat-bb-bounces at amsat.org] On Behalf Of Thomas Schaefer
> Sent: Wednesday, September 28, 2011 10:53 AM
> To: Simon HB9DRV
> Cc:<amsat-bb at amsat.org>
> Subject: [amsat-bb] Re: HB9DRV
> I have to say the statement about people not having the experience, time and patience to maintain it is pure egotistical nonsense. Plus it completely misunderstands the idea of maintainers of the source tree. Open source code is always better because no matter how clever ones thinks they are as a programmer, there are always better coders. If HRD was open sourced, I guarantee the satellite tracking piece would work perfectly for all radios because we would have fixed it.
> -----
> I've been lurking this thread for some time.  My day job is in IT and I am familiar with Linux.  The devil is very much in the details.  There are several caveats I'm obliged to point out.
> 1) Depending on the problem domain, "thousands of eyes", could be just "hundreds of eyes" or even "tens of eyes".  And that is only if these eyes are able to take the time to look at the code.  That can be the hardest thing to do unless you are very experienced and can see the bug jump right out at you through intuition.  There have been a number of security bugs in open source code that have been only found years later.  I don't pretend I can download Apache source and understand it enough to make a change, and try to commit it--and Apache is a very widely used and successful project in a very well understood *and well documented* domain;  most open source projects are not so fortunate.  There is much, much more to understanding a project than by just reading the source, and many, if not most open source projects seem to fail at this.
> 2) I said problem domain in my first point, and that can mean rig control.  Or framework design, libraries or even lower-level drivers.  We don't know what code Simon has used under license, but if it is only just rig control, I would be very surprised.  More likely, it is the framework he used and the terms he had to use it under.  That is a very important decision that a developer must make early on.  Usually, developers just use what's "out of the box", like .NET or another common framework like Qt.  That can affect everything, including the licensing.  Everything.
> 3) The GPL that many people advocate is a viral license.  By itself, the GPL requires that if you change the code, you have to publish it.  Plus all the other parts, which can include libraries, at least in some interpretations.  Other licenses like the BSD or the LGPL don't have this condition, but they also don't require (by themselves) that the changed code be public.  Some code repositories, like Codeplex, will not allow GPL'd code for this reason.  There's been much controversy over the use of such code in libraries and whether the license terms apply to the main code that calls them.
> 4) If you get through these points and you do change the code, no one is obligated to accept your changes.  Going back to my first point, of all the users and potential developers that can see the source code, there are historically only a small number of those that propose, and commit, code changes.  Sometimes, if there is a dispute between factions on a project, the code gets "forked".  Imagine seeing HB9DRV and HB9DRV-2, though it would probably be called HRD and "HR Super Betterer Deluxe" or something like that :) .  That can be a bad thing to happen, particularly in a small community like ours.  I believe this, and other related issues, have crippled Linux badly enough to affect its long-term future.
> The best chance that the group holding HRD would have towards the goals of open source, or at least what most people here seem to be asking for, would be to publish an API (Application Programming Interface) and ABI (Application Binary Interface) to its control interface.  That limits the scope of the developer, but makes it much more likely for him or her to succeed.  In other words, publish the specifications of the rig control interface.  That is still a big job not to be underestimated.  But it is much more feasible, and it may lead to a genuine standard in our field.
> 73, N1KGH
> _______________________________________________
> Sent via AMSAT-BB at amsat.org. Opinions expressed are those of the author.
> Not an AMSAT-NA member? Join now to support the amateur satellite program!
> Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb

More information about the AMSAT-BB mailing list