Deprecated externals

It is impossible for any developer company to keep

trace of all 3rd party contributed extensions, plugins and such over the years,

and to wait till all are up to date to go on with own development.

Most don't even try to keep own product compatible with previous versions,

think of appe and logic, finalcut etc not working after MacOS updates ?

Or mail does not recognise accounts ?

In case of max, it also often turns out that users forget or don't know how

to find updates to max externals packages.

Or don't want to keep older max versions installed.

I didn't say "all 3rd party contributed extensions, plugins and such", I said "important packages". A quick google tells me this happens all the time in every branch of software and why wouldn't it?
It's like when Ableton acquired Cycling 74 to make sure m4l was properly supported. When third party content gets relevant enough it makes sense to make sure that content works.

What is important to you might be totally irrelevant for me.

I don't understand what exactly you're asking for.

Someone invents a Max external, which is software that is tied to a specific environment. Now Cycling'74 should programme around this external because someone says that it is important? And if you do something else next year and the external is no longer important to you, does Cycling'74 also lose interest in it or do you tell them that and they no longer care about this external?

Or should it be a criterion that IRCAM is so good and important that any external or plugin of theirs has to run in Max at all times, no matter which IRCAM researcher or student or seminar participant nailed it together?

I'm afraid that whichever way we look at it, this can only work in special cases and then it's fine. In general, however, developers who programme platform-dependent software must be guided by this platform and consider how serious, reliable or ingenious they present themselves to their users.

But if the platform continues to develop and the external-developer doesn't react, or vice versa, the developer does something better and the platform doesn't keep up, the system has failed. One of the two is not working optimally. I wouldn't dare to predict who is the good guy and who is the bad guy.

We are not dealing with a master-servant system, but with different people who want to realise their ideas.

I probably put to much of my own experience into the original post but my question was just this: "What exactly is cycling 74’s stance on the backing and support for external developers?".
I don't expect Cycling 74 to back all MY favorite packages or just blindly throw money at Ircam or whatever. I do however think c74 should keep an eye out for tech that THEY find interesting and relevant and maybe do something to try and preserve those parts of their platform. Maybe they're already doing that, maybe they don't, I don't know, but I think it's a relevant question.
There are undoubtably packages out there that extend max's capabilities enough to grant them the rank of "important", not only for the end users but also just in a marketing sense.

i dont know if you noticed, but cycling always did that. today 80% of the compiled objects which come with the program are former third party externals or are based on them, and in several cases they not only licence or stole 3 lines of code but actually hired the developer as staff member.

regarding the issue to keep third party externals up to date... from what i know there are a few more problems than new cycling APIs for new processor architectures which have to be observed. providing a cycling-made "update from v6 to v9 kit" will not work.

in case you really need life-long support for third party stuff, there is a cure: do not update your copy of max and your computer.
(or even better: do not even use third party externals, gen or java at all if you do not want to update your code every 5 years. i am so happy to have my own paf, llist, lorenz, vbap, granola... so my max4 patches will still work in max9 )

agreed:

in case you really need life-long support for third party stuff, there is a cure: do not update your copy of max and your computer.
(or even better: do not even use third party externals, gen or java at all if you do not want to update your code every 5 years. i am so happy to have my own paf, llist, lorenz, vbap, granola... so my max4 patches will still work in max9 )

Cycling74 is like any other company that was born in the Silicon Valley area: it gained most of its early success from the exploitation of free and contractual labor. You must follow your own style of protection against the deprecation of your life.

so i do - about 10% of my abstractions are more or less copied from somewhere else.

"give a little, take a little", like goodiepal once put it when i remixed one of his apps... which later turned into the GUI-set of 110.modular... written on a 25 years old demo version...

i remember el.samm~ was a '3rd party external' of eric lyon's which became so popular, they included it eventually as a standard object in Max/MSP. and although, i wish i could say this shows how sometimes they can incorporate 3rd party externals into standard Max, now when i try it, i notice it's been removed again... and even searches on the web are informed by something that seems out of date, hahahaha:

ok, fair enough, i'm clueless: what happened to samm~?

i'm not asking because i need it, it's fine if it's been removed, but this is the first time, i was aware of an object that went from 3rd party to standard-include, and then somehow, back out of the standard included objects again?

so... does that mean we have to consider many other standard-included objects might be removed at some point if we don't remain vigilant about their existence?
(is DOGE involved in the deprecation of Max objects, too? 😜 )

what am i missing here?