I can't help but be skeptical of this, but... damn.

This was something I personally struggled with for a very long time, so much that we ended up abandoning the product we were working on to build a solution:

https://theseus.dev

Basically, Theseus reads your pull request and your codebase, categorizes the kinds of edits that were made, and writes human-readable documentation that describes what changed. Then, it shows the explanation side-by-side with the code, but presented in a way where you can decide what you want to skim and what you want to deeply review.

I don't think engineers should have to choose between wading through thousands of lines of slop and just smashing LGTM on every pull request. The problem is that the tools for code review are built for an age where code was expensive to write. Now that code is cheap, we need to start experimenting with tools that allow us to stay in sync with what's going on, while also not needing to review every single line individually.

What you're actually saying is that network effects are strong. Those network effects are the only reason Wordpress is still so commonly-used.

But, that has very little to do with the work described in the OP. Maybe EmDash will fail to gain sufficient traction to have their own network effects, but in the meantime, doing moderation on plugins in their marketplace is still important work. Automated moderation to prevent abuse and malware is useful, and is orthogonal to the social proof you're talking about.

Thats not what I'm saying at all. I really like a lot about EmDash and would love for a different default CMS to overtake WordPress.

What I am saying is that there are different levels of types trust when it comes to incorporating outside code into your project (in the form of packages/plugins/extensions):

1. Being able to quickly understand what the code does and what effect it will have (screenshots are pretty big here for CMS plugins)

2. Being able to examine the code before installation

3. Seeing feedback from others on the quality of the code and how well it meets the objectives

4 Limiting what the code can do once you install it

Right now the EmDash plugin catalog really only does #4. I don't see any screenshots of the UI of these plugins, there is no link to the repo, there is no indication if a plugin is used by 100 people or no one, and there is no feedback from anyone who has used it.

The bottom line is that there are several layers of trust that outside code has to pass before you even install it and consider what permissions to grant it. Ignoring that makes it very difficult for someone to start trying out different plugins. And it also makes me hesitant to develop a plugin, because it seems like it has very little chance of standing out from all the rest, even if it becomes popular.

I mean, that describes pretty much every trade. It's not difficult to turn a pipe wrench, but a plumber knows where and when to turn it.

When it comes to trades it's also a bit of "most people do not want to do this job because it's unglamorous"

Many people would choose not to be a plumber for various reasons. A shocking number of people seem to deem manual work as beneath them. Many others just prefer to do other work.

I have no problem doing plumbing or building. I've installed floors, ceiling fixtures, drywall, whatever. But I am best at software and would prefer to do that for my career.

Not only are they enabled by default, you can't easily turn them off. I turn the features off, and every time the firmware updates, they miraculously somehow turn back on. I finally gave up and disconnected the TVs from the internet and put an Apple TV on them instead.

And who is buying all that stuff from corporations? Who is actually the one consuming?

We can quibble about edge effects like "induced demand", but by and large, people just love cheap energy, cheap calories, and can shift the moral burden by playing "not my responsibility" games.

From the IPCC report, 2/3rds of all global emissions are directly tied to consumption.

Well, yeah. Corporations aren't just nefarious evil entities, dumping carbon into the atmosphere for no reason. They're doing it to sell goods. The problem is that a lot of the environmental costs for the manufacture and transport of those goods are externalized and go unpaid.

It's difficult to put the blame for that on the consumer, who has no visibility into manufacturing or logistics, and who has vanishingly-small options for not participating. Buying domestic goods is very difficult or impossible, and goods which are manufactured in more environmentally-safe ways are significantly more expensive (because the costs I mentioned earlier weren't externalized).

If a consumer is presented with two options, one that costs $X and has unknown environmental costs, and one that costs $2X and is marketed as being environmentally safe, the majority will choose the first. This is especially true as economic forces continue to squeeze average people.

Consumers absolutely participate in the problem, but the only process by which it could be corrected is regulation, and the only entity capable of that is the government. (Democracy being what it is, you can however place more blame at the feet of voters.)

I think pinning the blame on them is the wrong way to look at it. Its more a very complex system where each actor's behaviour affect the behavior of other actors. So politicians doing more is super important, consumers doing more is important, companies doing more is important. Everyone's collective effort pushes the flywheel in a different direction.

You over-estimate the amount of sway investors have on Stripe. If VCs had the influence you're describing, Stripe would have gone public many years ago.

I worked on developer experience at Stripe for a few years.

What really happened is that Stripe's products used to be simple. If you're only accepting credit cards and only serving the US market, the API surface is extremely simple. Once you start going multinational and accepting different types of payments it gets much more complex.

For example, OXXO gives users a barcode and lets them take it to a physical location and complete the purchase, so instead of a system like Visa which can confirm a transaction in a maximum of O(seconds), you also have to support methods where confirmations take O(days). Building custom API endpoints for each payment method isn't realistic, since there are hundreds worldwide, and merchants want a single integration point that can support anything from credit cards to coupon-based systems like OXXO.

TL;DR -- Stripe's APIs are definitely more complex now, but it's not because of poor design, it's because they simply have to be in order to serve the customers and markets the company is now reaching.