6 ms·

I think the general aversion to OSS is more that there is no responsible actor. In many cases, if you integrate a third party paid solution you can file a bug

by TimPC 5y ago

I think the general aversion to OSS is more that there is no responsible actor. In many cases, if you integrate a third party paid solution you can file a bug on that solution with reasonable confidence it can be a priority. If you use code from another team at the company you know you can file bugs on them. If you write code yourself you have confidence in fixing it. There is a danger with integrating OSS that you have code in your stack that no one knows well enough to fix and no one is responsible for. If something breaks you might have to learn a sizeable amount of code and domain knowledge to make a fix. Filing bugs on OSS is not viewed in the same way as filing bugs on paid third party solutions as whether the bugs are a priority to an OSS solution seems more risky. Note that large amounts of OSS is used in companies, but it's generally code that developers are expected to know well enough to dive into if need be. And code that is popular enough to be well tested for bugs and known that breaking errors in the framework will get fixes. Examples would be things like Python or Node.js. As a manager a potential problem you can have is a major bug your team is responsible for that no one is qualified to fix and thus your only reasonable time estimate is unknown. Avoiding certain parts of OSS is often a precaution against this situation.

WalterBright 5y ago
> I think the general aversion to OSS is more that there is no responsible actor. I have filed many bug reports for paid software over the years. The bugs were fixed exactly 0% of the time. If they ever gave a reason, it was along the lines of "you are a special snowflake, nobody else has had that problem, so it isn't worth fixing". Eventually, I just stopped filing bug reports. Things aren't better with OSS, either, though I resent went bugs get closed because they're old. Our policy with D is we never close bugs, no matter how old they are, unless we fix them or no longer have users for it (like D version 1).
- gopher_space 5y ago
  > I resent went bugs get closed because they're old I'm picturing the guy who came up with this idea sitting at his desk surrounded by unopened bills.
  - bryanrasmussen 5y ago
    well, you're wrong because of all the ideas my ADHD mind ever came up with - that wasn't one of them.
- hyperman1 5y ago
  While I understand your lack of success with bug reports, and I thank you for your stance on (not) closing bugs, note how the average manager got what he wanted:. A proof that reasonable effort has been made, and it's not his fault. This allows survival in a politically piosonous environment. If the bug got fixed is generally not their concern, others will have to deal with it and move on. Besides, I once got Oracle to fix a bug. It took months and I basically had to spell the fix out to them, but it actually is possible.
  - OldHand2018 5y ago
    Nice job! How long did you have to wait for the new software version after the bug fix? A few months ago, one of our young devs got a PR accepted to fix a tiny little Spark bug that had been bothering us for a while. The big boss meeting was happy, plenty of virtual pats on the backs and congratulations. And then someone had to go and ask when we'd see the fix in our DataBricks cluster.
- ptero 5y ago
  > I have filed many bug reports for paid software over the years. The bugs were fixed exactly 0% of the time In my experience, the big difference is buying software (good luck with getting Microsoft fixing a bug in office or windows; no one even tries) vs buying a service. If we bought specialized custom software support for some expensive hardware, those companies jump when there is a question.
  - voakbasda 5y ago
    They jump if you paid for a service contract. If you paid for a product, those companies owe you something fit for its intended purpose, and bugs are not that.
- winphone1974 5y ago
  What's the point of keeping open bugs if you never fix them? It's not a cost free decision.
  - WalterBright 5y ago
    It is cost free. It prevents people from filing it again. It provides insight into later problems. It provides a place where people can ask and offer advice on working around it. Sometimes an intractable bug becomes more tractable later. It can provide a clue to a later bug report. Sometimes someone new has a brainwave on how to fix it.
    - cxr 5y ago
      That would require a project be worthwhile to stick around long enough for an opportunity for someone new to come along, let alone come along and be interested in it. It's obvious that most career programmers are only used to ("interested in"?) pushing devops shovelware onto GitHub and other forms of busywork, so it shows in their bug-handling hygiene.
  - pabs3 5y ago
    They are still problems that need fixing, some day someone may be doing work on the project without knowing what to work on and having a backlog of issues categorised by importance/etc will be useful in that situation.
- ta988 5y ago
  Have you ever filled a bug for the JDK? I was at 20 emails, plus having to create accounts and give paperwork that our company had a license for a one-liner correction of a major bug when I decided to abandon and wrap my code in an exception catcher and manage it on my side...
spaetzleesser 5y ago
“ I think the general aversion to OSS is more that there is no responsible actor. In many cases, if you integrate a third party paid solution you can file a bug on that solution with reasonable confidence it can be a priority” I know that’s what management believes but in reality it’s a complete illusion. I can’t recall a simple time where we got a bug fix within reasonable time from any of our 6, 7, or 8 figure software vendors. You get fixes only if you have paid for custom code but tickets against the actual product disappear into the void.
legerdemain 5y ago
In contra other replies here, we have repeatedly sent bug reports to vendors and got productive, timely, comprehensive support and fixes: Hashi, Snowflake, Databricks, Confluent, and others. We're a Bay Area company of about 500 people, not a market behemoth in any way.
the__alchemist 5y ago
This is my take as well. I build and sell electronics, coded in Rust. (Cortex-M). I started using OSS HALs, device drivers, utility crates, peripheral access libs etc. Each of them had bugs, missing features, or awkward APIs. I got about 10% of my issues and PRs addressed. I now use almost exclusively internal code (with exceptions for debug tools and the cortex-m lib). If there's a problem or limitation, I fix it myself. Far easier than spelunking someone else's code, or hoping a maintainer fixes it.
- pabs3 5y ago
  Do you make the internal code OSS?
  - the__alchemist 5y ago
    Some of it - my custom HAL is OSS, and I've published the full repo code to one of my firmwares.
    - pabs3 5y ago
      And do you get any PRs/issues? Are they all solved?
      - the__alchemist 5y ago
        I've had a few. All solved except one. I suspect only a few people are using my lib, and all are hobbyists. A particular challenge with this lib is I'm attempting to support most (newer) STM32 variants using a single HAL lib, which makes ops testing tough. (This allows me the flexibility to choose whichever variant I'd like on future projects without modifying the code base). I've published code so others can use it as an example. Reading between the lines of your questions: I'm not throwing spears at the lib maintainers; I'm pointing out that relying on 3rd party code may cause complications. In my case, I made a decision on each individual lib.
        5y ago
France_is_bacon 5y ago
>reasonable confidence it can be a priority. hahaha, you so funny
pabs3 5y ago
> I think the general aversion to OSS is more that there is no responsible actor. Unless the OSS in question has an enterprise support subscription that is useful, the best responsible actor for OSS projects is all (or a subset of) your employees. They know your workload best and know the issues that affect you most and can learn the skills needed to improve the OSS that you use. Having a diverse set of companies contributing to an OSS project makes it suitable for a more diverse set of use cases and circumstances.

by TimPC 5y ago

WalterBright 5y ago

> I think the general aversion to OSS is more that there is no responsible actor. I have filed many bug reports for paid software over the years. The bugs were fixed exactly 0% of the time. If they ever gave a reason, it was along the lines of "you are a special snowflake, nobody else has had that problem, so it isn't worth fixing". Eventually, I just stopped filing bug reports. Things aren't better with OSS, either, though I resent went bugs get closed because they're old. Our policy with D is we never close bugs, no matter how old they are, unless we fix them or no longer have users for it (like D version 1).

gopher_space 5y ago
> I resent went bugs get closed because they're old I'm picturing the guy who came up with this idea sitting at his desk surrounded by unopened bills.
- bryanrasmussen 5y ago
  well, you're wrong because of all the ideas my ADHD mind ever came up with - that wasn't one of them.
hyperman1 5y ago
While I understand your lack of success with bug reports, and I thank you for your stance on (not) closing bugs, note how the average manager got what he wanted:. A proof that reasonable effort has been made, and it's not his fault. This allows survival in a politically piosonous environment. If the bug got fixed is generally not their concern, others will have to deal with it and move on. Besides, I once got Oracle to fix a bug. It took months and I basically had to spell the fix out to them, but it actually is possible.
- OldHand2018 5y ago
  Nice job! How long did you have to wait for the new software version after the bug fix? A few months ago, one of our young devs got a PR accepted to fix a tiny little Spark bug that had been bothering us for a while. The big boss meeting was happy, plenty of virtual pats on the backs and congratulations. And then someone had to go and ask when we'd see the fix in our DataBricks cluster.
ptero 5y ago
> I have filed many bug reports for paid software over the years. The bugs were fixed exactly 0% of the time In my experience, the big difference is buying software (good luck with getting Microsoft fixing a bug in office or windows; no one even tries) vs buying a service. If we bought specialized custom software support for some expensive hardware, those companies jump when there is a question.
- voakbasda 5y ago
  They jump if you paid for a service contract. If you paid for a product, those companies owe you something fit for its intended purpose, and bugs are not that.
winphone1974 5y ago
What's the point of keeping open bugs if you never fix them? It's not a cost free decision.
- WalterBright 5y ago
  It is cost free. It prevents people from filing it again. It provides insight into later problems. It provides a place where people can ask and offer advice on working around it. Sometimes an intractable bug becomes more tractable later. It can provide a clue to a later bug report. Sometimes someone new has a brainwave on how to fix it.
  - cxr 5y ago
    That would require a project be worthwhile to stick around long enough for an opportunity for someone new to come along, let alone come along and be interested in it. It's obvious that most career programmers are only used to ("interested in"?) pushing devops shovelware onto GitHub and other forms of busywork, so it shows in their bug-handling hygiene.
- pabs3 5y ago
  They are still problems that need fixing, some day someone may be doing work on the project without knowing what to work on and having a backlog of issues categorised by importance/etc will be useful in that situation.
ta988 5y ago
Have you ever filled a bug for the JDK? I was at 20 emails, plus having to create accounts and give paperwork that our company had a license for a one-liner correction of a major bug when I decided to abandon and wrap my code in an exception catcher and manage it on my side...

spaetzleesser 5y ago

“ I think the general aversion to OSS is more that there is no responsible actor. In many cases, if you integrate a third party paid solution you can file a bug on that solution with reasonable confidence it can be a priority” I know that’s what management believes but in reality it’s a complete illusion. I can’t recall a simple time where we got a bug fix within reasonable time from any of our 6, 7, or 8 figure software vendors. You get fixes only if you have paid for custom code but tickets against the actual product disappear into the void.

legerdemain 5y ago

In contra other replies here, we have repeatedly sent bug reports to vendors and got productive, timely, comprehensive support and fixes: Hashi, Snowflake, Databricks, Confluent, and others. We're a Bay Area company of about 500 people, not a market behemoth in any way.

the__alchemist 5y ago

This is my take as well. I build and sell electronics, coded in Rust. (Cortex-M). I started using OSS HALs, device drivers, utility crates, peripheral access libs etc. Each of them had bugs, missing features, or awkward APIs. I got about 10% of my issues and PRs addressed. I now use almost exclusively internal code (with exceptions for debug tools and the cortex-m lib). If there's a problem or limitation, I fix it myself. Far easier than spelunking someone else's code, or hoping a maintainer fixes it.

pabs3 5y ago
Do you make the internal code OSS?
- the__alchemist 5y ago
  Some of it - my custom HAL is OSS, and I've published the full repo code to one of my firmwares.
  - pabs3 5y ago
    And do you get any PRs/issues? Are they all solved?
    - the__alchemist 5y ago
      I've had a few. All solved except one. I suspect only a few people are using my lib, and all are hobbyists. A particular challenge with this lib is I'm attempting to support most (newer) STM32 variants using a single HAL lib, which makes ops testing tough. (This allows me the flexibility to choose whichever variant I'd like on future projects without modifying the code base). I've published code so others can use it as an example. Reading between the lines of your questions: I'm not throwing spears at the lib maintainers; I'm pointing out that relying on 3rd party code may cause complications. In my case, I made a decision on each individual lib.
      - 5y ago

France_is_bacon 5y ago

>reasonable confidence it can be a priority. hahaha, you so funny

pabs3 5y ago

> I think the general aversion to OSS is more that there is no responsible actor. Unless the OSS in question has an enterprise support subscription that is useful, the best responsible actor for OSS projects is all (or a subset of) your employees. They know your workload best and know the issues that affect you most and can learn the skills needed to improve the OSS that you use. Having a diverse set of companies contributing to an OSS project makes it suitable for a more diverse set of use cases and circumstances.