I see a way out of this mess that might conceivably be acceptable to the developers, the teachers, and the users of Csound.
First, the problems are not specific to Csound. The same issues exist for all cross-platform systems that accept plugins. Such systems include the VST protocol, Node.js, Pure Data, Max/MSP, and others. These systems offer, or have offered, several solutions:
(1) No solution – which is essentially what Victor is advocating, for lack of a better alternative.
(2) A separate source code repository that maintains external plugins and packages for them. This was the pattern for Pure Data for some time (PD-Extended). We have a separate repository for just plugins, but it’s only supposed to contain plugins moved out of the core repository. According to Victor, Csound doesn’t have enough manpower to maintain new plugins in this repository.
(3) An online catalog of plugins that just points users to where they can be obtained in source or binary form.
(4) A package management ecosystem. This is the pattern for Node.js (the package management system is npm) and now for Pure Data (the package management system is built in).
Csound actually has a package management system, namely Risset (https://github.com/csound-plugins/risset). However, a couple of things have prevented Risset from taking off.
The main problem with Risset is that it manages only binaries, but although Csound should support Mac OS, Windows, and Linux, most plugin developers only build for one or two of these operating systems.
A similar problem faced Node.js, and the solution was to create a special build system that is part of npm, the Node package manager.
Doing the same thing for Csound – creating a Csound-specific build system – would, in my opinion, be a serious mistake. However, we definitely need something LIKE this.
What I suggest is that we create templates for Csound plugin projects that will, in fact, build for Mac OS, Windows, and Linux. This can be done with template CMakeLists.txt files along with template GitHub actions that will build the plugin for each operating system and also package and upload the binaries as releases.
I have done something like this in https://github.com/gogins/csound-vst3-opcodes, you can see the results here: https://github.com/gogins/csound-vst3-opcodes/releases.
It should then be a requirement of Risset that plugins hosted by it be built in this way, and the binaries can be obtained directly from the GitHub actions artifacts.
Of course, the devil is in the details. And the details are the external dependencies required to build different plugins. But there should be some way of extending the GitHub actions to account for this.
Anyway, that’s just my 2 cents.