SEASON 2 - EPISODE 177 - DECEMBER 17, 2025

Open source outside the box

Open source has always played a big role at 37signals. This week, Jason Fried and David Heinemeier Hansson share why they’re drawn to working in the open, and how that mindset carries into their newest product, Fizzy.

Watch the full video episode on YouTube

Key Takeaways

00:12 - Why open source continues to matter at 37signals
05:12 - Sharing work publicly pushes quality higher
09:55 - How open source fits into Fizzy’s SaaS setup
15:15 - Treating open source as a gift
19:41 - Getting direct feedback in unfamiliar but fun ways
22:56 - How the team decides what goes into Fizzy and what doesn’t
24:34 - A Danish language lesson

Links & Resources

Transcript

Kimberly (00:00): Welcome to REWORK, a podcast by 37signals about the better way to work and run your business. I’m Kimberly Rhodes from the 37signals team joined as always by the co-founders, Jason Fried and David Heinemeier Hansson. Well, if you’ve followed 37signals, you know that we are big fans of open source and we’ve open sourced many of the technologies that have been developed right here, and I thought we’d talk a little bit about that today, as David likes to call them our gifts. And with the launch of Fizzy, we’re doing some things a little bit differently, the first time we’ve launched that product as both open source you can use on your own servers or as a SaaS product. So before we dive into the Fizzy portion of this, David, let’s just talk about open source in general. Tell us why you’ve been such a fan of it, why we as a company feel so strongly about sharing those things with the world.

David (00:46): Well, I think the first reason is that this company would not exist in this form as a software company without open source. Literally everything that we have ever built has been built on top of open source. So even though we make a bunch of open source software, we only make that and we’re only able to make that because everything beneath it is open source. We use the Linux operating system for many, many years. We used it just on the server. Now we also used it on our developer platforms or our developer laptops. We use open source databases. We use open source, pretty much everything, open source programming language, Ruby. So right from the inception of 37signals as a software company, I thought I had both a moral but also a practical obligation to give back to that open source culture that had enabled everything that we do and made it affordable to get started.

(01:40): I remember a time when open source was not as prevalent as it is now, and I remember what it was like to have to consider buying a database license and paying someone a lot of money before you even knew if you had anything. I think open source has simply just opened the doors to so many more people to be able to create things and get going before there’s any economic activity or value to what they do. But I think it also even goes deeper than that. I just love being able to see how things work. I love being able to take something apart and inspect it and learn from it, and open source allows that better than anything else when it comes to programming and system development in general. There’s the open source, like we do it with Ruby Rails and all these other things where you can look at the backend code.

(02:29): But even before that, the whole reason I got into building for the internet was this thing called View Source, which is essentially open source, which is the right clicking on a website and going down to the little menu that says view source. And then you could see how the HTML code is laid out for a website. And in the early days of the internet, before we had transpilers and Minimizers and all these other frameworks that made a lot of that source a bit of a gobblygook, that was a way to learn. That was a way to figure out how the web was put together. Oh, they used this clever CSS technique. Well back then it wasn’t even CSS, they used this clever spacer gif with a table and that’s how you lay something out. I’m sure Jason had looked at many view sources along the same ways and then once we got into the role of it, of what we’re doing and how we’re building, it just felt like a more productive way to work.

(03:25): I was going to write all this code for something like Rails for example, anyway, so if I could then also share it as open source, we could get a bunch of other people to help out, to find bugs to implement new features. And that whole flywheel effect of everything you use is open source. Everything you build, at least initially on the infrastructure level is also open source and you just accelerate that whole process of sharing and of learning and of finding people in the community that you can hire has been absolutely instrumental and fundamental to the success of 37signals. So, I’m an open source mega fan, super fan. Everything that I do on the backend level since day one has been open source. Everything that we do on that level that hasn’t yet been open source, I’m sort of itching to publish, itching to get something out there for others to be able to benefit from and help in some cases collaborate on something that we built anyway.

(04:26): This is the great economic model for me that we have to build this software regardless, regardless of what happens with it afterwards, we have to build it. So the investment is already made. By the time we’ve made that investment, distributing it for free for everyone seems like such a no brainer. There is no marginal cost to open source if you disregard sometimes a little bit of maintenance burden or dealing with ungrateful recipients of the open source gifts who you occasionally do have to flip off when they get a little bit too ungrateful about the gifts that they’ve received. But other than that, there is no marginal cost to it and that just makes it an absolute no-brainer to do.

Jason (05:11): One thing I would add too, I did learn how to do what I do way back in the day by viewing source. I’d view different websites and look at their HTML and learn. And I think one of the things that it sort of got me to think about actually was is hygiene. And what I mean by that is when people can see your code, you tend to just make it a little bit better. You care about how it’s laid out, you care about how you do it, you care about the techniques that you use because there’s no secrets. Everyone can see how you’re doing it. And I remember way back in the day when I was making websites, I took a lot of pride in basically tabs and spaces and lining things up in a certain way that just looked good. And I think it built good habits in me to care about that.

(05:53): And I think that’s true today that when you release something open source before we launch something, David’s very clear about going through everything and tightening everything up and like, do we have to do that? No. It’s personal pride, but also it’s reputation in a sense. And you want to make sure that if people can see the work that you’ve done, that you’ve done it well, you’re not cutting corners, you are painting the back of the fence as they say. You’re signing the inside of the case essentially by doing things right. And when you invite people in, it just encourages you to know there’s more eyes on it and so encourages you to really figure out how to make this thing just right. And I think it helps you take more pride in your work actually. So I think that’s another side effect of this whole thing.

David (06:28): And what’s so beautiful about that pride in the work is that it’s viral. Others who then see that pride in someone else’s work, they’re going to be more likely to take pride in their own work. They’re going to be more likely to try to step up, oh, that looks really good. They’ve really put a lot of effort into it. In which way can I put more effort into my work? Maybe I’m going to pick up some tricks here. The reason it is so elegant or clean is because they use this technique or they use that technique and I hadn’t considered that before. So there’s a nice viral leveling up of the entire industry When you share how you build things and you take care to build those things in a meticulous careful way, that then feels very gratifying that it’s a bit of a teaching hospital.

(07:16): That’s a metaphor we’ve used occasionally where we’re not just trying to cure the problems that we have. We’re trying to raise up an entire bar of practitioners and see more net benefit to the world. I mean it’s about as high flying kumbaya as you can get, but it also, it’s easy in my opinion to do that even from a commercial perspective because it feels like it’s free. In fact, it feels like it’s better than free. For all the reasons Jason says, when you up your game and you take more care and effort to make something really nice, you’re paying yourself dividends. And then that everyone else also get to get the dividends from that in turn just feels like such an additive process, like the best of what commercial software development can be, that it has these positive externalities. So much of what we talk about, especially with internet culture is all the negative externalities. So when you’re building things that are ad-based or whatever, you need to gather a bunch of data and it’s like, okay, well that may be true. And then there’s this other realm, there’s other domain where the externalities are basically just pure unadulterated goodness. Like who’s going to object to putting beautiful code that others can use to build their things into the world? No one sane that’s who, well, maybe we’ll get to the insane in a bit, but…

Jason (08:43): The thing I would say is that in some ways it’s proof that things can be done a certain way. I’ve been paying attention to the feedback when we launched Fizzy on the open source side of it, and one of the things people were shocked about how Vanilla it is actually. No build and a lot of Vanilla Rails, not a bunch of different extra frameworks and extra libraries and stuff. It’s just like the basics. And you show that it can actually be done this way. Nobody would believe that it could be done this way. And you can tell them, but they still might not believe you. But when you look at the work and you look at the evidence, then that speaks for itself. And so it’s another way of just saying, yes, it can be done this way, which is something we’ve done all along.

(09:21): I mean our companies try to be as transparent as possible, written books about this. You don’t need a big huge company, you don’t need to raise a bunch of money, you don’t need to do all these things. You don’t need to work 120 hours a week or 80 hours a week or 70. You can do all these things. A lot of that though is on faith because people can’t really see what it’s like to work here unless you work here. But when you look at code, what’s driving this program? Why is this program run the way it runs? How does it run the way it runs? And you can look at the actual code. That’s as close to proof as you’ll ever get. And so it’s kind of a really nice side effect as well of opening everything up.

Kimberly (09:54): Okay. Let’s talk more specifically about Fizzy. So this distribution model is one that we haven’t done before where we have one product that is both SaaS and open source. Tell me a little bit about the decision to do that first of all and then we can kind of go into some of the logistics for that.

David (10:12): It’s quite interesting because the majority of the open source work that we’ve done over the last 20 plus years has been on the infrastructure side. Ruby on Rails, Hotwire, Kamal, all these different projects are infrastructure projects. They’re not things that users interact with directly. And I do think historically there’s been conventional wisdom that you needed to keep some of the sauce secret because there was some unique elements where you might take 90% even of what you build and you give that away, but you got to hold 10% back. And we really question that with Fizzy, not because we were the first to question this paradigm. There have been others who’ve done a similar thing where they’ve released entire product as open source and then they’ve tried to commercialize it in a variety of ways. So in that regard, this isn’t pioneering some new deep dish here.

(11:13): Others have done it, but for us it was definitely a bit of a barrier to think that there’s a project we’re doing here that’s not just done as a free, we’re just going to give it away thing. We’re going to try to commercialize it. We’re going to try to make a SaaS version of it, but then realizing, does it really matter in a commercial sense, in an economic sense, if we take all that code and just give it away for the people who want to run it on their own? Partly influence by the way from the lessons we took out of ONCE. With ONCE, we thought maybe there’s a model here where folks can run the software themselves and they’ll pay us a one-time fee to do it. That turned out to be maybe too early. It wasn’t the sort of slam dunk runaway success that would’ve inspired us to just do this for everything.

(12:02): We had some nice base hits or recouped some investments on the work that we did with Campfire, for example, that followed this model. But it was also clear that there were some blockers here, that convincing people to pay a one-off fee for something they had to run themselves is not yet a major market. But, there are other aspects of that market, if you take the commercial aspect away wave, you take the price away from it that actually is working. There are a lot of people who are installing say a WordPress on their own machine and running it just by themselves, a Plausible or other tools of this genre. That’s always been true, especially in the blogging world that WordPress is part of. I think both when Jason and I started, we both started with self-hosted software before there was SaaS we’d run something like Movable Type was the system from way back in the day.

(13:00): I think actually maybe Blogger, Evan Williams’s original product was one of the first SaaS versions of kind of doing that. It was more common that you actually ran your own server. So there was something here and we thought, do you know what? If the market for selling that as a product has atrophied to the point that it really needs a long-term recitation to get back into viability, could we do something else? Could we do this setup where the SaaS version is where we recoup our investment and then we get all these positive side effects of giving the source code away for free for the entire thing so people can see exactly how we built products, and not just the people who are buying the software that we sell because we sort of did it with Campfire, with the ONCE model, we would sell the whole product and you got the source code and you could look at the source code, but the license prohibit you from sharing that source code.

(13:57): Now we’ve gone the other direction and said, all right, you get the entire source code. We will reserve one aspect of this for ourselves, which is the right to commercialize it, to profit off a SaaS version. But other than that, you can do whatever you want. You can install it on as many servers as you want. You can extend the software. You have almost all of the traditional rights that you would associate with open source with the caveat that the SaaS part of it is reserved. And we reserved that upfront because we’re very clear in the license. It’s this one paragraph of an otherwise MIT derived open source license. And this is where there’s some controversy on the interwebs about what that word or term actually means, what is open source, which I think very much is open for interpretation and debate. And it just seemed like this was the right next step of the evolution. And this is one of the things that very often happens when we try new experiments that not all of it is just right or it’s not just right right now. And we then take certain aspects of it, all right, let’s try that again with this twist. Let’s try again with this variation. Fizzy is a spiritual variation on the ONCE theme where we just carve up the economic rights a little bit different.

Kimberly (15:15): Okay. David, tell us about, because I’ve seen some things online like on Twitter, people getting riled up saying this actually isn’t open source. You kind of started to touch on it, but why are people so worked out? Honestly, I don’t understand.

Jason (15:28): Nor should you.

David (15:29): It does seem strange from like the normal, non-nerd neck beard perspective, that…

Kimberly (15:37): Yeah, I saw someone say, Fizzy is as open source as North Korea is a democracy. And I was like, what is happening right now?

David (15:47): This is, it almost a variation of the bike shed problem, like painting the bike shed where this is so low stakes. Here’s a gift, the source is open. Let’s quibble about whether that is quote, unquote open source. Now, that’s the least charitable description of those objections. If we’re going to give it the most charitable interpretation of it, some of this has historic roots all the way back to when open source was taking off in the nineties and there was a quite concerted effort from Microsoft and Oracle and others to embrace, extend and extinguish, to take the open source model and twist it into something that had very little to do with that initial open spirit of sharing, and try to undermine it. And I can see where people are coming from with that historical perspective. But also like, dude, that’s 30 years ago. We’re in a completely different place now.

(16:49): Open source has won. Open source is the dominant model for so much, if not nearly all of infrastructure, software distribution. We’re in a completely different space. And secondly, now that the threat that Oracle or Microsoft could undermine open source to the point of destroying it has passed, can we have a reasonable discussion about what that actually means? Because what I find so curious is that some of the most fervent advocates of the original open source idea, they talk about other licenses, like there’s something called the GPL, which is a form of open source license that’s official open source but also carves out all sorts of restrictions on how you can use the source code. Like for example, if you take the source and you make extensions to that source and you distribute it, you are obligated to re-release those extensions. You have to release open source to the rest of the community.

(17:49): And you might think that’s a good thing. Or you might think as I do, well that’s an encroachment on my rights. That doesn’t seem very open source spirit-y, that I can just take the software and do whatever I want with. There’s all of these stipulations on how you’re supposed to act on it. And I would actually say when you do the comparisons between something like the GPL and something like the O’Saasy license as we’ve christened the you can do whatever you want minus make a SaaS business out of it, I think a lot of people would find the O’Saasy license more fitting, having more freedom for their particular use case than the GPL does. So, some of this is I think is just nerds being nerds and pedantic. Some of it is legitimate, old historic battles that maybe someone is still traumatized by the nineties and fighting off Microsoft or Oracle trying to destroy things. And then some of it is also just people being pissy on the internet and finding fault with every goddamn thing that ever existed, including looking a freaking gift horse in the mouth. I dunno, is that a term in English like it is in Danish?

Jason (18:57): It is.

Kimberly (18:58): Yeah

David (19:00): Okay, good. Like we’re giving this away. There’s a license. It’s very clear about it. There’s no sort of, I’m trying to trick you here. The license literally fits on half a piece of paper. You can read it in about two seconds. So if you do not approve of those terms, you can just say like, well, okay, that’s a gift for other people and they can enjoy that as they see it’s not for me. But of course that is not the internet and that is not how these things sometimes go down. But it’s also just sort of like this circus, this sideshow. There’s no serious momentum here. This is not actually, of all the historic flame wars I’ve been involved with on the internet, this is barely even a campfire.

Kimberly (19:42): So now that people can look at the Fizzy code, they can make suggestions or submit pull requests. Tell me a little bit about how that’s going. I’m thinking this is the first time we’ve had outsiders contributing to one of our products. That’s probably exciting, right?

David (19:57): It’s really fun. It’s really cool. And it’s curiously foreign in some ways that all the open source we’ve been doing for literally decades have focused on this infrastructure level stuff, when you don’t have considerations about design, product direction, product management. Suddenly we’re getting pull requests on some of those things. How should the product look? How should it feel? Should it have this feature? Should it have that feature? And I think both Jason and I had a sort of quite open attitude towards that going in that historically speaking, we’ve been quite narrow on our vision, or not even narrow. Protective, let’s put it like that. Protective of our product vision for something. We wanted it to be this way and exactly this way and not another way. And the thought going into Fizzy was, do you know what? Let’s try to loosen the reins a little bit. Let Fizzy be the playground for letting other people come up with sometimes ideas that we need to give five minutes.

(20:58): We often ask our customers, potential customers to give it five minutes when we introduce something that feels brand new or feels foreign. I think there’s something good about turning that around and asking ourselves to give suggestions five minutes and also just see, where could this go? It’s just fun to have that collaborative process with people who are interested, people who are potential customers, people who are just curious programmers who want to be part of this. And some of them might just have read through the whole code base for their own edification, found a few things that could be different, fixed a few things. And that’s a really fun, collaborative process. And then finally I’d say, there’s also some learning here from the success of Omarchy. So, Omarchy was literally just put together this summer and in just a few months just went wild, went totally crazy, hundreds of thousands of downloads, and trying to observe what ticked that off.

(22:01): Why did that take off in such a way? Because that’s actually closer to user facing software than something like Rails. Rails is very adamant about being infrastructure and you should be able to create any kind of application and a user can’t even tell unless they’re really into the details whether something was built with Rails or not, because you can make any kind of application with it. Omarchy is much closer to something like a Basecamp or like a Fizzy where it is things about design and how would you feel and so forth. And yet we’ve had hundreds of people collaborated on it, literally hundreds of thousands of people trying it out. And we were trying to look at that and see how can we take some of the best elements of that, some of the best elements, both in terms of marketing, in terms of collaboration, in terms of excitement, in terms of energy, in terms of pride for us is making something that lots of people like and roll that into more of the traditional products that we do that is web software.

Kimberly (22:58): And then the last question I have for you guys is about this community contributions. How are we handling those? Is there one person who’s in charge of taking those community PRs and looking through them? Is it a team call every week? How are we making those decisions on what goes in versus what does not?

Jason (23:17): I think it kind of depends on the work. So some things are UI based, interface based. JZ seems to be running the show over there. I’ll look at some of that stuff. If it’s more infrastructure, it might be Mike, it might be Jorge. We’re all kind of paying enough attention to it to kind of get a sense. And there’s also a very vibrant GitHub discussion section, which is not pull requests, but there are suggestions or ideas or people talking about things. And I’m jumping in there. Mike’s jumping in there, JZ’s jumping in there. I think Jorge’s jumping in there. I’m not sure who else at the moment, but there’s quite a lot of activity actually over there as well. It’s also interesting to see what it’s getting voted up. So the number one thing with the most votes in the discussion thing is please add regular password authorization.

Kimberly (23:54): Oh, interesting.

Jason (23:55): Or authentication, I mean. So we have a magic link set up where you enter an email address, you an email, you enter a code. You just wouldn’t expect that to be a top thing, but it turns out it’s the most requested thing in the discussion section. It doesn’t mean it has to be done or anything, but it’s kind of interesting to see that sort of thing. So it’s always curious to watch that stuff and see what surprises you about what matters to people. And it’s oftentimes things you would not have expected to matter to people. There’s certain things I thought people would absolutely be up in arms about because the product works a little bit differently. Some people are saying some stuff, but for the most part it’s not that stuff as other stuff. So that’s kind of cool to see too.

Kimberly (24:31): Anything else that we need to say open source before I wrap it up?

Jason (24:35): I do want to hear, how do you say look a gift horse in the mouth in Danish?

David (24:39): Do you know what? That’s really funny because now the English version has kind of polluted my memory of what the explicit expression is in Denmark, but it is something about se ikke en gavehest i munden, I think it is. I think I’m butchering it. I think I’m Englishifying the Danish expression. I need to look it up actually.

Jason (24:59): Right.

Kimberly (25:00): You’re making it Danglish.

David (25:01): In Danglish. Oh my God, yes.

Kimberly (25:04): Well with that, we’re going to wrap it up. REWORK is a production of 37signals. You can find show notes and transcripts on our website at 37signals.com/podcast, full video episodes are on YouTube. And if you have a question for Jason or David, leave us a video question. You can do that at 37signals.com/podcast question. You could also email us at rework@37signals.com.