5 ms·

Users of only "stable" FOSS releases almost never contribute, in code, or to its health or longevity. They are leeching it, sometimes over decades. They don't

Users of only "stable" FOSS releases almost never contribute, in code, or to its health or longevity. They are leeching it, sometimes over decades. They don't contribute to testing either, since they just consume releases and ignore development, then wonder loudly why there are bugs. Don't be that guy... if you want your dependencies to have a long life being maintained, find some time to contribute. Leeching is not contribution.

passerby1 5y ago
It's probably a bit blind to think that there's only one way to contribute by fixing issues. However, the new feature development is very important too, and it usually it does not necessary require a testing or beta channel.
hsn915 5y ago
Thank you for confirmin that "Free and Open Source" does not value stability or quality. I'd rather pay for a closed program that comes with guarantees of stability and quality than participate in a community that considers these concerns tertiarty or off the menu entirely.
- exyi 5y ago
  Often times you can get a support for a stable OSS, and then you actually help the ecosystem by giving it resources
  - hsn915 5y ago
    Unfortunately, the "pay for support" business model means the incentive is to make a system that needs support but pretends on the surface to be stable and high quality. One way to make a system so incomprehensible that your customers absolutely need support is to make it configurable in a million different ways, and make the configuration invisible / opaque. Example: "Why is this program doing this when I told it to do that?" Answer: Because this file in that directory configure service A to do X, and this other file in that other directory configures the program to behave like Y if it detects that service A is doing X. But the program does not tell you that via its UI; you have to read obscure documentation.
    - md8z 5y ago
      I don't understand, isn't the original complaint here that everything needs support eventually?
      - hsn915 5y ago
        Everything should not need support. The fact that most everything needs support is a symptom of how crazy the software industry is.
        md8z 5y ago
        I keep hearing people say that, but how do you propose we write software that has no bugs and does everything perfectly right the first time? That seems impossible.
        AnIdiotOnTheNet 5y ago
        The first time? Sure, nothing ever gets it right the first time, but over time software should converge on being bug free and not requiring any support at all. Free-with-paid-support has a perverse incentive against this.
        md8z 5y ago
        "over time software should converge on being bug free" Yeah, and the way that's done is by refactoring things, removing buggy/deprecated things, and not adding any more new features/requirements... So, pick your poison, I guess? I'd love to go move on to the next job as much as the next person, but somebody still has to be paid to do those things. I don't see what the significant difference is there with free-with-paid-support, if you pay for it up front you're still paying the same cost.
        hsn915 5y ago
        All I hear is excuses. I'm not interestd in hearing excuses.
- yoyohello13 5y ago
  This is an absurd sweeping generalization. There are many FOSS projects that value stability and quality. Just like there are many closed source projects that don’t.
  - hsn915 5y ago
    The only one I'm aware of that does a good job of this is the Go language project, but it's not really your typical FOSS project; it's a Google project, and Google relies on it internally, so the incentive to make it stable and high quality is as high as it will ever get. They don't sell it to others, but they themselves rely on it as a core part of their own business.
    - zufallsheld 5y ago
      When was the last time the Linux kernel or the gnu utils broke for you? For me? Can't remember.
      - tomnipotent 5y ago
        The Linux kernel and many other big FOSS receive a non-trivial number of their contributions from professional programmers on the clock at their day job.
        comex 5y ago
        What does that have to do with anything?
        tomnipotent 5y ago
        It's not breaking because the contributions are from paid professional developers with commercial priorities and incentives, with internal or external customers often driving those changes. Not unlike Go.
      - hsn915 5y ago
bxparks 5y ago
I don't bother filing bugs or sending PRs. I spend hours filing a detailed bug report. No response. I spend hours crafting a PR. Ignored. I file a bug report along with several possible solutions. I get a snarky response totally unrelated the proposed solutions. But I get it. Maintainers are overworked and jaded. I'm on the receiving end as well, with 95% of the issues like: "help, it's broken" (with no error message), "please teach me git", "please debug my application code", "please implement this massive feature for me" (for free), "how do I do xxx?" (obviously didn't read the README.md), "your library is buggy" (no it's not, your pointer has run off the end of your array, causing Undefined Behavior). With all of that noise, it is difficult to figure out which bug reports or PRs are in the 5% that are actually well-researched and valid.
- throwaway13337 5y ago
  Well put. A reputation/karma system for bug reports could be an interesting way to deal with this problem. I wonder if it’s ever been tried.
- deathanatos 5y ago
  I file bug reports. It greatly depends on the person running the project; some are like you describe, or they're incompetent (particularly problematic in non-FOSS projects). Those, it's usually pretty clear that you're going to have to weigh "how much do I want this bug fixed" against how painful the process will be. But I've also had maintainers who were very helpful. Recently had to deal with the DST cross-sign expiring, and needed a third-party container to be rebuilt on a later version of Debian. Filed an issue with really nothing more than "Would you mind releasing with a newer version?"¹ and the maintainer had it published within like a day! Greatly made my life easier. So I really want to separate out those maintainers that are doing a stellar job; certainly some merit your criticism, just not all. ¹I didn't have time then to track down the Dockerfile & figure out the required patch. Might have once my time freed up, but the maintainer beat me to it.
  - tomnipotent 5y ago
    > particularly problematic in non-FOSS projects In my experience, the products I pay for usually fix bugs faster than FOSS.
jakear 5y ago
I would advise against calling users leeches. A product is meaningless without users, and those users that do go out of their way to file helpful bug reports should be lauded not disparaged. The phrase leeching implies an entity is consuming a host's life force in some way (seeders's bandwidth in the torrenting analogy), simply using the product does not meet this criteria.
SilasX 5y ago
I'd love to! Did you make sure your FOSS project is easy to build from source? I don't have to spend hours nagging the dev team for mysterious compilation bugs and dependencies? Projects that make this easy are the extreme exception, so if you actually get it right, then yes, I completely sympathize.

passerby1 5y ago

It's probably a bit blind to think that there's only one way to contribute by fixing issues. However, the new feature development is very important too, and it usually it does not necessary require a testing or beta channel.

hsn915 5y ago

Thank you for confirmin that "Free and Open Source" does not value stability or quality. I'd rather pay for a closed program that comes with guarantees of stability and quality than participate in a community that considers these concerns tertiarty or off the menu entirely.

exyi 5y ago
Often times you can get a support for a stable OSS, and then you actually help the ecosystem by giving it resources
- hsn915 5y ago
  Unfortunately, the "pay for support" business model means the incentive is to make a system that needs support but pretends on the surface to be stable and high quality. One way to make a system so incomprehensible that your customers absolutely need support is to make it configurable in a million different ways, and make the configuration invisible / opaque. Example: "Why is this program doing this when I told it to do that?" Answer: Because this file in that directory configure service A to do X, and this other file in that other directory configures the program to behave like Y if it detects that service A is doing X. But the program does not tell you that via its UI; you have to read obscure documentation.
  - md8z 5y ago
    I don't understand, isn't the original complaint here that everything needs support eventually?
    - hsn915 5y ago
      Everything should not need support. The fact that most everything needs support is a symptom of how crazy the software industry is.
      - md8z 5y ago
        I keep hearing people say that, but how do you propose we write software that has no bugs and does everything perfectly right the first time? That seems impossible.
        AnIdiotOnTheNet 5y ago
        The first time? Sure, nothing ever gets it right the first time, but over time software should converge on being bug free and not requiring any support at all. Free-with-paid-support has a perverse incentive against this.
        md8z 5y ago
        "over time software should converge on being bug free" Yeah, and the way that's done is by refactoring things, removing buggy/deprecated things, and not adding any more new features/requirements... So, pick your poison, I guess? I'd love to go move on to the next job as much as the next person, but somebody still has to be paid to do those things. I don't see what the significant difference is there with free-with-paid-support, if you pay for it up front you're still paying the same cost.
        hsn915 5y ago
        All I hear is excuses. I'm not interestd in hearing excuses.
yoyohello13 5y ago
This is an absurd sweeping generalization. There are many FOSS projects that value stability and quality. Just like there are many closed source projects that don’t.
- hsn915 5y ago
  The only one I'm aware of that does a good job of this is the Go language project, but it's not really your typical FOSS project; it's a Google project, and Google relies on it internally, so the incentive to make it stable and high quality is as high as it will ever get. They don't sell it to others, but they themselves rely on it as a core part of their own business.
  - zufallsheld 5y ago
    When was the last time the Linux kernel or the gnu utils broke for you? For me? Can't remember.
    - tomnipotent 5y ago
      The Linux kernel and many other big FOSS receive a non-trivial number of their contributions from professional programmers on the clock at their day job.
      - comex 5y ago
        What does that have to do with anything?
        tomnipotent 5y ago
        It's not breaking because the contributions are from paid professional developers with commercial priorities and incentives, with internal or external customers often driving those changes. Not unlike Go.
    - hsn915 5y ago

bxparks 5y ago

I don't bother filing bugs or sending PRs. I spend hours filing a detailed bug report. No response. I spend hours crafting a PR. Ignored. I file a bug report along with several possible solutions. I get a snarky response totally unrelated the proposed solutions. But I get it. Maintainers are overworked and jaded. I'm on the receiving end as well, with 95% of the issues like: "help, it's broken" (with no error message), "please teach me git", "please debug my application code", "please implement this massive feature for me" (for free), "how do I do xxx?" (obviously didn't read the README.md), "your library is buggy" (no it's not, your pointer has run off the end of your array, causing Undefined Behavior). With all of that noise, it is difficult to figure out which bug reports or PRs are in the 5% that are actually well-researched and valid.

throwaway13337 5y ago
Well put. A reputation/karma system for bug reports could be an interesting way to deal with this problem. I wonder if it’s ever been tried.
deathanatos 5y ago
I file bug reports. It greatly depends on the person running the project; some are like you describe, or they're incompetent (particularly problematic in non-FOSS projects). Those, it's usually pretty clear that you're going to have to weigh "how much do I want this bug fixed" against how painful the process will be. But I've also had maintainers who were very helpful. Recently had to deal with the DST cross-sign expiring, and needed a third-party container to be rebuilt on a later version of Debian. Filed an issue with really nothing more than "Would you mind releasing with a newer version?"¹ and the maintainer had it published within like a day! Greatly made my life easier. So I really want to separate out those maintainers that are doing a stellar job; certainly some merit your criticism, just not all. ¹I didn't have time then to track down the Dockerfile & figure out the required patch. Might have once my time freed up, but the maintainer beat me to it.
- tomnipotent 5y ago
  > particularly problematic in non-FOSS projects In my experience, the products I pay for usually fix bugs faster than FOSS.

jakear 5y ago

I would advise against calling users leeches. A product is meaningless without users, and those users that do go out of their way to file helpful bug reports should be lauded not disparaged. The phrase leeching implies an entity is consuming a host's life force in some way (seeders's bandwidth in the torrenting analogy), simply using the product does not meet this criteria.

SilasX 5y ago

I'd love to! Did you make sure your FOSS project is easy to build from source? I don't have to spend hours nagging the dev team for mysterious compilation bugs and dependencies? Projects that make this easy are the extreme exception, so if you actually get it right, then yes, I completely sympathize.