4 ms·

> Federal contractors don't need to sell proprietary software to make money -- they make more money selling FOSS software. tech companies in general are making

> Federal contractors don't need to sell proprietary software to make money -- they make more money selling FOSS software. tech companies in general are making billions using FOSS.

kube-system 4y ago
Of course, which is why I think viewing this as a push for proprietary software is not a fair assessment. Increasing your company's development costs is not a way to make more profit. The point of this is that you can't treat proprietary software dependencies the same way you treat FOSS. Community FOSS projects just don't have the same development process and governance model that proprietary software does. And so, the assessment of these projects is necessarily different.
- peteforde 4y ago
  Respectfully, you have a too-reasonable hunch of how decisions are made at the executive level, and because of that, you're reaching an incorrect conclusion. The primary factor driving the decision making process is not cost but risk. Many fail to remember the lengths to which companies like Microsoft, Oracle, Sun and others went to create FUD around the adoption of OSS in the public sector. It involved lobbyists, marketing campaigns and a whole certifications industry. When a CIO selects a technology, they aren't just weighing its merits and price tag; they are actively looking to leave a glowing legacy while actively doing everything they can to avoid being humiliated if the technology fails. See, the CIO knows that, as far as their board of directors is concerns, it's not the software that failed but the executive. That's why enterprise support packages exist; it's an insurance policy and a promise that if something goes terribly wrong at 2am, someone is going to pick up the phone when you call. Companies with expensive tools have an obvious interest in convincing their best customers that the competition in inherently risky.
  - deleted 4y ago
    [deleted]
  - Forgeties79 4y ago
    >Companies with expensive tools have an obvious interest in convincing their best customers that the competition is inherently risky Honestly I’m embarrassed at how revelatory this line is.
  - kube-system 4y ago
    Government contractors expensive tools are already heavily using open source tools. The whole log4j scandal that this bill is in response to is perfect evidence of exactly that. It is not in the interest of 'proprietary' software vendors to fearmonger about OSS libraries. They too use OSS libraries just like everyone else does today. It isn't 1995 anymore where a proprietary piece of software can run on a full stack of code written by the people who work locked away in a single building at one company. Everyone is using open source dependencies. There is nobody left that would benefit by demonizing open source libraries.
    - leaflets2 4y ago
      It's not OSS libraries they'd be worried about, as competitors, but OSS applications, I d think.
      - kube-system 4y ago
        This bill is in response to a recent issue with an OSS library: log4j.
        leaflets2 4y ago
        Maybe. At least that's what they want you to think
  - origin_path 4y ago
    "Companies with expensive tools have an obvious interest in convincing their best customers that the competition in inherently risky." The problem is that they don't need to do this. In the open source community we're doing a great job all by ourselves. I've written open source libraries and platforms, I've also written proprietary software that uses open source. Log4j, Heartbleed, half of NPM etc weren't the work of Oracle lobbyists, they were avoidable fuckups caused by everyone relying on critical infrastructure that wasn't really maintained. I'd actually go further and say you overestimate the power of lobbying and underestimate the possibility of lobbyist's having a point. The primary argument these firms made against relying on OSS was that it's often just a bunch of random people with no incentive to do the un-fun work like security audits or patch backports. There's nobody who takes responsibility for things. That's true and is pretty much the core of Red Hat's business model so it's not like anyone can really dispute this. The software industry does need new approaches to how we use open source stuff, IMO. Sandboxing of libraries would go a long way. But we can't just pretend there's no problem here and it's all the work of shadowy corporations, it's naive ideological stuff.
    - mistrial9 4y ago
      > they were avoidable fuckups caused by everyone relying on critical infrastructure that wasn't really maintained uhh rewriting history much? the reason the entire world uses openssl is because it operates correctly. The judgement here is diluted by exaggerating the worst moments of an otherwise profoundly performant ecosystem. btw- I turned my outward facing servers off for three days for Heartbleed, so .. how to balance a serious development, with the growth of billions of devices working correctly each day for years to get here. In a previous life I did work on internal proprietary C/C++ code bases and yes, there were ridiculous technical debts, bugs, and missed opportunities right along with correct code, insights reduced to code, and solving hard problems well.
- dathinab 4y ago
  > process and governance model that proprietary software does. except that a lot of proprietary software doesn't has anything like that either there is nothing in common proprietary dev practices which would have e.g. prevented log4j the main difference is that you can hold someone financially responsible in one case and not in the other (but in turn you can always fix any problem yourself, good luck fixing any proprietary software after it's support runs out).
  - themitigating 4y ago
    They could verify the security of the oss, look for vulnerabilities, run scanners. This is possible because log4j is OSS.
  - kube-system 4y ago
    It does when you sell it to the government, which is what this is about. The federal government has rules regarding the acquisition of software products, and they have various governance and risk management requirements for various scenarios. Many of these were designed with proprietary software in mind. The point of this bill is to update some of those requirements to make sense with the way OSS works.
- Too 4y ago
  That’s assuming these individuals aim to make profit for their entity. The risk raised above was corruption, with tax paid development cost going to their uncles company, with a big fat kickback under the table.
  - kube-system 4y ago
    Dependency management is a real security concern. There’s no corruption there. The root comment suggested that somehow this was a smear on FOSS, intended to sell more proprietary software. However, this doesn’t hold up, because FOSS components are widely used by all of the big proprietary software vendors in this space too.

> Federal contractors don't need to sell proprietary software to make money -- they make more money selling FOSS software. tech companies in general are making billions using FOSS.

kube-system 4y ago

Of course, which is why I think viewing this as a push for proprietary software is not a fair assessment. Increasing your company's development costs is not a way to make more profit. The point of this is that you can't treat proprietary software dependencies the same way you treat FOSS. Community FOSS projects just don't have the same development process and governance model that proprietary software does. And so, the assessment of these projects is necessarily different.

peteforde 4y ago
Respectfully, you have a too-reasonable hunch of how decisions are made at the executive level, and because of that, you're reaching an incorrect conclusion. The primary factor driving the decision making process is not cost but risk. Many fail to remember the lengths to which companies like Microsoft, Oracle, Sun and others went to create FUD around the adoption of OSS in the public sector. It involved lobbyists, marketing campaigns and a whole certifications industry. When a CIO selects a technology, they aren't just weighing its merits and price tag; they are actively looking to leave a glowing legacy while actively doing everything they can to avoid being humiliated if the technology fails. See, the CIO knows that, as far as their board of directors is concerns, it's not the software that failed but the executive. That's why enterprise support packages exist; it's an insurance policy and a promise that if something goes terribly wrong at 2am, someone is going to pick up the phone when you call. Companies with expensive tools have an obvious interest in convincing their best customers that the competition in inherently risky.
- deleted 4y ago
  [deleted]
- Forgeties79 4y ago
  >Companies with expensive tools have an obvious interest in convincing their best customers that the competition is inherently risky Honestly I’m embarrassed at how revelatory this line is.
- kube-system 4y ago
  Government contractors expensive tools are already heavily using open source tools. The whole log4j scandal that this bill is in response to is perfect evidence of exactly that. It is not in the interest of 'proprietary' software vendors to fearmonger about OSS libraries. They too use OSS libraries just like everyone else does today. It isn't 1995 anymore where a proprietary piece of software can run on a full stack of code written by the people who work locked away in a single building at one company. Everyone is using open source dependencies. There is nobody left that would benefit by demonizing open source libraries.
  - leaflets2 4y ago
    It's not OSS libraries they'd be worried about, as competitors, but OSS applications, I d think.
    - kube-system 4y ago
      This bill is in response to a recent issue with an OSS library: log4j.
      - leaflets2 4y ago
        Maybe. At least that's what they want you to think
- origin_path 4y ago
  "Companies with expensive tools have an obvious interest in convincing their best customers that the competition in inherently risky." The problem is that they don't need to do this. In the open source community we're doing a great job all by ourselves. I've written open source libraries and platforms, I've also written proprietary software that uses open source. Log4j, Heartbleed, half of NPM etc weren't the work of Oracle lobbyists, they were avoidable fuckups caused by everyone relying on critical infrastructure that wasn't really maintained. I'd actually go further and say you overestimate the power of lobbying and underestimate the possibility of lobbyist's having a point. The primary argument these firms made against relying on OSS was that it's often just a bunch of random people with no incentive to do the un-fun work like security audits or patch backports. There's nobody who takes responsibility for things. That's true and is pretty much the core of Red Hat's business model so it's not like anyone can really dispute this. The software industry does need new approaches to how we use open source stuff, IMO. Sandboxing of libraries would go a long way. But we can't just pretend there's no problem here and it's all the work of shadowy corporations, it's naive ideological stuff.
  - mistrial9 4y ago
    > they were avoidable fuckups caused by everyone relying on critical infrastructure that wasn't really maintained uhh rewriting history much? the reason the entire world uses openssl is because it operates correctly. The judgement here is diluted by exaggerating the worst moments of an otherwise profoundly performant ecosystem. btw- I turned my outward facing servers off for three days for Heartbleed, so .. how to balance a serious development, with the growth of billions of devices working correctly each day for years to get here. In a previous life I did work on internal proprietary C/C++ code bases and yes, there were ridiculous technical debts, bugs, and missed opportunities right along with correct code, insights reduced to code, and solving hard problems well.
dathinab 4y ago
> process and governance model that proprietary software does. except that a lot of proprietary software doesn't has anything like that either there is nothing in common proprietary dev practices which would have e.g. prevented log4j the main difference is that you can hold someone financially responsible in one case and not in the other (but in turn you can always fix any problem yourself, good luck fixing any proprietary software after it's support runs out).
- themitigating 4y ago
  They could verify the security of the oss, look for vulnerabilities, run scanners. This is possible because log4j is OSS.
- kube-system 4y ago
  It does when you sell it to the government, which is what this is about. The federal government has rules regarding the acquisition of software products, and they have various governance and risk management requirements for various scenarios. Many of these were designed with proprietary software in mind. The point of this bill is to update some of those requirements to make sense with the way OSS works.
Too 4y ago
That’s assuming these individuals aim to make profit for their entity. The risk raised above was corruption, with tax paid development cost going to their uncles company, with a big fat kickback under the table.
- kube-system 4y ago
  Dependency management is a real security concern. There’s no corruption there. The root comment suggested that somehow this was a smear on FOSS, intended to sell more proprietary software. However, this doesn’t hold up, because FOSS components are widely used by all of the big proprietary software vendors in this space too.