Why Block Handed Goose to the Linux Foundation  🔗 **Source:** [Why Block Handed Goose to the Linux Foundation](https://share.snipd.com/episode/7074fb27-719b-47a8-afff-feda36184c7d) ## Highlights - **Goose Started As A Skunk Works Project** - Goose began as a Skunk Works coding agent at Block and rapidly grew from a few engineers to thousands of users after internal rollout. - Block open-sourced Goose (Apache) early in 2024, which sparked huge community adoption and plugin contributions. Transcript: Manik Surtani Love to tell um there's a really fun origin story behind all of that and all it stitches together quite well so goose started life as a little coding agent we built within block and it gained Popularity very quickly at first amongst a few engineers. And very soon we realized there's several hundred engineers using it to several thousand engineers using it saying, wow, this is actually gaining a bit of steam. We decided, you know what, we should open source this because it's all based on MCP and plugins and extensions. And the more we opened it up to the world, the more we would see happen with it, right? So we started doing that. That was early last year. So let's say January 25th. Open sourced it. Alex Williams A couple months after MCP came out. So this is all kind of part and parcel of the same time frame. Manik Surtani There's another origin story between MCP and Goose. There's a huge overlap there as well that I'll get into later. But so we open sourced Goose. Goose got really popular. Lots of people started using it and contributing new extensions and new plugins. Gosh, it was like it was on fire. Everyone was using it. Loads of stars, loads of downloads, everything else. And we realized at some point by about middle of last year that shit, we're seeing some headwinds. It's slowing down. Well, what's going on here? And the biggest headwind that we saw was lack of open governance. Now it was open source. It was very permissively licensed. It was Apache licensed. Anyone could do what they wanted with it. ([Time 0:01:00](https://share.snipd.com/snip/169e4328-0f0a-423c-9bc9-80a6a389ef18)) - **Open Source Alone Didn't Solve Governance** - Rapid open-source adoption revealed governance friction: permissive license plus company-held trademarks made enterprises hesitant to contribute. - Lack of open governance slowed momentum despite Apache licensing and lots of downloads/stars. Transcript: Manik Surtani And we realized at some point by about middle of last year that shit, we're seeing some headwinds. It's slowing down. Well, what's going on here? And the biggest headwind that we saw was lack of open governance. Now it was open source. It was very permissively licensed. It was Apache licensed. Anyone could do what they wanted with it. But because there was no open governance around it, it meant that some companies were reticent to contribute back because we still own the trademarks and things like that. Right. So, OK, well, the foundation was the next obvious step. Let's create a foundation so you have open governance and that growth can continue. So I started thinking through that. What's the right foundation? Which one do we plug into? ([Time 0:01:57](https://share.snipd.com/snip/462eaae6-1ee8-41b6-b8db-0a531eb4669c)) - **Merging Projects Multiplied Momentum** - Combining projects into one foundation reduced duplication and accelerated launch by aligning governance for Goose and MCP. - Manik and David Soria Parra decided to merge efforts and soon included Agents.MD via OpenAI collaboration. Transcript: Manik Surtani Ideas for MCP itself. And he was seeing similar headwinds as well. I was like, oh, cool. Well, you know, how would you solve this problem? And he was asking me how I would solve this problem. And we were going back and forth and realized, you know what, we're pretty aligned in our thinking and what we want out of a foundation, how we want the ecosystem to grow, what we wanted Governance to look like and things like that. And so, you know what, instead of doing separate foundations for these two things, let's just combine them and create one foundation, right? It's like, okay, well, that sounds like a good idea. Multiplicative efforts and things like that. And soon after that, OpenAI got wind of it and said, hey, look, can we join? We want to bring in agents MD and we kind of like where you're going with it and what have you. So the three of us spent more time talking and it developed it further. ([Time 0:02:42](https://share.snipd.com/snip/a111f288-0539-4eb7-9a23-c6a5ec9cb97f)) - **Launch Fast With A Narrow Initial Scope** - For speed, limit initial scope: include a few key projects to get the foundation launched quickly. - Manik says they intentionally started with Goose, MCP, and Agents.MD and deferred other projects to avoid slowing setup. Transcript: Manik Surtani As well that politely didn't make the cut? Well, yes. Well, not didn't make the cut, but just we wanted to stop at those three projects just to get it out the door. Oh, I see. Okay. Let's go. For the sake of expediency, right? Like the more projects we had in there, things would have slowed down even further. It's like, no, we really want to get this out now. Now is the time. Several other companies wanted to put things in. It's like, great, join as governing board members, become members of the foundation, and we'll get your projects in later. ([Time 0:03:30](https://share.snipd.com/snip/e1752a7d-d244-47c9-839b-905db612997a)) - **Goose Influenced Later Coding Agents** - Goose predates many model-specific coding agents and influenced tools like Cloud Code, offering both CLI and GUI interfaces at Block. - It was in use before Codex and became a reference implementation for coding workflows internally. Transcript: Manik Surtani Talk them through it. Yeah, absolutely. So like I said, Goose, compared to cloud code, Goose is really old. I would actually say Goose inspired cloud code. We were using Goose. Yeah, kind of the OG. The OG, that's right. We were using Goose internally within block to write software just the way people use cloud code today. We had a text user interface, a CLI. We built a GUI on top as well. And all of this stuff was early 25, really. So kind of predating Cloud Code and influencing Cloud Code quite a bit. That's before Codex came out from OpenAI. That's before Codex as well. Absolutely. So, you know, so Goose has been around for a while, kind of in OG. Where it stands today, people still use Goose a lot to write software. We do it at Block quite a bit. There are lots of other companies doing the same thing. Where Goose kind of stands on its own, though, is it's not tied to a particular model. ([Time 0:05:30](https://share.snipd.com/snip/b1c69e1b-45bb-40e1-bd87-fa6c0979b8e6)) - **Model Agnosticism Enables Model Comparison** - Goose is model-agnostic, letting users pick or fan-out multiple LLMs for the same task to compare outputs. - Users can run parallel sub-agents across different models like Claude, GPT, or GLM-5 to determine best answers. Transcript: Manik Surtani There are lots of other companies doing the same thing. Where Goose kind of stands on its own, though, is it's not tied to a particular model. You don't have to use Claude as the model to write your code. You can use whatever you want. Now, sure, Claude Opus 4.6 is currently state-of and that's what everyone wants to use. Or GPT 5.3 Codex. Right, fair enough. Or GLM-5 is pretty good, too. That's exactly what I was going to get into. GLM-5 is fantastic for that. And we're seeing a lot of success within block using GLM-5, right? And the ability to switch, I think, is really powerful. So Goose gives you the ability to switch. ([Time 0:06:11](https://share.snipd.com/snip/5f011faa-1220-41d1-886a-da9bf0c485b1)) - **Decouple Interface From Runtime For Seamless Handoffs** - Decouple interface and runtime: adopt protocols (ACP/ACP) so Goose can run locally, remotely, in Docker, or in a mesh for frictionless task migration. - Manik describes migrating a task from laptop to server and continuing via phone as a target use case. Transcript: Manik Surtani Yeah, so Goose really is your driver. It's the frame, well, yeah, the driver really to be able to use your LLM underneath it. And there's more to it than just the stack that you mentioned. So for example, we're working quite closely with ACP, the agent client protocol within Goose, so that you can now have your IDE sitting next to Goose as well, and you can work with Goose And talk to Goose through your IDE, through VS Code, or IntelliJ, or Zed, really. Alex Williams VS Code in my case, but sure, yeah, yeah, yeah. Manik Surtani So that's pretty cool. And of course, there's lots of other stuff coming out as well. One very cool thing we've been working on recently, very much an experiment, if folks want to be on the bleeding edge, right, is something called Mesh LLM. We're thinking, what would happen if you were to run a local model on your laptop, and not just your laptop, but a bunch of other laptops, and your friends are doing the same thing. And you want to share that capacity, that compute capacity, and expose that to something like Goose. Okay, and what if you expose that over, let's say, Noster for Discovery? Now you've got this mesh of local LLMs running all over the place, and Goose knows where to look to find them, and is able to connect and farm out work to a cluster of machines. ([Time 0:09:57](https://share.snipd.com/snip/370e87d8-1276-4ea3-bcb8-e0e64df73eb6)) - **Experimenting With A Mesh Of Local Models** - Mesh LLM experiments let peers share local model compute for distributed inference without central APIs. - Manik likens it to pooling laptop models discovered via Noster to farm out work across machines. Transcript: Manik Surtani We're thinking, what would happen if you were to run a local model on your laptop, and not just your laptop, but a bunch of other laptops, and your friends are doing the same thing. And you want to share that capacity, that compute capacity, and expose that to something like Goose. Okay, and what if you expose that over, let's say, Noster for Discovery? Now you've got this mesh of local LLMs running all over the place, and Goose knows where to look to find them, and is able to connect and farm out work to a cluster of machines. ([Time 0:10:36](https://share.snipd.com/snip/1f9dbcd7-7dd1-4fce-9c70-5e3a490d1f4b)) - **Open Source Pays Back Through Hiring And Shared Maintenance** - Open source creates hiring and maintenance advantages: external community maintenance reduces internal upkeep and attracts top engineers. - Manik cites Block's Android contributions that hired great developers and removed maintenance costs. Transcript: Manik Surtani So open source has always been important to Block. It's a core part of our DNA. It always has been. A lot of the company is built on an open stack. It's built on open source operating systems and open databases and open source middleware all the way through. Always been the case. Jack does love Bitcoin, etc., etc., right? Even further down later on in Blockstory, but in the early days, like I said, everything was built on an open source stack to begin with. So we started hiring a lot of people, a lot of engineers from those open source communities to work on that stuff. And there's a bit of a flywheel effect that happens. You hire people who know how to do open source really well. Well, guess what? They're going to do more open source. Alex Williams They want to do more other things they do well. Manik Surtani That flywheel just contends, that's sort of where we are. Alex Williams I really appreciate that. Is there a minimum density of open source talent at a company that will spontaneously form projects and foundations? Is it like if 10% of your developers are big fans or is it more like 50% of your developers need to be into this idea to make it happen? Because I love that you're doing this ([Time 0:12:10](https://share.snipd.com/snip/5eaa6509-da69-41c9-9fe0-819e2b73f704)) - **Hire Influential Contributors To Jumpstart Open Source** - Invest in vocal, respected open source hires to seed community influence rather than chasing a specific percentage of contributors. - Manik notes Block grew influence by hiring well-known Android engineers who amplified adoption. Transcript: Manik Surtani I don't know what the number is. I don't think there's a hard and fast number, whether it's 10 or 50. I think it's closer to 10 than 50, by the way. But regardless, I think it's more about how vocal those people are than what the number is. So we were lucky in the early days of Block to have a couple of very, very vocal, well-known engineers, let's say specifically in the Android space. We got really well-known in the Android space early on because we hired some folks who were so well-known in the Android community that everything they did became really popular in The community at large outside of Block. And then other folks saw that and said, crap, that's really cool. I want to do stuff like that too. And they started working on that as well. So for example, the networking stack in Android, the core networking stack in Android came from us. We contributed that back. ([Time 0:13:15](https://share.snipd.com/snip/1f93644d-4ff2-4bc7-af09-620aad4bb59c)) - **ACP Enables Transparent Task Migration** - Embracing ACP lets Goose become platform-agnostic: run it locally, in containers, or migrate tasks mid-run to remote instances. - This enables starting work on laptop and transparently continuing on server or phone with the same instance. Transcript: Manik Surtani Of the biggest things we are doing is we are adopting ACP wholeheartedly, the agent-to protocol, which means that now you can run Goose in multiple different ways. Right now, you run it on your laptop, and you've got a user interface, whether a text user interface or a GUI. The way we're wrapping it up now, you'll be able to deploy Goose in a Docker container, run it remotely, run it locally, run it in a mesh, what have you, and you completely decouple the Interface from it, which means now you're switching. You can use it on your laptop to talk to Goose locally, start a task, shut your laptop down, the task gets migrated to something running on the server somewhere in a Docker container. Without friction, the handoff is done just... That's right. So that's what we're working on right now, right? So the handoff happens, and then you can pick up your phone and continue talking to that instance to see what's up with it and where it's got to, and so on and so forth. ([Time 0:16:56](https://share.snipd.com/snip/ea08f0d2-7773-454a-9e83-7a2950637eac)) - **Plurality Beats Winner Takes All For Agents** - Success in the agent ecosystem is plurality not monopoly: multiple agent harnesses will coexist and push standards. - Manik compares Goose to Firefox as a standards-focused, reference implementation among many competitors. Transcript: Manik Surtani I think i think winning is there's no winner takes all i think winning is plurality where you have multiple agents and multiple harnesses, and they're all learning from each other, And they're all growing. So I like to think of it as what we see in the browser space, right? There's lots of space for Chrome and Edge and Firefox and so on and so forth. Alex Williams There's decreasing amounts of room for Edge and Firefox. Manik Surtani Fair enough, fair enough. But for example, Firefox is still a really important part of that ecosystem. It keeps everyone true to standards. I almost see that as Goose's role, and Goose being the Firefox of the agent harness world, where we get to be the reference implementation, the standards compliant harness, and of course There'll be others. ([Time 0:18:10](https://share.snipd.com/snip/ab5ccb31-1908-4fbc-bb03-85c91ee0a9c8))