If we were anti-interoperability, why would we spend the majority of our technical resources working on interoperability?
We generally have 5-7 interoperability projects in flight at a time, not counting Roon Ready + Roon Tested certifications (which are also interoperability!). We released interoperability with three new families of audio products last year (Sonos, Devialet, KEF). We just totally re-built our volume controls to make them interoperate better with the hardware products that our users have. We are currently working on interoperability with two home automation systems, MQA files, and another family of audio devices that we are not ready to announce yet.
In the library management area, we made two serious iterations to the product last year that improved our interoperability with file tags and file-based organization. We added support for over a dozen new file tags, for controlling work/part structure via files, and for pulling liner notes + PDFs from folders. Then, we through our export feature to make sure that as much data as possible was being exported back into file tags at export time.
I think the problem is–you are defining interoperability selectively. The wider view is: we are working on interoperability constantly, but not prioritizing the things that are personally important to you.
This one folder browsing feature is a sticking point for you–as are a couple of library management topics, and I understand that. You made a list of a few things in another thread…let me address a few.
- folder view - This is against the philosophical purpose of the product and the presence of this feature creates rigidity that will be harmful as we evolve the product. Our decision making about this has nothing to do with interoperability.
- capability to search and sort by custom embedded metadata - We have no fundamental problem with this, but we do not totally understand the use case where it’s required and no other solution would do. I had a conversation with an alpha tester a while back asking for this, and it turned out that what he really needed was support for performance location and a couple of other fields, so instead of building a generic escape hatch and guaranteeing him grooming work for the rest of his life, we enhanced support for performance location (and related stuff like dates) and made sure that we could gather that information from file tags, integrate the same from our metadata sources, sort by it properly, etc etc. In other words–we addressed his real need instead of the literal feature request that let him do it the way he used to in the last software he used.
- compatibility with/ability to import track ratings - Track ratings are simply a feature we choose not to have. This is a user experience choice, not in the interoperability domain. If we had support for track ratings in the product + failed to import them, you’d have an argument that we were failing to interoperate. Nonetheless, we tried prototyping a solution to this last year (converting track ratings into tags like ★★★, ★★★★★), and found some issues in the user experience that caused us to pull the feature back.
- importing user tags - This is something that we would like to address. We also prototyped support for this last year, but ran into a set of experience issues that caused us to pull it back (same as the track ratings). We will likely re-consider both next time we do an iteration on the tags feature.
In general, with library management we are not over-eager to do stuff quickly/badly and make mistakes. It is nearly impossible to go back on these kinds of decisions (and in many cases ,they severely impact our possibilities for future architecture shifts–mobile products, cloud access to content, etc–these products would be substantially easier to build if we did less complex stuff in the library management sphere).
Our approach to library management involves re-thinking the ways things have been done in the past. That means that our stuff will sometimes work differently, or not translate 100% 1-1. It’s pretty obvious that there are some serious benefits to that approach, and also some tradeoffs. We try to minimize the tradeoffs, but sometimes it is better to push forwards.