cdata

The irony of this rationale to me is that an LLM is fluid and adaptable to dynamic, variable norms and tools across a given set of projects in a way a human contributor would not be.

For the last year or so I have used Niri window manager exclusively. It's out there, even by Linux tiling window manager standards, and it's the most delightful window management experience I've ever had. I'm guessing there isn't anything remotely like it on Windows or MacOS.

As you say, there is incredible variety and innovation to be found in Linux desktops. The post would make more sense if it mainly concerned itself with the UX stagnation on MacOS IMO.

I can't speak for all, but many mature open source communities have explicit or ad-hoc reputation schemes that are used to triage contributions. A fresh account means starting over with zero reputation, which in turn means your contributions wait at the back of the line.

I strongly prefer a world where open models "win," that said...

I don't understand how we will sustain an ecosystem of open models like the one that exists today. My thoughts go down this path every time I try to put the pieces together:

- Many open models depend on high quality frontier models as a distillation input

- US closed frontier models drive China's open model strategy despite the business model for open models being somewhat fuzzy

- What is the business model that benefits from open weights, exactly? How do their vendors recoup infrastructure and training costs?

I would be grateful to be enlightened on this topic.

I'm all for framing the spirit this way, so long as we recognize that it was rather difficult to come up with the sum total of human creative output (noting also that approximately zero of the cost to produce it has been born by frontier labs so far).

That's very cool, although AFAICT my hacked-together non-product shares most of the same virtues. Can you upsell it to me a little?

Google contains multitudes. I don't doubt that your personal experience was the opposite end of the spectrum from mine.

I maintain that firing is an extreme resolution here (taking the claims at face value of course). Surely this employee has demonstrated the capacity to deliver impact and could be redirected if properly incentivized.

When I was there, there was no universal process; different teams had different processes based on their focus. There was a launch process for Google products and there was the open source office for approving open source code (which amounted to a rubber stamp in my experience; they mainly checked for boilerplate issues). As I said above, my team and others were allowed to publish at our discretion.

Even if this person violated that process, it is an extreme consequence to fire them for that infraction.

Simply put: all work published to Google repos is implicitly affiliated with Google.

In my team's case we would include expectation-setting language in the README.md so that it was clear that the project was not an officially-supported Google product.

As far as I know, no-one ever lost their job for failing to set that expectation. A gentle correction from legal was sufficient to set the world right.

I'm noticing a few commenters who work (worked?) at Google (inferred from comment history) who are critical of this person's actions.

First: you ought to disclose that information when commenting on a topic that relates in some way to your financial incentives.

Second: when I worked at Google under Chrome it was very common for individuals and teams to publish projects to open source repositories under Google-managed Github orgs. In fact, for most of my tenure ('15-'21) my team had license to publish to Github unilaterally (no approval from the open source office required). Great power comes with great responsibility, but also I would put to you that publishing an open source project like this one is part of Google's culture.

Firing seems an extreme consequence for the perceived damage of a long-tenured employee's behavior in this case.

I think the author is referring to enterprise customers. You aren't the "customer" in this case; you're the bait.

How do you know that the other models you are referring to aren't subsidized?

If our strategy to avoid "slavery" involves "normal people" taking the local-vs-managed choice seriously, we have already lost.

This choice is made for us. The deciding factors will be convenience and economics.

My sense is that just like Web 2.0 SaaS we are destined for servitude.

A better strategy is to play an assymetrical game IMO. Don't let your would-be master write the rules by which you play.