>Which is a problem they without doubt did not inherit from the kernel team.
Interesting point, Windows, OS X, iOS etc. get derided for having internal private APIs that they try to prevent external devs from using, and not doing the same thing is now a 'problem' for GNOME and KDE? Isn't the whole point of Linux for developers, freedom to use it as you see fit?
Isn't the whole point of Linux for developers, freedom to use it as you see fit?
I've yet to hear of a philosophy that allows you to both 1) use everything as you see fit, even things marked as "internal" or "private" and 2) give you the right to complain about your software getting broken because you relied on things marked as "internal" or "private".
In other words, you can either restrict yourself to the published APIs and demand compatibility or you can use the guts of the system and have no expectations of stability when the guts change.
How many things can you mark as private in an application GUI toolkit like Gnome or KDE/Qt and make them available to your own applications? Private/public API doesn't really make sense for GUI or sound libraries.
The Linux internal APIs are things that can only be used to construct kernel modules & components - derivative works that make the kernel function differently or support more hardware. Windows/Apple 'internal' APIs enable Apple & Microsoft to create applications with features or performance not available to competitors.
Windows and Apple due it to illegally stifle or at least lazily under-support potential competition with their apps. That is a non-issue in free software. And Windows and Apple are the talking about company-private userland APIs, not kernel-internal APIs.
Interesting point, Windows, OS X, iOS etc. get derided for having internal private APIs that they try to prevent external devs from using, and not doing the same thing is now a 'problem' for GNOME and KDE? Isn't the whole point of Linux for developers, freedom to use it as you see fit?