LLVM: Backwards Compatibility versus Proprietary Forks

Saw this the other day:

https://forum.artlessdevices.com/t/llvm-backwards-compatibility-versus-proprietary-forks/276

The original post contains the following:

As an LLVM developer, I’m pretty confident in saying that there isn’t a single one of us who likes maintaining private branches, and if we had our way with things we would do everything in the public tree.

The reason is that LLVM’s development practices create a strong disincentive for keeping any code private because LLVM’s C++ API’s (which is where 99.999% of development happens) has no backwards compatibility and changes very rapidly, which means that anything that isn’t upstreamed bitrots. We’ve heard tales of it taking months to merge the changes in a single release, or straight up abandoning private branches.

We don’t do everything in public purely because of internal constraints of the companies that we work for and those won’t go away without significant societal changes (i.e., the necessary changes vastly transcend the developers’ own attitudes on the issue: we’re talking changes at the levels of entire business models).

Now, you may say that “that’s the wrong reason” to be pushing things upstream (i.e. it’s pragmatic, not dogmatic), and I won’t argue with that: it is pragmatic. Nonetheless, it is very effective in minimizing the deviation of the derived proprietary programs from the fully-free equivalent that you can build on your own from the public repository[*]. Realistically, this means that it maximizes the competitiveness of free programs with their proprietary counterparts[**]. I think is a win for free software.

An long discussion follows …