That’s a good question, even if I disagree slightly about the premise, as random large open-source products targeting consumers (as opposed to infrastructure projects like Linux kernel) can dramatically vary in quality.

My hypothesis: devs are much closer to users, as they are often users themselves, and have more freedom to work on fixing broken experiences, as opposed to just rolling new features.

Exactly.

Linus was able to out-compete a team of hundreds of Microsoft Engineers who spent years building a Source Control system by himself within a span of 10 days when he built git.

You can't take Microsoft Source Control, add a few stories, and end up with git in a Sprint. You can't split that work up between different teams.

The essence of git is in a unified design that matches the essential complexity of source control requirements. When you play the game of telephone from user to sales to program manager to project manager to architect to lead developer to UX designer to DB modeler, each step along the path introduces errors. Those errors made the system harder to design for, harder to scale, and harder to use.

Linus was able to cover every element of those to a passable degree himself. You need to empower your developers. If they don't use the product, if they are not dogfooding, you have no chance to compete against those that are.

IMO Linus is a very unique, one in a million, engineer building a proto git in 10 days is really not a common feat and is the result of a mix of passion and focus that is very hard to replicate.

That being said, I agree with the general point that having vision and trusting your developers with their vision can be a winning strategy.

I think it's less "passion" and "focus", more his position as the Linux lead giving him first-hand experience with change control at scale. He didn't need a product manager to gather requirements, because he already knew them.

That's basically what ItsMonkk is saying, but I think it's worth making it more explicit. Because a one-in-a-million engineer is not replicable, but a deep understanding of your users' needs is.

What large open source hosted office suite is better exactly? I’m unaware of one.

Same with large open source email services? (Ala Gmail)

It’s usually apples and oranges comparisons. There is libreoffice, but even on it’s best day it’s not doing real time document editing/collaboration with 10+ people on opposite sides of the planet, and that is the Google Docs bread and butter for instance.

I think you're trying to compare against Google's best and largest products (which probably have the best PMs working for them, with the clearest demand for "vision.")

Compare instead Google's average products (y'know — the kind they eventually shut down) to the largest FOSS competitors in those same verticals.

For example, compare Google Reader at its peak MAU, to the current #1 open-source RSS reader app.

Or compare Google+ to, say, Mastadon. (Mastadon is a FOSS Twitter knockoff whereas Google+ was a Facebook knockoff, but I think the point stands.)

Or, for a painful one, compare Blogger to Wordpress! (Okay, maybe that one's not fair, since Wordpress is a real company that can hire product managers. But most WP development is still random FOSS developers scratching their own itches.)

Or compare Google Code at its peak to, well, anything. GitLab CE, GNU Savannah, anything.

None of these were failures of engineering. They were either failures of product management, or failures of budget/staffing — which is in essence still product management, since it's a PM's role to fight for the budget and headcount to get the job done.

(That's not to say all but the best Google products rot on the vine. IMHO Google are pretty good with steering their internal B2B engineering-driven offerings, e.g. GKE, Firebase, BigQuery, etc. Those are run a lot like FOSS projects, in that it's a combination of internal engineers scratching their own itches, and customers directly filing bug reports, that determine what gets built. It's the B2C products, and the marketing-driven B2B products — where in either case the engineers involved might not have the problem themselves, and the customers might never directly engage with them in troubleshooting their workflows — that tend to falter.)

> There is libreoffice, but even on it’s best day it’s not doing real time document editing/collaboration with 10+ people on opposite sides of the planet, and that is the Google Docs bread and butter for instance.

If that's your only requirement, then the FOSS project https://etherpad.org/ that Google acquired to build Google Wave off of (and then later dis-acquired) satisfies it pretty well. These days it's even kind of a word-processor! (Originally it was just a multiplayer <textarea> with per-user text background colors.)

> For example, compare Google Reader at its peak MAU, to the current #1 open-source RSS reader app.

What's the current #1 open-source RSS reader app? Google Reader at its peak was by far the best RSS reader I've ever used - and presumably the same was true for many other users, hence why it shutting down functionally killed RSS entirely. But possibly I've just not found the better alternatives.

> Or compare Google+ to, say, Mastadon.

Wasn't your original point to compare similarly-sized services? G+'s userbase was multiple orders of magnitude larger than Mastodon's has ever been.

Which opensource product do you believe has 1 billion users like Gmail does?

None? Google has ~3 well-managed products that everyone loves and uses, such that nobody even bothers to try to compete with them. These products are the exceptions. They may as well not be Google products, because they aren't representative of Google's product-management philosophy at all. You can't set up a new team at Google and talk to them about doing things "the Google way" and have them to understand that to mean "like Gmail does."

Google has 1000+ badly-managed products. Google's actual product-management philosophy, is reflected in how these products are created, managed (into the ground), stagnated, and usually eventually killed. My post was about those.

It's very easy to beat the complete lack of product-management in your average FOSS project, by just having one full-time product manager with vision for where the product should go. See, for example, what this guy (https://www.youtube.com/c/Tantacrul) has to say about various pieces of FOSS DAW software, where all the flaws usually come down to a pure lack of product management on the FOSS projects' part. The problems he points out could all easily be fixed by having one person with vision submit bug-reports about workflow issues, and having those bug-reports get taken seriously by the engineers. (And he's now doing exactly that, as PM, for Audacity.)

Google should easily be able to hire guys like him, and put them on projects like the ones I listed in my sibling comment. But they just... don't... seem to have it in them.