On Tue, 27 Sep 2011 14:17:53 -0500 "Greg Beat" gregory.beat@comcast.net wrote:
"The support effort required has become more than I can realistically manage
- with many thousands of users, new radios and other hardware appearing all
the time and unexpected changes to the infrastructure used by HRD such as QRZ.com I no longer have any time at all for other projects.
Why not just open-source it? It's already free-as-in-beer. If it was also free-as-in-speech then there would be a potentially far greater number of eyes on the code, and a broader range of contributors. There's also the chance to use existing work like hamlib in it, and avoid duplication of effort on driving all these different radios.
I've never understood why so many in the amateur radio community are so keen to share circuit diagrams, antenna designs and all sorts of other information, but keep their software to themselves. In this case, it's a no-brainer - HRD needs a lot of work, and there is a willing community out there who would do it given the chance.
Proprietary software has absolutely no place in amateur radio.
On 28/09/2011 10:50, Gordon JC Pearce wrote:
On Tue, 27 Sep 2011 14:17:53 -0500 "Greg Beat"gregory.beat@comcast.net wrote:
"The support effort required has become more than I can realistically manage
- with many thousands of users, new radios and other hardware appearing all
the time and unexpected changes to the infrastructure used by HRD such as QRZ.com I no longer have any time at all for other projects.
Why not just open-source it? It's already free-as-in-beer. If it was also free-as-in-speech then there would be a potentially far greater number of eyes on the code, and a broader range of contributors. There's also the chance to use existing work like hamlib in it, and avoid duplication of effort on driving all these different radios.
I've never understood why so many in the amateur radio community are so keen to share circuit diagrams, antenna designs and all sorts of other information, but keep their software to themselves. In this case, it's a no-brainer - HRD needs a lot of work, and there is a willing community out there who would do it given the chance.
Proprietary software has absolutely no place in amateur radio.
I understand your logic and thought process - I am a strong advocate of open source having funded development of ApacheSSL in the past and tried to do my bit, but that's a broad statement.
There's lots of proprietary software involved, from that included in and with commercial transceivers to codecs to control software etc etc. It's truly up to the authors to decide the licensing module and the user to decide whether that fits with their ethos.
Open Source is a marvelous and vital part of Amateur Radio and virtually everything else to do with computing, but commercial models have their place too. In my humble opinion it's totally up to the user to make the decision as to what they use, support and evangalise.
Dominic G6NQO
There are many reasons for not providing software source, in my case I doubt there are many people with the requisite experience, time or patience to maintain this.
FWIW and contrary to some opinion HRD has in fact cost me money over the years, not the other way around. Also I just have no, and I mean no time for anything else whatsoever.
You use proprietary hardware with proprietary firmware, what's the problem with the software you use on your computer?
Simon Brown, HB9DRV http://sdr-radio.com
-----Original Message----- From: amsat-bb-bounces@amsat.org [mailto:amsat-bb-bounces@amsat.org] On Behalf Of Gordon JC Pearce
Why not just open-source it?
On Wed, 28 Sep 2011 12:20:54 +0200 "Simon HB9DRV" simon@hb9drv.ch wrote:
There are many reasons for not providing software source, in my case I doubt there are many people with the requisite experience, time or patience to maintain this.
That's a rather arrogant attitude to take.
FWIW and contrary to some opinion HRD has in fact cost me money over the years, not the other way around. Also I just have no, and I mean no time for anything else whatsoever.
Yes, software development costs time and money. Do you think the time and hardware involved in developing lysdr was free? Or, for that matter, any other software I have written.
You use proprietary hardware with proprietary firmware, what's the problem with the software you use on your computer?
I avoid proprietary hardware and proprietary firmware. All of my radios have full service manuals, with complete circuit diagrams. I only use open-source software on my computers, and eschew binary-only drivers.
Again I ask, why are people so reluctant to release the source code for software, but are more than happy to publish the circuit diagrams for devices they design?
Again I ask, why are people so reluctant to release the source code for software, but are more than happy to publish the circuit diagrams for devices they design?
Because maybe they have invested years of their time into it, and don't want to see it all hacked up beyond recognition by the whims of a few hack-and-go programmers who play with it for a while, screw it all up and then move on to the fad of the next flashing icons
On Sep 28, 2011, at 8:33 AM, Bob Bruninga wrote:
Again I ask, why are people so reluctant to release the source code for software, but are more than happy to publish the circuit diagrams for devices they design?
Because maybe they have invested years of their time into it, and don't want to see it all hacked up beyond recognition by the whims of a few hack-and-go programmers who play with it for a while, screw it all up and then move on to the fad of the next flashing icons
And what has that to do with Open Source software? Let's assume Simon would've opened the code and other's would've been able to contribute. Out of the gate you already assume that everybody else writes bad code. That's simply BS. Moving on .. if code is opened, it's not like everybody just hacks away beyond recognition but maybe makes a useful contribution which that person then would have to check in upstream to Simon so that he could include it into the main source tree. After all, the official version of OSS HRD would still come from Simon just with more people being able to contribute.
When I read some of the statements here, it seems that there's a huge misunderstanding of Open Source software and how Open Source communities and software development works.
Sure, people could use the code and fork it and "hack it up beyond recognition" but who would use that? Also it would be a fork and history has shown that most forks that were not in line with the mainstream source tree were not long lived.
Another reason of course for not open sourcing one's code can be that the code is so bad that one doesn't want to invite criticism (and this is not pointed at Simon, as I don't know his code, rather a general statement). There are plenty reasons for not opening code and plenty more for doing so. But nobody should be forced in either direction. I don't believe we (open source pro folks) can on one end preach freedom and then on the other try to force it on others.
Would it have been great if Simon would've open sourced HRD so that for example people could've ported it to other platforms? Well most certainly yes. But he decided not to, and that's a decision we all have to respect.
After all, if you don't like it, don't use it. There are alternatives to almost everything.
73 Mike K5TRI
You clearly don't understand open source. Is the Apache http server "hacked up beyond recognition"? I suspect hams keeping their source closed is far more about ego than the sanctity of the code base.
As someone else said though, I respect any authors decision to keep their source closed. It is their IP. I just don't agree with it.
Tom NY4I
On Sep 28, 2011, at 6:33 AM, "Bob Bruninga" bruninga@usna.edu wrote:
Again I ask, why are people so reluctant to release the source code for software, but are more than happy to publish the circuit diagrams for devices they design?
Because maybe they have invested years of their time into it, and don't want to see it all hacked up beyond recognition by the whims of a few hack-and-go programmers who play with it for a while, screw it all up and then move on to the fad of the next flashing icons
Sent via AMSAT-BB@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
On Wed, 28 Sep 2011 09:33:01 -0400 "Bob Bruninga" bruninga@usna.edu wrote:
Again I ask, why are people so reluctant to release the source code for software, but are more than happy to publish the circuit diagrams for devices they design?
Because maybe they have invested years of their time into it, and don't want to see it all hacked up beyond recognition by the whims of a few hack-and-go programmers who play with it for a while, screw it all up and then move on to the fad of the next flashing icons
And why would you care if they do? It doesn't make the program work any less. You are under no obligation to accept their patches back into your source.
Let me turn my question around, then. What do you gain from keeping your source code a secret?
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.
Tom NY4I
On Sep 28, 2011, at 3:20 AM, "Simon HB9DRV" simon@hb9drv.ch wrote:
There are many reasons for not providing software source, in my case I doubt there are many people with the requisite experience, time or patience to maintain this.
FWIW and contrary to some opinion HRD has in fact cost me money over the years, not the other way around. Also I just have no, and I mean no time for anything else whatsoever.
You use proprietary hardware with proprietary firmware, what's the problem with the software you use on your computer?
Simon Brown, HB9DRV http://sdr-radio.com
-----Original Message----- From: amsat-bb-bounces@amsat.org [mailto:amsat-bb-bounces@amsat.org] On Behalf Of Gordon JC Pearce
Why not just open-source it?
Sent via AMSAT-BB@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
On 9/28/2011 10:52 AM, Thomas Schaefer wrote:
I have to say the statement about people not having the experience, time and patience to maintain it is pure egotistical nonsense.
*snip*
Open source code is always better because no matter how clever ones thinks they are as a programmer, there are always better coders.
DING DING DING! I think you nailed the issue on the head. No one wants to admit that their code could be horrid. However, when opening your code, you are running the risk of someone coming up and saying "Hey, this is horrid, I rewrote it so it's ten times better." -- Plus there's the whole commenting, documentation, etc. That's at least doubling the workload.
I open source my software. Why? Because I /know/ my code is horrid. Nowhere to go but up.
If HRD was open sourced, I guarantee the satellite tracking piece would work perfectly for all radios because we would have fixed it.
However, that's a big statement to make. Getting an active development community around you codebase is a bit difficult. There is no way to guarantee such things.
On Wed, 28 Sep 2011 23:47:09 -0400 Ben Jackson bbj@innismir.net wrote:
I open source my software. Why? Because I /know/ my code is horrid. Nowhere to go but up.
You know, I was going to say the exact thing. I know my code is pretty horrible in places, but the more people that say "that bit is horrible, it should be like *this*" the better my coding gets. I'm still just learning. I've only been at it for 25 years, and I doubt I'll ever stop just learning.
If HRD was open sourced, I guarantee the satellite tracking piece would work perfectly for all radios because we would have fixed it.
However, that's a big statement to make. Getting an active development community around you codebase is a bit difficult. There is no way to guarantee such things.
Well the first thing to do would be to remove the existing radio controlling code and offload that to hamlib, if it doesn't already...
What's so wrong with Simon making a buck as the result of his hard work???
73, Joe kk0sd
-----Original Message----- From: amsat-bb-bounces@amsat.org [mailto:amsat-bb-bounces@amsat.org] On Behalf Of Ben Jackson Sent: Wednesday, September 28, 2011 10:47 PM To: Thomas Schaefer Cc: amsat-bb@amsat.org Subject: [amsat-bb] Re: HB9DRV
On 9/28/2011 10:52 AM, Thomas Schaefer wrote:
I have to say the statement about people not having the experience, time and patience to maintain it is pure egotistical nonsense.
*snip*
Open source code is always better because no matter how clever ones thinks they are as a programmer, there are always better coders.
DING DING DING! I think you nailed the issue on the head. No one wants to admit that their code could be horrid. However, when opening your code, you are running the risk of someone coming up and saying "Hey, this is horrid, I rewrote it so it's ten times better." -- Plus there's the whole commenting, documentation, etc. That's at least doubling the workload.
I open source my software. Why? Because I /know/ my code is horrid. Nowhere to go but up.
If HRD was open sourced, I guarantee the satellite tracking piece would work perfectly for all radios because we would have fixed it.
However, that's a big statement to make. Getting an active development community around you codebase is a bit difficult. There is no way to guarantee such things.
Well I can at least guarantee the 9100 and 821 would work as I would fix it. HRD has the nicest interface for the sat program. It just needs to be finished
Principal Solutions Architect Better Software Solutions, Inc. 727.437.2771
On Sep 29, 2011, at 7:26 AM, "Gary "Joe" Mayfield" gary_mayfield@hotmail.com wrote:
What's so wrong with Simon making a buck as the result of his hard work???
73, Joe kk0sd
-----Original Message----- From: amsat-bb-bounces@amsat.org [mailto:amsat-bb-bounces@amsat.org] On Behalf Of Ben Jackson Sent: Wednesday, September 28, 2011 10:47 PM To: Thomas Schaefer Cc: amsat-bb@amsat.org Subject: [amsat-bb] Re: HB9DRV
On 9/28/2011 10:52 AM, Thomas Schaefer wrote:
I have to say the statement about people not having the experience, time and patience to maintain it is pure egotistical nonsense.
*snip*
Open source code is always better because no matter how clever ones thinks they are as a programmer, there are always better coders.
DING DING DING! I think you nailed the issue on the head. No one wants to admit that their code could be horrid. However, when opening your code, you are running the risk of someone coming up and saying "Hey, this is horrid, I rewrote it so it's ten times better." -- Plus there's the whole commenting, documentation, etc. That's at least doubling the workload.
I open source my software. Why? Because I /know/ my code is horrid. Nowhere to go but up.
If HRD was open sourced, I guarantee the satellite tracking piece would work perfectly for all radios because we would have fixed it.
However, that's a big statement to make. Getting an active development community around you codebase is a bit difficult. There is no way to guarantee such things.
-- Ben Jackson - N1WBV - New Bedford, MA bbj <at> innismir.net - http://www.innismir.net/ _______________________________________________ Sent via AMSAT-BB@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
Sent via AMSAT-BB@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
On Sep 29, 2011, at 6:26 AM, Gary Joe Mayfield wrote:
What's so wrong with Simon making a buck as the result of his hard work???
73, Joe kk0sd
Nothing, but that's not what the discussion is about ...
Mike
This thread really spiraled out in all sorts of directions!
Anyhow, I have developed both OSS and commercial software. All I will say is you don't have to look very far to find utter crap or really good stuff in both worlds.
Dave Marhous' - What's your objective? Do you want a library to do your own thing?
If so, it may be worth taking a stab at some of these. I have a little bit of experience with all of them, so if you have any questions, fire away!
- If you're interested in writing your own tracking app in C, check out xephem (OSS)
- If you're interested in doing some tracking-scripting, there's a python wrapper called PyEphem, it's great and also OSS. See a brief blog post I did on it: http://libjoe.blogspot.com/2009/10/where-is-my-satellite-in-python.html
- If you're interested in writing your own tracking app in JAVA, check out JSatTrack (OSS). Ganos library is very easy to use! I am using it in an Android app I am writing.
If you (or anyone else) has questions, feel free to fire them off. I hope this helps!
Joseph Armbruster KJ4JIO
On Thu, Sep 29, 2011 at 9:58 AM, Michael Schulz mschulz@creative-chaos.comwrote:
On Sep 29, 2011, at 6:26 AM, Gary Joe Mayfield wrote:
What's so wrong with Simon making a buck as the result of his hard
work???
73, Joe kk0sd
Nothing, but that's not what the discussion is about ...
Mike _______________________________________________ Sent via AMSAT-BB@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
Nothing at all. My point was simply rebutting Bob's point that simply open sourcing code makes it a mess. As well as the arrogance to suggest no one else can understand your code.
The decision to go open source is the author's alone regardless of what the Richard Stallman code communists say. I think HRD could have been better as open source but that decision was only Simon's.
Tom NY4I
Principal Solutions Architect Better Software Solutions, Inc. 727.437.2771
On Sep 29, 2011, at 7:26 AM, "Gary "Joe" Mayfield" gary_mayfield@hotmail.com wrote:
What's so wrong with Simon making a buck as the result of his hard work???
73, Joe kk0sd
-----Original Message----- From: amsat-bb-bounces@amsat.org [mailto:amsat-bb-bounces@amsat.org] On Behalf Of Ben Jackson Sent: Wednesday, September 28, 2011 10:47 PM To: Thomas Schaefer Cc: amsat-bb@amsat.org Subject: [amsat-bb] Re: HB9DRV
On 9/28/2011 10:52 AM, Thomas Schaefer wrote:
I have to say the statement about people not having the experience, time and patience to maintain it is pure egotistical nonsense.
*snip*
Open source code is always better because no matter how clever ones thinks they are as a programmer, there are always better coders.
DING DING DING! I think you nailed the issue on the head. No one wants to admit that their code could be horrid. However, when opening your code, you are running the risk of someone coming up and saying "Hey, this is horrid, I rewrote it so it's ten times better." -- Plus there's the whole commenting, documentation, etc. That's at least doubling the workload.
I open source my software. Why? Because I /know/ my code is horrid. Nowhere to go but up.
If HRD was open sourced, I guarantee the satellite tracking piece would work perfectly for all radios because we would have fixed it.
However, that's a big statement to make. Getting an active development community around you codebase is a bit difficult. There is no way to guarantee such things.
-- Ben Jackson - N1WBV - New Bedford, MA bbj <at> innismir.net - http://www.innismir.net/ _______________________________________________ Sent via AMSAT-BB@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
Sent via AMSAT-BB@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
-----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
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@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.
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.
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.
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.
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@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
On Thu, 29 Sep 2011 08:53:28 -0400 "Lynn W. Deffenbaugh (Mr)" ldeffenb@homeside.to wrote:
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!
If you've written good code and good comments, you shouldn't need to take the time to do this. If you *haven't* written good code and good comments, you haven't a hope of understanding it in six months time. I and many others know this from experience ;-)
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.
What's stopping you posting it to a source repository with the caveat that if you want to dig around in it, you're on your own? That's pretty much what I do.
G4ILO has a fairly "interesting" attitude to it all, but his last paragraph is just about the truest thing written about software, ever. RTFM and say thank you. Oh, and send in bug reports and (if you have access to the source) patches!
While I have grown tired of the thread and shall retreat into the wood work, I do object to the generalization in the first reply that one has written bad code if one cannot handle multiple eyes on it. That seems unfair to make such a sweeping "black-or-white" statement. Forgive the pun, but too binary for my taste.
It has been fun and I look forward to those that want to release their code doing so and those that do not want to do that, keeping it under wraps. This has encouraged me to get something checked into the github or SourceForge (another thread?).
Tom NY4I On Sep 29, 2011, at 1:45 PM, Gordon JC Pearce wrote:
On Thu, 29 Sep 2011 08:53:28 -0400 "Lynn W. Deffenbaugh (Mr)" ldeffenb@homeside.to wrote:
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!
If you've written good code and good comments, you shouldn't need to take the time to do this. If you *haven't* written good code and good comments, you haven't a hope of understanding it in six months time. I and many others know this from experience ;-)
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.
What's stopping you posting it to a source repository with the caveat that if you want to dig around in it, you're on your own? That's pretty much what I do.
G4ILO has a fairly "interesting" attitude to it all, but his last paragraph is just about the truest thing written about software, ever. RTFM and say thank you. Oh, and send in bug reports and (if you have access to the source) patches!
-- Gordon JC Pearce MM0YEQ gordonjcp@gjcp.net _______________________________________________ Sent via AMSAT-BB@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
On Thu, 29 Sep 2011 12:17:45 +0000 David Moisan dmoisan@davidmoisan.org wrote:
- 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.
But they *have* been found. Who knows how many defects in closed-source OSes are out there, with viable exploits? Some eastern european guy, possibly, with a massive botnet. You? Me? Not bloody likely.
- 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.
Clearly if the absolute core of the OS is under some licence fundamentally incompatible with any OSI licence, then the whole gig is a failure from the start. Oh well, no matter. These things happen.
- 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.
Ah, the "viral licence" story. I wondered when that was coming out! You do realise that by using Microsoft's libraries and development tools for (for example) C#, you have to hand over the rights to your code to them? Check the EULA carefully - if Microsoft say they want it, you have to hand it over or you are no longer licensed to use their stuff. You have to be *so* careful with these things.
There's nothing to stop you dual-licensing code, even if one of those licences is the GPL.
- 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.
"Crippled", eh? I'm sure you can give some good examples, too.
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.
Is there really any point in doing that? As I've said in previous posts, controlling radios is a solved problem. You *do not need* to reinvent that particular wheel yet again. It's been invented, we have one, it's called hamlib, and it works.
No, the rig control interface is the least of the problems. The messy and incomprehensible UI needs work first.
participants (11)
-
Ben Jackson -
Bob Bruninga -
David Moisan -
Dominic Hawken -
Gary "Joe" Mayfield -
Gordon JC Pearce -
Joseph Armbruster -
Lynn W. Deffenbaugh (Mr) -
Michael Schulz -
Simon HB9DRV -
Thomas Schaefer