Browser Engines 2015: Commit Rates and Active Developer Counts | Hacker News Reader

Browser Engines 2015: Commit Rates and Active Developer Counts

mo.github.io

112 pointsmolsson23 comments

One thing to note is that the Chromium and Mozilla repos host browsers as well as engines, whereas the WebKit and Servo repos host engines only. (The most prominent browser front-end projects are Safari, desktop and mobile, and browser.html respectively, which are hosted in separate repositories.)

Also Chromium and mozilla-central are monorepos, servo/servo is only part of all the Servo code. There are a bunch of other repos under servo/. We also rely on some major Rust libraries like hyper, but those could be excluded.

This probably doesn't affect the author and commit stats for mozilla-central all that much. The various upstream libraries we use are updated infrequently, in single commits.

I'm not talking about upstream libraries (we have those too, like hyper).

The libraries under github.com/servo are just Servo components (some of them are used by other people, though) which are in different repos. These are maintained by the Servo team and in many cases Servo-specific, for example our HTML parser, CSS parser, URL library, and our layers/geometry logic. Also, eventually, most of our rendering logic.

Wow, I did not expect that Servo would be comparable to Webkit in number of unique authors per month, as young as it is. I know the Servo devs put a great deal of effort into outreach and making it easy for new contributors to jump in, and that appears to have paid off. :)

EDIT: Actually, now I'm curious about the methodology of how the numbers are collected. I know that Servo is designed to consistent of independent components contained in separate repositories whereas IIRC mozilla-central is fairly monolithic, so if you look only at the repo at https://github.com/servo/servo you may be underestimating the the activity on the project.

800 developers on Chromium seems like an insane number! What are the biggest projects they're working on?

I agree that seems like too many people working on it. I think brooks law would start to dominate.

Just look at the number of libraries (even project specific ones) Chromium pulls in. The projects are huge enough to accommodate quite a few people.

Presumably the number isn't counting the individual commits for the ~175 dependencies that make up src/third_party/ (including large ones like Skia and BoringSSL).

80M dollars a year and you get to control the future of the internet. It seems like it would be worth paying this if you were a large corporate or goverment, especially Google with its need to control the default search engine. Especially considering they were paying 300M a year for Mozilla to have google as the default.

I think you're understating the developer cost. Google pays pretty well and there's quite a bit of overhead (management, HR, IT, etc) as the original graph only counted pure developers.

Still yes, I agree that a few hundred million a year gets you control of the Internet.

Chrome sends every URL you type in the search/URL bar to Google. (With the pretext that they need to check if it ia search term.)

With Chrome they can build a profile on each user which includes how much time they spend on every site they go to. They can sell and use all this profile data in all sorts of ways.

They can fine tune search results to push more sticky sites, since they can aggregate which sites really keep their users.

And it means that they can verify that their other tracking cookies and methods are accurate, and can better weed out all sorts of shtick, and pick up the trends before they are bitten.

Controlling the internet (by controlling the interface used to reach it) is just the small change.

It'd be interesting to see similar stats for less well-known browsers like NetSurf and Dillo, which are also far simpler. I doubt they have anywhere near as many developers as the big ones, but as the saying goes, "quantity is not quality"...

Thank you to the author for making the colours easily distinguishable for people with colour vision deficiencies in most of the graphs. Graphs like these tend to be spectacularly bad at this, putting aesthetics over accessibility.

Why is pre-fork WebKit shown under the colour for Blink? Blink didn't exist in 2001.

There is one line/series for the blink _repo_ which also contains all of the webkit history. The line for webkit also contains an identical webkit history for the pre-fork period and by chance blink was rendered on top which is kind of unfortunate indeed. In the interactive version you can click the checkbox in the legend to hide a particular series and then it becomes easier to see why it looks the way it does.

Ahh, I see. Thanks for responding.

I find it interesting that, in the third graph (commits/dev), the Mozilla line gets a dip to about half its previous value as the Chromium line shows up, somewhere around mid-2008. Post-dip the jitter also seems to decrease.

Google used to pay/employ a number of people working at Mozilla who were then pulled to work on Chrome. This includes former Firefox lead developer Ben Goodger, for instance. I think Mozilla was still using CVS at that time, so the loss of a few central devs doing lots of commits for others would explain the drop.

Wouldn't that increase the commits/dev metric, if there are fewer (highly active) devs, but a reasonably similar amount of commits? Having it drop would actually mean that the Google folks had a higher-than-average number of commits of their own code (as opposed to committing for other people). Unless, of course, they were committing for folks that also worked on Mozilla without their own commit access, and that second group went away.

What is Intel contributing to Chromium? That was a surprise.

It might be related to Crosswalk[1], their mobile webview implementation.

[1]: https://crosswalk-project.org/

Intel contributed support for hardware accelerated VP8 encoding to Firefox. Given that its mostly used for WebRTC I could imagine they did the same for Chrome.

Reply on news.ycombinator.com