JUCE Announces Acquisition by PACE

The JUCE team, and Raw Material Software Limited, will remain in the UK.

You can see the details of RMSL in Companies House. Allen, Andrew and myself are directors.

5 Likes

As a side note, UVI has been working with Pace for more than 15 years and they are clearly trustworthy people and are not only “commercial” guys. I honestly don’t mind them to take control of Juce and I think it’s for the best. (UVI is a Juce users since 2008 FWIW)

There probably won’t be any fancy NAMM Juce presentation anymore but honestly I prefer this kind of money to be spent in the development aspect :slight_smile:

7 Likes

I have no good feelings about this. But the sun is shining right now, so I will go out.

1 Like

While I still have a bit negative initial reaction to this, I can see the point that things could have ended up even worse for JUCE.

PACE will have to be careful to not raise concerns for developers and end users who don’t want anything to do with the original PACE technologies like iLok.

I do understand there are developers and even end users who may even like PACE/iLok, but it would be a mistake to assume that is the case all over the board.

9 Likes

Brace yourselves prices are going to go up :cold_face:

1 Like

IIuc we we’ve seen so far is the opposite?

1 Like

IIuc we we’ve seen so far is the opposite?

$40 > $35
$130 > $65

How is that the opposite of prices going up?

1 Like

Ok maybe you have a point, but note that the tiers themselves have changed. What I took from the post I linked to was

Congrats to the crew! Hopefully this will help increase bandwidth in the near future and churn out more crazy stuff.

4 Likes

If you happen to be between 200k and 500k funding per year, the price went down from 65 to 40 p.a.
But obviously it is a mixed calculation for everybody individually…

3 Likes

How does this change in ownership affect Traction_engine? Now they have different owners.

Tracktion Corp has always been a separate company from JUCE/ROLI, and nothing has changed with the change of ownership of JUCE.

2 Likes

cough cough

This is all I’m asking to be added:

int getCurrentPopupIndex() const { return currentPopupIndex; }
4 Likes

There’s a different issue regarding accepting PRs that relates to ownership.
I’m fuzzy on the details but I think that whoever writes the original pull request by default maintains ownership of those lines of code.
This complicates accepting PRs because now you have different bits of code technically owned by different people and then you’re distributing all the code together under the GPL or selling it as a commercial licence.

To clean this up contributors usually sign a “contributor licence agreement” or “CLA”. For example, Facebook has a form you have to agree to before they’ll accept PRs from you.

GitHub has some text you can can customise when a PR is opened but I’m not sure if this is enough to be an “implicitly accepted CLA”.

Can anyone who has more knowledge on the subject clarify these points or correct me where appropriate?

3 Likes

This isn’t really the thread to be promoting your PRs, but it’s useful as I think it helps to prove my point. On the face of it that looks like a simple one-liner that we should just add to the library, but from the perspective of the library designers this is a bad idea. If we start exposing the guts of classes like MenuBarModel which are used in a lot of people’s code, then users start depending on that code and we can’t refactor the internals of the class in the future. So a simple one-line change becomes a much more complicated process of trying to figure out if there is a better, cleaner way to do what you want which doesn’t change the public API of the class, or does so in a future-proof way.

11 Likes

@ed95 - why can this kind of response not be made in the PR? (and then close it)
It would then also serve as a message to other potential contributors browsing PRs.

I think the more responses about style and appropriateness contributors receive the more likely future PRs will be to adhere to style and be more appropriate for inclusion in the library.

12 Likes

does this mean that in the near future i will need an iLok to run my juce code? :smile:

1 Like

Yeah, I think this might be the most important point. I experienced both: Raising a pull request and not getting any official response for some weeks and then suddenly seeing my feature request appear in JUCE 6 as a reaction to that and a different PR with no response for some months now.

I would never expect that a PR will make it straight into the official JUCE codebase, I would interpret it as some proof-of-concept, “works this way for me” sort of proposal that might maybe contain a few pointers towards whatever could be relevant in that context.

Now if there would be some kind of response like

  • “Sensible request” / “We already thought about something like this too” / “We are already working on a solution to this”
  • “We will put it on our backlog but with lower priority”
  • “This one won’t make it into JUCE because of…”

this could greatly help the person raising the PR to keep on working on whatever project he/she is working on. Because I guess no one just makes up PRs if there is no realistic need for the feature in a project someone is working on. Getting feedback on what will likely happen could make the decision easier if this is something to wait for or if a custom solution to that problem should be found.

That being said, what about moving the whole PR policy topic to a different thread – seems like there are too many topics mixed up here?

7 Likes

@ed95
I didn’t get a response to my thread explaining the reason behind this PR either other than “don’t tag us” so…

Y’all say you read every thread, but do you? :eyes: :eyes: :eyes:

related: Pull Request policy thread

2 Likes