> It's the fact that a company of 10k employees do not need to be at the mercy of a third-party vendor.
Oh man, where do I even start here. Have you ever worked in a company with 10k employees? In IT at a company with 10k employees?
> Github/Jira/CI/Contentful/Dropbox/Figma/etc/etc/etc, when there are alternatives that could work and people don't even try them.
So let me get this straight. You expect every organization with 10k employees to:
- Find talent to build, operate, and maintain on said systems
- Keep that talent
- Train employees on said systems. Cheryl in accounting has only used SAP and you want her to understand how to use XYZ?
- Spend the time NOT having the solution available to them while they wait for said system to be built/implemented.
- And and and...
> No, I am not. Check the comment that I referenced. I suggested a scenario where you can hire someone to implement the solution and have an ongoing support contract for a fraction of the cost from 1Password.
You absolutely are. You clearly have no understanding when it comes to what is required to "just hire someone to do it".
> Surely any Engineering Manager worth anything
Yaaa, no true scotsmen!
The trope of "just hire someone" needs to die. Orgs (of all sizes) regularly do buy vs build analysis all of the time. Saying that one is better than the other unilaterally is just plain wrong.
> Orgs (of all sizes) regularly do buy vs build analysis all of the time.
The point is not "buy vs build". The point is that one does not exclude the other.
Sally from accounting has only used SAP? Fine, keep paying for it, but also invest in the development of an alternative. Also go to Sally and offer training in this alternative. Ask Sally what is missing in the alternative compared to what she's used to. Take her feedback to the developers and tell them "If you solve X, Y and Z, we might be able to drop SAP and switch to you".
> You expect every organization with 10k employees to find talent to build, operate, and maintain on said systems.
No. I'm expecting that some of them will be able to it in-house. Others will look for a third-party vendor that does not lock them in. Others will continue using the proprietary solution BUT will set aside part of their budget to invest in open source alternatives, as a way to create an open source alternative that can help negotiate with the proprietary vendor.
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.
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.
> 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.
Oh man, where do I even start here. Have you ever worked in a company with 10k employees? In IT at a company with 10k employees?
> Github/Jira/CI/Contentful/Dropbox/Figma/etc/etc/etc, when there are alternatives that could work and people don't even try them.
So let me get this straight. You expect every organization with 10k employees to:
- Find talent to build, operate, and maintain on said systems
- Keep that talent
- Train employees on said systems. Cheryl in accounting has only used SAP and you want her to understand how to use XYZ?
- Spend the time NOT having the solution available to them while they wait for said system to be built/implemented.
- And and and...
> No, I am not. Check the comment that I referenced. I suggested a scenario where you can hire someone to implement the solution and have an ongoing support contract for a fraction of the cost from 1Password.
You absolutely are. You clearly have no understanding when it comes to what is required to "just hire someone to do it".
> Surely any Engineering Manager worth anything
Yaaa, no true scotsmen!
The trope of "just hire someone" needs to die. Orgs (of all sizes) regularly do buy vs build analysis all of the time. Saying that one is better than the other unilaterally is just plain wrong.