LLVM: Backwards Compatibility versus Proprietary Forks

Interesting comment from an LLVM developer discussing recent RMS statements on GCC:

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.

2 Likes

Rumors of this take are greatly exaggerated

It’s certainly true that engineers like open source and there is some disincentive to out-of-tree patches. On the other hand everybody has a staging tree (Rust, Swift) because in-tree patches also have disincentives. Now these aren’t ‘private branches’ in the sense the commentor wants to talk about but they exist without any ‘distortions from the business side’ if you like, and they’re on a spectrum with upstream LLVM on one end and the dark forks on the other.

Points further along that spectrum exist and have real consequences, Exhibit A, Exhibit B.

I might suggest the reason LLVM moves quickly, is because companies are more willing to invest in it as they (correctly or incorrectly) believe they can have more secret sauce than a project like GCC. To the extent they’re incorrect it creates these stories about how merging is hard etc. but you don’t hear much about the dark forks that turned out ok.

As always, Cui Bono:

Software engineers play both the role of rationalizing technical expert and that of hands-on craftsperson wielding particular knowledge of the work medium (code).

The Present and Future of Engineers By Nick Chavez

1 Like