There are always feature requests for various features and improvements to widgets which Jules understandably will never have time to fully address given the size and scope that JUCE has grown to.
How about taking a bunch of these Component objects (TabbedButtonBar and TabbedComponent immediately come to mind), moving them into their own separate module, and publishing them separately under a dual MIT / GPL license? There could be significant benefit: these objects would be developed in parallel by users. JUCE could still be sold under the commercial license. It would be optional whether or not Jules wants to pull some subset of the contributed changes back into JUCE.
This wouldn’t affect sales of the commercial JUCE license since its only a subset, you would still need to purchase a license in order to ship a proprietary application. And, since this separate module would be MIT licensed, JUCE licensees could use it in their proprietary software.
Thinking about it more; where would this module be set, and where would issues and suggestions related to it be set? In this forum - essentially giving Jules “forum-noise”? That doesn’t seem fair to him.
Of course the existing coding standards should be followed. You ask, who would police such things? I imagine there would be a handful of developers with write access to the Github repository (a new one to hold this module). Pull requests would be inspected and commented on using the existing Github mechanisms for doing such code reviews (have you tried it?).
If Jules wanted to get involve he could look at the code associated with a pull request and give it either a thumbs up (follows the style) or a thumbs down (i.e. "that’s not how I would do it) with the option of providing additional comments. Although Jules’ involvement is not required, a separate branch could be maintained containing only “green lighted” changes. This branch would be eligible for merging back into JUCE.
I expect that the developers who care the most about a particular Component would be the ones handling the bulk of the pull request inspection and merging (since they use it the most).
If anything, the possibility of a module of forked widgets I believe could open up a lot of conversation about what improvements should be made. A refactoring step of existing widgets to support improved features through new subclasses would be helpful in and of itself, this refactoring would be an ideal candidate for backporting to JUCE (so that the mainline JUCE distribution keeps its set of “stock” controls while still having an expandable interface).
On the other hand, as Jules mentioned in one of my other threads about my community driven project, people are busy with their own applications and there may not be enough support for maintaining such a project.
Yep, I sort of knew that before I posted but I figured I would toss this idea out there. The topic of community development is going to come up more often as the size of the JUCE user base outgrows Jules’ ability to single-handedly provide new features.