-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf 
Of Thomas Schaefer
Sent: Wednesday, September 28, 2011 10:53 AM
To: Simon HB9DRV
Cc: <[email protected]>
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 [email protected]. 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

Reply via email to