Thanks, that's a pretty comprehensive list. Apologies for the length of my reply but I want to address your points.
I don't think we can use MIDI as a model here. MIDI is a standard rather than a piece of software, and it is really a standard for hardware manufacturers. We sample library devs don't always obey the standard - partly because of its limitations which we are not able to change - there is no collective control for us.
SFZ would be comparable to MIDI as it's also a standard, and Sfizz is a player that uses that standard. It's also open source so anyone can contribute to it.
Assurance that the technology is controlled, and road mapped by a mutual consortium of members rather than a small group of "owners" controlling the future of the system.
All software is controlled by a group of owners. Even open source projects, because someone has to write the code and someone has to own the copyright. There is no way for it to be ownerless.
The only way to make sure all developers and future developers will have control over the source code is to make it open source, and copyleft. If it isn't copyleft (like GPL) then any developer can take the code and make a closed source version at some point, locking out everyone else from the control that you desire. This of course has the knock on effect that derived products must also be copyleft - I'm okay with that of course but no-one else here is, sample developers believe they have precious secrets that will ruin them if anyone else knows.
The benefit of using a system with adequate funding for best of class quality control instead of using dozens of sample players in various stages of (in-)stability.
Potentially best of class technology developed from pooling financial resources for development, better and larger code teams etc, than what would be sustainable by individual developer's financial means or be achieved by a single or very small pool of developers.
Adequate funding does not equal best of class quality control. Do you think EastWest/Spitfire/OT/Cinesamples don't have adequate funding? There are enough threads here complaining about their lack of QC.
Regarding funding in general: This foundation/consortium is to be made up of sample library developers, pooling resources to create a sample player. Who is actually writing the code and is their only incentive the money from the sample library developers? If so, then we're back to the situation where the sample library developer with the most money will have the most control.
HISE already surpasses Kontakt in almost every way, and it is primarily the work of 1 developer (standing on JUCE's shoulders of course). Incirios is another JUCE derived player that is developed by a single developer, as is Decent sampler.
A larger code team does not produce better code. Sometimes it does, but usually too many chefs is not a benefit. Reaper is one of the most efficient pieces of audio software and it only has 2 devs.
Potential technology contributions/donations by members.
I'm not 100% sure what you mean here. But again with HISE and Sfizz anyone can add anything they want. If you have an idea and you know how to implement it in C++ then you can add it.
Potential availability of grants not available to commercial developers or commercially licensed open-source projects.
Do you know of any such grants? I have a project that would benefit!
Edit: Ha, I just saw Lindon is after the grants too. Okay you can have the first one.
The only real use I can see for grants is if a developer (or multiple) wanted a specific feature adding, they could hire someone who is already familiar with that feature. But for general development a burst of money isn't going to be able to add anything. You can't hire someone full time on a grant, and you can't bring in an outside programmer and train them on your codebase and the needs of the users to add a feature or fix a bug for as long as the grant funding lasts.
No surprises when the controlling owner of the IP changes licensing structure and fees, development priorities or sells the IP/copyright to a third-party commercial interest.
Again a copyleft license is the only guarantee of this. It doesn't matter if the copyright is owned by an individual or a collective/foundation, if it isn't copyleft there is no way to prevent it being closed source in the future.
Lower risk for sample developers flowing from potentially lower financial expenditure as compared to developing an in-house proprietary sample player but with the benefit of still helping shape the system at the meta-data level.
All this I agree with. It is a crazy expense of time and money to reinvent the wheel. But software companies do this all the time.
+More control over library encoding.
Encoding is really a Kontakt thing. If you look at an SFZ instrument for example they are just text files and wav files. For most other formats encoding = compiling, and that's just a normal part of writing software.
A fair distribution channel.
I assume "fair" here is in contrast to what Mike Greene was describing the situation is with Kontakt? I don't see how you can get fairer than each developer can do what he wants independently of other developers, which outside of Kontakt's ad thing is pretty much the situation we have.
independence from commercial or quasi-commercial, or commercially licensed open source subsystem dependencies such as JUCE over which there is no control.
JUCE is free software, copyleft. There is total control over it for any developer. A copyleft license places only a single restriction on developers (not users). The restriction is that any freedoms they have been given, they must also give to future developers and users. Without this one restriction any developer can take the source code and withhold it from everyone further down the line. The copyright holder is always able to change the license for future versions, but versions already released are fixed.
The copyright holder can also dual license. For example if a sample library developer says to JUCE, "hey I want to use your code but I don't want to share anything I've done with anyone else", JUCE can say, okay but you have to pay me for that. This is how the collective of JUCE developers is funded. HISE uses a similar model.
When we're talking about selling sample libraries, commercial isn't a dirty word.
Management by the best industry leaders in management and technology visionaries appointed by and reporting to a board of contributing members.
Sounds like a perfect way to reward your friends
Who decides that someone is a visionary?
Development by a world class team of programmers. Pooled resources will make this possible.
A lot of programmers aren't motivated primary by money, they write code because it's what they enjoy doing. To use Reaper as an example, Justin is a fantastic programmer, and also incredibly wealthy, he doesn't write Reaper because he needs the money. You couldn't hire Justin to write your sampler even if money was no object (well you can ask him).
I've skipped some of your points because my answer would be "HISE already does this" for most of them. Your ideas are nice and idyllic but to me seem either impractical or unnecessary. The foundation you've described doesn't offer any advantages over what we already have and introduces some new concerns.
It seems what you want is HISE but without any individual holding the copyright. How transferring the copyright to an organization is better I still don't fully understand. Usually a foundation is primarily created for financial support, but in the case of something like HISE that isn't needed because it already has a financial model.
This works because HISE is a developer product, if it was for end users then a foundation would make more sense, because users don't have the same incentive to invest in HISE that a developer does. This is why things software like Firefox benefit from a foundation to generate income, because users are not going to fund the browser's development.
