Split off part of JUCE and make it MIT Licensed?

[TheVinn]

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.

[jrlanglois]

Gut feeling told me that this is what you were going to post!

I vouch for the idea; it gives flexibility of publicly pooling custom widgets.

The only issue I have is that this may break consistency. Should we use Jules' Coding Standard, and approaches? I would prefer that. But who would be policing such things?

[jrlanglois]

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.

[TheVinn]

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.

It could just be a new sub-forum. Jules would receive as little or as much noise as he wanted to hear.

[jrlanglois]

It could just be a new sub-forum. Jules would receive as little or as much noise as he wanted to hear.

Fair enough!

[TheVinn]

The only issue I have is that this may break consistency. Should we use Jules' Coding Standard, and approaches? I would prefer that. But who would be policing such things?

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.

[jrlanglois]

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.

That is rather true... not just anybody can take the time to do this, and even if they had time outside of building their own applications - doesn't mean they want to spend it programming after all!

After giving this idea some time to sit in the forums and not seeing any other posts - I have a feeling there's little interest, TheVinn...

[TheVinn]

After giving this idea some time to sit in the forums and not seeing any other posts - I have a feeling there's little interest, TheVinn...

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.

[TheVinn]

Should we use Jules' Coding Standard, and approaches? I would prefer that. But who would be policing such things?

I'd say that people who have published their own external modules that use JUCE would be the ideal candidates for regulating third party development.