Comment by skybrian | Hacker News Reader

Comment by skybrian | Hacker News Reader

Back when I worked on GWT, we had trouble accepting outside contributions because the team had a mandate to support Googlers. That is, much like other libraries and tools at Google, changes could not break google3. This means testing patches against google3 and either changing the patch, or fixing whatever code used it, and these are tasks that no outsider can do.

Shepherding these patches is no fun when you have your own changes to work on that are more important to the team.

We did something similar, by creating an external fork where changes could be tried out by the community, without necessarily being accepted into the internal version.

I think a fork could work if there was enough external momentum, but even 20 people working full time would actually be pretty good for an open source project. How many developers will this fork attract? The fork would need to attract other businesses who can put people on it.

One downside is that the code isn't tested against google3. Sometimes you find actual bugs that way.

Edit: reading more closely, the complaint doesn't seem to be that patches weren't reviewed, but rather that bug reports weren't investigated. That's definitely something outside developers could do more of, and seems a lot easier than forking?

The main Flutter GitHub repo does have infrastructure to run PR against all Google internal tests (which as you say, does find real bugs). https://imgur.com/a/Ih2oQIS

disclaimer: my team runs said infrastructure

Does that automatically run against every PR? What mitigations did you have to put in place for Google security to allow running untrusted code from PRs on internal CI?

Semi-automatically. Googlers have to review it.

Also known as “manually”.

What is google3?

Google's monorepo of closed source code.

Google's internal monorepo.

Here is a paper describing google3 https://research.google/pubs/why-google-stores-billions-of-l..., which includes the policy that “To prevent dependency conflicts, as outlined earlier, it is important that only one version of an open source project be available at any given time.” More documentation on The One Version Rule for third_party: https://opensource.google/documentation/reference/thirdparty.... This rule may make it more difficult to upgrade a third_party library frequently since the maintainer of the third_party library has to test all the uses of the library from all teams, rather than each team deciding when to upgrade.

I used to maintain the internal (single) version of numpy and scipy and honestly I think the one-version rule was awesome. It greatly reduced noise and churn. It meant far less breakage, and it was easy to find and fix all the breaking tests when I was updating to a new version. I guess the only downside is sometimes an older version of numpy would prevent deepmind from making some sort of ML advance until I upgraded to get some new feature they wanted.

Couldn't flutter work as public-first that then gets vendored into third_party? Or is that literally the fork strategy you are talking about that I'm too dense to understand?

Yeah, that's what I meant. Public-first is good in some ways, but it means some bugs might be discovered rather late.

> when you have your own changes to work on that are more important to the team.

That part is the killer. Important to the Google Flutter team != important to the wider Flutter community.

Or maybe it’s not important to the community either? Sometimes, a bug is pretty obscure and only important to the person who filed it. People will get annoyed if they aren’t investigated, though.

It’s good to be a little skeptical when people claim to speak for the community just because they’re part of the community. Often it’s not so.

Yeah, this seems to be a common theme with Google's open source projects. Bazel feels very similar in many points.

It obviously wouldn't exist if not for Google putting resources towards it, but Google's (and google3's needs) are so significantly prioritized that it hurts the community. E.g. due to the low allocation of resources and extensive usage of rules_proto and bazel-skylib inside google3, they are completely ossified and the community has given up contributing to them and instead created either forks or contribution-friendly wrappers.

i avoid contributing to flutter because it feels like a google soon to be abandoned project.

hacks like not accepting tabs in any tools and using space indentation wrong on top of it. tools ignore parameters like port numbers just so it works better for Android studio very specific use case while bringing pain to any ci pipeline, etc.

Reply on news.ycombinator.com