Andre: And we are, are not that far along yet. Um, we are, you know, starting with this significant improvement that we thought that we could ship and, 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, we're making sure that everyone doesn't need it, right? The, 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, 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, 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, you know, 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.

Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn, and today we are screaming in the past. Andre Arco, CEO at Spinel Cooperative comes to us from the past, by which I mean the Ruby community. Andre, how have you been?

Andre: Hi Corey. It's great. Great to see you. Um. I, I have been in the past apparently. Um, you know, I, I do spend a lot of time talking to people about how Ruby is dead now or whatever, and, uh, I, what I always tell them is, uh, 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

Corey: Duck Bill. Do you have a horrifying AWS 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 AWS, or just figuring out why it increasingly resembles a phone number, but nobody seems to quite know why that is. To learn more visit. Bill hq.com. Remember, you can't duck the duck bill.

Bill, which my CEO reliably informs me is absolutely not our slogan. I, I like that it's one of those boring things that, you know, runs half the internet as we know it. In fact, I, I, 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.

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 a 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 skunkworks, tell me about rv. What is it?

Andre: Absolutely. So the, the biggest, uh, inspiration for RV is, uh, the, in the PI coming from the Python community. They, you know, historically the Python community has had a lot of options if you wanted to manage dependencies, right?

Like, uh, the Ruby community historically had Ruby Gems and the other options kind of fell by the wayside. And then had Bundler 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 Bundler. 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 Pippen for. Poetry or six other tools that I don't remember the names of off the top of my head.

Corey: And if you disagree with this, you're not listening to the podcast because you're too busy solving dependency problems.

Andre: Right, exactly. And so UV is super interesting to me because as.

A, you know, a, uh, package management enthusiast. Uh, I, 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.

Corey: I do wanna push back on that a smidgen, because I still remember and have the scars to prove it from the RVM versus RBN War wars. Where, okay, how are we gonna handle all the languages on our developer laptops? I'm just gonna overwrite the system. Ruby seems like a bad plan.

Andre: Oh, man. Um, I, I do have to say as, as the maintainer of Bundler during that era.

Uh, I, I actually hate all of the environment dependency version management tools because they would all get in fights with Bundler, 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, uh, C Ruby, which sets some shell variables and does nothing else whatsoever.

Stupid shell tricks every time. Exactly. So, uh, so over in the Python world, UV has over the last year become this kind of like, uh, al 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, and using UV myself. I was blown away.

Corey: It's amazing. It, I dunno how it does with magic that it does, but it is super fast. It doesn't stomp other things you have going on. You type uv, vn, 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.

Uh, uv, uh, PIP install, you know, 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, it is life changing. You've, and they're like, oh, well I wanna 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 A 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.

Andre: Right, right. Absolutely. Uh, and, and so as a, 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. Uh, it's not making my life any better now.

Corey: Yeah, it feels like docker containers were the only way to handle Ruby projects because everything was so specific as far as how it worked, that even with some of the, 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.

Andre: Yes, yes. And that, 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, 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

Corey: and it doesn't clean up after itself.

Like on, on my desktop right here. If I. Fire up a terminal on the right hand prompt. Uh, I believe that's what PS two, whatever it's is, uh, the, yeah, where it winds up, uh, listing out that I'm using Ruby version 3.0 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, uh, we know who I'm speaking of when I say that. Uh, not you. To be clear, uh, there are, uh, it, 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 breakage has come from.

It's just, it's one of the great mysteries.

Andre: Definitely one of the great mysteries,

Corey: whereas Python is decent. Python cleans

Andre: up after its mess. Definitely. I, I definitely feel like UV is contributing to this, so,

Corey: well, I, I still remember back in the CentOS five days when I was up in support people on IRC and whatnot.

'cause I was a, uh. My minor part of the project and people would say, okay, great. So I've installed, I, 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've 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. Uh, it has always been spectacular at, I have an idea and I wanna build it. I'm going to reach for something that gets me, uh, from start to finish, largely with batteries included.

And Ruby has been the. Thing. Uh, 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 wanna say 1.8 0.3 into something modern, uh, 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 BlackRock, 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 it ever got fixed in that context.

Andre: Ruby. Ruby upgrade satisfactorily resolved. You know, great work.

Corey: This was such a monolith, 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, I used to be deep in the puppet world and had enough problems with the way they did config management. That alright? I was one of the early developers behind SaltStack and, good. This'll fix it. And nope, you can give someone the latest generation shiny lap. Top and they wonder about the bad hammer you just sold them when they hold it wrong.

Andre: Oh man, that, that really brings back memories. Uh, I, I was friends with the, uh, the puppet crew back in the day of whatever that was, the mid to late two thousands as we were all doing fancy ruby things. And I, I mean, I gotta say it was a big step up from, we have a shell script that we run anytime we stand up a new server.

Corey: Chef kind of went too far in the ruby direction from my perspective at the time because the, I remember that was the one, uh, 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 CIS admins 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, 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 gonna 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.

Andre: 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.

Uh, 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, 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, uh, you know, fit into exactly this weird plugin 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.

Corey: 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 tar.

They went with the 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.

You, 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 the biggest problem in many cases with the config management stuff that I learned, and this is a truism programming everywhere. You can be really clever with these things.

The problem is, 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.

Andre: Yep. Absolutely. Absolutely. That is definitely one of the, uh, 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. Um, and so our, our, uh, you know, again, inspired by uv, the ultimate goal is to fully kind of like encompass the entire range of anything that 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, you know, like 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. Uh, but you just wanna run one command and have it all actually happen for you. So that's, that's kind of like the, the UV inspired vision that we're aiming for with rv.

Uh, and then today, kind of like as our, our first effort demonstration of what. Towards what we think is possible. Uh, we've shipped just the initial ruby version management part of the tool. Uh, 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, R-V-M-R-B-N-C, Ruby, Ruby build, Ruby, install, uh, all those things, they all.

Expect you to download a source tar ball for whatever Ruby version you want, and then start to compile it yourself on your machine. And so installing Ruby, you know, 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,

Corey: or raspberry pie, which we're still waiting for that to finish, I'll let you know and send a postcard if we ever get there.

Andre: Sounds amazing. Um, so the, 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 makes sure that there's a ruby that works for the platforms that we support, which so far is recent Mac os within the last couple of Y two or three years and 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 prefilled binaries install a lot faster than, you know, source tar balls that have to run, configure, and then make and then make install. Yeah. My

Corey: philosophy on this, and this is controversial, I know this, but I, 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 I.

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 gonna sit here with bailing wire and popsicle sticks trying to keep the thing on life support.

I, I find that I can move on. Counterpoint. I don't build anything that has a widespread install base. So do you agree, disagree? Like how, how do you think about that?

Andre: Coming from the, the position of being on the Bundler 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, uh, I don't know. Like it should do a licensing concern.

Corey: Yeah. Yeah. And on some level, like I, that's the beautiful thing about not having a large install base. I can take a professional support policy, eh, fuck them kids, but that's not something you can do at scale most of the time.

Andre: Yeah. So, 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 hope, 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, 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 Lifeing policy. And I 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.

Corey: Yeah, on some level, I, I have to think, and please, I, 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?

Andre: 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 Mac Os was end of life more than five years ago.

Corey: It almost feels like they'd be doing a better service

Andre: 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 Mac os that, uh, 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.

Corey: That sounds, that sounds painful,

Andre: but, uh, the, the upside there of system, Ruby finally being so old that it's extremely obvious you should not be using it, is that we basically expect you to need, you know, some kind of of installed Ruby, which we plan to provide in a very fast and easy to use package.

Corey: 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 doc bill hq.com. So a, 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. 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, 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, it feels like that's, that's not realistic.

Andre: That, that is definitely not realistic. Uh, and and I, I, I have to admit, like we, 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, are not that far along yet. Um, we are, you know, starting with this significant improvement that we thought that we could ship and, 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, we're making sure that everyone doesn't need it, right? The, 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, 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, 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, you know, 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.

Corey: Yeah, I, I do have to ask, uh, 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 PyTorch and the rest and all of the other AI things, it seems like that is the defacto thing that people go for. I always liked it because it's pseudo code.

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?

Andre: That's a very, it's a very good question, and I think that there's a few aspects to it.

Corey: It really is 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 nineties. 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 our giant companies now started off with Ruby.

Andre: It's true. Um, and, and in fact, uh, unless, 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, like all those companies still have.

A pile of ruby in the middle getting, you know, slowly built into an even bigger tower with lots of other things around it. Yeah, I, I never liked the argument, by the way

Corey: of, well, yeah, okay, fine. Ruby's easy to get started with, but it's not gonna 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, uh, millions of requests a second. Uh, more millions of users a second are very different things. It, it's an early optimization until you suddenly have to get there.

Andre: I, I do sometimes. One of, 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 a hundred x 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 in 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 a hundred x more users.

Corey: 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.

Uh. The, 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, the 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. Uh. 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.

Andre: 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, 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, 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, there's a business model too. Wow. Imagine that. Yeah, absolutely. Uh, but it's, 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.

Uh, like, I don't know, it matches my brain more successfully than any other language. But as, as you were pointing out, uh, not all of us are Shopify with an entire legion of, you know, rust developers writing a ji to, uh, squeeze the blood from the stone to get, uh, millions of, of requests a second out of our Ruby web processes.

And, uh. And to, you know, I, I gotta 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, 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, uh, if I'm writing a CLI tool that I want to execute really quickly, uh, I think, I think that Rust is actually a, a great fit there and, and actually some of the motivation, you know, for, for many years. We stuck, we put a lot of effort into making Ruby Gems and Bundler 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 code 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, I am unfortunately, unfortunately, after 10 years, I have to report back that that is not actually a viable strategy because it, it turns out if you are writing the dependency manager, you can.

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? Uh, somebody, somebody, there aren't any. Um, but, uh, 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 Bundler, you absolutely cannot do that. And so it turns out. That the subset of Ruby that we write, bundler 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, it turns out that today, effectively, 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, just solve this the same way I would my every day application. And then we have to say, sorry, we can't take your pr.

Corey: Yeah. So I, I do wanna get into this as our last topic. You are the CEO at the Spinel Cooperative. Uh, you can visit that at spinel, S-P-I-N-E l.coop, uh, which it is a community nonprofit, which I read.

Given your open source bonafides as you don't particularly like money, uh, how do you get people to support this financially from an open source perspective?

Andre: Totally. So, so this, 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,

Corey: while also balancing it with that pesky food addiction.

You have, you have to eat

Andre: 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 bonafide IRS approved 5 0 1 C six 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? Butler, Ruby Gems, all that good stuff.

Corey: I just learned. A 5 0 1 C six is things like business leagues, chambers of Commerce, real estate boards, boards of trades, and apparently professional football leagues, which I'm guessing it's not that one.

Andre: It is, it is not that one. Although the NHL and some comic cons are very interesting examples of 5 0 1 C six s, they're trade associations.

Corey: The NHL, the NFL is no longer a, not one of those after being basically dragged for that every year for, you know, 30.

Andre: Yes. Yes. Uh, exactly. Um, and so the, the experience that I had with that type of nonprofit was that in 2015 when, uh, when corporations.

Basically had money for free, you know, uh, 0% interest rate, et cetera, et cetera. Uh, 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, uh, 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 get dirty, but we'll say bad things about you over the drinks we can't afford. Exactly. Uh, and so ultimately I wasn't able to crack the nut of a nonprofit that is able to, you know, pull in enough money to.

Feed my food addiction. And so this, this structure in, in the meantime, while I was figuring this out and while I was concluding that it wasn't gonna work for my day job, uh, a an an example popped up, uh, there is, there is another open source maintainers collective called the Geomi. Uh, started by, uh, Philippo Valora for the Go community.

Um, and, uh, Filippo maintains the Go Cryptography libraries and various other useful and important tools that ship with the Go Standard Library. And, uh, he, 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, 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 spinel, we, we would be actually pretty jazzed to succeed as a Geomi style, you know, collective, where people, you know, have companies that need to solve problems related to Ruby, Ruby Gems, bundler Rails, uh.

Uh, 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. Uh, 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.

Corey: I like that quite a bit. The idea of being able to, you know, do things the smart way. It, it taking money from people who have it and wanna support what you're doing.

Seems like a good model.

Andre: Yeah. Uh, I'm, I'm very hopeful that, uh, that it will appeal. And, 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, 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, uh, feed our ongoing and SRT food addictions.

Corey: Exactly. I, I wish you well with this, and I definitely want to hear from you, feedback from you in a few months on how the adoption of RV is gone.

I, if people want to keep a little bit more of a real time finger on the pulse, where's the best time, where's the best place for them to find you?

Andre: Uh, 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, if you need me, uh, my, my homepage@arco.net contains links to all of my various profiles on GitHub, Instagram, mask it on, uh, LinkedIn, you know, take your, pick your poison, but, uh.

Yeah, any, any and 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 Spinel about our expertise.

Corey: 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.

Andre: Yeah, absolutely.

It's great as always to have a conversation with you, Corey.

Corey: Andre Arco, CEO at Spinel 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 gonna have time to write that comment 'cause you're still fixing dependency problems.