Because centralized management of resources is the death of innovation, intrinsic motivation and speed?
The dreaded "process" to get a single tool registered, working and allowed, is the reason a company is slow, dysfunctional and usually failing at a task.
The security tax and speeding tickets on everything are a luxury destroying much value.
This is the new old way. This was fine before irresponsible use of AI. Between vibe coding and using AI to find vulnerabilities as a result of vibes, I'm afraid that we will have to find ways to have more controlled environments.
It seems likely that some companies where the trade off shifts will head in that direction.
The problem with controlled environments is that even when done sensibly by people with good intentions they do slow things down and a lot of orgs will decide the trade off isn’t worth that.
I’ve worked for companies that did have much more controlled environments but given everything is made of a thousand packages these days and those packages have CVE’s and you do need to patch doing it after the fact is a recipe for paralysis.
I don’t think it does, I was just pointing out their issues are likely caused by the centralized resource managementent (mentioned by https://news.ycombinator.com/item?id=48219114 you responded to), and not the „move fast, break things“ aspect. Just my guess. But yeah, it doesn’t matter if it is MS or GitHub itself
Your company getting hacked because of random plugins for emerging or dysfunctional ecosystems that don’t have enterprise management solutions yet is worth it to avoid friction?
The friction they should have probably had here is: did this employee need access to 3,800 internal repos?
I'm with the poster above in believing restricting what you can install makes a lot of things more difficult, but if you're going to take the risk you should be limiting the blast radius.
It's true. But at the same time, isn't it crazy to conclude that a company should restrict their developers from using their own developer productivity tools and services? If Microsoft devs shouldn't use random VSCode extensions, how could anyone?
Fair point, I hadn't considered this, but wouldn't they just disallow it?
Like, I use a VSCode fork at work, but the enforced extensions store backend is based on an allowlist and extensions need reviewing to be available there.
Ah, that must have been AL2023, right? IIRC, it's tightly integrated with internal deployment toolchains like Apollo and Brazil (Amazon's internal package management and build systems).
The dreaded "process" to get a single tool registered, working and allowed, is the reason a company is slow, dysfunctional and usually failing at a task.
The security tax and speeding tickets on everything are a luxury destroying much value.