Clearly it’s a rhetorical device, presenting a reasonable speculation that matches the evidence (number of projects, and quality), as part of the natural flow of the writer making their point.
From experience, what happens internally in an organization is quite different from what is visible from the outside. Making up numbers like that is just a terrible insult to the people who work on a lot of useful stuff in Mozilla.
You can question the waste (which is obvious; Mozilla was bloated, and has no evolutionary pressure as long as the money keeps flowing in from Google deals) without it denigrating what’s useful.
You criticised their guess as baseless just to follow up by denying their numbers without sources. Only one of you two chose to present a fact without backing it up.
There's also this gesture of assuming that the opponent is motivated by evil intentions, which is almost always wrong.
On topic though: Our conversation could really benefit from some actual numbers. I made a quick search but didn't find anything.
Is it? I feel that people vastly overestimate the actual number of competent programmers (not managers, CxOs, etc) many projects need.
Consider that even here on HN we have one person who wrote their own HTML5 renderer, JS-like scripting language, CSS, etc from scratch (csmile). How do you figure that to go from that to what is needed to make a browser that renders sites properly you need to add more than 49 additional programmers?
Its not just about the code though. Somehow that code needs to keep up with the latest standards and magically be delivered to my client device. To think that a project as complex as the Firefox ecosystem can be maintained with less than 50 engineers doesn't match my experience working on large product teams.
Here's my estimate:
* A dozen build engineers to support development and builds for X client platforms
* A dozen engineers for the Javascript VM
* Dozens of engineers to support ongoing javascript and CSS standards
* A dozen engineers or more to support the firefox core
* Dedicated teams for Android, MacOS, Windows and Linux targets
* Dozens of Team/Programme/Project managers to _enable_ devs to do their best. These folks aren't optional.
You work on large teams, so your estimates are for large teams. Smaller teams work faster and can get more done with less. Basic "Mythical Man Month" stuff.
I'm not saying you're wrong. Just that you might not be right.
Sciter doesn't even come close to a fraction of what Gecko or WebKit offers or does, and it still took the author many years to get to that point, so I'm not sure what you're trying to get at. The "JS-like engine" is an excellent example. It turns out, you need an actual JS engine to run real websites, not a "JS-like" engine. The difference between 80% and 100% of that problem is massive, and it also turns out running that fast is a ridiculously complex project on its own. (And, unsurprisingly, the recent Sciter FOSS Kickstarter announced that it would pivot to QuickJS instead. It might be educational to think about why they would do that.)
This doesn't even get into things like translations, technical writing (manuals, help pages, etc), infrastructure needed to actually deliver updates and downloads, collaboration on web standards, etc.
> Sciter doesn't even come close to a fraction of what Gecko or WebKit offers or does
It is close enough to show that a web engine can be made by a single person even if it doesn't fully adhere to the standards and its functionality is certainly not less than 1/49th of what you'd need to go there.
> The "JS-like engine" is an excellent example. It turns out, you need an actual JS engine to run real websites, not a "JS-like" engine.
Fabrice Bellard has written (among many other things) a full modern JavaScript interpreter, again showing you do not need a "dozen" people (like another commented mentioned) to make such an interpreter.
Yeah, as someone who wrote a good chunk of a CSS layout engine (Servo) I can confidently say that this comment demonstrates a huge lack of appreciation of what the scale of work involved is.
The comment was not asking out of curiosity, because when you do that you don't frame it in a way (50 out of 1000) that matches the larger point you're trying to make.
You have a source for those numbers? It looks to me like you're just making them up because you want to sling mud.