There’s something off-putting about making a blog post about some splashy tech that’s is a fork of an open source project, and that tech not also being open source? It reads to me like “Hey, we thought the open source goose project was just okay, so we forked it to do it better. But we’re not going to contribute it back to and instead rename it.”

I think it probably wouldn’t be as weird if the project were a meaningfully different fork of it, but it sounds like it’s trying to accomplish the same goals as the open source project which I feel should probably be ported back? and renaming it seems sorta ungrateful? Kinda like that “you made this? I made this” meme. Maybe I just don’t have an understanding of how different the projects are though…

They seem to have just optimized its integration with their existing tooling and workflows. That doesn't sound largely useful to the broader community. It's also probably different enough from goose at this point that rebranding it makes sense. I do think such integrations are hugely important for productivity and usefulness of this sort of tool. It seems like the post is advocating for doing deep 1p integration to further improve the utility of coding agents.

…and you can get almost identical features by simply installing the GitHub app inside Slack, and then asking Copilot to work on something, this should take < 5m to set up for any organisation using Slack and GitHub.

How would they contribute back when their fork is a customization of how it works?

> We’ve customized the orchestration flow in an opinionated way to interleave agent loops and deterministic code

Is goose in such disrepair that you can just drop code changes into it and the smol developer auto-accepts it, happy that anyone is doing the work?

Or is goose actually it's own project with 250 issues and 74 PRs and might have its own ideas about how it's built?

I don’t know enough about either but if their approach was to make it substantially more opinionated, which is likely in the case of an org that’s subject to audits, it would make sense to keep it separate.

I don't have specific information about Minions, but I do know about Stripe's architecture and internal tooling.

The article isn't really talking about changes they made to goose, it's describing how they went about integrating goose with the rest of their developer infrastructure (ie. the AWS-based remote devbox system, Toolshed, etc).

Welcome to the free software movement!

If they didn't violate the licence agreement then I'm struggling to understand why it's off putting

You should always expect this when you make MIT. When you give every company permission to fork your software, make it proprietary, and sue you for copying or reverse engineering it, don't be surprised when they do exactly that. It's in their best interest, after all.