Screaming in the Cloud - From Code to Cash: How André Arko Builds Better Tools and Gets Paid for Open Source

Episode Date: November 13, 2025

André Arko, CEO of Spinel Cooperative and longtime Bundler maintainer, joins Corey Quinn to introduce RV, a new Ruby tool that installs Ruby in one second instead of 10-40 minutes by using precompiled binaries. Inspired by Python's UV, RV aims to simplify Ruby dependency management without the complexity of older tools like RVM and rbenv. They talk about why Ruby isn't actually dead, Apple's problem with shipping a five-year-old end-of-life Ruby in macOS, and the challenges of writing dependency managers in the language they manage. André also shares how he transitioned from a struggling nonprofit model to a cooperative that charges companies for expertise, proving that open source maintainers can build sustainable businesses without relying on donations.Show Highlights:(03:50) Introducing RV(05:12) The RVM vs rbenv Wars and Why They All Break Bundler(09:00) Why Your Mac Still Shows Ruby 3.0.0 in Your Prompt(11:00) The Chef vs Puppet Philosophy Divide(16:30) Installing Ruby in One Second vs 40 Minutes(18:13) Apple’s Ancient System Ruby Problem(22:20) RV’s Incremental Approach (24:23) Is Ruby Dead? (28:44) Why RV Is Written in Rust, Not Ruby(31:10) The Bundler Problem(32:15) The Financial Reality(38:00) Spinel’s Plans to Make Money(39:23) How to Stay In Contact with AndréLinks:André Arko: https://arko.netBlue Sky: https://bsky.app/profile/indirect.ioSpinel Cooperative: https://spinel.coopSponsor: Duckbill: https://www.duckbillhq.com/

And we are not that far along yet. We are, you know, starting with this significant improvement that we thought that we could ship and we shipped it. And it is a significant improvement. But I think to be able to do everything is definitely going to take more time and more development work. And mostly the way to solve this problem of everyone needing it, we're making sure that everyone doesn't need it, right? The initial version just happens to install Ruby in one second instead of 10 to 40 minutes. And if you have the right version of Ruby and you want that one improvement, knock yourself out.

We offer that. It's great. Some people have said that they are using it and very excited about it in the last 24 hours. But it means that we can incrementally improve the other use cases that we have on the roadmap over time. And I don't feel like our goal is necessarily the same as UVs in the sense that we need to convince people to switch off of six or seven different competing tools towards our tool. The difference is just that we need to offer a better user experience than the two or three Ruby version managers that exist today.

And once we've done that, hopefully people will feel motivated. to use our tool instead. Welcome to screaming in the cloud. I'm Corey Quinn, and today we are screaming in the past. Andre Arco, CEO at Spinell Cooperative, comes to us from the past, by which I mean the Ruby community. Andre, how have you been?

Hi, Corey. It's great, great to see you. I have been in the past, apparently. You know, I do spend a lot of time talking to people about how Ruby is dead now or whatever. And what I always tell them is, in that case, I hope that you would be happy to sign up for the pager that keeps going off because traffic has grown by 20% a year for the last 10 years at Ruby Gems. And I keep getting woken up in the middle of the night. So I'd be happy to hand that off to anyone who's convinced Ruby is dead. this episode is sponsored in part by my day job duck bill do you have a horrifying a ws bill that can mean a lot of things predicting what it's going to be determining what it should be negotiating your next long-term contract with a w s or just figuring out why it increasingly resembles a phone number but nobody seems to quite know why that is to learn more visit duckbill hqcq dot com remember you can

can't duck the duck bill bill which my CEO reliably informs me is absolutely not our slogan i like that it's one of those boring things that you know runs half the internet as we know it's in fact it's our timing on this is very apt because i'm on the bus frantically heading home this morning from an appointment to be on time for this and i'm checking you know slack because blue sky was boring and one of my colleagues pointed out that ruby is now picking up a new trick from the python world and link to your post on RV. And my response to that was, well, I shit you not. I'm talking to him in 15 minutes on the podcast. Like I'm sitting here pulling leaves off the flower. He shits me. He shits me not. Exactly. But no, I shit you not. So our timing is superb now that you have some

stuff coming out of the skunk works. Tell me about RV. What is it? Yeah, absolutely. So the biggest inspiration for RV is coming from the Python community, historically, the Python community has had a lot of options if you wanted to manage dependencies, right? Like the Ruby community historically had Ruby gems and the other options kind of fell by the wayside and then had Bunler and the other options never really got off the ground. And so in the Ruby community, if you want to manage dependencies, you just use Bunler and 99.9% of everyone is on the same page as you.

But in the Python community, you had to say, oh, are you using PIP or PIPN for poetry or six other tools that I don't remember the names of off the top of my head? And if you disagree with this, you're not listening to the podcast because you're too busy solving dependency problems. Right, exactly. And so UV is super interesting to me

because as a package management enthusiast, I watched the Python community, sort of like shift in real time over the last year from we use 17 different tools and no one can agree about which the best one is to well actually everyone pretty much agrees that uv is the best tool and maybe you don't use it yet now i do want to push back on that a smidgeon because i still remember and have the scars to prove it from the rvm versus rbn wars where okay how are we going to handle all the languages on our developer laptops i'm just kind of overwrite the system ruby seems like bad plan. Oh, man. I do have to say, as the maintainer of Bunler during that era,

I actually hate all of the environment dependency version management tools because they would all get in fights with Bunler and Bundler would lose in the sense that they would break Bundler and then we would get tickets about it. And so I personally, I ended up for the last decade just using C.H. Ruby, which sets some shell variables and does nothing else whatsoever. Stupid shell tricks every time. Exactly. So over in the Python world, UV has over the last year become this kind of like almost consistent standard for people to use if they need to manage their Python projects or their Python tools, which is incredibly impressive to me because I feel like Python was starting much farther behind than Ruby where they didn't even have a tool that everyone had

rallied behind for, you know, 10 years. And using UV myself, I was blown away. It's amazing. I don't know how it does the magic that it does, but it is super fast. It doesn't stop other things you have going on. You type UVVN, press enter, and by the time you remove your finger back from the enter key, it has the virtual environment ready to go of whatever version you have specified. UV PIP install your list of dependencies. It does massive parallelization. I'm pretty sure that they have, I don't know, tortured a witch into making it as fast as it is somehow

because it's the only thing that I can find that would explain it. And it is life-changing. And they're like, oh, well, I want to install something globally that runs everywhere. Yeah, UV tool install. And then you give it whatever you want to. It's how I use my ABLE CLI these days. It's phenomenal.

Across the board, everything about UV. has made my life better, except for the part where I still have to work with computers. Right, right. Absolutely. And so as a Ruby developer, I would use some Python tools and say, wow, UV has made my life better in every way. And then I would turn around and open my Ruby project and say, oh, no, it's not making my life any better now. Yeah, it feels like Docker containers are the only way to handle Ruby projects, because everything was so specific as far as how it worked, that even with some of the package management stuff that was out there, it still felt like I was always teetering on the brink of disastrously screwing up my

Ruby environment. Yes, yes. And that was definitely a significant amount of the motivation. I have been kind of like kicking around in the back of my mind a better version dependency management tool for like probably 10 years now. I've been like, oh, man, I really wish that I didn't have to, you know, install rbn and then install ruby build and then install a ruby and then switch to that ruby and then install ruby gems and then install bundler and then install my gems and then have a

project and it doesn't clean up after itself like on my desktop right here if i fire up a terminal on the right hand prompt uh i believe that's what ps2 whatever it is uh is uh the yeah the where it winds up uh listing out that i'm using ruby version 3.0.0 why what does it need ruby for I don't know. Does my laptop, which has the same config, say that? No, it shuts up about Ruby like I wish some people would, but never seem to. We know who I'm speaking of when I say that. Not you, to be clear. There are, but in this case, I don't know what I did one day when I was trying to get something to work. And honestly, I'm scared to touch it because that's where breakages come from. It's just, it's one of the great mysteries. Definitely one of the great mysteries.

Whereas Python is decent. Python cleans up after its mess. Definitely, I definitely feel like UV is contributing to this. Well, I still remember back in the CentoS five days when I was helping support people on IRC and whatnot because I was a minor part of the project. And it would say, okay, great. So I've installed, I've upgraded my system Python. Now what do I do? And it's like, well, that broke yum. So now you get to reinstall your operating system.

Yeah, back your shit up and try again, which as it turns out was not. the most supportive thing we could have said, but it was honest. It's, oh, great, you broke it and now you get to keep the pieces. Good for you. Absolutely. In seriousness, I wanted to call out where Ruby's been great. It has always been spectacular at, I have an idea and I want to build it. I'm going to reach for something that gets me from start to finish, largely with batteries included, and Ruby has been the thing. My last real job was a Ruby shop. I remember that we spent the year there trying to figure out how to upgrade from, I want to say, one.8.3 into something modern at the time, which was still a few versions beyond that. And as it turns out, the way that we did that

was we got the company acquired by Black Rock, who then took the product and smothered it to death in its crib. And, you know, time marches on. I have not been there for almost a decade. And I don't imagine ever got fixed in that context. Ruby upgrade satisfactorily resolved, you know, great work. this was such a monolith at the time and again it's easy to blame the language for it but you can commit atrocities in any language as it turns out i used to be deep in the puppet world and had enough problems with the way they did config management that all right i was one of the early developers behind salt stack and good this'll fix it and nope you can give someone the latest generation shiny laptop and they wonder about the bad hammer you just sold them when they hold it wrong oh man that that really brings back memories I was friends with the puppet crew back in the day of whatever that was, the mid to late 2000s as we were all doing fancy Ruby things. And I mean, I got to say, it was a big step up from we have a shell script that we run any time we stand up a new server.

Chef kind of went too far in the Ruby direction from my perspective at the time because I remember that was the one config management tool I never really got into because it really didn't have its own DSL so much as it had just, write your config and Ruby. The problem is, is back in that era, you're talking to a bunch of sysadmins and you're telling them, oh, you should just become a software engineer. And for the few that were willing and able to do that, they discovered, especially in large companies very quickly, it's, huh, I could go work somewhere else for a 60% raise and not be on call. I think I'm going to go do that instead. So there was an upskilling that was required that was

a hard leap for most of us to make. I certainly couldn't make the leap at the time. That's fascinating. I guess I never really thought about the impact that chef had coming from the other direction since I was already a software engineer by the time that I encountered chef. And so for me, the enormous frustration was that chef made you build a very strange ruby building blocks that you then had to plug into your chef scripts rather than being able to just write some ruby. And so from the from the opposite side, there is a very difficult, you know, kind of like hard to figure out, like, wait, what is the API that this has to conform to? Why does this have to, you know, fit into exactly this weird plug-in structure that you've decided all chef things have to fit into? And it was not well documented to the point where the easiest way to learn how to write chef modules was to buy the O'Reilly book and not to read the chef documentation. Or in some cases even to read the code, which gets you back to, and now you're a software engineer. Puppet, it always seemed, it was

tart. They went with a DSL for Puppet, which is its own problem. You have to write a specific language for a tool. It already feels like you're going down the wrong path. But it was, it felt like it was much more squarely aimed at the systems administrator type, where a lot of what it was doing felt a lot more shell script friendly-esque. And you could obviously break out into Ruby with it, but most people didn't. and it was considered an anti-pattern for good reason. The biggest problem in many cases with the config management stuff that I learned, and this is a truism of programming everywhere,

you can be really clever with these things. The problem is that someone, maybe you in six months, has to untangle the rat's nest of being clever to figure out what the hell it's doing and why it even worked in the first place. So simple is a lot more scalable. Yep, absolutely. Absolutely.

That is definitely one of, of the more intangible essences that we are attempting to capture with RV here is what if you could do stuff and it was just simple to clearly state the thing that you wanted to happen and then it would happen, right? Instead of this pile of six things

that are all dependent on each other that you have to set up correctly and if you knock one of them out, your software no longer runs, it's just one tool. that's just one executable binary with no dependencies. And then you can just say, I would like to run this Ruby and we make sure that that Ruby exists

and is configured and is available. And then we run it with the thing that you want, hopefully, to run. And so our, you know, again, inspired by UV, the ultimate goal is to fully kind of like encompass the entire range of anything that you you might want to do while you're running Ruby code, whether that's the Ruby interpreter itself,

or a command line tool that happens to be written and packaged as a Ruby gem, or it's your fancy web application, and you want to be able to run it with all of its dependencies included in a Ruby that actually works, but you just want to run one command and have it all actually happen for you. So that's kind of like the UV-inspired vision

that we're aiming for with RV. And then today, kind of like as our first effort, demonstration of what towards what we think is possible, we've shipped just the initial Ruby version management part of the tool. But the cool thing about this part of the tool is that installing Ruby with all of that entire, like, you know, pile of Ruby version managers,

RVM, RBM, RBN, C.H. Ruby, Ruby build, Ruby install, all those things. They all expect you to download a source tarball for whatever Ruby version you want, and then start to compile it yourself on your machine. And so installing Ruby, depending on exactly how new and fast and fancy your Mac is, is somewhere between a five-minute process

and a 20-minute process. And honestly, if you're on the tiniest digital ocean droplet, a 40-minute process, because, Or Raspberry Pi, which we're still waiting for that to finish. I'll let you know and send a postcard if we ever get there. Sounds amazing. So the nice thing that we wanted to build as kind of like our first proof of the direction

we want to go is RV installs pre-compiled rubies. We have a setup in GitHub actions that make sure that there's a Ruby that works for the platforms that we support, which so far is recent macOS within the last couple of two or three years. recent Ubuntu within the last two or three years. But if you install a Ruby version that we support, it's installed in one second. Like, there's, turns out, pre-compiled binaries install a lot faster than, you know, source tarballs that have to run configure and then make and then make

install. My philosophy on this, and this is controversial, I know this, but I've always found that with least when you're targeting Mac as a development environment, it's a lot easier from the perspective of At some point, if you are no longer getting security updates for your operating system, which Apple moves off of pretty quickly as time advances, I find I don't have to worry about your version of the operating system anymore. Like when it goes end of support by the vendor, I'm not going to sit here with bailing wire and popsicle sticks trying to keep the thing on life support. I find that I can move on. Counterpoint, I don't build anything that has a widespread install base. So do you agree, disagree? How do you think about that?

Coming from the position of being on the Bunler team for the last 15 years, it has been an ongoing struggle to know exactly how far back we should support, primarily because Apple ships a ruby so far beyond end of life that, I don't know, like it should do the licensing concern. Yeah, yeah. And on some level, like, that's the beautiful thing about not having a large. install base. I can take a professional support policy. Fuck them kids. But that's not something you can do at scale most of the time. Yeah. So we're attempting to, you know, resolve this tension kind of initially at least by stating that our goal is to support any Ruby that hasn't been

end of life to already. And hopefully our users plan to stay, you know, live and upgraded if the upgrade, you know, if the install process is one second rather than 10 minutes, maybe that's an additional incentive to occasionally apply Ruby upgrades. But yeah, the Ruby core team has sort of semi-recently settled on kind of like a yearly cadence and a two or three yearly end-of-lifing policy. And honestly, I think that's pretty reasonable. Like there will be a version of RV that was built to support, you know, the rubies that were viable this year. And if you want to use the new RV, maybe you should also

use the new Ruby. Yeah, on some level, I have to think, and please, I fully accept that I could be way off base, I'm the problem, et cetera, et cetera when it comes to this. But it feels like if you're going to be doing any kind of Ruby development or working with Ruby on a Mac, which let's face it, is where an awful lot of development lives these days, I feel you can safely assume that you will not be using the system ruby to do it is that a fair assumption that that is a fair assumption because the system ruby doesn't actually work with anything anymore um the system ruby today that ships in the very newest macOS was end of life more than five years ago it almost feels like they'd be doing a better service to not include it at all they apple has been threatening to remove system ruby for

more than five years and my theory on why they keep not removing it with each subsequent release is that it would break their own tools built against it that they haven't had time to rewrite from scratch to no longer be Ruby scripts but there are scripts down in the bowels of macOS that that are absolutely Ruby scripts and so they just keep shipping this ancient Ruby that they can never upgrade just to keep the OS from breaking that found that sounds painful but the upside there of system Ruby finally being so old that it's obviously you should not be using it, is that we basically expect you to need, you know,

some kind of installed Ruby, which we plan to provide in a very fast and easy to use package. This episode is sponsored by my own company, Duck Bill. Having trouble with your AWS bill, perhaps it's time to renegotiate a contract with them. Maybe you're just wondering how to predict what's going on in the wide. world of AWS. Well, that's where Duck Bill comes in to help. Remember, you can't duck the Duck Bill Bill, which I am reliably informed by my business partner, is absolutely not our motto. To learn more, visit DuckbillHQ.com. So a question I have, because as you said, the Python community has coalesced around UV, which I think in many cases is part of the reason I'm starting to see it everywhere,

is that it's amazing and people are embracing it. I understand it might not be fair to ask you about this less than 24 hours after the thing comes out. But how are you envisioning this uptake looking? It feels like it might be one of those problems where, and now all we need to do is have everyone embrace it simultaneously. It feels like that's not realistic. That is definitely not realistic.

And I have to admit, like, we don't have VC funding. like Astral, the company behind UV. And so we are taking a slower and more methodical approach. We aren't shipping a thing that does everything kind of out of the gate, right? Like UV by the time it had reached 0.3 basically did everything. And we are not that far along yet. We are, you know, starting with this significant improvement that we thought that we could ship and we shipped it and it is a significant improvement.

But I think to be able to do everything is definitely going to take more time and more development work. And mostly the way to solve this problem of everyone needing it, we're making sure that everyone doesn't need it, right? The initial version just happens to install Ruby in one second instead of 10 to 40 minutes. And if you have the right version of Ruby and you want that one improvement, knock yourself out. We offer that. It's great. Some people have said that they are using it and very excited about it in the last 24 hours. But it means that we can incrementally improve the other use cases that we have on the roadmap over time. And I don't feel like our goal is necessarily the same as UVs in the sense that we need to convince people to switch off of six or seven

different competing tools towards our tool. The difference is just that we need to offer a better user experience than the two or three Ruby version managers that exist today. And once we've done that, hopefully people will feel motivated to use our tool instead. Yeah. I do have to ask, ecosystem-wide, it seems like Python is the darling these days. Part of that, I think, comes from the fact that that has for a long time been the lingua franca of a lot of things uh data science machine learning and given that with pie torch

and the rest and all of the other AI things it seems like that is the de facto thing that people go for i always liked it because it's pseudocode it feels very easy to read easy to write badly and it's the sort of thing that there's always an import library for something that i need i don't hear as much about ruby in the modern era why that's a very it's a very good question and I think that there's a few aspects to it. Because Ruby's a great language. It is terrific at getting things out the door quickly. It is very approachable for folks who are not themselves, software engineers.

It is, there's certainly, it's been around for about as long as Python has, give or take, since the 90s. It's a, it is something that is, you like, well, what can you possibly build with Ruby? And the answer is most websites you have heard of that are giant companies now started off with Ruby. It's true. And in fact, unless it's Twitter, most of those giant websites that you've heard of still have Ruby at their core today. The backend API for Figma, still Ruby. GitHub's backend, front end, middle end, still Ruby. Whatever, Stripe, Square, Airbnb, all those companies still have a pile of Ruby in the middle getting slowly built into an even bigger tower with lots of

other things around it. Yeah, I never liked the argument, by the way, of, well, yeah, okay, fine. Ruby's easy to get started with, but it's not going to scale to hyperscale speeds. It's, do you have any idea how little of what you've actually built will do that, regardless of who you are and what you're doing? Because if you look at anything that is hyperscale, it's been rewritten a bunch of times because what you need to do to launch versus what you need to do to grow to service millions of requests a second.

millions of users a second are very different things. It's an early optimization until you suddenly have to get there. I do sometimes, one of my favorite pet peeves, and this isn't even a Ruby specific thing, is watching companies talk about how they rewrote their system into a new language or a new stack so that they could support 100x more users. And every time I've ever looked at one of those, I've been like, you could have just kept the same language and the same stack and rewritten it using the like architectural changes that you're describing to get the two orders of magnitude

change. And nobody ever really seems to like acknowledge that part. It's always the new language and the new stack that really made it work for the 100x more users. There is a counterpoint that I will make. And I understand that this might not make me a popular man, but that's okay. That ship has sailed a very long time ago. There is an argument to picking languages, not just on the basis of technical capability, because let's face it, you can with most programming languages, read as all of them, if you squeeze it hard enough, you can make blood come out of them to do the thing that you need. It's very often a recruiting story of what language do the engineers you hire know, what language do those engineers you're attempting to recruit

want to work in, and there is a perception that Ruby's star has faded somewhat, and I don't necessarily think that that's fair yeah i mean i i think that from the perspective of people who just want to work with the new hotness that uh ruby is no longer the like you know star new hotness child which i i think it was for a while um i guess i have a small advantage personally in that i got into ruby before rails or any of the reasons to get into Ruby as a new hotness commercial success existed yet. Not very long before, but just enough where I was like, I love this language because of the language itself

and then turned around and I was like, oh, there's all this stuff where people will pay me to use it. That's very cool. Oh, and there's a business model too. Wow, imagine that. Yeah, absolutely. But it's also meant that because my motivations for getting into it in the first place

were not the new hotness motivations, as it has been less of the new hotness my motivations have basically stayed the same. And it is the language that feels the best for me personally to write. Like, I don't know, it matches my brain more successfully than any other language. But as you were pointing out, not all of us are Shopify with an entire legion of, you know, Rust developers writing a jit to squeeze the blood from the stone to get millions of requests a second out of our Ruby web processes.

And to, you know, I got to admit, RV is also not written in Ruby because we want it to be really, really fast. It's written in Rust. And that is part of the thing that you were describing there, right? Like, there are some languages that are constitutionally better suited to some specific use cases. I'm definitely not planning on quickly writing a new web app in Rust anytime soon. But if I'm writing a CLI tool that I want to execute really quickly, I think that Russ is actually a great fit there. And actually, some of the motivation, you know, for many years, we stuck, we put a lot of effort into making Ruby gems and Bunler be written fully in Ruby, partly for deployment reasons, where we just wanted it to work on, you know, if you have a Ruby interpreter, this is just pure Ruby.

that any Ruby interpreter can run. But for the other reason of thinking that it would be easier to get contributors if, you know, the Ruby tool was written completely in Ruby. And I am unfortunately, unfortunately after 10 years, I have to report back that that is not actually a viable strategy because it turns out if you are writing the dependency manager, you can't use all of those dependencies, at least not in the same easy, straightforward way that all normal Ruby developers use them, right? Like, what's a normal Ruby developer?

Somebody, somebody, there aren't any. But if you're working on an app and you have a gem file and you want to do something new, you can say, oh, I know that there's a gem that does this for me. So I will add it to the gem file. and then I will solve the problem using the library. And if you are working on Bunler, you absolutely cannot do that. And so it turns out that the subset of Ruby that we write Bunler and Ruby gems in has continued to get more contorted and weirder and have more and more workarounds for the fact that we can't use any of the popular libraries

that solve these problems in Ruby. And so it turns out that today, effectively, the bundler and ruby gems are written in a interesting dialectic cousin of ruby that does not overlap with the ruby that all of the other ruby developers in the world are using every day in their applications and that makes it a lot harder to get contributors um because you know the contributors show up and they say oh i'll just solve this the same way i would in my everyday application and then we have to say sorry we can't take your PR yeah so i do want to get into this as our last topic you are the CEO at the Spinell Cooperative, you can visit that at Spenell, S-P-I-N-E-L.Coop, which it is a community

nonprofit, which I read, given your open source bona fides, as you don't particularly like money. How do you get people to support this financially from an open source perspective? Totally. So, so this cooperative is basically the latest step in my attempts to figure out how to balance, uh, sort of like community benefit and being as inclusive as possible to people who may not have money, but are interested in participating while also balancing it with that pesky food addiction you have. You have to eat every day as it turns out. It's the, it's the food and housing addiction that it has actually pushed me in the direction of this co-op. I guess to provide a little bit of background for your listeners, about 10 years ago, I started an

an actual bona fide IRS approved 501c6 nonprofit it was called ruby together and we ultimately the the mission of the nonprofit was to figure out funding for kind of like the ruby package management ecosystem right bundler ruby gems all that good stuff i just learned a 501c6 is things like business leagues chambers of commerce real estate boards boards of trades and apparently professional leagues, which I'm guessing it's not that one. It is, it is not that one, although the NHL and some comic cons are very interesting examples of 501cses. They're trade associations. The NHL, the NFL is no longer a, not one of those after being basically dragged for that every year for, you know, 30 years.

Yes, yes, exactly. And so the experience that I had with that type of nonprofit, was that in 2015, when corporations basically had money for free, you know, zero percent interest rate, et cetera, et cetera, you could actually just go to a company and say, hey, I'm running a nonprofit that makes stuff that you use that's good. Will you give me some money? And the companies were like, yeah, sure, money's free. Here's some money.

And around 2018, when money structurally stopped being free, I suddenly had a very, different conversation with all of those same companies where I said, hey, will you give me some money? And they said, wait, so you're saying we could give you some money or we could not give you some money and you would keep doing the same thing and we would keep getting to use the same thing. And I would say, yes. And they would say, great, thanks for stopping by. We'll take that option where we don't give you. But we'll say bad things about you over the drinks we can't afford.

Exactly. And so ultimately, I wasn't able to crack the nut of a nonprofit that is able to pull in enough money to feed my food addiction. And so this structure, in the meantime, while I was figuring this out and while I was concluding that it wasn't going to work for my day job, an example popped up. There is another open source maintainers collective called GOMES, started by Philippo Valsorda for the Go community. And Philippo maintains the Go cryptography libraries and various other useful and important tools that ship with the Go standard library. And he started a collective where what they do is they make open source that is useful to people critically. one, they are not a nonprofit, and two, they make money by offering goods and services to corporations in exchange for money.

What an amazing model. I know, right? And so the primary thing that they do is they offer retainers, where they happen to employ several of the, you know, world-class experts in their respective open-source packages. And there are companies in the world that use those open source packages to build their business. And that makes it valuable and worthwhile for those companies to have that world class expertise on tap to answer questions, solve problems, you know, resolve things that come up. So that is, you know, kind of like the initial model that we are taking for Spinell. We would be actually pretty jazzed to succeed as a Gioomi's style collective where people have companies that need to solve problems related to Ruby, Ruby gems, Bunler, rails, not just rails, but also, you know, stimulus, hotwire, hotwire native, all of these tools that companies are using to build really successful. profitable businesses. Our co-op has at least one person who was either been on the core team of all of those things or actually, you know, created those things in the first place. And so we have the expertise that can solve those problems and answer those questions and help those companies, you know, get out of those gnarly situations in dramatically less time than they would otherwise. And so we're hopeful that rather

than rely on the nonprofit situation where we say, hey, would you, you know, throw some money at us? We can say, hey, would you be interested in saving yourself a bunch of money by paying us to solve your problems so that your actual engineers can build your actual product that makes you actual money. I like that quite a bit. The idea of being able to, you know, do things the smart way. Taking money from people who have it and want to support what you're doing seems like a good model. Yeah. I'm very hopeful that it will appeal. And our initial conversations with a bunch of people have been pretty positive. So we'll see how it goes. But ultimately, the idea is definitely to sort of combine the tooling that I have always wished existed with expertise that actually

saves companies money and appeals to them while making sure that we, have funding to, as you said, feed our ongoing and undisruptible food addictions. Exactly. I wish you well with this, and I definitely want to hear back from you in a few months on how the adoption of RV is gone. If people want to keep a little bit more of a real-time finger on the pulse, where's the best place for them to find you? I spend the most amount of time these days on Blue Sky, where my handle is indirect.io. Uh, I can also, you know, if you, if you need me, uh, my, my homepage at arco.net contains links to all of my various profiles on GitHub, Instagram, Mastodon, uh, LinkedIn, you know, take your, pick your poison. But, uh, yeah, any, any in all of those ways, uh, would be a great way to reach out if you're interested in providing feedback or, uh, hitting us up at Spinell about our expertise. And we will, of course, put links to that in the show notes. Thank you so much for taking

the time to speak with me. I appreciate it. Yeah, absolutely. It's great, as always, to have a conversation with you, Corey. Andre Arco, CEO at Spinell Cooperative. I'm cloud economist, Corey Quinn, and this is screaming in the cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with a comment. But let's be serious. you're not going to have time to write that comment because you're still fixing dependency problems.