5 ms·

> but why can't bigger companies at least foment the develop of alternatives that reduce their dependency on third-party, closed service providers? They do. Th

by mbesto 4y ago

> but why can't bigger companies at least foment the develop of alternatives that reduce their dependency on third-party, closed service providers? They do. This is literally called "buy vs build". > why is it that smart and distinguished people like you always put a response in absolute, all-or-nothing terms? Because you started the conversation with absolute, all or nothing terms, which I countered. Read these two statements and tell me which is absolute, all-or-nothing and which isn't: *It's the fact that a company of 10k employees do not need to be at the mercy of a third-party vendor.* *Orgs (of all sizes) regularly do buy vs build analysis all of the time.* > What do they teach in the Big Boys League that show how that absolute conformity and total adherence to the rules is the surest way to win? Lay off of the conspiracy kool-aid will ya? Lots of reasonable people are disagreeing with you because we've all experienced this, not because some holier-than-thou entity is telling us to. > Something troubling you? Not the slightest, thanks though.

rglullis 4y ago
Nice to know is all good with you, it's a shame though that you resorted to personal attacks and name-calling. > This is literally called "buy vs build". "Buy vs build" presupposes an either/or decision. Like there is no point in building an alternative once a company has decided to buy something or vice-versa. It also seems to implicate that if a company chooses to "build", that they will be taking all of the burden and costs of development to themselves. What I'm talking about is beyond the buy/build dichotomy. What I am advocating is for companies to treat all and any systems that they depend on as a risk, and never stop looking or financing the development of F/OSS alternatives that can mitigate these risks. This does not mean that all companies should stop using Github and implement their own source repo/CI systems. It just means that companies should look for a way to hedge their bets. And if you think that this is something that companies do "all the time", I'd be eager to know of any, e.g, Design Agencies that support/contribute to the development of Gimp/Inkscape as insurance against their heavy dependence on Adobe Suite. Or companies (of any size) that allocate part of their budget to fund F/OSS alternatives to the SaaS solutions that they use. > Lots of reasonable people are disagreeing because we've all experienced this What I am seeing is "lots" of people attacking a strawman like the one you created. Maybe my phrasing was off, but my original question was "what would be the size of the team where having someone in-house to mitigate the risk of this dependency becomes clear?", and somehow this got translated (by you and others) to "why don't they just do everything in-house?".
- mbesto 4y ago
  > it's a shame though that you resorted to personal attacks and name-calling. > but I wonder what would be the point where it wouldn't take a bean-counter to say Name-calling you say? > Maybe my phrasing was off, but my original question was "what would be the size of the team where having someone in-house to mitigate the risk of this dependency becomes clear?" It wasn't. > It's the fact that a company of 10k employees do not need to be at the mercy of a third-party vendor. Re-read what you wrote again. You're just not discussing in good faith...we're done here.
  - rglullis 4y ago
    I didn't call you a bean-counter. You called me directly for "being out of my league". > Re-read what you wrote again. I read these two sentences you put there, and I still can not see what is contradictory about them. The idea I am trying to convey from the very beginning (even from last week's conversation) is "I think that buying from a closed SaaS when there is an open source alternative is stupid. Not only it costs more, it also does not really mitigate risk and it just gives an excuse to a manager to punt the problem to someone else. If however the open source solution is lacking some key functionality or you think that the best solution at the moment is to go with the established player, at least throw some money to the developers of the open alternatives as a hedge and eventual way out. The open source solution can give you optionality. You can do it in-house, or you can outsource it, etc."
    - mbesto 4y ago
      > Not only it costs more, it also does not really mitigate risk and it just gives an excuse to a manager to punt the problem to someone else. > You can do it in-house, or you can outsource it You are 100% correct companies should do this AND better yet this is exactly what is referred to as "Buy vs Build"[0]. You keep trying to convince me and others that companies ARE NOT DOING THIS ANALYSIS. I'm telling you that they most certainly are because it's literally what I do for a living (tech strategy consulting). And guess what, the reason companies keep coming back to closed-sourced providers (GitHub, etc.) is because over and over again we conclude it makes financial sense to do so. > at least throw some money to the developers of the open alternatives as a hedge and eventual way out. Now, this part is a hilarious suggestion. No one does this or would do this, because it makes zero financial sense. [0] - https://medium.com/adobetech/when-to-build-vs-buy-enterprise-platform-risks-benefits-and-considerations-fea358449b30 https://medium.com/adobetech/when-to-build-vs-buy-enterprise...

by mbesto 4y ago

rglullis 4y ago

Nice to know is all good with you, it's a shame though that you resorted to personal attacks and name-calling. > This is literally called "buy vs build". "Buy vs build" presupposes an either/or decision. Like there is no point in building an alternative once a company has decided to buy something or vice-versa. It also seems to implicate that if a company chooses to "build", that they will be taking all of the burden and costs of development to themselves. What I'm talking about is beyond the buy/build dichotomy. What I am advocating is for companies to treat all and any systems that they depend on as a risk, and never stop looking or financing the development of F/OSS alternatives that can mitigate these risks. This does not mean that all companies should stop using Github and implement their own source repo/CI systems. It just means that companies should look for a way to hedge their bets. And if you think that this is something that companies do "all the time", I'd be eager to know of any, e.g, Design Agencies that support/contribute to the development of Gimp/Inkscape as insurance against their heavy dependence on Adobe Suite. Or companies (of any size) that allocate part of their budget to fund F/OSS alternatives to the SaaS solutions that they use. > Lots of reasonable people are disagreeing because we've all experienced this What I am seeing is "lots" of people attacking a strawman like the one you created. Maybe my phrasing was off, but my original question was "what would be the size of the team where having someone in-house to mitigate the risk of this dependency becomes clear?", and somehow this got translated (by you and others) to "why don't they just do everything in-house?".

mbesto 4y ago
> it's a shame though that you resorted to personal attacks and name-calling. > but I wonder what would be the point where it wouldn't take a bean-counter to say Name-calling you say? > Maybe my phrasing was off, but my original question was "what would be the size of the team where having someone in-house to mitigate the risk of this dependency becomes clear?" It wasn't. > It's the fact that a company of 10k employees do not need to be at the mercy of a third-party vendor. Re-read what you wrote again. You're just not discussing in good faith...we're done here.
- rglullis 4y ago
  I didn't call you a bean-counter. You called me directly for "being out of my league". > Re-read what you wrote again. I read these two sentences you put there, and I still can not see what is contradictory about them. The idea I am trying to convey from the very beginning (even from last week's conversation) is "I think that buying from a closed SaaS when there is an open source alternative is stupid. Not only it costs more, it also does not really mitigate risk and it just gives an excuse to a manager to punt the problem to someone else. If however the open source solution is lacking some key functionality or you think that the best solution at the moment is to go with the established player, at least throw some money to the developers of the open alternatives as a hedge and eventual way out. The open source solution can give you optionality. You can do it in-house, or you can outsource it, etc."
  - mbesto 4y ago
    > Not only it costs more, it also does not really mitigate risk and it just gives an excuse to a manager to punt the problem to someone else. > You can do it in-house, or you can outsource it You are 100% correct companies should do this AND better yet this is exactly what is referred to as "Buy vs Build"[0]. You keep trying to convince me and others that companies ARE NOT DOING THIS ANALYSIS. I'm telling you that they most certainly are because it's literally what I do for a living (tech strategy consulting). And guess what, the reason companies keep coming back to closed-sourced providers (GitHub, etc.) is because over and over again we conclude it makes financial sense to do so. > at least throw some money to the developers of the open alternatives as a hedge and eventual way out. Now, this part is a hilarious suggestion. No one does this or would do this, because it makes zero financial sense. [0] - https://medium.com/adobetech/when-to-build-vs-buy-enterprise-platform-risks-benefits-and-considerations-fea358449b30 https://medium.com/adobetech/when-to-build-vs-buy-enterprise...