Hi everyone, firstly I’d like to say a huge thank you to everyone who responded to the JUCE survey saying they use pluginval either regularly or occasionally. Knowing that people are using these tools is very rewarding.
I wanted to use this opportunity firstly to say sorry that there hasn’t been much development on pluginval recently as I’ve been spread pretty thinly and secondly to see if there was any interest in triggering more development?
In order to fund some development, either by me or trusted contributors, we’d probably need some kind of sponsorship. So firstly I’d like to ask how much people would be willing to GitHub sponsor development.
$2 per month
$5 per month
$10 per month
More than $10 per month
One off $50
One off $100
More than one off $100
I’d like to fund specific feature development (a la Kickstarter)
0voters
Secondly, I have a list of things I’d like to add, so I would be keen to know what people would find useful:
Integration of real-time safety checking (via RTsan or rtcheck)
Improved command-line handling and json config file support
Automatic integration of Asan/Tsan on platforms that allow it
Improved stack trace/crash reporting
More tests/logging
Integration with CTest
Acceptance testing using input files and reference output files
0voters
If you have other things you’d like to see added, let me know in this thread.
If there is significant support, I’ll see if I can work something out.
I just wanted to follow up quickly on this as it seems like pluginval isn’t quite a popular or essential as the JUCE survey led me to believe.
I appreciate everyone who did reply to the above but due to the spread of requests and generally low appetite for sponsoring I’m going to have to put this on the back burner for a bit.
I did consider doing some kind of kick starter type campaign to fund specific features as this seems the most popular option, but that kind of funding isn’t available via GitHub and I’d like to keep things on that platform for ease.
I greatly appreciate that pluginval is free, but I also think it’s a shame that its further development is struggling to find funding. I wonder if there might be potential for some sort of plugin brand sponsorship, where they get to display some sort of special “all our plugins are validated by pluginval“ badge in return for a monthly stipend. I’m sure that at least a few plugin companies would be willing to chip in (I would hope…)
This was something we encouraged developers to do anyway. I originally envisaged pluginval as a kind of standard conformance tool (which is still a goal but we’re definitely not there yet).
In the very first instance I tried to create a database where developers would send their logs to be added to it and then we’d grant a “verified by pluginval” status. But this was a bit intractable to manage so I flipped it and just encouraged manufacturers to put that on their plugin pages.
But yes, a few dollars a month from people making money for plugins felt like it could push pluginval to the next level. But I do understand there are lots of small payments small companies have to make and these are hard times.
it seems like pluginval isn’t quite a popular or essential as the JUCE survey led me to believe.
I believe pluginval is more popular/essential/mainstream than ever. I know newer devs who don’t know a ton about JUCE, but have already used pluginval. From what I see in the wild, it’s a required part of the stack.
I’d chock up any perception of lackluster response to:
The total active community size at any given time is small (low hundreds?). A lot of established companies that rely on pluginval probably aren’t casually trawling the forum. This post only has 300 views.
Unlike other dev framework communities, there’s not a ton of extra money floating around. I’d bet the majority of people first setting up pluginval aren’t (yet?) handling money.
There’s not really a practice / history of people paying for tooling in this community beyond paying for JUCE. So I think there’s some friction there that IMO pluginval could help shake loose (in part because of items 1 and 2).
I experimented with allowing support for pamplejuce/blur/inspector/etc and it was mostly quietly ignored. My takeaway was it’s in part a community size/makeup issue. If we were 10,000 audio devs making a killing, it would be trivial to find 100 sponsors with a post like this. The community is small but that doesn’t mean the projects aren’t well loved / appreciated / used.
That being said, I 100% think that pluginval should open up to sponsorships. I know there are companies out there that would be happy to sponsor today. It seems at least worth turning on GitHub sponsors and posting back here as an experiment. It could gain community traction (wink wink) over time, especially with a bit of effort (writing about it in the readme, the tracktion landing page, etc). And it would be a good precedent for other less essential community projects.
I’ve added several tiers for both monthly and one-time sponsorship but if that doesn’t fit with people’s requirements, let me know and I can adjust them.
I’d love to be able to justify spending more time making this a better tool for more people.
This is a great idea, I wish you all the best with it. I guess though, I would like to be able to sponsor you without involving Github. Maybe also set up a wallet address - there is nothing at all wrong with accepting donations, is there?
EDIT: I think that goes for all the awesome projects out there, @sudara. Anyone publishing great software that helps out other developers’ lives should be able to just put a wallet address in the app for an instant donation.
Can I ask why you want to avoid GitHub? The reasons will probably determine what other options I can offer. FYI, you can sponsor via GitHub with just a card.
Is “wallet” that a specific product or service?
It’s not one I’m familiar with.
We’ve just done a “diamond” sponsorship, and I hope this encourages others to get behind it as well.
We love pluginval and think it provides great value for the community. It’s something many would pay for, and I think it’s awesome that @dave96 provides this for us. We need to support him!
A perk of our sponsorship is that we can have a roadmap feature fully implemented. What feature would you like to see the most? Vote here
Integration of real-time safety checking (via RTsan or rtcheck)
Improved stack trace/crash reporting
Acceptance testing using input files and reference output files
Automatic integration of Asan/Tsan on platforms that allow it
More tests/logging
Integration with CTest
Improved command-line handling and json config file support
0voters
@kerfuffle ‘s vote is “Fixing that annoying issue with boolean parameters ”
If there’s another feature outside of the list, please let us know in a reply and why you think that feature is important.
If you are making plug-ins you should be using it, and you should encourage others to use it too (and sponsor!). Catching a problem before you release a plug-in is much less painful/expensive than discovering it later. If all plug-ins passed all of the pluginval tests the whole plug-in/host development community would save money tracking down and fixing issues.
Thanks @t0m, JUCE and all those who have already sponsored. It really does make a difference and gives me confidence that it’s a worthwhile tool to keep working on.
I’m not sure this is a good idea for a multitude of reasons I’m not sure if the following idea would work here, but I do think of a burger chain where I live. The premise is that for every $x you spend, you get some tokens. Then there are 3 local organisations (like cricket clubs etc) and you can put your token in the bucket you like. So from a high level, the chain has put the price of these donations into their menu, and it’s forcing all customers to donate, but it never feels like it’s your own money.
This kind of thing could work for something like JUCE. Up all memberships by a couple of dollars, give users the choice where to contribute from a list of third party, but essential, projects.
Edited opening line to not sound like I’m being an a-hole
”
