Staying "As Rails as Possible": How Buzzsprout Runs a Large Podcast Host with a Tiny Team
Ruby on Rails
Tom Rossi, co-founder of Higher Pixels, the company behind Buzzsprout, joined Robby Russell on On Rails to explain why the company stays as close to vanilla Rails as it can. Rossi's reason is pragmatic rather than ideological. Rossi calls themself a pragmatist who never went shopping for the best technical stack. They wanted to build a SaaS business, and Rails supplied the guardrails for that. Since it kept working, they saw no reason to look elsewhere, and they say they never chased the "shiny objects" when others talked about switching technologies.
The conversation covered Buzzsprout's history and scale, the painful move from Paperclip to Active Storage and the upstream contribution that came out of it, RSS polling and ETags, a shift in analytics from hand-built summary tables to ClickHouse, and why Rossi wants the company to stay small.
Inheriting opinions from people "smarter than you"
Asked whether the Rails community fits a business-first mindset, Rossi said that, especially when starting out, it is valuable to inherit opinions from people smarter than you, and they had no trouble admitting that others had made better decisions. They also admitted that on their first couple of Rails projects they wrote configuration to override the defaults because they didn't want to follow them, and those overrides "come back and bite me later."
Rossi started with Rails before 1.0, around 2005, not long after the well-known "build a blog" video. The video came from Kevin, a designer they had worked with who later became their business partner. The two had been a .NET shop, and Kevin told them the video described exactly the problems they kept hitting when building apps in .NET. Kevin wasn't a programmer, but after watching it Rossi was "blown away" and never looked back.
From client work to a portfolio of products
Higher Pixels began doing client services. Around 2001 it pivoted toward its own products, starting with one built in .NET. Rossi liked running a SaaS product and proposed that Kevin join them in building another. That became Tick, time tracking for people who track time against budgets, and it was built on Rails. More products followed: the original .NET product was rebuilt in Rails, and the company launched Donor Tools and StreamCare, a product in the medical space. For a long time the two founders had more products than people, which Rossi describes as "spinning plates."
Tick and StreamCare were the main revenue sources. Buzzsprout, built in 2008 and launched (Rossi thinks) in 2009, was a small product they built because they needed it to complement another product. It didn't make much money at first. Early podcasters were mostly technical people and a lot of DJs. As podcasting took off, Buzzsprout "just exploded." Rossi credits Rails with letting the team keep adapting and adding features as podcast hosting evolved as a service.
Rossi has no desire to return to client work. They describe it as brutal and prefer being "the client" who makes the decisions. They do miss the variety and seeing clients' "eyes light up" when a problem gets solved, so they occasionally help friends for free. At the time of recording they were doing this for a friend whose technical team hates Rails without knowing much about it. Rossi told the friend they could build what was wanted in probably less than six weeks.
Rossi also described a lesson about marketing. The team used to think building a great product was enough. When growth stalled, their instinct was to build more features, but "the problem isn't the features," it is marketing. Kevin handles the creative side and connecting with audiences. When the medical product launched, a third partner, Marshall, joined on the finance side and balances Rossi and Kevin, who in Rossi's words "put all of our chips on the table all the time."
Scale, team size, and the January spike
Today Higher Pixels works only on Buzzsprout and StreamCare, each with its own team. StreamCare has one developer, Ron, who is part of a Ruby group in Colorado, and Rossi occasionally helps out. Buzzsprout has two SREs, three programmers, and two designers, which Rossi calls a pretty small team compared with competitors.
Buzzsprout hosts about 472,000 podcasts. Rossi estimates about 125,000 are active, meaning people are still uploading episodes. Asked about the common claim that most podcasts never get past a certain number of episodes, Rossi said they checked their own statistics for something like a "seven-episode hump" and found nothing, other than that many people never upload a first episode. The free plan makes the numbers hard to read. By the time someone is paying, they usually have at least one episode.
Podcasting turns out to be seasonal. January is a big month because people decide to finally start that podcast, the same way they join a gym.
Bringing in an SRE just before 2020
The SRE roles are relatively recent. Buzzsprout hired its first SRE in 2019. Rossi knows how to write Rails code but not how to handle server configuration and the tuning that scale requires. The team had relied heavily on a vendor for that work, then realized that "our whole business is built on this" and that without the skill in house they could go down.
The timing was fortunate. In 2020, with people locked in their homes during the pandemic, podcasting exploded, and Rossi says the team was "holding on by your fingernails" as signups poured in. The SRE scaled them up quickly, and Buzzsprout moved to a Kubernetes environment in 2020. It still runs on Kubernetes.
The SRE is named in the transcript as Brian Treywick. Rossi describes them as "an SRE plus" because they also do development. For the ClickHouse work, for example, they didn't just start the server; they worked out the Active Record configuration and how to run parallel tests. A second, more traditional SRE joined about a year to a year and a half ago. That person watches memory usage and scaling for job processing, and was hired partly so Brian could take real vacations. Rossi says Brian always brings a laptop when away, and Rossi would love them to go to Italy without one. Robby shared advice they once received: don't hire for a role until you can afford one and a half to two people in it, so there is redundancy. Rossi summed this up as the "bus factor."
What "as Rails as possible" means day to day
Buzzsprout's mission, in Rossi's words, is to help podcasters start podcasting and keep podcasting, and they will use whatever means best delivers that. Rails is good at this because it has no opinions about podcasting but has opinions about things that "probably don't matter," such as column types and table naming. Those are topics teams can spend a lot of time debating. Rossi also calls Rails agile: things are easy to change. As an example, Buzzsprout recently introduced annual plans. That was painful, but mostly because of how to communicate the change in English to customers, not because of the Rails implementation, which was much simpler.
Robby noted that naming conventions may sound like a small benefit, and recalled pre-Rails teams mapping out whole schemas and debating column prefixes. Rossi agreed it isn't the biggest lift and offered Hotwire as a better example.
Hotwire and the mobile apps
Rossi says Hotwire has saved the company "a ton." The team designed and built the Buzzsprout mobile app within six months. The Android app took about three more months. The team wanted both platforms to launch at the same time, and the design work was already done, so implementation wasn't too hard. Rossi's explanation is that they are web developers working in Rails and could reuse everything they already knew, connecting the app with Hotwire. Rossi says the app feels native because the parts that need to be native are connected in, and mentions Stimulus in that context.
Asked about payments, Rossi said the team avoided Apple's and Google's in-app payment systems by putting no payment information in the app at all, presenting it as a "companion app." That position still had to be defended. According to Rossi, the app had been approved during development, but when the team was ready to launch it was denied. They argued that it was a companion app for people already paying through the website, and waited without knowing how long the dispute would take while prepared launch marketing sat on hold. Rossi called it brutal. They know the rules have changed since then but still haven't added payment features because they don't want to risk going through that again. The app doesn't do recording, but Rossi says that when the team gets to features like that, Rails gives them a good toolbox to reach into.
From consumer to contributor
Higher Pixels is a member of the Rails Foundation, and Rossi ties that to the fact that everything the company builds is on Rails. They explained that using Rails in a business is very different from contributing to it. Over the past year to year and a half the team has started trying to contribute, and Rossi says it requires "a different brain" because you have to think so meta about the work. The company has had a couple of contributions merged.
The most recent was in Active Storage. Rossi thinks Buzzsprout can help the community here because the company stores so much data and cares so much about bandwidth, which is a major cost of goods sold. That PR took about a year to get merged. To explain why the team cared, Rossi went back to the migration from Paperclip.
The Paperclip to Active Storage migration, and what took down production
Rossi presents Active Storage as a case where the company's lack of participation hurt it. The team always tries to follow Rails' opinions, so as soon as Active Storage was generally released (they weren't on Rails edge), they decided to drop Paperclip. Rossi calls this "the wrong move": Active Storage wasn't built for Buzzsprout's use case, and the switch led to a long run of monkey patches. In hindsight, they think the team should have waited and helped Active Storage become what they needed.
This happened before the company had an SRE. The team was just Rails developers. They deployed the change and Buzzsprout ground to a halt. They rolled back, reviewed their code, redeployed, and the site went down again. They rolled back once more and asked their hosting vendor for clues. The vendor said request volume was rising exponentially beyond the available resources.
The cause turned out to be asset URLs. With Paperclip, public assets were linked directly (still on a Buzzsprout domain), so requests never reached the Rails server. With Active Storage, every asset request went through Rails. Each RSS feed contains hundreds of links to artwork, episodes, and MP3s, so all those URLs suddenly hit the application. The first monkey patch overrode this behavior to link directly to public assets in RSS feeds and a few other places.
The second round came when Buzzsprout started relying on a CDN. Rossi says you don't need to worry about CDNs when starting out, but eventually a lot of unchanging requests didn't need the server at all. The team had to patch Active Storage again to emit CDN links instead of redirecting to S3. Rossi thinks Active Storage was designed around a domain like Basecamp's, where assets sit behind a login and should be private, while most of Buzzsprout's assets are public and need to be served through a CDN with fine-grained control. As Rossi describes it, Active Storage's current CDN support downloads the asset to the web server so it can then be cached on the CDN, which doesn't fit Buzzsprout's needs. Rossi says the "next big push" will be improving how Active Storage works with CDNs, and there is still a lot of monkey patching in that area.
Immediate variants: the problem behind the PR
The merged PR came from image variants. When a podcaster uploads episode artwork, Buzzsprout resizes it into two or three sizes. Active Storage's behavior, as Rossi describes it, was to schedule a job to create those variants. But as soon as artwork is published, podcast apps polling for new content request it, possibly thousands of times depending on the show's popularity. Each of those requests triggered the job to create the variants. The PR's original name was along the lines of "immediate variants": the variants have to be generated right away, before the asset starts being served, because it will be requested immediately and heavily.
Audio processing and a 600 MB WAV file
Audio is handled by Buzzsprout's own tooling, built before Active Storage existed, even though Active Storage's documentation mentions processing audio and video. Podcasters can upload any format, and Buzzsprout converts it to MP3 using industry standards so users don't need to understand audio preparation. The processing uses FFmpeg.
Rossi recalled that within the first couple of weeks after launch, someone uploaded a 600 MB WAV file for about a 30-minute podcast. They hadn't anticipated it. The server struggled, and because they are "not the server guy," it took time to realize the huge file had used up the disk space. Rossi took it as proof that Buzzsprout had reached its intended audience of people who aren't geeks and don't know the difference between an MP3 and a WAV, which is why post-processing matters.
Uploads now go directly to S3 through Active Storage. Rossi says the team sometimes sees slowdowns, which they attribute more to Amazon, and there are edge cases with podcasters outside the US depending on where the bucket is located. Overall they call direct upload a really nice feature: the file doesn't touch Buzzsprout's server until it's in the bucket as a key, which makes processing easier. Robby and Rossi recalled the old days of adjusting web server limits for large uploads, moving files manually, and building Ajax progress bars that failed at unknown points. Rossi's summary: "so much of that we get for free now."
Few gems, and owning the payment stack
Asked about gems they depend on, Rossi said the list is short. Buzzsprout uses the Stripe gem to talk to Stripe, but Rossi wants to control credit card processing and be able to switch vendors. They have been burned before: Buzzsprout depended on an FFmpeg gem that stopped being maintained, and the reaction was "I'm just going to do it myself." Billing predates Stripe. Buzzsprout originally used Authorize.net, so logic for subscriptions, declined cards, and retries already lives in the company's own library. If they started a new project today, the gem Rossi would reach for is VCR, which records web interactions so tests can replay them without calling real APIs. It has been useful on both Tick and Buzzsprout.
Robby raised vendor-specific columns like stripe_id and the difficulty of adding processors such as PayPal for customers without credit cards. Rossi said the goal is to be able to switch. Stripe is hard to resist because its API and documentation are so good, but Rossi calls it expensive and says it "know[s] they own you." Rossi is glad subscriptions aren't managed there, while acknowledging that actually switching processors may never happen.
Donor Tools, which helps nonprofits track donations, was where Rossi deliberately resisted Stripe and used WePay. After Chase acquired WePay, the team expected good things, but Rossi says Chase shut it down about two years later, forcing a move to Stripe. Because Donor Tools was written around 2015, much later than Buzzsprout's 2008–2009 code, it was more abstract. Stripe-specific columns lived in a delegated type table for that processor, although, Rossi notes, delegated types didn't exist in Rails yet at the time. They call it a good case study in making merchants swappable. Buzzsprout doesn't have that structure, and a switch there "would be painful."
How the storage data migration was done
Returning to the Paperclip migration, Rossi recalled, without being fully sure of the details, that Buzzsprout had millions of assets. The team duplicated them into a new bucket for Active Storage so either system could run. The difficulty was reconciling uploads and deletions that happened after each copy run, which required a "true up" done with scripts from the console. It wasn't a gradual rollout to a percentage of customers; it worked or it didn't. Rossi admitted "it was broken for a while."
Rossi pointed out that many requests to Buzzsprout come from machines, not people, which gives the team some slack. If RSS feeds have issues for a while, users aren't directly affected, though feed readers may be. Rossi once received an email from Amazon, which ingests podcasts, asking whether Buzzsprout had changed something.
RSS polling, Apple, and two lines for ETags
According to Rossi, Apple hits Buzzsprout's RSS feeds an excessive amount, sometimes thousands of times an hour for a single feed that rarely changes. Rails supports conditional GET requests, but clients have to honor them, or they download and parse the whole feed every time. Rails lets you set ETags: the client sends the last ETag it saw, and the server returns the full feed only if it changed, otherwise a 304 Not Modified. Clients that respect this can just check the CDN. Rossi says Apple runs two ingestion engines, for reasons Rossi doesn't know, and only one uses ETags. They have raised the energy waste with Apple.
Rossi presents ETags as an example of benefits that come from staying vanilla. When bandwidth costs from feed polling were climbing, Brian told them it would take "two lines" to add an ETag. As soon as it was deployed, the team saw 304s. Rossi's point: "I'm not a genius for doing that. It just came with Rails." Robby added that another podcast host they use doesn't send ETags, which forces them to re-fetch every episode to rebuild a static site.
A decade of analytics data outgrowing summary tables
Rossi tells other SaaS founders, "don't solve problems you don't have," while noting they probably borrowed the phrase from David or Jason. Then 2020 brought all those problems at once, including scaling stats.
Buzzsprout has collected stats since its 2009 launch, originally a single download count per episode, which Rossi thinks was stored in a separate table. In 2014 the company launched advanced analytics: location from IP address, which app (Apple Podcasts, Spotify, and so on), and more. That meant storing every play in a table that never stops growing. Rossi says the usual hot/cold data distinction doesn't apply here. Nobody cares about server metrics from a month ago, but a podcaster does care how many downloads a 2015 episode got, so old data has to stay available.
Rossi went to RailsConf asking people how to solve this, hoping for a magic bullet, and didn't find one. That's why they want to pitch a Rails World talk on the subject. Their own solution was hourly summary tables: each hour a job summarized recent data into tables such as episodes by date, by location, and by user agent. It worked until those tables also grew too large. Adding CPU got them through 2020, and moving into Amazon's ecosystem with Kubernetes allowed some horizontal scaling. But at one point the hourly summary job took close to an hour, and a job that runs hourly can't take longer than that. The team was constantly fighting it.
ClickHouse and thinking in OLAP
Rossi says the real shift was understanding OLAP databases; ClickHouse is simply the one they chose. As a self-described relational database person, Rossi explained the difference. Relational databases favor separate tables, joins, and indexes. OLAP databases are about columns: you put data in and they are very efficient at retrieving and aggregating it (counting, max, sums). You have to learn to write queries in a way that performs well.
Buzzsprout ran ClickHouse alongside the summarizer, which was still running at the time of recording because some queries still used the summary tables. Rossi expected to move fully off it in the next six-week work cycle.
Robby described a pattern Planet Argon often sees: slow dashboards lead to summary tables, cached columns, background jobs, jobs limited to recently updated records, and even jobs triggered when someone visits the site, so data is precomputed for users who may never log in. Rossi said Buzzsprout reached the end of those techniques and needed a new tool, which is where OLAP came in. It was intimidating, but Rails' multiple-database support made it feel natural to reach into a second database and get Active Record objects from an OLAP store.
How data gets into ClickHouse
Much of the solution came together at Tropical Ruby, where Rossi set out to get an answer from people there. They kept hearing "OLAP," and many immediately suggested a Kafka-style streaming pipeline. Rossi says Buzzsprout may end up there eventually but chose something simpler.
Buzzsprout already processes logs continuously and writes play data to its relational database. That includes Ruby logic to make sure a stat is real: filtering bots, collapsing repeated requests from the same IP within a time window, and similar checks. The job that used to build summary tables now assembles a large batch and pushes it into ClickHouse, roughly 50,000 rows an hour according to Rossi. ClickHouse handles the inserts while continuing to serve reporting queries. Rossi says this works well for now. Robby mentioned that another guest described using BigQuery on top of a production database for a similar purpose.
Multiple databases: two lines of config, many rewritten queries
Rossi encouraged listeners not to be intimidated by multiple databases, and credited the community, which Robby identified as Shopify, with compressing the complexity so that connecting took about two lines of configuration. When Robby called the change almost "boring," Rossi said it isn't boring yet. Connecting was two lines, but every query had to be rewritten and rethought.
Rossi's example is denormalization. In a relational database you avoid repetition and join to other tables. In OLAP "it's one big table." The user agent column sits next to a podcast app column even though the app is derived from the user agent, and a location ID sits next to city, state, and country. Rossi says this enables queries they couldn't run on summary tables because those queries wouldn't perform.
Staying small on purpose
Rossi goes further than being comfortable staying small: they want to. They enjoy running a small business, and they credit Rails' productivity for making it possible. With AI added, they call it "a multiplier on top of a multiplier," something that feels like "cheating." Rossi says larger competitors with more people but fewer podcasts don't believe Buzzsprout's team size, and competitors of StreamCare, which has one developer, reportedly have hundreds of people. Rossi calls Rails "a superpower."
The downside Rossi identified is support coverage. They've learned that a great support team is "a massive feature" that involves no code: invest in good people and let them advocate for customers. Customers love Buzzsprout's support team. But Rossi doesn't want staff spread across the world, so matching something like Basecamp's around-the-clock support in local work hours is hard for a small team.
Build vs. buy, and AI inside Buzzsprout
Rossi says they don't have a formal ethos on building versus buying beyond disliking dependence on other companies for mission-critical things, such as recurring billing. They were clear that if they started a SaaS today, they would absolutely use Stripe and Stripe subscriptions, because you can always bring it in house later. Buzzsprout is now at a stage where it can.
The AI features are an example. When a podcaster uploads an episode, AI listens to it and drafts titles, descriptions, chapter markers, social posts, and a blog post, which helps podcasters with the last steps before publishing. Initially Buzzsprout sent the audio to a vendor that returned these assets. Once customers adopted the feature, Buzzsprout brought it in house. Rossi says that gave them control to improve it, removed the dependency, and allowed them to lower pricing.
Robby asked when episode descriptions could get longer. Rossi said that is driven by Apple, which still has a "stranglehold" on podcasting after long being its benevolent dictator. Rossi mentioned talk of extending the limit and letting Apple catch up. Robby wants richer descriptions mainly for websites, search, and AI indexing. Rossi said the value depends on the podcast, since some shows naturally come with supporting links and reading material.
Rails as the secret sauce
Asked to sum up, Rossi said everything discussed shows Buzzsprout moving faster and more nimbly by sticking to vanilla Rails and using new framework features as soon as they appear. They added caching as an example. Fragment caching wasn't available when they started with Rails and is now easy. With Solid Cache, Rossi says, Buzzsprout has very few evictions, so much of its content is served directly from cache, a benefit they say they got "for free" from smart people building it into the framework.
For reading, Rossi recommended Sandi Metz, including Practical Object-Oriented Design (which they have read multiple times) and Metz's talks, calling Metz the biggest influence on how they code. They also cited everything 37signals has published, including the Rework material. Rossi says Higher Pixels has settled into its own version of those ideas. Both hosts said they miss seeing Metz at conferences.
Five years out: AI and development
Asked what they believe now that more people will agree with in five years, Rossi said they think developers already broadly agree that AI makes coding better, as a partner for discussing ideas and strategies, and that it makes the work fun. They said it used to be controversial but doubted it still was. Robby, who describes themself as a former skeptic, said it depends on which bubbles you're in. Robby has seen people abandon open source projects over AI use, even when maintainers are transparent about it, and asked where the line would even be, for example whether editor autocomplete counts. Rossi said that binary "has to go away" and predicted that in five years nobody will talk like that. They compared it to requiring people to disclose that they used Google. Robby didn't commit to that prediction and suggested checking back in five years, and Rossi agreed.
Welcome to On Rails, the podcast where we dig into the technical decisions behind building and maintaining production Ruby on Rails apps. I'm your host, Robby Russell. I run Planet Argon and for over 20 years, we've helped teams maintain and evolve long-lived Rails apps. So, I tend to approach these conversations through that lens.
On this episode, we're joined by Tom Rossi, co-founder of Buzzsprout. Buzzsprout is one of several SaaS products built and operated under the Higher Pixels umbrella. In our conversation, we talk about what it looks like to stay as Rails as possible as a company scales. We dig into their recent migration from Paperclip to Active Storage, what went sideways in production, and how they adapted Rails to fit their needs.
We also touch on analytics at scale, including a recent move to ClickHouse and how Rails helped make that transition quite manageable. We also explore how their infrastructure has evolved over time along with why Higher Pixels chooses to give back to the Rails ecosystem. Tom joins us from Jacksonville, Florida in the United States. All right, check for your belongings. All aboard.
Tom Rossi, welcome to On Rails.
Thanks for having me. I'm excited to be on the show.
I've been looking forward to this conversation as well. So Tom, I have to ask, what keeps you on Rails?
I love Ruby on Rails. It makes life... like, I could be focused. At the end of the day, I feel like I'm a pragmatist. I didn't do a lot of shopping. I wasn't looking for the best technical stack. I was looking to build a business, a SaaS business on software. And Ruby on Rails just provided all the guardrails I needed to be able to quickly build a business on it.
And since then, there's no reason for me to shop. So I stay on Rails because it works for me and I'm very practical. So I've never chased any of the shiny objects when, you know, when everyone was talking about switching to different technologies that were out there. I just wasn't interested because I was more interested in growing my business.
Do you feel like there's anything about the general wider community within the Ruby on Rails ecosystem that tends to align well with that particular goal that you have about building your business and things like that versus maybe geeking out about the technology? Do you feel like you still get to geek out about the technology and get super excited about that, or do you feel like there's always that, like, well, I'm also kind of running a business here and I want to just get that part done?
I think especially when you're getting started, it's so great to inherit opinions from people that are smarter than you. And I had no issue recognizing that people were smarter than me and they've made decisions and this is the way they did it. And it's funny because even still, I remember the first couple projects I did with Rails where I overrode... I basically spent time writing configuration because I didn't want to follow, and sure enough, those are the things that come back and bite me later.
Sure. Sure.
But for the most part it provides so many opinions and so many guardrails for me. It makes it easy to get going, to get, you know, out the door with a product.
Do you recall approximately what version of Rails you started playing with it?
Oh, it was pre-1.0.
Okay. So, this gets you back in the 2004, 2005 range or so, give or take.
Yeah, I think it was 2005. It was not long after the infamous build a blog video, which is really how I got into it. Actually, it was a designer that I worked with, who now I'm a partner with, but he sent it to me and he was like, look, 'cause we were a big .NET shop before that, and he's like, look, this guy's talking about all the things that we ran into when we were building apps using .NET, just watch the video and see what you think. Right, so he's a designer, not a programmer at all, and I watched the video and was just blown away and then started playing with Rails and haven't looked back.
So it's a similar timeline to me as well. But to give our listeners a bit of context and grounding, could you give us a quick overview of specifically Buzzsprout, but then you also mentioned your business partner. So talk a little bit about Higher Pixels as well.
Yeah, so originally we started off and we were doing client services work back in the day. People would hire us, we would build product for them, but then around 2001 we started to pivot into building our own product. Our first product was .NET and we just tasted what it was like to have a SaaS product and loved it. And so I ended up partnering up with one of the designers I used to work with, Kevin. Kevin came on and I was like, "Look, let's just partner up and build another SaaS product." And that's when he said, "Look, watch this video first."
And we built our next product called Tick, which is time tracking for people that track time against budgets. And we built that product on Rails. And it was an incredible experience. And then after that we just wanted to build more products.
So for a long time it was just the two of us. We had more products than people 'cause we had built the original product in .NET, then we rebuilt it in Rails, and then we had Tick and we launched a product called Donor Tools. We have a product called StreamCare, which is in the medical space. So we have all these different products that we've built, but it's just kind of... we used to refer to spinning plates. You know, you're doing a little bit of work over here, doing a little bit of work over here.
And our big money makers were Tick on time tracking and a product in the medical space called StreamCare. But we had this little product that we built called Buzzsprout that was in the podcasting space, but we built it in 2008. I think we launched it in 2009. And it didn't make a lot of money, but it was super fun to build and we wanted it. We needed it because we had another product that kind of complemented it.
And that product ended up just exploding as podcasting started to take off. When we first launched it, not a lot of people were podcasting. It was mostly technical people and there were a lot of DJs. But now everybody podcasts, and so Buzzsprout was positioned really well, and being built on Rails, we were able to continue to adapt and add features and functionality and keep up with the industry as it was evolving. As podcast hosting as a service was evolving, Buzzsprout was able to evolve with it.
Nice. You know, I also work in the client services area and so you were able to make that transition from working with clients. Do you still work at all with any sort of clients at this point anymore, or do you pretty much truly just have your portfolio of SaaS platform products and things that you're selling?
Right. No offense, but I have no desire to go back to working with clients. Like, it was brutal. I mean, you know, it just gets really hard. And once you have... Well, I'm kind of the client now. So I love it. Like, I get to make the decisions as opposed to having to pitch a client on why they should or shouldn't do something.
No, I can appreciate that. Well, I think that the ingredient there is not every... I realize that I'm not necessarily great at selling the product. So I feel like I can build things and we experimented over the years with building several products and trying to figure out how we're going to bring those to market. And it was that part of it. So you or your partners or people you work with have that skill set to know how to bring the thing to market and sell it and do that part, but I'm like, "Oh, I'm actually really good at helping people with their projects." So I realize that that part of distinguished at least with how I think about software development and so I enjoy the client services.
It's fun too. What's fun about client services is there's so much variety and so you get to go solve... you get to see their eyes light up when you solve a problem. You know, you see it get deployed and this problem that they've had gets fixed, and there is a lot of enjoyment that I miss from that. Occasionally I'll do it more for, like, friends, and I don't even want to get paid for it. I just want to come in and help you solve this problem. I'm doing it right now with a friend of mine where his technical team just hates Rails, but they don't know anything about it. And so I've convinced him. I said, "Let me build it. I could build this thing in probably less than six weeks to do all the things that you want to do." And so anyways, I like doing stuff like that to play with, but not as a business. I don't want to have to pay people's salaries based on my ability to sell, you know, large projects.
Fair. It's fair. I mean, having been doing that for a couple decades now, I can appreciate not wanting to have to deal with that part of it because it's definitely not for everybody. And I don't even know if it's for me, to be honest, but I've been doing it and I figure it out. So the ebb and flows of running.
But you do touch on a really good thing that I learned, which was the importance of marketing and selling, because we used to think you just build this incredible product and that's all you needed to do. But you still need to... yeah, you still have to go get those customers. And so what happens a lot of times is you're like, okay, we're not growing the way that we want to. What should we do? Let's build more features. The problem isn't the features. The problem is the marketing element.
And so it's great, my partner Kevin, he's really good on the creative side and coming up with different ways to connect with audiences and be able to get the word out there and stuff like that. And since we launched our medical product, I took on another partner, Marshall, and Marshall's on the finance side, and so he's really good at helping balance Kevin and I in terms of, you know, we'll put all of our chips on the table all the time and Marshall will be like, "Yeah, maybe we should..." You know, so it's good to have partners, partners that you trust, but it's marriage.
Yeah, you probably know.
It's a whole thing. Yeah, I've got a business partner. It's a whole thing. But also having people on my team that I need to bounce ideas off with, you know, try to play off their strengths, play off my strengths, and somehow move things forward and still have to deal with the challenges of marketing a software consultancy just as much as it would be a software product. Maybe I need to rethink this. Anyhow, let's talk more about... so out of curiosity, how many engineers approximately are actively working on, let's say particularly, the Buzzsprout codebase on a regular basis?
Right now we only work on Buzzsprout and StreamCare and they have separate teams. StreamCare is pretty simple. There's only one developer on StreamCare. Occasionally I'll pop in and help out on that, but mostly it's one person, Ron. He's part of the Boulder City Ruby group in Colorado. Ron does all the development for StreamCare. On the Buzzsprout side, we have two SREs, three programmers, and two designers. So pretty small team compared to our competitors.
And approximately how many podcasts are you hosting at this point, if you don't mind me asking these questions? At least one.
Yeah. Right now there's about 472,000 podcasts active. There's 472,000 podcasts on Buzzsprout. But of those, I would say probably 125,000 of them are active, meaning that people are continuing to upload episodes and do things.
Getting past that first... What is it? You might know the number, but how many episodes do podcasts usually not get past? Is it like five or something?
One. Like, I tried to look at this because I've heard this before. Oh, you know, you've got to get over the seven-episode hump and things like that. But I looked at our own statistics and I couldn't find anything like that other than you need to launch. There's tons of them that never upload their first episode. And it's hard. Our numbers are hard to look at because we do start with a free plan. And so somebody that signs up for a free plan, you know, are they really into podcasting? By the time they're paying, they are. They've got at least hopefully one episode.
Yeah, that makes sense. And you could be maybe evaluating different platforms or whatever and just testing something out. You're like, "Oh, I got this really excited energy one afternoon. I'm going to start a podcast with my friend, do this thing," and then you're like, "I'll have to get back to that." And then six months goes by and you're like, "Oh, yeah. I forgot."
January is a huge month for podcasting. It's funny because you wouldn't think it's seasonal, but a lot of people are like, "Okay, I'm finally going to start that podcast in January." Just like they join the gym, they're going to go launch that podcast. And so we see a big uptick in January.
Specifically around the number of engineers and stuff. You've got, you know, you mentioned three, is that three programmers actively working, a couple of SREs and some other roles around that as well. Has it relatively been about that size for at least the last several years now, or...?
Yeah. Yeah, that size for a long time, and the SREs are relatively new. The SRE, thankfully, was 2019 that we hired our first SRE, and we just recognized this was a competency we had to bring in house. I had to have somebody... I mean, I know how to write code. I love writing Rails code, but understanding the configurations on the servers and being able to scale and things like that and all the tweaking that's required once you get to that kind of size. We were relying a lot on our vendor to do a lot of that work. And at some point, we just recognized, man, our whole business is built on this and if we don't have that competency in house, we could go down.
Thankfully, we hired our first SRE. Then 2020 hit, when the pandemic hit, podcasting exploded because everybody's locked in their house. So it was like you're holding on by your fingernails as it was just exploding and there were so many people that were signing up, and thankfully we had an SRE that was able to scale us up quickly. And so we ended up moving into a Kubernetes-type environment in 2020 to be able to scale up with everything else that was happening.
Interesting. And just for everybody listening that might not know, SRE is a site reliability engineer, correct?
Yeah.
Okay, and so what are their responsibilities? Are they primarily, like, within the context of your organization, are they primarily keeping an eye on monitoring metrics, scaling, keeping your... I don't know, are you running this on AWS or where do you run your cluster there? Are you still using Kubernetes as well?
Right, we're still on Kubernetes. And so Brian Treywick is our SRE and he is exceptional, and I think it's hard to call him an SRE because he'll go do development work too. So he floats back and forth. So he's not just about keeping the server powered on and running, like he'll go in and write code.
So one of the things that you and I had talked about was our recent shift where we introduced ClickHouse into our environment. Well, he's not just spinning up the ClickHouse server, he's actually figuring out how do we get the Active Record configuration working and how do we configure our parallel tests to run. So he's an SRE, but he's kind of an SRE plus, and then we have another SRE who is strictly an SRE. He is basically watching the servers, making sure that memory usage is in line with what it needs to be, that it's scaling up and scaling down whenever it needs to
be able to work on jobs and things like that. And so he's more of a traditional, and he's relatively new to the company. I think he's only been with us for maybe a year, year and a half. And he was really to give some relief to the one SRE we had so he could go on vacation. I would always tell Brian, I was like, "Dude, I want you to go to Italy and not take your laptop. Like, that would be amazing if you did that," because whenever he goes out, he's always got a little laptop because he's always nervous, you know, he's going to get paged.
I can understand that. There's always been a little bit of... I remember there was someone a long time ago who gave me advice like, don't hire for roles until you can kind of afford to hire one and a half to two of them. That way you have some redundancy, because it's really great that people can step up and take on that role, but then also if you can't give them some relief, then, you know, they don't get to enjoy their vacations and things like that.
Or Tom's going to have to try to figure out how to modify the Kubernetes cluster and redeploy that. So that's fun. We were talking about the bus factor. Like, how many buses would it take to wipe out your company? If it's one bus, you're in trouble. [laughter and gasps]
Well, yeah. That's not good. So let's talk a little bit more about Rails in particular. So in one of our prep conversations, you specifically described Buzzsprout as being as Rails as possible, but not out of purity, but pragmatism. Could you talk about what you mean by that and what that looks like in day-to-day decision-making?
Sure. Yeah. I think from a pragmatist standpoint, I want to help podcasters start podcasting, keep podcasting for that product. Like, that's our mantra. That's what we're trying to accomplish. And so I want to use whatever means possible to deliver on that value prop. And so from a practical standpoint, Rails is really good at that because it doesn't have opinions about podcasting, but it has opinions about things that probably don't matter: what type of columns you should use, how you should name your tables, and, you know, things like that that you can spend so much time debating and working on, where for all those decisions there's tons of opinions out there. And so it just helps you to move fast. And Rails is very agile. I can just go change things. You know, we recently introduced annual plans to Buzzsprout, and it was painful, but it wasn't painful from the Rails perspective. It was just painful because it was such a big change, right, to be able to communicate. It was more on the English that we use to communicate what we do, but actually doing it with Rails was so much simpler.
Yeah, that resonates. You know, you talk about, say, defaults, and so what sort of decisions do you think it saves you from having to make? You mentioned maybe column names, things like that. People might be like, "Oh, that's nice." That doesn't feel like the biggest lift necessarily. But I also remember pre-Rails, and I remember we would have these kinds of conversations as teams, like, "We're going to map out our whole database schema, and what are we going to call that?" Like, people kind of
Yeah. And remember different naming conventions on our columns, and oh, it'd be str as a prefix, and then... Yeah. I mean, all kinds of... I don't think about any of that anymore.
Yeah.
But yeah, it's not the heaviest lift. I think a better example would be Hotwire. So Hotwire has saved us a ton. We were able to come up with what the mobile app for Buzzsprout would look like and develop it all within six months. Like, you couldn't
And then we built the Android app. We wanted to launch them both at the same time. It took us about three months to build Android, just because we had already done all the design work, and so the actual implementation itself wasn't that bad. Well, why? Well, because we're web developers and we're on Rails, and because we're on Rails, we can take advantage of all the things that we know how to do. We can just use Hotwire to connect it up. There are those elements that need to be native. I don't know if you've used the Buzzsprout mobile app, but it feels like a native experience, because in the areas that need to be native, we can connect in with Stimulus to do different types of native things.
How was the
That's a great example.
No, I think that is a good example. How have you approached payments? Is that all happening pretty much on the web interface right now, or did you need to work around anything to deal with Apple's or Google's payment approaches?
Yeah, we avoided it completely with both of them by not putting any payment information into the app. So they call it a companion app. We had to make the argument.
We had to make the argument. They originally approved everything, and when we were ready to launch, they denied it.
And we're like, whoa, whoa, whoa, you've already approved it in the past. We've told you it's a companion app. So somebody who is using this has already put in their credit card, they're already paying us, whatever. But we had to fight it, and you never know how long it's going to take. Meanwhile, we've got all this marketing that we've prepared that we're holding off. It was brutal. But we still haven't added anything. I know there have been some changes, but we don't want to risk getting in trouble
Yeah, we go through that process again.
Yeah.
And do you think that argument around the companion app holds? I haven't played that extensively with the app, but I think there are some content management type features and stuff like that, maybe seeing some data in there. But you're not recording the episodes in the app or anything at this point, right?
No.
So I understand that.
But when we get into those types of features, we have this wonderful toolbox to be able to reach into and use.
What if I told you your model already knows who it is? Introducing Enum Chart. The ancient practice of assigning your records a fixed identity based on a small integer column they'll never truly understand. With Enum Chart, your post doesn't just have a status, it is its status. Are you a draft? Creative, misunderstood, not ready to be seen? A published? Confident, public, living your truth. Archived? You've done the work. Now you [music] rest. Simply declare your values in order, and Enum Chart will assign each one a sacred number. 0, [music] 1, 2. A number you must never speak of and never reorder, or your entire database will enter retrograde. Need to change your status? Just call .published exclamation mark and feel the transformation. Need to ask who you are? Draft question mark. The answer is always boolean. [music] The answer is always certain. Enum Chart. You're not just a row, you're a status.
Enum Chart is not responsible for adding a new value in the middle and watching 10,000 of 30 records suddenly become arch type. Do not gaze upon the integer column directly if you must use underscore prefix. You were never meant to have two in the same model. Except this,
Your schema has spoken.
So you mentioned also in our conversations in the past that you lean heavily on the Rails and the Ruby ecosystem. So can you tell us a little bit about some of the open source libraries and how they help carry your platform?
Everything that we do is built on Rails. And so that's why we're members of the Rails Foundation. That's why we want to support what you're doing with your podcast. We want to support the Rails community, because everything that we built is on top of Rails. And it's kind of like we were talking about before, the difference between being the practical business that uses Rails versus the contributor to the open source community writing Rails code. It's very different. You know, it's been challenging. We've tried in the last year, year and a half to start contributing to Rails, and it's like you've got to put a different brain in your head, because you have to think so meta about the work that you're doing. It's very different. So we've been longtime consumers and users of open source code, but only recently have started to dabble in: could we actually contribute? Like, could we actually do this?
Have you actually started making any contributions to Rails itself at this point, or got any PRs you've sent as a team?
Yeah. Yeah. It's exciting.
A couple, for sure. The most recent one was in Active Storage. And so we think Active Storage is something where Buzzsprout can really help benefit the Rails community, because we have so much storage. We're so concerned about bandwidth. Like, that's a big cost of goods sold for us. And so because of that, we're very invested in how Active Storage works. And so that was the first PR that I kind of worked on in Active Storage. It took about a year, but it's out. So
I feel like when we met up at a conference, we had maybe a hallway track conversation. Maybe it was Sin City Ruby or something. And I feel like, I don't know if you were already through the process or you were working on a migration to Active Storage. What were you using? Was that like Paperclip before that, or how were you managing that stuff?
I think Active Storage is an example of our lack of participation. Like in other areas, we just went with Rails' opinion. So we are always trying to follow Rails' opinion. We're vanilla Rails. So as soon as Active Storage came out, not... we weren't on Rails edge, but as soon as it was general release, we're like, "Okay, it's time to ditch Paperclip and go to Active Storage." And that was the wrong move. Like, Active Storage was not built for what we use it for. And so that led to a whole series of monkey patching to really get it to do what we needed it to do, when we should have really just held off and waited and maybe helped Active Storage become what we needed it to be. But that was years ago, whenever Active Storage rolled out. And so we've just had that monkey patching out there for a while. And so that's why we're like, okay, can we take that monkey patching and actually incorporate it into Rails, you know, push it upstream the way that 37signals generously has provided for us? Can we do something like that?
Do you recall what types of things you were needing to monkey patch? Can you remember much of the lower-level detail? And what was so different about how you were approaching things with Paperclip versus Active Storage? And if I recall the timeline, you know, thoughtbot also kind of said they were going to stop maintaining Paperclip. So everybody kind of needed to figure something out at that point, unless you forked Paperclip and tried to keep it going long term. I believe there's still a fork of that that's still being maintained right now. So this was pre... but tell us more.
Yeah, this was before Brian Treywick, our SRE. So literally it's just some Rails coders. We don't know much about servers. We're not thinking about that kind of stuff. We just write code, and so we just switch it out. So we deploy it, and all of a sudden Buzzsprout goes down, and we're like, huh? Like, what happened? Why did it go down? We're trying to figure it out. We can't figure it out. We roll it back. We're looking at our code. Did we do something wrong? It just crawled to a stop. It wasn't responding. And so, like any good developer, we just roll it out again. Site goes down. So we roll it back, and we reach out to our vendor, and we're like, okay, can you give us any clues as to why this is happening? And they're like, well, whatever you're doing, the number of requests that your server is handling is going up exponentially, and you don't have the resources available to be able to service that many requests.
Well, we start to uncover what's actually happening. When we were using Paperclip, every asset that you link to, they're public assets.
So they don't actually touch our server at all. They don't touch the Rails server at all. But with Active Storage, every request,
So just for context for everybody: if you were using Paperclip, it would return an S3 URL, maybe a CloudFront URL, whatever, but it was just pointing to the asset. So it completely bypassed your own Rails server, right? It wasn't part of the equation at that point. It's like, well, here's the URL, go serve it up from your browser. Right.
Yes. Yes. And so that URL would go directly to the asset. It was still in a Buzzsprout domain. So we had public assets. You can link to your public assets in such a way that they don't actually tax the server. Well, anyways, when we rolled it out, every RSS feed includes, you know, hundreds of links for the artwork, for the episodes, for the MP3s, everything. And so all of those URLs were all of a sudden just getting slammed. And so the first monkey patch that we had to do was to override that and actually link directly to the asset when it's a public asset like that. But it was just in our RSS feeds and a couple other places. So that's the one that I can think of that's the most important for us.
Then the next wave was when we started to really rely on content delivery networks. So CDNs help. When you're starting off, you don't need to sweat it. You don't need to worry. I mean, you can do caching and you can do server-side caching with a CDN, but you don't have to, right? You can get things going. Well, we hit that place where we're like, okay, we need a CDN, we need something in front of our server, because there are so many requests that we don't need to service that don't change. We could just use a CDN to do that. And when we implemented the CDN, again, we had to touch that. We had to monkey patch Active Storage to include links that go to the CDN rather than redirecting them to the S3 assets.
That makes sense. You know, I'm curious, thinking about when Active Storage came out, the context of, let's say, something like Basecamp, where most of those assets are in a project.
Yeah. Yeah. You have to log in, and then you have access that's very dependent on your role, and, you know, you're not just serving up public assets. It's like the open web of RSS and podcasts. You don't know who's necessarily even pulling down these things. It's just people on the internet and machines and caching things, and that's harder to predict, but it also kind of makes it seem a little simpler. So I think that was always an interesting... what it's like when
Active Storage was built based on that domain model. It was thinking, hey, these are assets that are going to be behind a password, so they need to be private. We don't want to just drop in links to these assets.
But that's not the case for everybody. And certainly for Buzzsprout, the majority of our assets are public assets. And so we want to be able to serve them up, and we want to be able to control serving them up through a CDN and even have different controls over how we do that. Whereas right now, if you look at Active Storage, there's some support for CDN, but
It doesn't make any sense because what it does is it downloads the assets to the web server so that then it can get cached on the CDN, but we need it to cache on the CDN. That'll be the next big push, will be looking at how we can get Active Storage to work with CDNs, but right now there's a ton of monkey patching that we've done in there.
Are you doing anything like image resizing, things like that? Like we used to, in the olden days, you know, someone would upload an image, maybe a high-res image, and we'd have to make like 10 different versions of that and push them all S3 into a bucket of all the different versions. And then if I recall, when Active Storage came out it was like, oh, it'll kind of do that dynamically, and there's been other ways you can do that kind of dynamically. So if you change the size of your... Are you doing anything like that when someone uploads like an asset to have different versions for like a thumbnail versus like, so that way you can optimize the images, and where's that happening?
Yeah. This is a great because this is what the PR that just made it through. The reason that we pushed into that was because when somebody uploads, let's just say episode artwork. So they've uploaded an episode and they want to upload the artwork for that episode. When they upload the artwork, we resize it to two or three different sizes. We do it immediately because we know they're going to get requested.
So, I can't remember what the option was, but what would happen is it would schedule a job to go create those images. But the problem is as soon as that artwork is uploaded, it will get requested thousands of times depending on how popular the podcast is, because that podcast is getting hit all the time and they're saying, "Hey, is there anything new? Is there anything new? Oh, there's an episode. Oh, there's artwork. Let me download the artwork." And so what happens is it starts making those requests. Well, then every one of those requests trigger the job to go create the... right.
So the original name for the PR was like immediate variants. The idea that we need to create these variants of the art, but we need to do it immediately before it actually begins to serve up the asset. We need to have those variants ready to go because as soon as the variant is, or as soon as the asset is created, it will be requested, and it will be requested, you know, thousands of times.
Yeah, that's a fun problem to kind of deal with. Are there any other kind of fun things... you also have like audio files you're dealing with, and are you needing to do much on those after they get uploaded, and like are you resizing them or anything, like maybe not recompressing them, or because not everybody... because I know like in different platforms you can have like a, you know, a WAV file versus an MP3 or whatever, an AIFF file, and like
We had that tooling done before Active Storage. So, you know, Active Storage has some capability to do that. Like they even talk about in the documentation being able to process audio and video and things like that, but we already have all that tooling done. So, we still use our own tooling, but what happens is when somebody uploads an audio file, they can upload anything they want, and then we're automatically going to process it. We're going to turn it into an MP3. We're going to use industry standards for everything to be able to make it so that they don't have to worry about how do I prepare my audio to be able to get it out to the world.
When we first launched Buzzsprout, I'll never forget it, it was probably in the first couple weeks. I did not anticipate somebody uploaded a 600 meg WAV file for like, you know, a 30-minute podcast, but it was 600 megs, a WAV. And I just hadn't... like you need a lot of disk space. You need a lot of processor to be able to do that. And so the server, I was trying to figure out again, like because I'm not the server guy, and I'm like, why is the server struggling? Well, it was because the disk space was used, because it had taken up all the space with this massive WAV file. So from the beginning we wanted to be able to help people that don't, they're not geeks. They don't understand the difference between an MP3 and a WAV. And so it was proof that we definitely hit that audience. But it does mean that we need to be able to do that post-processing.
I'm also thinking back to an era when we had to change, you know, like our Apache or Nginx settings to make it allow it to upload files of a certain size and... What does that world look like now these days? Is that even needing to go through anything like Apache or Nginx at that point, or like if someone uploads a pretty large file, what does that kind of look like behind the scenes? Where does Rails come into that, or have you needed to work with or kind of around Rails for things like that?
That works pretty well with Active Storage. So, they upload it because it does a direct upload. Now, we do have some issues with direct upload, but I think that's more of an Amazon issue because they're uploading it directly to Amazon and so sometimes they'll experience the slowdowns. There are a lot of podcasters outside of the US too, and so you hit those edge cases too where they're uploading it. So, where is your bucket located that they're uploading to and all that kind of stuff. But Active Storage, that is actually a really, really nice feature, that they're directly uploading it to S3. They're not even touching our server until it's done uploaded, and then it's just, you know, a key in your S3 bucket, which makes it so much easier to process. In the old days, like you said, we had to fight the web server to allow it to let them upload these massive files.
And we have to upload it and then we'd have to then move it ourselves, and then, you know, there's a lot of levels of different transportation that involved, and we would try to put like a nice little Ajax interface in front of it, and like here's like little progress, and be like, oh, something went wrong, and like where did it break in the process, and
Yeah, so much of that we get for free now, right?
Yeah, it's so true, you know. And think about, you know, you mentioned those types of projects where you've done some monkey patching and you've made some contributions back to the PRs. Are there any other like open source gems or other aspects within the Rails ecosystem outside of Rails, like, Rails provides? I know you try to keep it as vanilla as possible, but where do you tend to gravitate towards? Are there some gems you really, really depended on and you've been really appreciative of, and like payment processing, anything like that, or
I mean, yeah, so we definitely use the Stripe gem to be able to interact with Stripe, but I am just a big believer in, I want to be in control of my credit card processing and things like that. Like I want to be able to switch vendors, and so I don't want to be beholden. And we've all seen it, right? Where you've had a gem that you depended on and then that gem went belly up. Try to remember, there was actually an FFmpeg... So we do our audio processing with FFmpeg, and there was a gem that we were using that we were dependent on that just stopped getting support. And so you get burned like that and you're like, you know what, I'm just going to do it myself. I'm just going to do it myself.
And so credit card processing, it was long before... I mean, we launched credit card processing before even Stripe was around. We were using Authorize.Net. So we had already built a lot of that functionality for like subscriptions and what do you do when the card is declined and how do you reprocess it? So all that code already lives in a library for us. So we don't have a dependency there. But we do have dependency... like I was trying to think of which gems would we install if we were to start a new project, and it's just not many. Maybe like VCR, because VCR is great for being able to do replayable... VCR records your web interactions so that you can play them back without actually hitting APIs, and that's been great for both Tick and for Buzzsprout to be able to record those interactions and run those tasks.
You know, you brought up the Stripe and that you started back when you had Authorize.Net. And I'm assuming back then, like when that timeline, I mean, was Active Merchant around? There was things like that around, right? And that's, you know, I think Tobias from Shopify, I think, initially released that, and we contributed some payments to that. But I always think about, you know, how easy it is and alluring it is to just go gravitate to like, oh, we'll just use the gem that that provides, right? And then so you're using their SDK, and then you also end up with a situation where, I don't know if this is the case in your codebase, but do you have a lot of like column names where it's like Stripe ID, and you know, that's very specific to a vendor, versus like, okay, what's our payment processor ID? And like, because you're using Stripe behind the scenes right now for handling payments and everything, but there's also plenty of companies out there like, oh, they work in different markets, and like not everybody has a credit card, but we need to accept, let's say... what am I thinking... PayPal, you know, because they have a PayPal account and they live, you know, they're somewhere in, you know, in the Middle East or something, and they're like, well, I don't have a credit card where I'm at, so I can't integrate. And so like there's not like a lot of... coupling gets really complicated when you become really reliant on being able to take money from people, right? And obviously want to remove as many barriers as you can there.
So you mentioned that you have written your own code to kind of manage that yourself. Have you needed to bring in other payment gateways, or have you come up with clever... do you have like a philosophy around that? And maybe I just want to get people thinking about that when they're listening and, you know, watching this, like to think about how easy is it not just to swap vendors but to maybe add vendors if you need to for different types of things.
Yeah, I think that's a good way to think of it, is I want to be able to swap vendors. I don't want to be beholden to one. I mean, it's hard because Stripe is so good. Their API is so good. They make it so hard. But man,
Good documentation is so good, too.
Great documentation, but I mean, they're expensive, and they know they own you, and so they can kind of do what they want. And so, it's hard when you're like, "Oh my gosh." Like, and so I'm glad that I don't have all my subscriptions through them so that I can manage that on my own. I could easily switch credit card processors. But what's the reality that I'm going to do that?
Now, we launched a product called Donor Tools. And Donor Tools is kind of a fun project for us. It's to help nonprofits just basically track donations. And Donor Tools, I was like, "Okay, we are not going to use Stripe. I'm going to resist the urge." And so we ended up using WePay. I don't know if you remember WePay, but WePay credit card processing. And so we launched it with WePay and it was great. But then Chase bought WePay, and so we're like, "Oh, this is going to be amazing because Chase is going to turn into something incredible." And then like two years later Chase shut it down. But because of that we ended up having to go from Chase WePay to Stripe, and in the process I was able to... it was the latest code we'd ever written. Like Buzzsprout was written 2008, 2009, and Donor Tools was written like in 2015 or something, and so the code was so much easier for me to be more abstract, like you were saying, not a lot of columns about Stripe ID, or the columns about Stripe were in a delegated type table for that credit card processor. And like, delegated types, that wasn't even a thing. But it was a great case study for us to be able to make it so that I could easily swap out different merchants to be able to process, but we don't have that in Buzzsprout. Buzzsprout would be painful.
When you go back to and think about the Paperclip to Active Storage migration, was there anything you recall needing to do? Did you need to write any one-off scripts to like migrate assets into a different format for that, or because you mentioned like, oh, we swapped it out and we flipped this, we've deployed it and things, but did you need to roll that, and was it complicated to kind of roll it back and still have everything kind of work in the meantime?
Oh well, it was broken. It was broken for a while. The way that we did it, and I can't totally remember, but I know that we had millions and millions of assets. I think we duplicated them into a new bucket that we were going to use for Active Storage so that we could run both. You could run Paperclip or you could run Active Storage. So, the only problem was if somebody uploaded something new since you last ran your script or they deleted something since you last ran your script. So, there was like this true-up that had to happen, and all of that was done through scripts that you're running from the console.
So it wasn't necessarily... wasn't something you could easily do in like a phased, all right, we're going to start incrementally doing this with like 10% of our customers at a time, and... it was kind of like an all or nothing, it's going to work or it's not going to work.
I love that. I love that when you can do that and it works out, but sometimes you get a couple things. But I obviously know that maybe in the context of the type of... obviously people want their podcasts to work and be listened to and they get their ads served and all the other things, and upload new things. They don't want to break their publishing schedule. So I'm not saying it's not, but it's not like you're migrating a bunch of confidential HR details from one system to another and people are like, where's my taxes? You know, it's like... there's a little bit more wiggle room... we're servicing are not users.
A lot of the requests, I mean, Apple... Apple hits our RSS feeds a ridiculous amount of time. They'll hit one RSS feed like thousands of times in an hour. It doesn't change that often, but they're hitting it thousands of times. So those are the kind of requests that hit the RSS feed, are typically feed readers, and they're just polling essentially, but they're not respecting the goodness that we get with Rails, right? That we can have it so you can do conditional GET requests, but they have to respect the conditional GET request. Otherwise, you're downloading the whole RSS feed and parsing it every time. But anyways, all that to say that there's a little bit more flexibility in us where the RSS feed, if we run into an issue for a little while, users aren't actually being affected by that. Now, the feed readers might be affected by it. So I might get an email from... I did get an email. I can't remember what we broke, but I got an email from Amazon, because Amazon ingests podcasts, and they're like, "Hey, did you guys change something?"
I met a... you know, we've worked on some projects for some of our, like one of our largest clients is Nike, and we've done a lot of stuff that's public facing for them, like their news and RSS feeds that feed into like Apple News and things like that, and so we've dealt with a lot of fun Apple-specific hitting RSS feeds a little too aggressively and having to kind of like massage that in some ways. I'm also curious, like, have you been able to lean on things like... what other... like what is it, RSS feeds have, is it ETags or something, so that you know, like, if something's changed, or do you
Yeah.
Yeah. So Rails gives it to you out of the box. You can set your ETags so that now it can respond to a conditional request, which basically says, hey, here's the last ETag that I had. If you have a new ETag, send me the request, otherwise just send me not modified, a 304 I think. And it just keeps going. And so some feed readers respect that and it works great, because then they can just basically hit our CDN and say, "Has it been modified?" And they don't actually have to pull it down. But Apple, they have two different ingestion engines, I'm not sure why, that run, and one of them uses it and one of them doesn't.
If anyone works at Apple in these areas, you should listen to this episode and maybe have someone put a ticket in to get that sorted out for us.
I've gone back and forth with him about, you know, because Apple is so green, and I'm like, I don't think you understand how much energy you're wasting processing these RSS feeds.
You know, it's funny, I'm not going to name names, but there is a competitor to Buzzsprout that I use for one of my other podcasts, and one of the biggest gripes is, because I tried to build a static site version of it to add some other features on top of the website for the other podcast that I have, and they don't send an ETag. And so every time I pull, I have to literally fetch every single episode and just see if anything's changed, when I'm like, oh, if I want to go fix an edit for some content on two episodes again because there's a broken link.
I got to rebuild the whole site again. And I'm like, this is so ridiculous. So ridiculous. And they've not
But think about it, I'm not a genius for doing that. It just came with Rails. If you stick with vanilla, you get this great business benefit. Because I remember having this conversation with Brian, my SRE, and I'm like, what can we do? Because these guys are just hammering the RSS feeds and it's costing us a fortune because of all the bandwidth we're spending, blah blah blah. And he's like, "Oh, you know, two lines to add an ETag."
And as soon as we deployed it, all of a sudden we saw the 304s. We saw people respecting the ETag and using conditional GETs. So it's like a great example of
Yeah.
Okay. Somebody smarter than me figured that out.
I appreciate that. Thank you, Rails.
Yes. So, speaking of large volumes of bandwidth and data and collecting and downloading statistics, so I know that you've been downloading statistics. I think maybe on a prior conversation you mentioned maybe since 2014 you've been collecting a lot of data about all these podcasts, I think it was maybe you said 2014. And I think you mentioned earlier as well that you've integrated with ClickHouse. So how has that come into play, and how has it kind of shifted how you think about collecting and storing data? And maybe for anyone that's listening that's not that familiar with ClickHouse, because it's come up on a number of conversations in the last several months that I've been part of, but what is ClickHouse? Not here to advocate for them or against them necessarily, but how does that kind of fit into what you folks are working on over there at Buzzsprout?
Sure. So it's funny because, you know, I talk to other SaaS founders and I always tell them, you know, don't solve problems you don't have. And I'm sure I'm stealing that from David or Jason or somebody smarter than me. But it's something that we've always said, you know, don't solve problems you don't have. But then when 2020 hit and Buzzsprout and podcasting really exploded, we hit all those problems that we said don't solve problems you don't have. And one of the problems that we ran into was scalability on our stats, because we have data that's just growing all the time. So we started collecting stats when we launched in 2009. But when we first, the only data we were collecting was a single number. How many downloads did this episode get?
Right. That was the only number that we were
Total number.
Yeah. Incremental numbers, pretty easy, but then
In the episodes table itself, or did you have a different table for that, or
I can't remember, I think it was a separate table. But it was a simple piece of information. But now let's fast forward to 2014. So we're like, okay, we're going to now offer advanced analytics for our customers. And so now we're going to tell you, based on the IP address, we're going to tell you the location, we're going to tell you what kind of podcast player was it, you know, Apple Podcasts, was it Spotify, we're going to tell you all this different information about it. But in order to do that, we need to store that information. So I had a table that was filled with all of this data, and then we would just run queries against it. But that table is never going to slow down. Like, it's never going to stop. You're always going to query the data. And you know, there's like the concept of hot and cold data. Like, nobody cares about what your analytics were on your server from a month ago, right? For a five minute window. You might care about it over a larger window, but you don't look at the same. But that's not true with podcasting. A podcaster cares how many downloads did they get in 2015 when they launched that episode. You know, they talked about this thing and they want to be able to see those numbers all the time. So anyways, that just makes it more complicated, because that data has to be fresh. It has to be available to be able to serve it up. And so as it grew, that data got harder and harder to serve.
That sounds painful. Do you, you know, like with that amount, volume of data, like, so what were you able to do then? Were you able just to entirely move that over into something like ClickHouse, or was that like a phase?
So the first iteration, so I'm literally, I'm going to RailsConf. I'm talking to people. I'm like, how do you, like, what do I do? How do I solve this problem? And I'm hoping there's a magic bullet for it. I'm hoping there's something, and I don't get anything. And so that's funny, that's why I want to pitch a talk for Rails World, to give a talk on this topic, because I went to so many RailsConfs looking for this topic. But anyways, so this database is growing and I need to be able to make it accessible. So what I did was I came up with a solution where I would create these summary tables, which were essentially every hour it would summarize all the data that's most recently come in. So it would take all the data from the last hour and it would populate a table that showed episodes by date, episodes by location, episodes by user agent. So that way each individual table could just summarize it, and oh, magical. It worked out great, except that those tables continue to grow and grow and grow, and eventually they got to the place where I'm like, I need another solution. I need something else. Now, you can throw more CPU, which got us all the way through 2020. Was, you know, just getting into the Amazon ecosystem with Kubernetes, that allowed us to kind of scale a little bit horizontal with our database, but we needed something, that process to create those summary tables. I mean, at one point it almost took an hour, and it runs every hour. So if it takes more than an hour, you're in trouble.
Yeah. And so we were constantly battling with these summary tables and the summarizing process that runs. So that's where ClickHouse comes in. And really, it's more about understanding OLAP databases, and ClickHouse is just the one that we chose. But I've always thought about relational databases. I'm a relational database guy, and it just doesn't make sense when you start doing OLAP stuff. Like, in a relational database, you want your stuff in different tables and you want joins and indexes on the joins and things. But with an OLAP database, you think more in terms of columns of data, and you just shove it in there, and it's super efficient at bringing back columns of data and summarizing columns of data, counting, maximizing, adding, all those kind of things. It's just really good at. But you have to understand how to write your queries in such a way to make them performant. So that's what we began doing, was implementing an OLAP database with ClickHouse, and we ran it in parallel with our summarization process. Actually, our summarizer is still running today, because we still have some queries that are still using those summary tables, but in the next work cycle, the next six weeks, we'll get completely off of it. So now we'll be totally on ClickHouse for all of those analytics.
Nice. It's definitely a mental shift, I think, for folks there to think about relational databases versus thinking about it OLAP. I'm curious about, you know, and for those listening, because it's like this common pattern that we get called into doing some consulting stuff where you'll try to pre-optimize. Like, all right, we have some slow areas. Maybe it's like a dashboard for some pages where there's some reporting and things like that. Like, okay, this is really slow. So there's this very natural progression. We're like, okay, well, how can we speed this up? Well, maybe we could precache this. So maybe you're putting like a summary table, or we'll have a different table, or we'll have some cache columns or whatever. You know, there's a lot of different patterns people do, and maybe that moves to a background job, but then they're doing it for everybody. You know, they're doing it for all the podcasts or whatever, and they're going through and cycling. Oh, is there anything from this? So they're having to check, and then they're like, oh, maybe we can do that just for the ones that have uploaded podcasts in the last hour, or data from the last hour. So you're not cycling through everything, because that number will just keep growing as you add new customers and more users. And then they're like, well, this isn't working either. This is taking too long. So it just becomes like they keep fanning out the problem in an interesting way. And then so we'll come in sometimes, and we've seen people come up with really clever tricks, like, what about, you're optimizing a lot of data for people that are not even logging in to look at the data, you know, but it's there in case they do show up today. But it's like a Sunday at 11 p.m. and you've got an hourly process reaching all the stuff, and there's a bunch of CPU time, like, yeah, whatever, let the computers do the work, but nobody's ever going to see the data, like very, very small. And so they're like, all right, well, how do we only optimize it for the people that are showing up? Like, well, if they hit the web page to log in, we can see they're logging in. I've seen all these clever things that people have done, and we've helped implement some of these, maybe overly. Oh, someone hit the web page, we got a cookie, they haven't even logged in yet, but we're going to fire off a background job and pre-cache
To make the request
before they hit the dashboard, it's there, you know. Like, we can do this in 20 seconds, so let's start doing it as soon as we notice that they're hitting our website.
Seems like
I feel like we reached the extent of all of those things. Like, we reached the end of it, and that's when we're like,
okay, there needs to be a new tool in our tool belt to be able to accomplish what we need to do. And that's where OLAP fit in. And it was super intimidating, but when you get into it, Rails has made it so, so easy to be able to have multiple databases. I mean, some of the things that it does, I just cannot believe the way that it works, but it feels so natural to have a second database that you're able to just reach into and pull Active Record objects, but it's coming from an OLAP database.
For anyone listening out there, could you just describe how does the data get into the OLAP database? You mentioned using Active Record to fetch it. Is it just extracting data from your relational database itself and then you've configured it, or do you have something like Active Record actually writing to the OLAP database directly, or a bit of both?
Yeah. So this was something that we talked about a lot, because as I talked to people, and really a lot of this came together at Tropical Ruby. I went there and I was like, once and for all I'm going to answer the question. I'm going to figure out what is the solution, and I'm going to ask all these intelligent people, how would you solve the problem that we have? And I kept hearing, you know, OLAP, OLAP. But a lot of them fixated immediately on something like Kafka, which, Kafka does the, you know, you're putting information in and you're streaming it into the OLAP database. And maybe that's where we're going to end up eventually, but what we ended up doing was much simpler. Because we already ingest the play data from the logs. So we're processing logs all the time. We're just constantly adding records to our relational database. We're just adding play data, like, okay, this episode was played. But there's processing. There's a lot of Ruby processing that has to happen to make sure that the stat is a real stat, you know, that it wasn't a bot, that it wasn't multiple requests from the same IP address within a certain time period, all these kind of things. That's all Ruby processing. And so we do all that Ruby processing and then we put the row into the table. Then what we do is we have another job that right now does summaries, where it's summarizing into summarized tables. Instead, it just puts together a massive, massive update, and then, boop, pushes it into the OLAP database, and that's it. So it inserts like 50,000 rows an hour, and it'll just drop them into the OLAP database. And then the OLAP database is very performant. Like, it can handle that request and it's still handling all the select requests that are coming in. So it's still giving reporting data while it's updating. And so that process has worked out really well for us. I'm not saying that we won't go to something like Kafka, some type of pipeline process, but for right now it's working really well for us.
That's interesting, because I was also talking to someone else recently and they mentioned that the strategy that they took as they scaled up was to use something like BigQuery or something, where you would have something else sit on top of your production database, and it's like mirroring that data, and then it's way more performant. So basically the queries to pull that data out are way more efficient because of however that magical beast of a database is. But there's all these different strategies that people kind of experiment with. So for anyone listening, if you've got interesting ideas or have solutions for how you navigate these things, definitely reach out to us and let us know, because I think we're always curious to keep iterating on our
And don't be intimidated by multiple databases. The work that the open source community has done for Rails, and I think specifically, was it GitHub who pushed the multiple databases into Rails, all that work?
I think that was Shopify, but
Shopify, Shopify.
Right, yeah. But they saved us. They took all that complexity and compressed it to a point where you can do multiple databases very, very simply. It was like two lines of configuration to be able to get it connected, and then it felt really natural from then on. So whether you're using, you know, a big
query, or you're using ClickHouse, or you're using some variation of all these other... I'm trying to remember some of the other, Pinot. There's all these different databases that are out there that are essentially OLAP databases, that they are designed to do the kind of thing that we're talking about.
Yeah. It sounds almost like it's a boring change to make in some ways, and that's maybe a good thing. You know, it's not
It's not boring yet. It's not boring yet. But, well, a two-line change, I think, or coding change, to be like, it's not intimidating.
It was two lines to configure the database, but you had to rewrite all your queries. So you had to rethink your queries to how would you write it, and you're doing things that don't make sense from a relational database standpoint. I'll give you a perfect example: in a relational database, you're trying to normalize the data, right? You're trying not to repeat yourself, so that you do joins to other tables. But in OLAP, it's one big table. It's one big table. So there is a column that is the user agent, but then there's another column right next to it, which is the podcast app. Well, the podcast app is just a function of the user agent. In a relational database, that would be in a separate table. But in an OLAP database, you want to put them right next to each other. You want to denormalize the data. You want to have it right next to it. So then I can run these, you know, incredible queries that you couldn't... I mean, there's literally queries that we're running now that we couldn't have run based on summary tables. They just weren't performant. Locations, like, it's denormalized. There's a location ID, but then there's also city, state, country, you know.
You know, something you touched on that I don't feel like I hear often about is that you're comfortable staying small even as Buzzsprout is growing as a business. So, how do you feel like Rails helps support that decision?
Yeah, I would say I'm more than comfortable. I desire to stay small, right? I enjoy the small business. I enjoy what we get to do, and Rails makes that possible because you can be so productive, and now you throw AI into it. I mean, that's a multiplier on top of a multiplier. So I feel like it's cheating, because we're able to do so much with such a small team. And so we talk to our, you know, competitors that are much larger than us in terms of number of people. We have more podcasts than they might have, but they have more people, and they don't believe us. Like, no, there's no way. There's no way you do that. StreamCare, our medical product, you know, we have one developer. We have one developer that's worked on it, and competitors in that space, they're like, no way. They have hundreds, hundreds of people, you know. So I think it's Rails. I think it's a superpower.
That's awesome. Are there any problems you feel like you have, though? You mentioned maybe needing to hire an additional person so that someone can enjoy their vacations, or the bus factor, but are there any other things you think are maybe a slight downside to kind of staying small?
Yeah, I think it's hard to do what Basecamp has done in terms of around-the-clock support, so that people are actually supporting in their own work time zone.
Yeah.
So, it's one of the things that we've learned. You talk about marketing a SaaS product. I did not know this, but having an incredible support team is a massive feature for your product, and there's no code involved. It's just having incredible people that you invest in, that you allow to be good advocates for the customer. And man, it's been such a benefit for Buzzsprout, because people love our support team. They love interacting with them. But because we're small, I really don't want to have people spread out all over the world to cover all the different time zones. And so that's a bit of a challenge with a small team.
Yeah, I appreciate that. You know, I'm also curious, do you have an ethos about when you decide you're going to pay, say, monthly for something versus building something yourself, like tapping into some platform or SaaS product to help, like an add-on for your product?
I don't know that I have a specific ethos about it, other than I don't like being beholden to other companies. And so if it's something that's mission-critical, like, you know, subscriptions for who's paying us monthly, I don't want that outsourced. I want to be able to do it in-house.
Now, that being said, there's nothing wrong... I mean, if I was starting a SaaS product today, I would absolutely use Stripe, and I would absolutely use Stripe subscriptions, because you can always build it later. You can always bring it in-house later. But for where we are as a business now, we can absolutely do those things in-house. I'll give you a great example of it: we launched AI inside of Buzzsprout to listen to people's podcast episodes. So when they upload their episode, the AI will listen to it, and then it'll give them ideas for titles, descriptions, chapter markers, social media posts, a blog post, all this kind of stuff that AI is really good at. It's really good at coming up with those drafts, right? And
what it does is it helps podcasters finish that last... You know, they've recorded the episode, but now they need to go live, and they've got to give it a title. They've got to do all these things. So anyways, when we originally did that, we did that with a vendor that we worked with. So we would actually send them the audio file, and then they would send us all the AI assets. But then, as that feature was adopted and we saw that our customers really liked it, we brought it in-house. And when we brought it in-house, we now had control. We could make it better. We didn't have this dependency on them. We could actually lower our pricing, you know, things like that. So,
Do you know when there's ever going to be a conversation about when we can make the episode descriptions longer?
You know, that's driven by Apple.
I know. I was like
Apple somehow still has a stranglehold on podcasting, because, you know, I mean, they were the benevolent dictator of podcasting for the longest time.
It's such an interesting... I'm like, why is this so short? I want to add more details. I want to add more links, and it's just like, all right, well, I guess there's a limit to this. I'm like
I know there's talk. I know there's talk about just extending it and then letting Apple catch up, essentially. Catch up.
Yeah. I mean, just as a podcaster, most of what I want that for is for the benefit of what we're displaying on the websites, right? I think, yeah, maybe in a podcast app and stuff like that, but I'm just like, I want the... what are the AI bots and Google indexing and people browsing and finding useful links and stuff like that. So that's where I want the richness to be. I don't know if people are spending as much time in the apps clicking around all the links. Maybe they are. I don't know. I don't know how to track that stuff.
It depends on the type of podcast, right? There's some podcasts that lend themselves to supporting information, where I want to be able to go read it, or I want to be able to follow links, or I want to be able to see things.
Yeah, I get that. So, you know, we've definitely covered a lot of ground so far with you, Tom. So, when you step back from all this, and you've kind of alluded to this, but maybe for a good sound bite, how has Rails actually been part of, let's say, Buzzsprout's secret sauce?
I think everything that we've talked about in this call. Buzzsprout has been able to move faster and more nimble as a result of sticking to vanilla Rails, being able to capitalize on when features and functionality are exposed in Rails. We get to take advantage of it immediately. You know, we didn't talk about caching. Caching is a great example, like fragment caching. I mean, that wasn't something I could do when I originally started coding in Rails. Well, now it's so easy. And then with Solid Cache, we got to the point now where there's very little evictions in our cache. So much of our content is just served directly from the cache. We got all of that for free, all of that benefit of very smart people putting together an easy way to be able to create these caches. Okay, that's just one hyperfocused example, but it has benefited from Rails, by doing things like that where we can just move quickly. We can take advantage of the latest technology, and we can do things that we couldn't have done without the framework that we have.
That definitely resonates, and I can definitely concur with that. You know, I'm curious, Tom, is there a book, or like a technical book, that you find was very foundational, that you find yourself still recommending to peers?
Sandi Metz. Sandi Metz. I mean, I still go back... I've read her book multiple times, the Practical Object-Oriented... the POODR book, POODR book, and her videos of different talks that she's given. I think Sandi has probably impacted me the most in terms of the way that I code. And so anything that she's done, and then everything that 37signals has ever put out, that's really impacted us. I feel like we are our own version of it. Like, we've kind of settled into what does it look like for Higher Pixels, for our company? What does it look like to embrace some of these things? But we've, you know, read and listened to all of the Rework stuff.
Awesome. I'll definitely include links to Sandi's book in there, and also to an episode where I interviewed her on my other podcast, Maintainable, a couple years back. And I also really
She is an incredible asset to the Ruby community.
I know she's not been at any of the conferences in a few years, though, right? So
I know. I know.
Yeah. We miss you, Sandi.
We miss you, Sandi. If you listen to this, you've made a huge impact on our business, and we'd love to see you again. We'd love to see you at a conference. I'd love to hear us talk.
Likewise. You know, you briefly just touched on AI, and I hadn't planned on digging into that, and we've kept you long enough, but I'm curious, is there something that you believe about building software and SaaS products right now, today, that you believe more people will agree with in 5 years from now?
I think we're all in agreement. I feel like we're all in agreement that AI is making our life better from a coding standpoint, right? I don't know about what's going to happen with our phones and stuff at home, but when we're talking about, as a developer, being able to have a partner in AI to go over ideas and strategies and work together with it, I just feel like it makes it fun. But I don't think that's controversial. It used to be controversial, but I think everybody's kind of on board with it now, right?
I want to agree with that. I feel like that's... I was a little bit of a slow comer, a little skeptic. I'm happy to say that I was a skeptic, but I think it depends on which bubbles you're kind of hanging out in. And I think you can definitely go to some social media sites right now, and it feels like a completely different world, in a weird way. And I'm kind of rubbing up against that a little bit with even running open source projects myself, where I'm a proponent of using AI as long as we're open and being transparent about it. And some people are like, "I don't want to use your software project anymore because you're using AI." And I'm like, "Oh, I didn't know that it had to be this or that." Like this binary.
I think that has to go away, right? Like, in five years, there's no way that anybody's going to say something like that, because you're not going to be able to... That would be like, "Oh, you can do it, but you can't use Google." What? You have to tell us if you used Google? Well, of course I used Google. I had to look up something, you know?
And we got into a big conversation about this, where specifically I'm like, well, what is AI even? Like, when you're in the context of, say, using VS Code, I'm like, is AI only when you're interacting with the agent in a prompt, or is it if it autocompletes the end of your line? Like, what? Right, where's the distinction there? I don't know what actually happened behind the scenes there. So do I need to disclose that? Because I don't know that we can hold people accountable to that. So, I don't know. It's an interesting time to be. There's definitely a lot of things moving here. And so, I won't hold you to it, but we'll check back in five years, Tom.
Deal.
Well, Tom, this was great. Thanks for walking us through the long arc of building Buzzsprout on Rails, and for supporting the Rails ecosystem much more broadly, and for helping host this podcast. So, thank you so much for coming on On Rails, Tom.
All right. Thanks for having me.
That's it for this episode of On Rails. This podcast is produced by the Rails Foundation with support from its core and contributing members. If you enjoyed the ride, leave a quick review on Apple Podcasts, Spotify, or YouTube. It helps more folks find the show. Again, I'm Robby Russell. Thanks for riding along. See you next time.
Article published