Re: [LAD] NSM fork

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, January 29, 2021 11:44 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote: I'm glad that I'm not the only one. I think there are two aspects, one ethical and one practical. The way they try to take over the NSM landscape, with their deceiving use of language and the (mis)use of their community roles, doesn't show any signs of respect to the one who actually designed this thing. Nor to it's community who worked hard to create this unique linuxaudio session management landscape. Not being humble, because you realize you just copied the thing, but didn't design it. Then there is the practical side, where it is obvious that it's not good that two teams work on the same session management landscape and on the same API, cause they took the freedom to change the API without discourse too. Personally I did my best to avoid it. I thought I was working with the Agordejo developer on a situation where he could work out his new GUI for NSM and having nsmd, with one or two extra patches maybe in a dedicated repository, not part of Non-Daw and without the NTK dependency. It was even the NON developer who suggested something like this. But in meantime, a small group of 'wise man', including the same Agordejo developer, orchestrated by the man with the many roles in this community (but who now strangely denies his undeniable role in this fork), where working on a huge take-over apparently... They dream big, unrealistically. They thought NSM patches would fall from the sky, with their fork. It proofs to be very hard already to create a modular environment with stable JACK tools, working together with one session API. Finally we have that one session API, but still, lot's of JACK applications are not stable or don't have a NSM patch. In other words, we don't need a revolution, we don't need big dreams, we need small fixes and especially we need to cherish this unique session landscape, with one session API. It's better to accept small annoyances, then to try to fix them with huge plans, cause you're only creating problems that are far larger then the small annoyances. A screwed session landscape. The last thing is under pressure obviously, with this fork. You see they're already changing the API and it's pretty likely they think they will need a big API change sooner or later and they won't hesitate to do it, that is what their way of forking tells us. They will find that excuse. It's a sad situation indeed.