7 ms·

While open source is free as in beer, it’s also free as in baby (2014)

84 points by dantiberian 10y ago

seagreen 10y ago
> software decays over time, a.k.a. entropy This is similar advice to "always have your castle ready to withstand a siege". Both are excellent pieces of advice -- for 2010s software/the medieval ages respectively. But the advice is not timeless, once we get/got our crap together it stops making sense. Software decays because we don't track all its inputs. Once we do it will no longer decay, when run in environment X it will give output Y, every time. There's already movement on this front with http://nixos.org http://nixos.org and imitators -- I expect massive improvements on that front in our lifetimes. Of course, you still need an x86-64 computer or whatever. I doubt they'll stop making them any time soon though=)
- skybrian 10y ago
  You can track the environment all you want, but you still have to modify your software when the environment changes. If your software has a web page, browsers are not under your control. You don't know what the next version of Firefox is going to do. If your software runs on any cloud service, you don't know what they're going to do. Also, even if the software stayed the same, business requirements will change. New security holes will be discovered. Customer expectations will change. Who knows, maybe IPv6 will finally happen? Freezing your software is not an option for most people. The Internet is not done yet and it's not going to be done anytime soon.
  - chubot 10y ago
    It's possible that we will reach a point in computing history where we can run all historical software, and that this state of affairs will continue indefinitely. It just requires enough manpower put into "bootstrapping" of hardware in software (emulation). A decentralized Internet file system might help too. In other words, the "digital dark age" [1] for code (in addition to documents) doesn't need to last forever. You might compare it to things like farming, metallurgy, or plumbing. Many things in those areas were invented independently in different geographical areas, and some were altogether forgotten and reinvented later. But now we've reached a point in civilization where we're not going to forget them, because we have libraries, the Internet, and so forth. Likewise, at some point we should stop forgetting how to run old software as well. Old software can be made runnable now through conscious effort, but the "default" is still for it to rot and be forgotten. For web pages, the Internet Archive only does the server side... there does need to be an archive of web browsers as well, and there probably will be some day. I have no idea when that will be, but I think it will happen. [1] https://en.wikipedia.org/wiki/Digital_dark_age https://en.wikipedia.org/wiki/Digital_dark_age
    - ashitlerferad 10y ago
      https://www.softwareheritage.org/ https://www.softwareheritage.org/
      - chubot 10y ago
        That's a great effort. Though their mission isn't exactly what I am describing, it's definitely on the way. It seems like it is mostly about collecting source code at this point. But the harder problem is the build and runtime environments (and how to "bottom them out"). Without the ability to execute it, source code has limited utility. "Given that any software component may turn out to be essential in the future, we do not make distinctions and collect all software that is publicly available in source code form."
        ashitlerferad 10y ago
        The Debian snapshot service keeps binary packages too: http://snapshot.debian.org/ http://snapshot.debian.org/ The Ubuntu Launchpad system has something similar. Fedora's build servers keep all packages for eternity IIRC.
  - ashitlerferad 10y ago
    If your software runs on a CPU, those are not under your control :)
  - seagreen 10y ago
    I agree with all this:) I also enjoyed the article, "free as in baby" is a great phrase. At the same time I think it's important to note that the entropy analogy is just an analogy. Software is not actually subject to the laws of entropy (at least no more than a book or a poem is). Sure, often we want to change programs for various reasons -- that's not entropy. Most fields have to deal with actual entropy -- the fact that we don't should be super exciting. See chubot's adject comment for just some of the things this makes possible.
- hinkley 10y ago
  The inputs we don't track are the decisions that go into every bit of the code. Your memories are as important as the code, and your memory decays. So the code rots, even though the text stays the same. This is also why buying a software company and letting all the developers leave doesn't work. All that information disappears with them and you're stuck with a dead thing you have to try to reanimate.
- PieterH 10y ago
  The set of problems that any particular design will answer (it's a general thing, not just software) will change over time as economies change. That's why you probably don't own a horse, and certainly don't ride to work on one. Software may be 100% stable and yet will become gradually less accurate over time, doing work no-one needs and yet which places a cost on the project. You cannot prevent this. The right thing to do is to learn to abandon old solutions when they're no longer economical, and to move rapidly to build new ones that fit the same APIs, yet know more about the modern world. Hence your car seat is approximately the same API as a horse saddle, built on different technology.
- jussij 10y ago
  > Of course, you still need an x86-64 computer or whatever. I doubt they'll stop making them any time soon though=) There is plenty of hardware that would have been made 10 years ago that is no longer available. So if your system is based on such hardware, eventually it will fail, only because you wont be able to find spare parts to keep it running. Then as soon as you upgrade to newer hardware, you will run into OS issues where your older OS no longer works with the newer hardware. That will force you to also do an OS upgrade and that upgrade will then cause issues with your old code, which no longer runs on the new OS. So there is plenty of external factors, all outside of your control, which will cause decay in your software.
hiddentag 10y ago
Before you file a github issue, see if you can fix the problem yourself and submit a pull request. You're in the best position to fix the bug - you've reproduced the problem, you have the correct environment, and you have full source code. If you're unable to fix the problem, it's your duty to provide as much useful information as possible in order for someone else to solve it. Saying something like "it doesn't work with X" is not helpful. Put yourself in the position of the maintainer and provide the information you'd like to see - OS, versions, exact commands to reproduce the issue, sample data - whatever is necessary. And if you've reported an issue, it's your responsibility to follow up and test and prospective solutions and provide feedback. Their time is not less valuable than yours. Remember that open source project owners have done you a favor by giving you access to the code and owe you EXACTLY NOTHING. Complaining free riders are the worst. Give back to the community.
- no_protocol 10y ago
  > fix the problem yourself and submit a pull request For smaller projects out on GitHub I often see attempts at this that fail. Stuck in "Open" status for years or outright rejected. Maybe the account in control of the canonical repository is no longer active or interested in the project. Maybe that person doesn't understand or agree with the submitted code or asks for more accompanying work. Maybe the submission is under-documented or not even fully understood by the submitter. Each of these types of sticking points can be overcome, but the bottom line is they all take a lot of work from one side or the other. Does anyone have examples to share of open source projects that have very low friction for drive-by contributions while still maintaining quality? Projects with very clear documentation and instructions for contributing? It would be nice to have some models to aspire to.
  - hiddentag 10y ago
    Sure, you have to meet the coding guidelines and rules of the project. Many won't accept a drive by pull request without a unit test and documentation for example. 9 times out of 10 the project authors are grateful for the help.
  - voltagex_ 10y ago
ashitlerferad 10y ago
[2014]
mattip 10y ago
The OP refers to open source, but his comments apply just as much to any third-party component in your product. Many proprietary products also suffer from slow or non-existant upgrade paths, and then what do you do to upgrade the component?
exolymph 10y ago
tl;dr from the conclusion: > Open source software is a massive boon to programmer productivity, saving man centuries of effort. But remember, just as you own your availability, you also own your software and everything that goes into it.
mlvljr 10y ago
Free as a beer with a hair from Stallman's beard in it :)
JoeAltmaier 10y ago
"Free as in Baby" - how apt! I have my own children; I have no desire to adopt someone elses' brats. This explains perfectly why I'll search for a supported commercial product before any open-source deal.
watermoose 10y ago
While Daniel is correct that open source projects require upkeep and typically require a community of users and developers giving back to the project in order to succeed or at least continue, I think this could be misused as a reason to back those that erroneously conclude that closed source software that is backed by paid work on software is the best method, and this in my many years of experience is incorrect. Another correction is that "open source" does not mean free as in beer. Source can be open and not free. To ensure that you are using or offering source with a free license, please read: https://www.gnu.org/licenses/license-list.en.html https://www.gnu.org/licenses/license-list.en.html
- AJ007 10y ago
  By analogy open source is free as in baby while closed source is like a baby in a maximum security prison. At least one you have the option of fixing when it breaks. The other, you hand someone cash and maybe they fix it. The other problem, especially as software migrates in to pay-to-use cloud services, is that you have no clue what the future $ cost will be. Software startups that began with free tiers or really competitively priced tiers have morphed in to things that cost six or seven figures a year. String a few of these together and suddenly you have to figure out how to roll those costs back on to your own customers -- and it may turn out you don't have a viable business model. Further down the road, some of those companies won't exist. Some may be purchased by Oracle/IBM/MS and then reallocate funds from upkeep & dev to nightmare salespeople.
Klathmon 10y ago
>If you only need a small amount of relatively simple code and the license allows it, then just copy that code into your project. I disagree with this. With a good dependency management system, this should almost never be done, even for the most trivial code. If you find it somewhere else, and it's published as a "dependency" (module, package, etc...), you should install it as such. Lock the version, vendor your dependencies, keep a copy of the full source, but don't just copy it into your project. Even trivial code snippets "decay", and being able to look at a piece of code that "decayed" and see that there was an update 6 months ago that fixed the problem will save time over trying to follow code copied into your code base, a possibly out-of-date comment saying where it came from, and the chance that anyone could have modified it from it's original without updating the comment in the meantime. I think of a dependency is "copy-paste with metadata", and throwing out that metadata seems like a bad idea. Is there something I'm missing or have completely wrong, as I seem to see this being advocated for more and more, especially in the javascript ecosystem?

84 points by dantiberian 10y ago

> software decays over time, a.k.a. entropy This is similar advice to "always have your castle ready to withstand a siege". Both are excellent pieces of advice -- for 2010s software/the medieval ages respectively. But the advice is not timeless, once we get/got our crap together it stops making sense. Software decays because we don't track all its inputs. Once we do it will no longer decay, when run in environment X it will give output Y, every time. There's already movement on this front with http://nixos.org http://nixos.org and imitators -- I expect massive improvements on that front in our lifetimes. Of course, you still need an x86-64 computer or whatever. I doubt they'll stop making them any time soon though=)

skybrian 10y ago
You can track the environment all you want, but you still have to modify your software when the environment changes. If your software has a web page, browsers are not under your control. You don't know what the next version of Firefox is going to do. If your software runs on any cloud service, you don't know what they're going to do. Also, even if the software stayed the same, business requirements will change. New security holes will be discovered. Customer expectations will change. Who knows, maybe IPv6 will finally happen? Freezing your software is not an option for most people. The Internet is not done yet and it's not going to be done anytime soon.
- chubot 10y ago
  It's possible that we will reach a point in computing history where we can run all historical software, and that this state of affairs will continue indefinitely. It just requires enough manpower put into "bootstrapping" of hardware in software (emulation). A decentralized Internet file system might help too. In other words, the "digital dark age" [1] for code (in addition to documents) doesn't need to last forever. You might compare it to things like farming, metallurgy, or plumbing. Many things in those areas were invented independently in different geographical areas, and some were altogether forgotten and reinvented later. But now we've reached a point in civilization where we're not going to forget them, because we have libraries, the Internet, and so forth. Likewise, at some point we should stop forgetting how to run old software as well. Old software can be made runnable now through conscious effort, but the "default" is still for it to rot and be forgotten. For web pages, the Internet Archive only does the server side... there does need to be an archive of web browsers as well, and there probably will be some day. I have no idea when that will be, but I think it will happen. [1] https://en.wikipedia.org/wiki/Digital_dark_age https://en.wikipedia.org/wiki/Digital_dark_age
  - ashitlerferad 10y ago
    https://www.softwareheritage.org/ https://www.softwareheritage.org/
    - chubot 10y ago
      That's a great effort. Though their mission isn't exactly what I am describing, it's definitely on the way. It seems like it is mostly about collecting source code at this point. But the harder problem is the build and runtime environments (and how to "bottom them out"). Without the ability to execute it, source code has limited utility. "Given that any software component may turn out to be essential in the future, we do not make distinctions and collect all software that is publicly available in source code form."
      - ashitlerferad 10y ago
        The Debian snapshot service keeps binary packages too: http://snapshot.debian.org/ http://snapshot.debian.org/ The Ubuntu Launchpad system has something similar. Fedora's build servers keep all packages for eternity IIRC.
- ashitlerferad 10y ago
  If your software runs on a CPU, those are not under your control :)
- seagreen 10y ago
  I agree with all this:) I also enjoyed the article, "free as in baby" is a great phrase. At the same time I think it's important to note that the entropy analogy is just an analogy. Software is not actually subject to the laws of entropy (at least no more than a book or a poem is). Sure, often we want to change programs for various reasons -- that's not entropy. Most fields have to deal with actual entropy -- the fact that we don't should be super exciting. See chubot's adject comment for just some of the things this makes possible.
hinkley 10y ago
The inputs we don't track are the decisions that go into every bit of the code. Your memories are as important as the code, and your memory decays. So the code rots, even though the text stays the same. This is also why buying a software company and letting all the developers leave doesn't work. All that information disappears with them and you're stuck with a dead thing you have to try to reanimate.
PieterH 10y ago
The set of problems that any particular design will answer (it's a general thing, not just software) will change over time as economies change. That's why you probably don't own a horse, and certainly don't ride to work on one. Software may be 100% stable and yet will become gradually less accurate over time, doing work no-one needs and yet which places a cost on the project. You cannot prevent this. The right thing to do is to learn to abandon old solutions when they're no longer economical, and to move rapidly to build new ones that fit the same APIs, yet know more about the modern world. Hence your car seat is approximately the same API as a horse saddle, built on different technology.
jussij 10y ago
> Of course, you still need an x86-64 computer or whatever. I doubt they'll stop making them any time soon though=) There is plenty of hardware that would have been made 10 years ago that is no longer available. So if your system is based on such hardware, eventually it will fail, only because you wont be able to find spare parts to keep it running. Then as soon as you upgrade to newer hardware, you will run into OS issues where your older OS no longer works with the newer hardware. That will force you to also do an OS upgrade and that upgrade will then cause issues with your old code, which no longer runs on the new OS. So there is plenty of external factors, all outside of your control, which will cause decay in your software.

hiddentag 10y ago

Before you file a github issue, see if you can fix the problem yourself and submit a pull request. You're in the best position to fix the bug - you've reproduced the problem, you have the correct environment, and you have full source code. If you're unable to fix the problem, it's your duty to provide as much useful information as possible in order for someone else to solve it. Saying something like "it doesn't work with X" is not helpful. Put yourself in the position of the maintainer and provide the information you'd like to see - OS, versions, exact commands to reproduce the issue, sample data - whatever is necessary. And if you've reported an issue, it's your responsibility to follow up and test and prospective solutions and provide feedback. Their time is not less valuable than yours. Remember that open source project owners have done you a favor by giving you access to the code and owe you EXACTLY NOTHING. Complaining free riders are the worst. Give back to the community.

no_protocol 10y ago
> fix the problem yourself and submit a pull request For smaller projects out on GitHub I often see attempts at this that fail. Stuck in "Open" status for years or outright rejected. Maybe the account in control of the canonical repository is no longer active or interested in the project. Maybe that person doesn't understand or agree with the submitted code or asks for more accompanying work. Maybe the submission is under-documented or not even fully understood by the submitter. Each of these types of sticking points can be overcome, but the bottom line is they all take a lot of work from one side or the other. Does anyone have examples to share of open source projects that have very low friction for drive-by contributions while still maintaining quality? Projects with very clear documentation and instructions for contributing? It would be nice to have some models to aspire to.
- hiddentag 10y ago
  Sure, you have to meet the coding guidelines and rules of the project. Many won't accept a drive by pull request without a unit test and documentation for example. 9 times out of 10 the project authors are grateful for the help.
- voltagex_ 10y ago

ashitlerferad 10y ago

[2014]

mattip 10y ago

The OP refers to open source, but his comments apply just as much to any third-party component in your product. Many proprietary products also suffer from slow or non-existant upgrade paths, and then what do you do to upgrade the component?

exolymph 10y ago

tl;dr from the conclusion: > Open source software is a massive boon to programmer productivity, saving man centuries of effort. But remember, just as you own your availability, you also own your software and everything that goes into it.

mlvljr 10y ago

Free as a beer with a hair from Stallman's beard in it :)

JoeAltmaier 10y ago

"Free as in Baby" - how apt! I have my own children; I have no desire to adopt someone elses' brats. This explains perfectly why I'll search for a supported commercial product before any open-source deal.

watermoose 10y ago

While Daniel is correct that open source projects require upkeep and typically require a community of users and developers giving back to the project in order to succeed or at least continue, I think this could be misused as a reason to back those that erroneously conclude that closed source software that is backed by paid work on software is the best method, and this in my many years of experience is incorrect. Another correction is that "open source" does not mean free as in beer. Source can be open and not free. To ensure that you are using or offering source with a free license, please read: https://www.gnu.org/licenses/license-list.en.html https://www.gnu.org/licenses/license-list.en.html

AJ007 10y ago
By analogy open source is free as in baby while closed source is like a baby in a maximum security prison. At least one you have the option of fixing when it breaks. The other, you hand someone cash and maybe they fix it. The other problem, especially as software migrates in to pay-to-use cloud services, is that you have no clue what the future $ cost will be. Software startups that began with free tiers or really competitively priced tiers have morphed in to things that cost six or seven figures a year. String a few of these together and suddenly you have to figure out how to roll those costs back on to your own customers -- and it may turn out you don't have a viable business model. Further down the road, some of those companies won't exist. Some may be purchased by Oracle/IBM/MS and then reallocate funds from upkeep & dev to nightmare salespeople.

Klathmon 10y ago

>If you only need a small amount of relatively simple code and the license allows it, then just copy that code into your project. I disagree with this. With a good dependency management system, this should almost never be done, even for the most trivial code. If you find it somewhere else, and it's published as a "dependency" (module, package, etc...), you should install it as such. Lock the version, vendor your dependencies, keep a copy of the full source, but don't just copy it into your project. Even trivial code snippets "decay", and being able to look at a piece of code that "decayed" and see that there was an update 6 months ago that fixed the problem will save time over trying to follow code copied into your code base, a possibly out-of-date comment saying where it came from, and the chance that anyone could have modified it from it's original without updating the comment in the meantime. I think of a dependency is "copy-paste with metadata", and throwing out that metadata seems like a bad idea. Is there something I'm missing or have completely wrong, as I seem to see this being advocated for more and more, especially in the javascript ecosystem?