Well, for what it's worth, according to the articles it amounted to billions of dollars. It was supposed to be used to police the area for deforestation, fires and other things.
As a Brazilian I disagree that other countries should be paying us anything, we should sort those problems by ourselves.
However I think there's a huge incentive problem here: The people who stand to gain from foreign money coming to "save Amazon" (Brazil's general population) is not the same people who stand to gain from its destruction (businesspeople).
Second, a large chunk of the current government ideologically believe there's nothing wrong with deforestation, or deny it, or deny climate change. Hell, some of them are flat-earthers.
It is common in the Brazilian right to associate environmental causes (include climate change) with leftists, and the current Brazilian government treats the left (any kind of left) as the worst possible enemies. So a sure-fire way of not being heard by the right is... talking about environmental causes/climate change.
So, in the end it should really be an astonishing amount to make sense for the current government to change its course.
I used to work with WebForms and Cocoa (before iPhone) back when enterprise was completely allergic to web. Not only those tools were faster, but the development process itself was quicker and less traumatic than it is today. Interfaces were crude, but snappier. All grey, and users preferred using the return key to move between fields. And we could knock a calculator app in a few hours.
The landscape was much more diverse too, a lot of women, and older folks (40/50+) coming from Fox Pro, Clipper or even COBOL (mostly on WebForms). I don't know what happened to those people when everyone moved to web tech. A lot of people my age moved to backend because they find HTML/CSS/JS too hard. Cocoa guys moved to iOS. I'm on frontend + iOS now.
For the enterprise shops around here I know it all went to hell when both business AND developers started pushing modern multi-platform development: Qt, Java, Adobe, Cordova, you name it. Suddenly apps became crappier and a lot of people got pushed away from development because it was becoming too hard for them. After that everything became browser based. Mobile was weird for a while (too much Cordova), but it later settled on React Native.
I know WebForms (and Interface Builder!) might look primitive and limited to today's developers, and I might be looking trough rose-colored glasses, but I remember when it was enough to build 90% of the apps people need, you don't need John Carmack or dealing with the audio buffer directly. Since this tech still exists, I can't see why that's not the case anymore :/
Reducing the amount of code shouldn't be the end goal, but a way of increasing quality.
You should seek to demonstrate instead that you're making software that is more malleable, has less bugs, is easier for new hires to understand, is easy to add new features, etc.
Of course it is not an end goal. But a quarter as much code has (in general, everything else equal) a quarter as much bugs, a quarter of the amount of code to read and understand for new hires a quarter as much code to take into account when adding new features. But none of these things are easy to measure or demonstrate. It is just easier to see that Ma8ee took 1.5x weeks to write 10,000 loc while other developer wrote 40,000 loc in x weeks.
Industry this days is more about headcount than quality itself. Why hire two good engineers when you can have three mediocre ones for the same price?
On simplicity, common wisdom these days dictate that we should use bloated kitchen-sink backend MVC frameworks that generate dozens of directories after `init`, because supposedly nobody knows how to use routers. Frontend compiler pipelines are orders of magnitude more complex than the reactive frameworks themselves, because IE11. And even deployment now requires a different team or expensive paid services from the get go. We're definitely not seeking simplicity.
The second point is also something that most developers and managers would balk at: "To build good software, you need to first build bad software, then actively seek out problems to improve on your solution". Very similar to the Fred Brooks "throw one away" advice that no one ever followed.
https://news.ycombinator.com/item?id=20769327