Hacker News Reader

Comment by logshipper | Hacker News Reader

I really respect that attitude.

I happen to be doing a security assessment on some products (PuTTY etc) at the firm (Fortune Global 100) where I am interning.

It baffled me to read a directive from management that said that we should shy away from open-source projects - I must confess that I was somewhat frustrated at the sheer ignorance in the memo but your comment allows me to see a silver-lining. I hope that one day I can rise up to management and make decisions based on greater nuance than simply saying "OSS bad and insecure".

View on HN

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.

> 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).

> 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.

well, you're wrong because of all the ideas my ADHD mind ever came up with - that wasn't one of them.

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.

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.

> 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.

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.

What's the point of keeping open bugs if you never fix them? It's not a cost free decision.

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.

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.

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.

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...

“ 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.

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.

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.

Do you make the internal code OSS?

Some of it - my custom HAL is OSS, and I've published the full repo code to one of my firmwares.

And do you get any PRs/issues? Are they all solved?

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.

There is a bit of a programmer trope "its easier to write code than to read it". This leads to reinventing wheels, duplicated effort, etc. When it comes to open source, I take the position that we are all in it together and try to come up with fixes for problems that I see in existing projects, even if I've never used the language before or the codebase is messy. I also think being able to work on code that came before you is a useful skill to have.

>reasonable confidence it can be a priority.

hahaha, you so funny

> 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.

Do you think the "clueless middle managers" the OP alludes to view themselves as such? Or are they too protecting their teams so they can get real work done?

We all see ourselves as the rare exception, the one bucking the status quo and doing things differently.

Reply on news.ycombinator.com