AOSP and Chromium are actual open source projects with actual open source contributions. Chromium is almost entirely developed in the open other than security fixes. AOSP is partly developed in the open and partly behind closed doors with code dumps (merges into AOSP) for those.
Conversation
It doesn't matter where LLVM was started. Android wasn't started at Google. Google acquired it. Apple essentially acquired LLVM.
I'm really not sure how can you can claim that WebKit is a more collaborative project than Chromium. It's entirely not based on the actual reality.
1
because I contribute to webkit, and I'm well aware of how it is to contribute to chromium as well
1
result: those several KLOC of patches that I have to maintain downstream (rejected by google on the grounds "this is not important enough for us")
1
The same thing happens with the Linux kernel and most other open source projects. That's quite normal. Once you're an established contributor, you start having the influence to land things that the people responsible for the upstream project don't need themselves.
2
fwiw, in case of the ppc64le patches, not even a push from IBM helped; the patches have been lingering around for years now, with no issues with their quality
1
I've never seen any contribution in webkit where this would happen, you don't even need to go through a complicated CLA process and patches from individuals go in on regular basis (regardless of how much it matters to apple)
1
There's no complicated CLA for AOSP or Chromium, and no copyright assignment to contribute. I've regularly landed patches in AOSP. It has been drastically easier to get my patches reviewed and landed there than in the Linux kernel where I'd be unlikely to try contributing again.
3
1
e.g. one such example chromium-review.googlesource.com/c/chromium/src
the reasoning presented there is nothing more than an excuse (most of the existing conditionals are reused, and it adds no work for them, especially since they don't have to care if they break it)
2
i find relying on codebases like this rather shortsighted; right now, your requirements may align with theirs, but what happens once they don't? maintaining a fork on codebases like this is pretty much impossible for a small team
1
Our requirements align much better with theirs than the Linux kernel and most other open source projects. If we didn't use projects because they didn't entirely align with our goals then we couldn't do anything. What are we supposed to use then?
it's your own project, you can do whatever you want
but it seems like we've got a fundamental disagreement on some things there, and those things happen to be important to me, so let's leave it at that