Thanks for the response. It confirms what I suspected, but I appreciate the time you spent elaborating (especially given my post’s poor timing with the JUCE 7 release).
It typically takes a new member of the JUCE team 12 months or so of full-time work to get up to speed with good API design practices and writing code that meets our quality expectations.
This is understandable, especially with JUCE’s surface area and history. In a community open source project, it might take someone years before they’d be qualified to make API design decisions.
As someone building their livelihood on JUCE, my motivation is quality as well, with an emphasis on quality of developer experience and end user experience.
To use myself as an example: I spent a week of dev time on TextEditor before I felt it was “quality” enough that I would ship it in a paid product to users. I took the time to investigate, document and provide fixes for those issues. I got no response from the team on forum posts or PRs, so in the absence of information, my assumption is that widget UX is low priority. (Perhaps this isn’t true and it was partly bad timing with JUCE 7?) I walked away debating if the next time I should quietly fix on my fork or if it’s worth spending that extra effort documenting the details and prepping a PR. I’m starting a business and my time is also very valuable.
As you said, every company has their high priority pet topics. They all have JUCE forks with fixes and changes that are important to them. I think this is the biggest potential “feature” of community contributions. We can geek out and improve code quality in ways that a small core team just can’t make time for.
However, when small things like doc improvements don’t get contributed back, the codebase accumulates papercuts — bugs/improvements too small to be deemed worthy of prioritization, but add up to seriously impact dev/user experience. Devs duplicate effort, hunting the forum for issues first encountered years ago, chasing peers down to ask how they worked around things, etc.
Opening the floodgates to strongly opinionated devs pushing for their pet topics sounds like an absolute nightmare — especially given your existing backlog!
However, maybe there are improvements that are slow and safe, done in areas that the core team doesn’t consider high risk. Examples: Docs-only or small fixes only get reviewed. Assessing and responding to PRs could happen quarterly, or only between big releases. The widget library (or some lower priority module) could be broken out into its own repo and 10% of new team member’s time could be babysitting it as a trial. JUCE 7.2 could be “community focused” or a “little details” release. There are ways to limit impact to the JUCE team’s time while taking advantage of community contributions that would improve the developer experience and raise the quality of the framework itself.
Anyway, that’s my full pitch. Thanks for taking the time to read. It took me 2 years to feel “integrated” enough to clearly state these opinions, but this was the primary concern of mine when selecting and onboarding JUCE, and still on my mind re: “marrying” my business/future to JUCE (to be clear, the concern isn’t directly about the ability to contribute, but the quality of lower prioritized parts of the framework given its large surface area and small team). I understand and respect the JUCE’s team current position, and understand that it’s historically consistent. I wanted to explicitly bring it up in detail before I go heads down on shipping products enabled by this fantastic framework. I’m willing to make time available in the future to help with any effort in these directions, but consider my expectations set. Thanks Tom!