Hacker News new | past | comments | ask | show | jobs | submit login

> The point is not "buy vs build". The point is that one does not exclude the other.

This whole discussion is literally "buy vs build" and the fact that you don't know that means you're way out of your league here.




Something troubling you? Is making personal attacks going to make you feel any better? If putting me down helps your self-esteem: my very first comment started with "I was not cut out to work for a large organization". So cheer up, you get to wear the big man pants, ok?

The one thing that bugs me though... Maybe it is me being out of my league, but why can't bigger companies at least foment the develop of alternatives that reduce their dependency on third-party, closed service providers?

Another thing that I fail to grasp: why is it that smart and distinguished people like you always put a response in absolute, all-or-nothing terms? Case in point: when presented with one possible strategy, your counterargument was "do you expect all companies to do this?". The answer is (obviously) negative. In my childish mind, I thought it was possible to have different companies doing different things. Can you explain why this type of thinking is so clearly wrong? 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?


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


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


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


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


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


> You keep trying to convince me and others that companies ARE NOT DOING THIS ANALYSIS.

I am not arguing that they don't do "buy vs build" analysis. What I am saying is that they stop here, where it would be smart if they look for other options.

> No one does this or would do this, because it makes zero financial sense.

This is what I am saying that companies DON'T DO, and I am arguing that not doing this is short-sighted. There are plenty of strategic reasons that make it reasonable to invest in open source projects:

- It is good PR. [0]

- It can help with hiring: [1]

- It can be used as a negotiation tactic when dealing with different vendors. This is just an extension of the "Smart companies commoditize their complements" [2] idea from Joel Spolsky. Going back to the 1Password example: even if you still want to continue using 1Password, the "threat" of a viable open source alternative is enough for them to not try to jack up prices. By investing small sums in open source projects, you might be able to negotiate the price down on the closed services that you depend on.

- It reduces the risk of becoming locked into solutions from third-party vendors. Even if your company "keeps going back to Github", it might be wise to contribute to the development of an alternative as a backup plan. So, if push comes to shove and Github outages become so problematic that the they affect your business, there is a way out.

Not to mention that it can be tax-deductable, so you can get all these benefits without really affecting your bottom line.

[0]: https://blog.sentry.io/2021/10/21/we-just-gave-154-999-dolla...

[1]: https://news.ycombinator.com/item?id=31679118

[2]: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: