The Spinel Cooperative Blog

rv 0.6.0 is out, with `ruby-dev`, `rvx @namespaces`, and more

Wed, 22 Jul 2026 20:00:00 +0000

We’re running a bit behind on announcements, so here’s our post about releasing rv version 0.6.

The headline features added to version 0.6 are daily releases of ruby-dev, adding namespace support to rvx, and supporting gem servers that require authentication, for projects that use Sidekiq Pro, Avo Pro, and the like. We also added a self-update command.

`ruby-dev` daily releases

The daily releases of ruby-dev are especially helpful if you want to test your application against the latest Ruby version that’s currently in development — you don’t have to download Ruby source code, or compile it, you can simply install a build of Ruby from git that’s less than a day old, any time you want, by running rv ruby install dev. We run nightly builds of Ruby and publish them to GitHub Releases, where anyone using rv can try them out by spending a second or two installing. No more recompiling Ruby every time you want to try the latest — just try it.

rvx namespaces

The second change helps anyone trying to use rvx to run CLI tools from gems. Before, it was possible to run rvx gist and everything would work as expected. However, gem servers with namespaces, like gem.coop, didn’t have a way to instantly run gems from a namespace. Now, it’s as easy as rvx @indirect/card to immediately run the CLI tool from the gem named card in the gem.coop namespace @indirect.

server authentication support

On the gem installation side of things, we built support for server authentication. That means rv can now install Gemfiles that use the private gem servers for Sidekiq Pro and Avo Pro, or any Gemfile that uses an entirely private authenticated gem server.

`rv self-update`

Finally, we added a self-update command. Many of our users install using Homebrew, and get updates automatically as part of Homebrew’s updating system. For everyone else installing rv directly, the built-in self-update means that you don’t have to re-run the installer every time there’s a new version. Just run rv selfupdate to get the latest version, once you’ve installed 0.6.0 or higher at least once.

more version 6.0 updates

This version also includes dozens of bugfixes, and several significant compatibility improvements when working with Bundler configuration and lockfiles. Check out the changelog for the full list of all 43 changes.

We’re continuing our work on installing full Gemfiles, as well as adding additional features to make rv the best way to use Ruby and gems. If you’d like to help test our changes, give us feedback about how rv could be better, or even help us implement new features, we’d love to have your help. Head over to rv.dev to get started, and we’ll see you soon!

Factory Frustrations: Optimized for Isolation

Wed, 15 Jul 2026 00:00:00 +0000

When Rails developers write tests, part of that process is to arrange test data in a certain shape, in order to make assertions about the database state and domain. For example: does this active account have access to this feature they’re supposed to? Do we correctly ensure a cancelled account does not? And so on.

Rails’ default approach to supplying test data is database fixtures written in YAML. With fixtures, you manually write out data and relationships in N files for N associations. Fixtures prioritize speed of running tests, but many Rails developers, myself included, find the approach cumbersome and clunky to work with. The tradeoff often doesn’t feel worth the cost.

A popular alternative to fixtures is factories, primarily via the FactoryBot gem. With factories you don’t focus so much on relationships but just the object data for each record. Factories are easier to write than fixtures: there’s just less to think about to get started. It’s easier with factories to test your codebase, particularly during the greenfield phase.

However, as the app grows and the codebase has hundreds of models, controllers and test files, the benefits of factories can start to hinder you more than help. In my experience, test suites using factories become slow and confusing, with few affordances for developing shared language within teams.

In this series, I’ll go over issues I’ve seen with factory-heavy test suites and what I find difficult about the constraints they impose. It’s based on my decade of using factories at jobs and in client codebases.

Your Test Setup’s Topology

Factories have a local-first approach where each test case is isolated, and any test data scenario is set up from scratch each time. It’s super easy to write user = create(:user) when you need a user for your test, but now that test has to wait for everything about a user to be created from scratch.

On top of the speed issues, this strategy makes your test data setup scattershot and spread across many test files. Within each test file, much of the setup is overall similar but slightly different. This makes it really difficult to spot what’s important or what’s just incidental.

That adds cognitive load when you’re trying to update a test file. You have to learn the bespoke setup pretty much from scratch each time you revisit the file. Moreover, what you learn in one file doesn’t apply to another because it has its own slightly different setup.

Let’s contrast with the fixtures approach. With fixtures we’d have a base set of test data that’s seeded once ahead of time, while still allowing for local modifications as needed. It’s annoying to visit a separate `users.yml` file every time you need to make an adjustment to the base user, but you can write `user = users(:one)` in your test and have a user without spending any time in the test on creating that user.

While fixtures are more difficult at first, over time you recoup that investment because you’re working with named data sets. I have my own issues with fixtures, but we don’t have time to go into that today. I’ll explore more of the ways fixtures can help or hurt you in a later post.

What you can do

Rather than trap yourself with a separate factory that has to run for every test, or YAML files that might fail validations or require editing multiple files for every association, you can get the best of both worlds by building fixtures once in regular Ruby code.

This strategy has been gaining mindshare lately in the Ruby community, with multiple gems now implementing this pattern. My own gem Oaken was born directly from the pains of working with fixtures and factories after they have grown beyond what’s manageable.

Using Oaken, you get a factory-like interface for creating your records, but you get fixture-like speed when running your tests, since the records are seeded once ahead of time exactly like fixtures.

# db/seeds/accounts/spinel.rb  
account = accounts.create :spinel, name: “Spinel Cooperative”  
users.admin.create :spinel_kasper, name: “Kasper”, accounts: [account]

# test/models/user_test.rb  
def test_user_name  
  assert_equal “Kasper”, users.spinel_kasper.name  
end

All the speed of fixtures, all the ease of factories. Easy.

I have a lot more thoughts about both factories and fixtures, based on my work with some of the most famous Rails apps. There wasn’t room to fit everything today, but I’ll be back soon with more.

Meet Spinel

Thu, 02 Jul 2026 21:26:13 -0700

Welcome! This is the blog of the Spinel Cooperative, and after a very busy season of new client work, we’ve finally managed to write the very first blog post we put on our todo list: this post. What is Spinel? Who is Spinel? Why is Spinel? Read on to finally receive the answers to all these and questions and more.

What is Spinel?

Let’s start with the what (and the who). Spinel is a group of software developers and open source maintainers – including founders of the Rails and Bundler core teams – who have created a worker-owned cooperative. When I needed to find new work last year, the idea for Spinel grew from my passion for making software development a good experience for every developer (including myself!).

We all deserve to experience quality, speed, and joy both in our tools and on our teams. It’s an amazing feeling to work with a fast, reliable test suite and tools that help you instead of getting in your way. It has been an amazing experience to work with other developers that I’ve known and looked up to for many years, as we bring these values to life in ways that are as satisfying for us as they are for our clients.

What is a worker-owned cooperative?

A cooperative works mostly like a regular company, but adds some rules around decision-making and profits. In a worker-owner cooperative, the people doing the work also run the company, make the decisions, and share the profits. In company decision-making, each member gets one vote. When there are profits, each member gets a share based on how much they contributed to the work.

co-ops and open source projects have a lot in common.

Although cooperatives are very non-traditional in the tech industry, their structure is surprisingly similar to how healthy and successful open source projects work. Most open source projects have a membership system, with some non-member contributors, and a core team of peers making decisions and working together. We may write a post in the future about what working in an OSS-developer-owned co-op has been like so far. Let us know if you’re interested in hearing more!

Why create Spinel?

Across 20 years of working with Ruby and Rails professionally, I’ve spent years as a frontend developer, a backend developer, and an infrastructure engineer, but I’ve always had the strongest feelings about developer tools. Over and over again, I’ve seen the way developer tools impact the quality of developers’ lives and projects, and exactly how rare it is for devs to find useful, robust tools that help them do their jobs well.

It’s the difference between feeling like you have to clear a path through the dense jungle of a clunky, legacy codebase, fighting you every step of the way – or hiking a prepared trail through your project, with the right equipment. As software developers, we have the skills and ability to make software that is more reliable, more helpful, more useful, and better. We should do that!

the business reality of open source work led us here.

My open source work, from helping ship Bundler 1.0 in 2010, to working on RubyGems itself and the RubyGems.org service, has always been motivated by improving the tools we use every day. While well-intentioned, corporate support for maintaining open source is often scattershot and not sustained, leading to cycles of burnout and contributor turnover.

When I created Ruby Together in 2015 in an attempt to solve those issues, we aimed to level up from “volunteers mostly keep things working” to “professionals who are giving a boost to every single Ruby developer on earth”. Many community members were supportive, but the overall model really only worked while tech companies had tons of cash floating around. Any time budgets tightened, “optional” support for open source was one of the first things to be cut. Other people will keep supporting it, right?

With that reality in mind, we set out to find a different model, where we can use our combined decades of expertise to offer support, advice and skills—like speeding up your development cycle from ticket to production—to developer teams and the engineers who run them.

Kicking off the new, exciting project rv at the same time meant a natural source of inspiration for how we might make this work sustainable was Astral, the company behind uv for Python. Another major inspiration was Filippo Valsorda and his company Geomys. They are a great demonstration of what a company of professional open source maintainers could look like, providing major value to both their clients and the community, at the same time.

How does Spinel work?

So, with that background in mind, what does Spinel actually do? Our goal is to make it easier to be a software developer, especially if you use Ruby. Right now, we have two main approaches to that work: we build open source tools, and we make client teams more productive.

Our open source work is aimed at every Ruby developer, whether they are a student, a startup, or a Fortune 500 company. Our client work is especially valuable for companies between 50 and 500 engineers, where adding developers dedicated to productivity creates a multiplier for the productivity of every other developer at the company.

The tools we’re building

If you’ve ever worked on a Rails app in the past, you’ve used our work, including many parts of Rails itself, RubyGems, Bundler, Hotwire, Stimulus, Trix, and others. Our current projects are all based on and motivated by that past work, including rv to manage Ruby versions and gems, oaken to simplify and speed up seed data for tests and development, and brat for writing tests that can run directly in any POSIX shell without a single dependency. We have tons of ideas about how we could make software development easier, faster, and more productive, and we think the open source model is awesome because those tools become community projects for community benefit.

How we can support your team

The other major thing we are doing at Spinel is taking on clients and working with them to make their software development teams more productive. The exact form the work takes can vary a lot depending on the client, but the two versions we do the most are retainers and projects.

When we’re on a retainer, we join your company Slack to answer questions, brainstorm solutions, and investigate confusing behavior. Any time you need to architect new features, solve tricky bugs, or hear about the tradeoffs between different options, we’ve got you. Over the last 20 years, we’ve probably tried most of the options at least once or twice, and we can tell you what went well, what went badly, and why you would choose one option over another.

When we’re on a project, we jump in directly to your codebase, and smooth down all the rough edges and snags of a problem that you’re having until it’s gone. Struggling with a huge, slow test suite? We have optimized more legacy test suites than you can count. Features taking too long to ship? We know exactly how to shrink the nested loops of editing, testing, and deploying your codebase until it’s a breeze.

If your company could use that kind of help, we would love to chat. You can drop us a note or schedule an intro chat to hear more.

If you you’re interested in our open source projects, we’d love to have you as a contributor! We’d also be very excited if you recommended us to your boss — our client work helps sustain all the other work we do. Either way, thanks for checking us out!

`rv` 0.5: CLI tools + Windows

Wed, 11 Feb 2026 11:41:00 -0800

For almost 6 months now, rv has been installing Ruby versions in under a second, thanks to our precompiled Rubies. Today, we’re releasing rv 0.5, which brings that same focus on speed to installing Ruby on Windows, running scripts with rv run, and running and installing all sorts of gems and binaries via rvx and the rv tool commands.

The new features in rv version 0.5 are:

Windows support.
New subcommand: rv run
New command: rvx (aka rv tool run)
New subcommand family: rv tool
New subcommand: rv selfupdate

Let’s look at each of these in more detail.

Windows support

Thanks to the solid Windows support in the Rust language, the rv tool itself has always compiled on Windows, but the rv-ruby project doesn’t create any precompiled Rubies for Windows (at least, not yet!) Without precompiled Windows Rubies, there wasn’t much point in making rv available on Windows. New contributor @case changed all that, by adding support for the Windows Ruby binaries created by the RubyInstaller2 project. Now that rv can install Ruby on Windows, it finally makes sense to release rv for Windows.

To make installing rv on Windows easy, we’ve added a PowerShell one-line installer script to the installation instructions for every release. Check out our 0.5 release for Windows right here!

One important caveat: if you use PowerShell, there is already a built-in rv command for removing environment variables. For anyone who wants to leave the existing PowerShell command in place, we offer two other options: running rv.exe, or by running our Windows-specific binary, named rvw. Either command will get you the same fast Ruby and gem tools, without conflicting with the PowerShell alias.

Windows support has historically been a tricky situation for Bundler, so if you run into any problems or unexpected behavior, definitely let us know!

`rv run`

With a big boost from new contributor phromo, we now have a top-level rv run command. What can you run with rv run? Anything! Well, anything that’s in your PATH or any filename. That opens up a few great new use-cases.

You can use rv run irb to immediately get an interactive Ruby prompt in under a second — even if Ruby wasn’t previously installed (installing Ruby via rv is fast). If you have a Ruby script, you can use rv run myscript.rb, and we’ll install Ruby and run your script with it.

You can even use rv to make your Ruby scripts executable, whether or not Ruby is already installed! Just put #!/usr/bin/env rv run ruby as your shebang in any script, and it’ll become executable via an rv-provided Ruby.

We’re excited to see what everyone comes up with, now that it’s easier to run Ruby scripts and commands than ever before.

`rvx`

We’ve added a new command, rvx, which runs any command from a Ruby gem (we call these global gem-based CLIs “tools”, the same name used by uv). You can run rvx rubocop to run the latest version of rubocop, or rvx rubocop@1.82 for a specific version. Give it a try — it’s very fast! The first time rvx runs a tool, it’ll download all required gems (in parallel), install them (in parallel), then run the tool. If you rerun the tool again, it’ll reuse all the cached downloads and installations, so it’ll execute near-instantly. Here’s an example:

By default, rvx looks for an executable and a gem with the same name (e.g. rvx nokogiri runs the nokogiri binary provided by the nokogiri gem). If you wanted to instead run the racc binary that nokogiri provides, just run rvx --from nokogiri racc.

For almost 6 months now, rv has been using precompiled Rubies to install your Ruby versions in under a second. We hope we can bring that same focus on speed to downloading, installing and running gems via rvx. We’re very grateful to the Rust ecosystem, which lets us use awesome crates like tokio and rayon to download and install gems in parallel. We hope the rest of the Ruby ecosystem embraces parallelization — please talk to us if you’d like to collaborate on speeding up other Ruby workflows!

`rv tool`

Under the hood, rvx is just an alias for rv tool run. When you run a tool, it’ll be downloaded and installed if you don’t already have it. You can manually install, uninstall and list your tools with rv tool install, rv tool list and rv tool uninstall.

`rv selfupdate`

Thanks to new contributor duckinator, you can update rv using itself: rv selfupdate should Just Work. This is the first release with an rv selfupdate command, so to upgrade from 0.4 to 0.5 you’ll have to do it the old-fashioned way, by running the installer command from the releases page. But when we release 0.5.1, you’ll be able to run rv selfupdate to easily upgrade.

In addition to these headlining features, we saw dozens of smaller improvements, fixes, optimizations, and generally making things work better and faster. Thank you to all of our contributors!

Try out rv 0.5 today by running brew install rv, or using the one-line installer script.

Announcing `rv clean-install`

Tue, 06 Jan 2026 09:37:00 +0700

As part of our quest to build a fast Ruby project tool, we’ve been hard at work on the next step of project management: installing gems. As we’ve learned over the last 15 years of working on Bundler and RubyGems, package managers are really complicated! It’s too much to try to copy all of rbenv, and ruby-build, and RubyGems, and Bundler, all at the same time.

Since we can’t ship everything at once, we spent some time discussing the first project management feature we should add after Ruby versions. Inspired by npm and orogene, we decided to build clean-install. Today, we’re releasing the rv clean-install command as part of rv version 0.4.

So, what is a clean install? In this case, clean means “from a clean slate”. You can use rv ci to install the packages your project needs after a fresh checkout, or before running your tests in CI. It’s useful by itself, and it’s also concrete step towards managing a project and its dependencies.

Even better, it lays a lot of the groundwork for future gem management functionality, including downloading, caching, and unpacking gems, compiling native gem extensions, and providing libraries that can be loaded by Bundler at runtime.

While we don’t (yet!) handle adding, removing, or updating gem versions, we’re extremely proud of the progress that we’ve made, and we’re looking forward to improving rv based on your feedback.

Try running brew install rv; rv clean-install today, and see how it goes. Is it fast? Slow? Are there errors? What do you want to see next? Let us know what you think.

Why are `exec` and `run` so confusing?

Wed, 10 Dec 2025 17:34:16 -0800

While working on rv, there’s a specific question that has come up over and over again, in many different forms. In the simplest possible form, it boils down to:

What is the difference between rv exec and rv run? Why have both?

We haven’t finished implementing either rv exec or rv run yet, but every time one or the other comes up in a conversation, everything instantly becomes more confusing.

This post will summarize the history of exec and run in Bundler, npm, Cargo, and uv. Once we have the history laid out, we can take a look at what we plan to do in rv, and you can give us your feedback.

Bundler `exec`

Bundler manages project-specific packages, but not generally available “global” commands. Project-specific packages installed with Bundler can include their own commands.

While working on Bundler 1.0, we needed a standard way to do something new: run commands completely scoped inside a project, rather than scoped to the entire Ruby installation on the current machine. We tried both a wrapper command (bundle exec COMMAND) and generating dedicated scripts in the project’s bin/ directory. With binstubs, you could run bin/rake to get the project rake, and rake to get the global rake.

I personally preferred the binstub approach, but it was bundle exec that ultimately became the popular way to use commands inside your project. My theory is that it won because you can use it to run any command, including ruby, or bash, or anything else you want.

RubyGems `exec`

Somewhat confusingly (inspired by the npm exec command explained below) there is a separate gem exec command that is not related to Bundler and instead installs and runs a command from a package. RubyGems only manages global packages and commands, so gem exec is more of a convenience to make it easier to globally install and run a package with just one command.

npm `run` and `exec`

npm manages both project-specific and global packages, and can install any package so its commands are available either only within a project or globally across every project that uses the same version of Node.

The project-focused design of npm expects commands from project packages to be run by first adding the command to package.json in the script section, and the run via npm run SCRIPT. This is even more inconvenient than Bundler’s binstubs, and so I think there was pent-up demand to be able to “just run a command directly”. That was eventually provided by npm exec and its alias npx.

The npx COMMAND setup makes it very easy to run any command, whether the package is in the local project or not, whether a script is set up or not, and even whether the package is installed at all or not. Simply running the command is enough to install the needed package and run its command.

It’s especially helpful to have npx available when you need to create a new project by running an npm package, since it’s a huge pain to create a project and install a package and set up a script just so you can run the package to overwrite your project. The most popular example of this I am aware of is npx create-react-app, but it’s a popular idiom for many packages that contain commands.

Cargo `run` and `install`

Cargo is simalarly a package manager, but unlike Ruby and Node, project-level packages do not include commands, and package commands are installed globally. Library packages are added to a project with cargo add, while command packages are installed globally with cargo install. Once a package is installed globally, it can simply be available on your $PATH, and Cargo no longer has to be involved in running it.

The cargo run command is extremely limited in scope, and only allows you to build and run a binary created by your own project – it does not work to run commands from packages, either project-local or global.

uv `exec` and `run`

In uv, the exec command seems to be most strongly inspired by npm exec, including having its own short alias of uvx. The uv exec command is exclusively for running commands directly from packages, automatically installing them if necessary. To give an example, that means you can use uv exec github-backup to install and run the github-backup command from the Python package named github-backup, whether or not that packge is included in your current project.

Conversely, the uv run command is closer to bundle exec: it installs and configures Python, installs project packages if inside a project, and then runs a command from $PATH or runs a file. That means uv run can be used for both uv run bash to get a shell with only your project’s Python and packages, and can also be used as uv run myscript.py to run a script file directly.

Summary

bundle exec runs:

commands created by your package
commands from project packages (like bundle exec rails)
commands from $PATH (like bundle exec bash)
scripts from files (like bundle exec ./myscript.rb)

npm run runs:

project-defined script commands (like npm run my-project-script), which can call:
- commands from project packages (like generate_pdf.js)
- commands from $PATH (like bash)
- scripts from files (like ./myscript.js)

npm exec installs and runs:

non-project commands from any package (like npx create-react app)

cargo run builds and runs:

commands created by your package

uv run installs python and any project packages, then runs:

commands from project packages (like uv run datasette)
commands from $PATH (like uv run python)
scripts from files (like uv run ./myscript.py)
project-defined script commands (like uv run my-project-script), which can call:
- commands from project packages (like github-backup)
- commands from $PATH (like bash)
- scripts from files (like ./myscript.py)

uv exec installs python and the named package, then runs:

non-project commands from any package (like uv exec github-backup)

The question for `rv`

With all of that background now set up, what should rv exec do? What should rv run do?

To be the most like Bundler, we should use rv exec to run commands for a project. To be the most like npm and uv, we should use rv exec to install and run a single package with a command.

Today, we’re leaning towards an option that includes all of the useful functionality from every command above, and aligns Ruby tooling with JS tooling and Python tooling:

rv run installs ruby and any project packages, then runs:

commands from project packages (like rv run rspec)
commands from $PATH (like rv run bash)
scripts from files (like rv run ./myscript.rb)
project-defined script commands (like rv run my-project-script), which can call:
- commands from project packages (like rspec)
- commands from $PATH (like bash)
- scripts from files (like ./myscript.rb)

rv exec installs ruby and the named package, then runs:

non-project commands from any package (like rv exec rails)

If we try to combine those two commands into one command, we quickly run into the ambiguity that has been so frustrating to handle in Bundler for all of these years: if you rv run rake, do you want the global rake package? Or do you want the project-local rake package? How can we know which you want?

In my opinion, uv solves this relatively elegantly by having uvx always run a package globally, and uvr always run a package locally inside the current project, if one exists.

What do you think? Let us know in the GitHub discussion about this post.

rv 0.3.0 released

Mon, 08 Dec 2025 01:24:54 -0800

We’re excited to announce rv version 0.3.0 has been released.

Highlights include support for Ruby versions 3.2.x, 3.5.0-preview1, and 4.0.0-preview2, as well as automatic Ruby installation during the rv ruby run command. We also added support for .tool-versions files, which are also used by the asdf and mise tools.

Just for fun, we also added the oldest version of Ruby that has released source code: 0.49! If you’d like to try it, there are some example scripts available in the repo where @sampersand modernized the code.

Make ruby pin reject invalid versions (https://github.com/spinel-coop/rv/pull/223, @deivid-rodriguez)
Test against Arch Linux (https://github.com/spinel-coop/rv/pull/193, @case)
Support Ruby preview releases (https://github.com/spinel-coop/rv/pull/201, @indirect)
Support Ruby 0.49 (https://github.com/spinel-coop/rv/pull/189, @indirect)
Install Ruby during rv ruby run (https://github.com/spinel-coop/rv/pull/182, @adamchalmers)
Sign macOS binaries (https://github.com/spinel-coop/rv/pull/179, @indirect)
Support SOCKS Proxy configuration (https://github.com/spinel-coop/rv/pull/175, @indirect)
Support .tool-versions file for Ruby version (https://github.com/spinel-coop/rv/pull/172, @indirect)
Add configuration for Nushell (https://github.com/spinel-coop/rv/pull/170, @indirect)
Fix fish auto-switch when shell launches (https://github.com/spinel-coop/rv/pull/165, @Mado13)
Add rv cache prune (https://github.com/spinel-coop/rv/pull/164, @savechina)
Add rv ruby uninstall (https://github.com/spinel-coop/rv/pull/153, @savechina)
Add rv ruby dir (https://github.com/spinel-coop/rv/pull/150, @savechina)

Special thanks to our new contributors @savechina, @Mado13, @case, and @deivid-rodriguez!

Install rv by running brew install rv, or directly from releases on GitHub.

Rails Performance from Spinel

Sun, 01 Jan 2023 08:00:00 -0700

We make Rails applications perform.

Faster Ruby & Rails applications

Optimize application boot times, shrinking the development feedback loop to make everyday work faster
Profile and target inefficient database queries, finding optimal indexes, schema adjustments, and other improvements
Reduce memory and CPU usage to deliver faster responses, with fewer outliers
Scale your app to 10x or 100x by systematically finding and resolving bottlenecks
Provide the plugins, extensions, and libraries to solve problems quickly, without rebuilding the world from scratch
Work with your team to offer documentation, training, and workshops on performance gotchas and patterns for speed

Faster development cycles

Speed up CI and testing configuration, to deliver results faster and with higher confidence in what your team has built
Build faster CD and deployment automation, to get code into production more frequently, and more reliably
Analyze development cycle time, optimizing the entire process from request to PR to going live in production
Design partnership on developer tooling, ensuring the tools we create and maintain address the needs of your developers
Fully custom development tools, processes, and documentation to multiply your engineering team’s work output

For less than the cost of one fully-loaded engineer, we can start multiplying the output of every engineer on your team. Email us to get started today.

Our background

Our team has spent years building the tools you use every day, and either created or has been on the core team of the open source projects behind every Ruby business:

rails, the Ruby web application framework
hotwire (turbo + stimulus), the default front-end framework for Rails
hotwire native, a web-first framework for building native mobile apps
trix, the rich-text WYSIWYG content editor for Rails
kredis, higher-level data structures built on redis
rbenv + ruby-build, the original Ruby version management tools
rubygems, the Ruby standard library package manager
bundler, the Ruby standard library dependency manager
rubygems.org, the Ruby language package registry

Our newest tool is rv, the next-generation Ruby version and project manager.

Our Team

André Arko helped create the Ruby dependency manager Bundler in 2009 and led the team of maintainers working on Bundler and RubyGems.org from 2014 to 2025. As a fan of the Ruby language, he wrote The Ruby Way, 3rd Edition for Addison-Wesley. Outside of open source, he has spent the last 15 years consulting on tools and processes to make software teams safer, faster, and more productive.

Kasper Timm Hansen was on the Rails core team from 2016-2022, is the top 14th contributor, authored major features and reviewed & merged thousands of contributor pull requests. These days Kasper’s focus is on helping teams upskill, as well as Domain Modeling for Rails apps — including inventing the riffing technique to do so. Kasper still pushes Rails forward with gems like Oaken, ActiveRecord::AssociatedObject, ActiveJob::Performs, and ActionController::StashedRedirects.

Sam Stephenson is a veteran Rubyist and member of the original Rails core team. He created Prototype.js, the Pow development server, and rbenv and ruby-build to manage Ruby versions. Later, he led development of the Trix rich text editor and Stimulus Javascript framework. He also invented the technology behind Turbo and Hotwire Native. In 2024, Sam released N₁₀, a Mac app to help people stay focused on short-term goals while they work. He lives in Mexico City where he likes to feed the squirrels.

David Rodríguez is the number one contributor to Bundler & RubyGems, and was primary maintainer from 2018 to 2025. During this time, he fixed many longstanding bugs, migrated to to a state-of-the-art resolver, and brought a fast release cadence to the projects, managing the release of more than a hundred versions. He has also worked on the Dependabot system at GitHub, helping everyone keep their dependencies secure in dozens of languages. He lives in Madrid, where he is a proud carless but careful person.

Mon, 01 Jan 0001 00:00:00 +0000

Retainer Prospectus

Mon, 01 Jan 0001 00:00:00 +0000

Spinel is a cooperative of Ruby open source maintainers, founded by André Arko and Kasper Timm Hansen, and focused on a portfolio of tools to increase developer productivity with Ruby and Ruby on Rails.

André helped create Bundler 1.0 in 2009, and led the joint RubyGems and Bundler team from 2014 to 2025. Kasper was a member of the Rails core team from 2016 to 2022, and is the 14th all-time contributor. They are joined by Sam Stephenson, a member of the original Rails core team and creator of Prototype.js, rbenv & ruby-build, Trix, Turbo, and Stimulus.

Our maintainers have either created or been on the core teams of the open source behind every Ruby business:

rails, the Ruby web application framework
hotwire (turbo + stimulus), the default front-end framework for Rails
hotwire native, a web-first framework for building native mobile apps
trix, the rich-text WYSIWYG content editor for Rails
kredis, higher-level data structures built on redis
rbenv + ruby-build, the original Ruby version management tools
rubygems, the Ruby standard library package manager
bundler, the Ruby standard library dependency manager
rubygems.org, the Ruby language package registry

The Spinel portfolio includes rv, the Ruby version and dependency manager, and Rails extensions Oaken, ActiveRecord::AssociatedObject, ActiveJob::Performs, and ActionController::StashedRedirects.

A Spinel retainer offers organizations direct access to the expertise of our maintainers, which would be prohibitively expensive to acquire and retain directly.

Retaining us gets your team all the answers they need for a fraction of the cost of a single full-time engineer.

Spinel Platinum Retainer

The platinum retainer provides extensive and unlimited access to Spinel maintainers and their expertise.

The Spinel maintainers will be available to your whole team through a dedicated Slack Connect channel. Expertise access is unlimited and can span from project issues, to upstream liaison, to adoption and deployment counseling, strategy and architecture support, Go dependency assessment, to other incident areas of expertise such as cryptography, static analysis, and performance.

We encourage engineers at client organizations to think of the Spinel maintainers as another team at the company they can tap for advice.
We will set up an introductory session for engineers to meet the maintainers, and yearly sync sessions to ensure everyone is aware of us as a resource.
In the event that a new security vulnerability is publicly disclosed in Ruby, Rails, or a portfolio project, we will be available to advise. We guarantee a response within 12h if contacted within 24h of the vulnerability’s disclosure.
We will hold portfolio projects to the high Spinel standard of care, including timely and confidential vulnerability handling, modern feature support, complexity reduction, systematic testing, performance improvements, and strict security practices.
We are always open to hear about other areas that could benefit from Spinel maintenance and will consider adopting important OSS projects in the Ruby ecosystem.
Your company logo displayed on spinel.coop, github.com/spinel-coop, and in Spinel talks and presentations. In addition, you can provide custom text (e.g. a hiring pitch, product description, social media link, or event announcement) to include in each Spinel monthly newsletter.

$75,000 / year

Spinel retainers renew automatically indefinitely, and are meant to be a long-term relationship, but are billed month to month with no lock-in. We have experience working with the procurement processes of companies from startups to Fortune 100.

Work with Spinel

Mon, 01 Jan 0001 00:00:00 +0000

Work with Spinel

At Spinel, our common work breaks down into solutions for your problems, workshops to boost your team, or a full-fledged Engineering Efficiency team for your organization.

Expert solutions

Whatever problem your team is running into, we can offer you meaningful options to resolve it.

Deciding between dependencies? Unsure how to architect a new feature? We’ll walk you through the tradeoffs we’ve experienced, so you can make an informed decision.

Bring us into your Slack, where we can hear about the context and work with your team to resolve any place where they are getting bogged down. Satisfaction guaranteed.

One problem solved: $500
A week of unlimited solutions: $2,500
Solutions for a month: $7,500
A full year of on-demand expertise: $75,000

Workshops and training

We can help your entire team develop new skills and expertise that they can use on a daily basis while doing their work.

Riffing on Rails: a new strategy for finding the best shape for your data and code, from a former rails-core member
It’s Your Bundle: demystify dependency management and make your gems do what you need, instead of getting stuck
Beyond Git: learn to use jj, the VCS originally developed at Google. What if the git CLI was good, instead?

An engineering efficiency team

We’ve spent our entire careers chasing the speed, quality, and joy that come from working on software using good tools. We can work with your team to build (or re-build) your tools into a force-multiplier, making everyone on your team faster and better at their jobs.

We’ve done it at 37Signals, Gusto, One Medical, and others. We can do it for your engineering organization, and give your team a boost towards getting ahead of their backlog.

The Spinel Cooperative Blog

rv 0.6.0 is out, with ruby-dev, rvx @namespaces, and more

ruby-dev daily releases

rvx namespaces

server authentication support

rv self-update

more version 6.0 updates

Factory Frustrations: Optimized for Isolation

Your Test Setup’s Topology

What you can do

Meet Spinel

What is Spinel?

What is a worker-owned cooperative?

co-ops and open source projects have a lot in common.

Why create Spinel?

the business reality of open source work led us here.

How does Spinel work?

The tools we’re building

How we can support your team

rv 0.5: CLI tools + Windows

Windows support

rv run

rvx

rv tool

rv selfupdate

Announcing rv clean-install

Why are exec and run so confusing?

Bundler exec

RubyGems exec

npm run and exec

Cargo run and install

uv exec and run

Summary

The question for rv

rv 0.3.0 released

Rails Performance from Spinel

We make Rails applications perform.

Faster Ruby & Rails applications

Faster development cycles

Our background

Our Team

Retainer Prospectus

Spinel Platinum Retainer

Work with Spinel

Work with Spinel

Expert solutions

Workshops and training

An engineering efficiency team

rv 0.6.0 is out, with `ruby-dev`, `rvx @namespaces`, and more

`ruby-dev` daily releases

`rv self-update`

`rv` 0.5: CLI tools + Windows

`rv run`

`rvx`

`rv tool`

`rv selfupdate`

Announcing `rv clean-install`

Why are `exec` and `run` so confusing?

Bundler `exec`

RubyGems `exec`

npm `run` and `exec`

Cargo `run` and `install`

uv `exec` and `run`

The question for `rv`