Google Open Source Blog

I won't try to be exhaustive here, but I think it's worth mentioning a few things:

One con is that most open source (as well as publicly available but proprietary) tooling is geared towards the non-monorepo approach. So if you want to use a monorepo, you're going to have to fight a bit of an uphill battle because most tools and processes assume you have lots of little repos. For example, build triggers in a lot of CI/CD tools operate on a per-repo basis.

There are some random benefits - it's easier to make everything public-by-default, which encourages people to look at source code written by other teams, and creates a culture of transparency and internal openness.

But the big thing in my opinion isn't directly the monorepo itself, but what's known inside Google as the "One Version Rule"[1]. Basically this means that only a single version of any package should be in the repo at a time. There are exceptions, but that requires going to extra effort to exempt your package from this rule.

I guess Chrome and Android are examples of this - they are made up of lots of little Git repos that are stitched together, but they generally follow the One Version Rule. On the other hand, if you just stick a lot of npm modules in there and every single one has a separate package.json file, then it's technically a "monorepo" but it's not following the One Version Rule.

You also need good test coverage. Not just in terms of line coverage or some other artificial metric, but to the point…

> Nothing in the article suggests it did not autonomously do the work.

I don’t know how to respond to that other than to ask you to quote the part of the blog post where the author described the language model running into a problem that it could not fix and then described the details of how he manually intervened to fix the problem that the language model could not fix when you elaborate on your definition of “nothing” in that sentence.

>Every agent would hit the same bug, fix that bug, and then overwrite each other's changes. Having 16 agents running didn't help because each was stuck solving the same task.

>The fix was to use GCC as an online known-good compiler oracle to compare against. I wrote a new test harness that randomly compiled most of the kernel using GCC

As for:

> Because a lot of naysayers here pretend as if this is somehow trivial.

This is an answer to “why do you want someone to do that?” You have already established that you would like that to happen. It doesn’t answer “why would a real human being (who is not you) that isn’t impressed by the compiler that doesn’t work put their time into making Anthropic look good?”

For example “I will pay a naysayer $20,000 to try” or “I know a guy that will pay a naysayer to try this, succeed or fail” or “I will give a naysayer a bunch of hardware to play with in exchange for attempting this” would be motivation to work for Anthropic and not get paid by Anthropic. Saying “I want you to do that because I think…

I haven't commented on HN in a while, but this article actually pretty much complains about me, since I wrote the text in question and enabled the policy to be released.

So i'm just going to say:

1. The author claims the Google states something, then doesn't actually quote anything google stated, but instead writes their own interpretation of the words and a made up example. That's not a good start.

2. Having set up their own example, the author then proceeds to say it's wrong because of an appeal to authority, asserting no reasonable disagreement is possible - when not only is it possible, but large numbers of IP lawyers disagree on what the AGPL requires. It's true that someone wrote it, and there are FAQ's, but depending when and where, their opinion on what it means is not as relevant as one might think.

In truth, lots of people disagree over interpretation of the AGPL - many more than disagree about GPL interpretation or LGPL interpretation (which are fairly settled at this point). Searches over any legal licensing list in existence will you this.

When I wrote the interpretation you see here, it was the best available info at the time, guided not just by own views, but by listening to a lot of smart lawyers, counterparts at other companies, etc.

Even if you ignore all the lawyers and whatever as useless, the author has the huge problem that There are people who make AGPL software that take the view listed in the google policy

So it's not just Google or…

I don't really want to debate with you here, and if anything I feel like the points you are hammering on just fortify my stance that this topic is a waste of breath.

> The OSI is merely pointing out that it will make everyone's lives easier if developers try their best to use one of the licenses that already exists

Maybe, maybe not! Perhaps existing licenses are not sufficient. I doubt we'll be using the same licenses in 100 years. I bet there are better licenses waiting to be authored -- maybe TFA's license is the future?

> > The OSI includes GPLv3, which is certainly not "free" for a ton of commercial uses.
>
> Incorrect. Commercial customers are free to use, modify, and redistribute just like everyone else. They can even sell a product based on it - they just can't keep any changes they might make closed source if they do so.

Look, I live in the real world. If I link to a GPLv3 library in my product, I have to release all of my source code. This is potentially a pretty big burden on a lot of folks. Sure, there's a lot of legal FUD, but unfortunately, while FUD, has a very real impact. Lawyers won't sign off on a lot of this stuff.

> Take a look at some of the approved licenses - for example AGPL, GPL, MPL, and MIT. In _all_ cases I'm free to modify and redistribute. In some cases I might be required to make my changes available, but never am I barred from making use as I see fit. Source available is simply not the same thing.

AGPL is defacto banned at most…

This sort of mixes up a number of issues:

The whole git/mercurial thing is, as I understand it, related to the extensibility of the systems. Mercurial is hackable and extensible in ways that matter, git isn't (or at least wasn't)

The one version policy only really matters for third party dependencies. If you're making a change to a library that is entirely within the monorepo, you can do a three phase migration (add the new functionality, migrate users, deprecate the old functionality). Google is exceedingly efficient at this, and the vast majority of the time these migrations can be done without any effort by local owners.

For third party deps, you can't usually do that, but there's a workaround[2].

I also think that this post and the one here[1] are amusingly both on the front page at the same time. This one decrying the exact sort of mandate based approaches that "make SRE scale".

Also worth mentioning that

> The person making the new API is expected to change client code to match, but is not responsible for ensuring the change does not break the client.

Is just explicitly untrue. There are policies that are clear about this (this generally comes down to "we cannot break your tests, but if it isn't tested, we can't know we broke it")

[1]: https://news.ycombinator.com/item?id=28825352

[2]: https://opensource.google/docs/thirdparty/oneversion/#temporary-month

I would love to begin using this system, but the licensing is giving me serious pause.
While most of the software is under the AGPLv3, the Commercial License section of the README [0] implies that the company takes on a fairly broad interpretation of the AGPL.

In particular, the line "[...] to build a feature on top of Windmill, to comply with AGPLv3 your product must be AGPLv3 [...]" seems to imply the company aligns with the stance taken by Google and other companies: that even calling the application via API is enough to trigger copyleft [1].

This implies that if I were to build a sign-up form that triggers a Windmill workflow in the backend, my entire application would either need to be AGPLv3 or I would need a commercial license.

That's perfectly reasonable, as it means any non-AGPL use will have to contribute back to Windmill via a commercial license. However, it does mean positioning this as an "Fully Open-source" alternative to Airflow is only technically correct. This is much closer in practice to "source available" than how most developers would think as "open source".

If this isn't how Windmill wants their license interpreted, I highly encourage clarifying things.

[0] https://github.com/windmill-labs/windmill#commercial-license

[1] https://opensource.google/documentation/reference/using/agpl-policy