Delivering faster was never the promise of Agile. It also can't turn a shit team into an agile team. But it certainly empowers a solid team to deliver what business needs while moving faster.
Agile (capital A) processes have always been trying to sell the idea that a mediocre team can be elevated if they have the right process to guide them. Whether that actually works when the team isn't good enough to self-organise anyway is debatable but that's the sales pitch.
The word "good" here is very vague :-) People can be well-intentioned ("good"), but disorganized, unskilled, or wishful-thinking. People can be strong programmers ("good"), but work by themselves, without coordinating with others. People can be good, yet have managers micromanaging them. People can be good, yet required to work on different projects at once, which breaks focus. People can be good, yet separated from the customers of stakeholders by a layer of managers. People can be good, but required to analyze and estimate the project before even starting working on it, and then be held accountable for their estimate when they run over time. And so on, and so forth.
Pretty sure having motivated people who find the work kinda fun destroys agile/any other methodology. When people wake up excited to pull down tickets or just get shit done, you're doing business right.
What open-source projects in particular do you have in mind? And what do they run on, exactly? And what would this model look like if transplanted into a business setting?
I can see some aspects of agile project management in open-source projects. One, transparency/visibility. Two, working software over documentation. Three, customer feedback. In fact, some large open-source projects have introduced channels for early interactions with customers (i.e. developers) — for example, the RFCs initiatives of React or Lit, or community engagement in various html or css work groups.
I do not know how well developers on open-source projects coordinate/communicate between each other. Or how work gets prioritised. I've certainly seen a fair number of failures in that aspect of open-source projects.
Everything else seems incidental
Re: that fun thing, yes, but most projects aren't fun on a daily basis.
In any case, what I originally meant was that agile is not perfect, but if you've seen startups who don't know any development workflow (ie neither agile nor cascade), software dev grinds to a halt really quickly as they try to reinvent an entire field of management.
Treat it like a normal job. Often no "management" is needed. Get done what you can, talk to you tomorrow.