Having it hosted on some kind of revision control system would be very useful and GitHub is the most prominent public place to do that, but otherwise no real reason.
It could be workflow related. The OS team has been around for decades and pivoting to a new RCS for a whole OS is not easy.
Now that I think of it, Google seems to take this approach with a lot of features. I guess that's why everything based on Blink forks or embeds Chromium instead of using bare Blink.
- My understanding is that the Blink fork happened because Google was the primary contributor to WebKit prior to the fork, and Google engineers were spending a significant amount of time trying to make Apple engineers happy. Additionally, there was a lot of code needed to support both Apple's and Google's JavaScript engines and multi-process implementations, which was no longer needed after the fork. WebKit2 and the Chromium multi-process architecture did exist for some time before the fork.
- WebKit2 is a layer on top of WebCore, which is the part Blink forked. So both WebKit and Chrome implement multi-process in another layer on top of the renderer. I'm not familiar with WebKit2, but in Chrome, this is done in the content layer, which provides most of the core rendering code (including the multi-process stuff), but without all the browser-specific features (e.g. autofill, extensions, spell check, etc.). I believe Opera is currently built on top of the Chromium content layer.
Opera is indeed built on the Chromium content API (v. the Chromium Embedded Framework, which provides a stable API but was less power), and that was a design choice made prior to the Blink fork and hence why Opera followed Google to Blink.
Those thoughts prompted me to create https://github.com/epipping/xnu-kernel-sources-x86 (and its cousin https://github.com/epipping/xnu-kernel-sources-ppc). Maybe you find it help (please take a look at the wiki)