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