>as opposed to the pulse maintainers who are jerks.

That doesn't seem fair to just throw out without proof. In all the interactions I've seen them in, they've come across alright for the most part.

Sure, here's a good example: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge...

Maintainers unresponsive, talking about making changes but not following up. They strung the guy along for quite a while on this new codec selection mechanism problem. They claim to be in a v14.0 freeze for two months. He updated his code to work on new v14.0 to more unresponsiveness from maintainers about merging. And it goes on from there.

If you've had to use pulseaudio-modules-bt or pali's patched version rather than official pulse, this is why. By comparison, pipewire managed to get it working with little effort because its lead developer is a nice guy and responsive.

I understand both side's perspective here. I've been a contributor just waiting around for my changes to get merged. But I've also been on the other side maintaining a project which is no small feat. There's a lot that goes on that isn't obvious.

Overall a really unfortunate turn of events there. On a personal note I've been watching that space for awhile and was looking forward to Pali's great work on bluetooth.

Alas, stable API doesn't mean the software itself is actually stable and bug-free

Definitely fair; I still encounter bugs. But that was true of pulseaudio as well, and it is true of pipewire to a significantly lesser extent, especially around bluetooth profile switching, interoperability with jackd, etc.

The Pipewire author is the guy who basically made GStreamer good by overhauling its core logic back in the day - he really knows what he is doing. I fully expect that Pipewire will make audio on Linux really good (latency of Jack, consumer audio feature set of Pulseaudio, reliability of GStreamer) when it's done.