People say this, but it my experience, it simply isn't true. You're at a _slight_ economic disadvantage, and if you anticipate it, and correctly staff and plan for it, it's entirely manageable. The huge win is that in the long run you are massively more productive and you're not held back by framework incompatibilities, version updates, or web standards changing faster than you can keep up.
Many shops don't have the mentality or the expertise to actually do this, partly I feel because this canard as taken as rank truth and no one ever dares to challenge it. Web standards have gotten much better in the past 10 years, they're actually pleasant and useful now.
> we're talking massive differentials in productivity
You have an ability to get something that feels "fully featured" off the ground more quickly. I'd wait for the actual user reviews before I make a decision on the quality of the output.
Apologies for nit-picking, but that's not quite how sum-of-probabilities work. Total probability across 200 tries of 1% chance each, is ~87%:
p=0
for _ in range(200):
p=p+(1-p)*.01
print(p)
0.8660203251420382
1) Best of luck in an audit explaining that there is almost a 14% chance that your project is free of backdoors given reasonable assumptions. I recommend taking a photo of the auditor's expression and reporting back.
2) There are quibbles to be had about the IID assumption here; dependencies tend aren't selected randomly and attackers aren't targeting them randomly.
3) You don't need a for loop for that, you can calculate directly with `1-(0.99*200)`.
The problem is that the people who act on this and minimise dependencies are at a significant economic disadvantage to those who don't. A project with high risk tolerance has to write a fraction of the code and solve a fraction of the problems as someone who carefully writes secure software.
The trade off isn't just "convenience", we're talking massive differentials in productivity that favour insecure models. It is much cheaper to accept that data will leak sooner or later, to the point where we can assume that if something is economically developed that is evidence it can't possibly be secure. That isn't an argument for more security though; if possible it is better to just design systems where leaks don't matter (eg, here in HN it isn't clear why I'd care about a leak - everything is already public except for the IP address in the server log).