Open source outside the box – REWORK

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 like tell why are people so worked up? Honestly, I don't understand. >> It does seem strange from like the normal non nerd neck beard perspective that >> yeah like I saw someone say fizzy is as open source as North Korea is a democracy and I was like what is happening right now? Welcome to Rework, a podcast by 37 Signals about the better way to work and run your business. I'm Kimberly Rhodess from the 37 Signals team joined as always by the co-founders Jason Frerieded and David Heinmire Hansen. Well, if you've followed 37 signals, 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 SAS 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. >> 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 use 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 37 signals as a software company, I thought I had both the 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. 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 to simply just open 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 I 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 and Rails and all these other things where you can look at the backend code. 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 um right clicking on a website and going down to the little menu that says view source. And then you can 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 gobbledygook, 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, this 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 sort of the the role of it of what we're doing and how we're building um it just felt like a more productive way to work. We were going to make all this code. 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. Um, and that whole flywheel effect of like 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 37 signals. I'm an open- source mega fan, super fan. Everything that I do on the back end uh 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 like 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, this is the great uh 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 um ungrateful about the gifts that they've received. But other than that, there is no marginal cost to it. And that just makes it uh an absolute no-brainer to do. 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 um got me to think about actually was was like is hygiene. Um and what I mean by that is when people can see your your code um 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 like 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 well tabs and spaces, you know, and lining things up in a certain way that just looked good. And I think it built good habits in me to care about um that. And I think that's true today that when you release something open source and I know David before we we launched something David's very clear about going through everything and tightening everything up and like did we have to do that? No. It's personal pride but also it's also like 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. Um 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 it 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. >> 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 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 a teaching hospital. 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 kaya 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, like 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. Oh, 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, this 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's sane. That's who. Well, maybe we'll get to the insane in a bit. But >> the thing I would I would say is that in some ways it's it's um it's proof that things can be done a certain way. Like I I've been you paying attention to the feedback um when we launched Fizzy on the open source side of it. And one of the things people were shocked about is how 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 unless you sh 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 um in our company is try to be as transparent as possible written books about this like 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. Like 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 of of opening everything up. >> 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 SAS 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. >> 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. uh Ruby and 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 um 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 a whole 10% back and we really question that with busy 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. 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 SAS 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 want to run it on their own. Partly influenced, 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 onetime fee to do it. that turned out to be maybe too early. It wasn't the sort of slam dunk runaway success that would have inspired us to just do this for everything. 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 oneoff 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 if 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 uh applausible or other tools of this genre and 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 SAS we'd run something like Movable Type was a system from way back in the day I think actually maybe Blogger Um Evan Williams's original product was one of the first SAS versions of kind of doing that. It was more common that you actually ran your own server. So there's sort of a there was something here and we thought you know what if the market for selling that as a product has atrophied to the point that it really needs um a long-term recitation to get back into viability. Could we do something else? Could we do this setup where the SAS 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 so people can see exactly how we build 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. Now we've gone the other direction and said all right um 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 SAS 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 SAS part of it is reserved and we reserve 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 does 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 vari variation on the one's theme where we just carve up the economic rights a little bit different. >> 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 like tell why are people so worked up? Honestly, I don't understand. It does seem strange from like the normal non nerd neckbeard perspective that >> yeah like I saw someone say fizzy is as open source as North Korea is a democracy and I was like what is happening right now? This is it's almost a variation of uh 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 him the most charitable um interpretation of it. Some of this has historic roots all the way back to when open source was taking off in the 90s. 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 I also like, dude, that's 30 years ago. We're in a completely different place now. Open source has one. 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 explan or uh discussion about what that actually means? Because what I find so curious is that some of the most fervent advocates of the originalism of that 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're obligated to re-release those uh extensions, you have to release that open source to the western community. 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 um open source spirity that I can just take the software and do whatever I want. Well, there's all these stipulations on how you're supposed to uh act on it. And I would actually say when you do the comparisons between something like the GPL and something like the Osassy license as we've christened the you can do whatever you want minus make a SAS business out of it. I think a lot of people would find the Osassy license more fitting having more freedom for their particular use case than the GBL does. So some of this is I think is just like nerds being nerds and pedantic. Some of it is legitimate old historic battles that maybe someone is still traumatized by the '9s 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 don't know. Is that a term in English? It is in Danish. Okay, good. that 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 sideeshow. Like there's no there's no serious momentum here. Like this is not actually of of all the historic flame wars I've been involved with on the internet. This is barely even a campfire. >> Okay. So now that people can look at the physi code, they can make suggestions or submit poll request. 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? >> It's really fun. It's really cool and it's curiously foreign in some ways that uh all the open source we've been doing for literally decades have focused on this infrastructure level stuff where 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 J 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 another way. And the thought going into Fizzier was do you know what let's try to loosen the reins a little bit. Let busy be the playground for letting other people come up with sometimes ideas that we need to give five minutes. 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 just curious programmers who want to be part of this. And some of them might just have read through the whole codebase 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 Umachi. So Umachi 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 tick that off. Why did that take off in such a way? because that's actually closer to userfacing 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. Omachi is much closer to something like a base camp or like a fizzy where it is things about design and how it should feel and so forth. And yet 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 like 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, terms of excitement, in terms of energy, in terms of pride for us of making something that lots of people like and roll that into more of the traditional products that we do. That is web software. Okay. And then the last question I have for you guys is about this community contributions. How are we handling those? Like is there one person who's in charge of kind of taking those community PRs and looking through them? Is it a a team call every week? Like how are we making those decisions on what goes in versus what does not? I >> think it kind of depends on on the work. So some things are UI based, interface based. Jay-Z seems to be running the show over there. Um I'll look at some of that stuff. um if it's if it's more infrastructure it might be Mike might be Jorge um we're all kind of paying enough attention to it to kind of get a sense and there's also a very vibrant um on GitHub uh discussion section which is not which are not pull requests but there are suggestions or ideas there people talking about things and um I'm jumping in there Mike's jumping in there Jay-Z'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 quite a lot of activity actually uh over there as well it's also interesting to see what's getting voted up so like the number one thing with the most votes and the discussion thing is please add regular password authorization um or authentication I mean which is something we like just I mean you wouldn't imagine so we have a kind of a magic link set up where you enter an email address you get an email you enter a code you just wouldn't expect that to be like a top thing but it turns out it's the most requested thing in the discussion section doesn't mean it has to be done or anything but it's kind of interesting to see that sort of thing so that always um it's always curious to watch that stuff and see what surprises you about what matters to people and it's often times things you would not have expected to matter to people. There's certain things I thought people would absolutely be like up in arms about because product works a little bit differently. Some people are saying some stuff but for the most part it's not that stuff. It's other stuff. So that's kind of cool to see too. >> Anything else that we need to say open source before I wrap it up? >> I do want to hear how do you say look a gift horse in the mouse mouth in Danish? >> It's got to be you know what? So 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 um in gay. I think it is. I'm I think I'm butchering it. I think I'm I'm Englishifying the Danish impression. I need to look it up actually. >> Right. >> You're making it danglish. >> In Danglish. Oh my god. Yes. With that, we're going to wrap it up. Rework is a production of 37S signals. You can find show notes and transcripts on our website at 37signals.com/mpodcast. 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/mpodcast question. You can also email us at rework@37signals.com.

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. *Key Takeaways* 00:00 – Episode highlights 00:40 – Why open source continues to matter at 37signals 05:55 – Sharing work publicly pushes quality higher 10:53 – How open source fits into Fizzy’s SaaS setup 16:16 – Treating open source as a gift 20:49 – Getting direct feedback in unfamiliar but fun ways 24:08 – How the team decides what goes into Fizzy and what doesn’t 25:58 – A Danish language lesson *Links and Resources* Fizzy is a modern spin on kanban. Try it for free at https://www.fizzy.do Record or upload a video question for Jason and David — https://www.37signals.com/podcastquestion Get a free Basecamp account at https://www.basecamp.com Books by 37signals – https://37signals.com/books 30-day free trial of HEY – https://www.hey.com/ Once. com – https://once.com/ Campfire – https://once.com/campfire HEY – https://www.hey.com/ The REWORK podcast – https://37signals.com/podcast/ Get some REWORK podcast merch – https://37signals.com/podcast/shop *Let's be social!* Twitter/X: https://x.com/37signals Instagram: https://www.instagram.com/37signalshq/ Rework is a production of 37signals. You can find show notes and transcripts on our website https://www.37signals.com/ Leave us a video question at www.37signals.com/podcastquestion or send an email to rework@37signals.com, and we might answer it on a future episode.