Season 4 Episode 6 May 20, 2021

Babel’s Money Challenges, What It's Like to Work on Rails, and Coinbase’s End to Salary Negotiations


The room where it happens.


This week we’re talking about cryptocurrency company CoinBase refusing to negotiate job offers and a blog post by the Babel core team titled, “Babel is used by millions, so why are we running out of money?” which created a bit of a Twitter storm, and speak with Babel Core Maintainer Nicolò Ribaudo. Then we speak with Principal Engineer at Heroku and Rails Contributor Richard Schneeman, about what it’s like to work on Rails in the aftermath of Basecamp co-founders Jason Fried and Rails creator David Heinemeier Hansson’s highly criticized blog post, which raised concerns about Rails' independence from its creator.


Saron Yitbarek

Disco - Founder

Saron Yitbarek is the founder of Disco, host of the CodeNewbie podcast, and co-host of the base.cs podcast.

Josh Puetz

Forem - Principal Engineer

Josh Puetz is Principal Software Engineer at Forem.


Nicolò Ribaudo

Babel - Babel Core Team Member

Nicolò Ribaudo is an open source maintainer working on Babel and on many related projects. When offline, he's a math student in Turin, Italy.

Richard Schneeman

Heroku - Principal Software Engineer

Richard Schneeman created and maintains, a tool for helping people contribute to open-source When he isn't obsessively compulsively refactoring code he spends his time reminding his kids to wash their hands.

Show Notes

Audio file size





[00:00:10] SY: Welcome to DevNews, the news show for developers by developers, where we cover the latest in the world of tech. I’m Saron Yitbarek, Founder of Disco.


[00:00:20] JP: And I’m Josh Puetz, Principal Engineer at Forem.


[00:00:22] SY: This week, we’re talking about cryptocurrency company, Coinbase, refusing to negotiate job offers in a blog post by the Babel Core Team titled, “Babel is used by millions. So why are we running out of money?” which created a bit of a Twitter storm.


[00:00:36] JP: And speak with Babel Core Maintainer, Nicolo Ribaudo.


[00:00:40] NR: No one of us in the team cared about what people were writing on Hacker News. But when we saw like the tweets of Sebastian, they hit us quite hard.


[00:00:52] SY: Then we’re joined by Principal Engineer at Heroku and Rails contributor, Richard Schneeman, about what it’s like to work on Rails and the aftermath of Basecamp co-founders Jason Fried and Rails creator David Heinemeier Hansson’s highly criticized blog post, which raised concerns about Rails independence from its creator.


[00:01:11] RS: Personally, I had fear and I don’t know what’s going on about all of this stuff that’s going on at Basecamp because I don’t know how it’s going to turn around and impact Rails.


[00:01:23] SY: In what might become a growing trend, Coinbase announced they will completely eliminate negotiations from their hiring process. In the post, Chief People Officer L.J. Brock writes, “Traditionally, people expect they need to negotiate for the best package after being hired in a new job. Those that do this well tend to be rewarded and those that don’t lose out. These negotiations can disproportionately leave women and underrepresented minorities behind and a disparity created early in someone’s career can follow them for decades.” Coinbase also says it'll be increasing their cash and equity across the entire company from the 50th percentile to the 75th percentile amongst their peers. I have many opinions about this. I’m very interested to hear your opinion about this. I’m going to start with you and then I’ll tell you how I feel next. Okay. Go.


[00:02:13] JP: Okay. We should give a little bit of a context to Coinbase. For those that aren’t familiar, Coinbase banned discussions of politics at work, similarly to what Basecamp did, but they actually did their banning a few months ago, I believe, at this point.


[00:02:28] SY: A little while ago. Yeah.


[00:02:29] JP: Yeah. Yeah. So they are developing quite the reputation for being an employer that is going to set their own path and doesn’t care what anybody else thinks.


[00:02:37] SY: Right.


[00:02:38] JP: So given that, oh, I’m suspicious.


[00:02:42] SY: Okay.


[00:02:43] JP: This sounds nice, right? Like you don’t have to negotiate. We’re just going to pay everybody the best price and there’s going to be no more futzing around. You don’t have to worry if you’ve negotiated more or less. That sounds great. However, as many commenters on Twitter pointed out this doesn’t always happen. Inevitably, companies will negotiate. There’s some questions about, “Are they not negotiating all positions? If they hire a new CEO, would they not negotiate that?”


[00:03:16] SY: Right.


[00:03:17] JP: What happens with existing employees? Well, they’re going to bump them up to the 75th percentile among their peers, but where do they get that information from? Is that competitive? I’m just suspicious.


[00:03:27] SY: Yeah, I totally get that. So as someone who has done a pretty good amount of hiring and had to do the negotiation as an employer, I love this idea. I think it is fantastic. I think it’s awesome. I hate the negotiation process when it comes to hiring people. I think it is uncomfortable. I think it is awkward. I hate the game of like, “Okay, this is how much I want to pay them. But okay, is this person likely to negotiate? Probably. Okay. So I can offer them what I really pay them. Let me pay them a little bit less, knowing they’re going to go higher than I want to go. Okay. Now let’s meet in the middle. Okay. Did they get to the middle? Yes, they did.” It’s just such an annoying process. And you just kind of realize that you’re basically giving people, I mean, it’s exactly what they said. You end up giving people an opportunity to make more money based on their comfort level of negotiation.


[00:04:13] JP: Right.


[00:04:14] SY: People who are comfortable negotiating and people who are willing to push back, which, frankly are, generally, not women or people of color. Those are the people who get more money. And then it becomes this really screwed up system where it’s not about the people with the most skills I get paid. It’s the people who ask for more to get paid. And that is not why you should be getting paid more. Fundamentally, that should not be the reason why you make more money and making hundreds of thousands of more money down the line because as we know, the higher you make earlier in your career, the more money you’re going to have saved up by the end of your career. So it’s a really, really huge factor. It’s a huge deal. So in principle, I love it. And I’ve been thinking about that a lot for my own company in terms of like, “How do I want to do hiring?” And I think for me, a way to do this kind of thing genuinely would be to tell people upfront what the salary actually is.


[00:05:10] JP: Yes. That’s a huge criticism I have of this particular system.


[00:05:15] SY: Yes.


[00:05:15] JP: And as a job candidate that has been uncomfortable negotiating my salary and has gotten to a place where I accept it, I don’t love it, but I accept that I can make more by negotiating my job salary. If I were applying for a job and I knew what the job was paying right off the bat, and I have seen job postings that do occasionally advertise a range of what they’re paying or an exact number, my significant other used to work in the healthcare industry. And in the healthcare industry and in government jobs, it’s extremely common to just flat out list what the position is paying before anyone applies. And so the negotiation is just completely off the table. That’s a better way to go about it. I’d be pretty peeved if I went through a job interview process and then I found out what was going to be paid. Like if you had that information ahead of time, then tell me. To me, it seems pretty disingenuous to say, “We’re not going to negotiate salary, but also we’re not going to tell you what the salary is before you apply and before you qualify and before we want to make you an offer.” So if you want to do that, I think it’s great, but put that number out there and you need to be confident as an employer in that number that you are going to compete against other employers and other possible offers.


[00:06:27] SY: I a hundred percent agree. And that’s why I love this idea in theory, but the implementation is definitely where it becomes either you’re genuine or disingenuous, as you said. And so in order for me to believe that this is really the way the intention will be implemented, I think they have to say salaries upfront. Otherwise, I have no way of verifying whether this is a good use of my time. We’re verifying whether or not you’re actually paying me what the job is worth, if I have no chance to negotiate it. I think I need that information upfront. It also gets really tricky because as you said, I don’t know how realistic it is that all positions are non-negotiable. If you’re talking about like a C-suite level employee and they have some incredible out of this world resume and with years of crypto experience at a competing, I don’t know, like if you have some outstanding person, you’re probably going to be inclined to give them a little bit more to incentivize them to get there. So I don’t know how realistic it is. You can actually have a purely non-negotiable process. I think it makes more sense for mid to lower-level employees. I don’t know if it makes sense for executives specifically. So I’m interested to see the limitations around this.


[00:07:43] JP: There were two other things I was thinking about in the context of this. And one was, what do you do about raises?


[00:07:48] SY: Yes.


[00:07:48] JP: And that gets into questions about, “Are there salary bands? Is there a schedule for who gets a raise and when?” So I have questions about how raises could be addressed in a situation like this. Also, I would want to see everyone else’s salary. Great. You said you’re going to pay me X amount of money, but what about the next person? What about the CEO’s? What about the people already at the company? If this is such a transparent process, go ahead and make everyone’s salary public. I know there’s a few companies that have experimented with this. I think Buffer, the social media scheduling company, is one I know of that. They publicly list all of their employees and their positions and what they make on their website.


[00:08:30] SY: Like each individual employee?


[00:08:31] JP: Yeah. I’m looking at the spreadsheet now. Here’s what the CEO in Boulder pulls down 290,000 a year and his executive assistant pulls down $100,000 a year in Nashville, Tennessee. And it’s like all listed.


[00:08:44] SY: I don’t know if I like that. I don’t know if I want my information out there like that. That’s a little too personal. I’m down to like salary bands. If you want to say, “A principal engineer at this company makes this amount,” like generally speaking, that’s fine. But for me, my personal finance is very personal to me and I definitely would not want that information published for random people to find out. That’s a little too far out. I’m not on board with that one.


[00:09:10] JP: But if you’re publishing a job listing and you’re putting out what it pays.


[00:09:14] SY: But it’s a range. It’s a range. And I feel like, ultimately, you don’t really know how much someone is getting paid. Like you said, I could be getting a bonus. I could be getting a raise. Maybe I have fewer years of experience, so I’m on the low end of that band, higher. You know what I mean? Like there’s still some variability in there. But for someone to like go to an article and say, “Saron makes $100,000 a year.” And just to have that fact out there on the internet, because then like people in your family who don’t have any money come asking you for checks, it gets complicated. Your mom was like, “Yeah, I didn’t get a big enough present for Mother’s Day. What are you doing?” It’s just I don’t want anybody to read my business out there like that.


[00:09:51] JP: So thought exercise that if there’s a range of salaries, when you’re hiring a candidate in a range, let’s say just $10,000 range, who and how do you decide where in that range the candidate goes?


[00:10:02] SY: That is a great question. I’ve been thinking a lot about this. So two things. Number one, when it’s time, right now my team is very small. So it’s not really relevant. But hopefully, when we get big enough to take on these problems, in the future, I plan on hiring like a third-party HR person to come in and assess and evaluate for me in an unbiased way. And I’m going to give that person my constraints of like, “This is what I can afford. This is the requirement of the job. These are the things I value.” And I’m going to have someone who’s frankly done this more than I have to come back with some type of hiring salary breakdown and plan to make sure that I’m not missing something. So that’s one thing that I would do. But the second thing is when you’re hiring for a job, the bare minimum is can they do the job? Right? Because if they can’t do the job, then obviously they’re not getting the job. But then there’s like layers to it. There’s, “Okay, does this person have an advanced degree where they wrote a thesis about this particular topic? Does this person have more years of experience for this job? Did they have experience building software in this particular context and so might move a little bit faster or just do a slightly better job coding because they’ve already solved these exact problems before?” So I think that there are other factors that go into it where you have reason to believe that they might be a stronger fit for that role above just can they actually do the job at all. And I think that’s where maybe you throw in a thousand dollars for this specific background. And again, very gray. It’s not going to be a perfect system, but I think there are ways to kind of almost have like an a la carte of, “For every additional point you get, you get a thousand dollars.” I feel like there’s maybe something around that that you might be able to create.


[00:11:50] JP: Not to be contrary, but like what I hear like an employer wants to pay a range and there’s a system setup and we’re going to judge based on X and Y I hear as a job candidate, the is willing to pay from X to Y, but they want to judge whether they pay to X to Y not based on my negotiating ability or in reality they could afford Y, but they will pay me less.


[00:12:17] SY: Yeah.


[00:12:18] JP: Okay. Well, then we’re back to negotiation though.


[00:12:20] SY: No. I don’t think so. Okay. So this is the way I look at it. The way I look at it is let’s say my range is 1 to 120, $100,000 to $120,000. I’m looking at two candidates. I’m looking at someone who has, I’m totally making things up here, so, sorry. This is not actually market value.


[00:12:37] JP: Not real dollars.


[00:12:39] SY: Not real dollars. Not real experience. But I’m talking to someone who has three years of experience versus five years of experience. Right? If I’m talking to those people, one person has almost doubled the experience they do. They’re both applying for the same job. They’re both good candidates. I’m going to assume that the person with a couple of more years of experience would probably work a little bit faster, do a little bit of a better job, maybe have a little bit more leadership skills because they’ve been doing it for two extra years. I’m much more likely to give that person the higher end of that and give the three years, that person, the lower end because I’m essentially paying the 10, 20k for the additional experience that I think will make that person a better candidate. That’s not really about negotiation. That’s about like having a rubric. That’s having a rubric that says, “I value these additional features more and I’m willing to pay on the higher end to get these additional things out of this role.”


[00:13:33] JP: I mean, I get that, but that just seems at odds to me with the idea that you would tell candidates, “We’re not going to negotiate.”


[00:13:40] SY: Why?


[00:13:40] JP: As a candidate, coming into that position, A, I want to argue for the higher salary, and B, I know you’re willing to pay more. If you have a range, I know you’re willing to pay more.


[00:13:48] SY: But I’m not willing to pay more for someone with three years of experience.


[00:13:51] JP: Then I guess maybe the answer is to just throw out the lower number for the three years of experience thing and you have to let that five-year experience person go.


[00:14:00] SY: But why would I do that?


[00:14:03] JP: I understand not all candidates will negotiate, but it seems like, oh my God, I can’t believe we’re getting in a fight about this, this is great, it just seems like if there’s a range there, it seems like you, as the employer, want to pick without having to negotiate or having the candidate have any kind of power in that discussion at all.


[00:14:23] SY: Yeah. Exactly. I mean, that’s the whole point. The whole point of not allowing negotiation, at least if you do it innocuously, is so that it’s not about the employee’s confidence level. It’s not about them being like, “Oh, I feel comfortable in negotiating.” It’s to remove the confidence out of the equation and to judge them purely on merit. And the reason there’s a range is because not all candidates bring the same amount of value to a company. I mean, I would argue kind of the same way back to you where I would say if you’re a candidate evaluating two job positions, if you believe that this startup is going to be the next billion-dollar company, you’re probably going to accept a lower salary than you would at Google. You know what I mean? Just because you’re doing the same job at those two companies doesn’t mean that they don’t provide different levels of value. You’re still doing the same type of thing, but you understand that even though they’re the same role, same titles, same responsibilities, the way you value two different companies with two different value propositions is different. Same thing for employers. Different candidates provide different types of value, different types of things they bring to the table. So the range is to be able to accommodate that people are all different and they’re not cookie-cutter. They’re not just interchangeable.


[00:15:35] JP: I can get behind that. But I think that like is different than what Coinbase is doing by saying, “We’re just not going to negotiate.”


[00:15:41] SY: I agree with you. I don’t know Coinbase’s, I mean, their intention sounds very nice, according to their official statement. It sounds great, but it’s all in how they implement it. If they implement it well, then they have a great chance of living up to that mission and living up to that promise of leveling the playing field and et cetera, et cetera. But this can easily be used as a way to just pay everyone a little bit less. So it really just depends on how they implement it and how they think about their salary in a holistic way. It can’t just be, “Let’s remove negotiation.” It has to be, “Let’s review our entire hiring salary process and make sure that is in the best interest of both the employee and the employer.”


[00:16:24] JP: I absolutely agree with you that being upfront about the ranges you’re going to offer is really, really key. I completely agree with you on that point.


[00:16:31] SY: Yeah.


[00:16:32] JP: Well, I can’t believe we didn’t solve the problem of salary negotiation in the last 20 minutes.


[00:16:36] SY: Ridiculous! What were we doing?






[00:16:58] RudderStack is the Smart Customer Data Pipeline. It makes it easy to build event streaming, ETL, and reverse ETL pipeline. It’s warehouse first. RudderStack doesn’t persist any of your data. It builds your customer data lake and your identity graph in the data warehouse and it’s open source. Sign up for free at and give them a star in GitHub.


[00:17:17] Scout APM is the leading edge application performance monitoring designed to help developers quickly find and fix performance issues before the customer ever sees them. See why developers call Scout their best friend and sign up for your 14-day free trial today at




[00:17:35] JP: Speaking of money, Babel, the open source JavaScript compiler software project, announced on their blog that they’re running out of it. A recent blog post entitled, “Babel is used by millions, so why are we running out of money?” Written by the Babel Core Team starts off with, “Since 2018, Babel has been doing a funding experiment. Can full-time work on Babel be sustained? We learned the answer might be no.” Babel’s a very popular software project, which is used by thousands of companies. According to the Babel post, they’re hitting over 117 million downloads per month.


[00:18:08] SY: Wow!


[00:18:08] JP: Initially, the company paid only the lead maintainer, Henry Zhu, the full salary of $11,000 a month, and then made a move after a year to increase the salaries of three other maintainers from $2,000 a month to $6,000 a month. All of this was funded through a large grant and a handful of sponsors. The project had hoped future sponsors would fund these additional salaries, but contributions have since decreased. They say that to continue to fund their currently paid three maintainers, they need to fundraise at least 333,000 US dollars a year, and they asked that folks do this via Open Collective and GitHub sponsors. This news led to a bit of a tech Twitter storm, which started out by the creator of Babel, Sebastian McKenzie, who no longer works at Babel, where he tweeted and later deleted the following, “The reason there’s no money is because someone took a $130,000 annual salary and didn’t actually work on the project.” And, “Because funds were misallocated for years and the project has been slow to improve.” In an illuminating Hacker News post, one of the paid Babel maintainers, Nicolo Ribaudo, addresses what McKenzie is referring to. He says that McKenzie is equating the number of commits to the project as a reflection of how much work someone has done. We’ll put that piece in our show notes, but we also reached out to Ribaudo to further shed some light on this. He pointed out that the number of commits don’t necessarily reflect the number of contributions. For example, someone might prefer reviewing while others prefer coding. And he also said to us…


[00:19:35] NR: It’s awesome when individual developers sponsor us and that’s because they show how much they appreciate what we do and how much they need and they rely on our software. However, what is really important for us is to get companies to sponsor because companies can give us a lot of money. The problem is that the people behind the open source projects are developers. And we are not like marketers or experts in developer relations. And so it’s hard for us to properly communicate with people mostly because it’s something that most of us never had the necessity to do at this level. We are lucky because, Harry, he’s actually working a lot on this and he talks with companies and talks with developers, explaining how funds are used and trying to convince companies to give us money. Things like marketing or talking with people about open source are really hard to appreciate from the outside because it’s not something that people can see. Like you do not see a GitHub issue or anything about that. Always keep in mind that behind open source projects, there is also this work, and so do not try to measure everything just based on what you see on GitHub.


[00:21:04] JP: He also mentioned that McKenzie’s comments really affected the team.


[00:21:08] NR: No one of us in the team cared about what people were writing on Hacker News. But when we saw the tweets of Sebastian, they hit us quite hard. Mostly because we already talked with Sebastian. And so we already knew that he felt like that, but we did not understand how strongly he felt about what he tweeted and we didn’t expect his anger to became public.


[00:21:37] JP: We also asked Ribaudo what he thought some of the biggest misconceptions about open source are.


[00:21:41] NR: We realize that a lot of people do not realize that mainly open source projects are maintained not by a company, but just by individual people, either doing it in their free time or like in our case, by ourselves. So for example, many people thought that Babel was a Facebook project and I think that this is because Sebastian worked at Facebook for a while. And many other projects have the same problem. For example, Jest or Create React App, for them it’s even harder because Facebook owns the GitHub repositories, but they’re still managed by the community and the company does not necessarily have to maintain those projects or they do not pay the maintainers of those projects. And so this is a problem because many people would be willing to donate, but they just do not know that the project needs money and that it’s not maintained by a company.


[00:22:47] JP: Ribaudo did say that since the post, Babel has started to receive some money and are in talks with larger companies for ongoing support.


[00:22:53] NR: So in like two days, we raised about $50,000, which might not be a lot compared to like even with those very small company uses. But for us, it expanded the problem of thinking about what to do after finishing money by maybe like six or seven months. And this is really good for us because now we have more than one year to think about other ways of getting money. And most of those donations were from individuals or from small companies. And now we are in contact with a few big companies to check if they would be able to donate to us. I mean, for big companies, it’s not like a decision that you can take in one day. You need different levels of approval and it’s a long process. But different people from some big companies reached out to us and are trying to get their big companies to sponsor us.


[00:23:54] JP: First of all, Babel is huge. Babel is foundational to so many JavaScript projects. It lets you write code in the latest and greatest version of JavaScript and then transpiles it back to work on a variety of browsers. It’s essential for JavaScript frameworks. And the idea that they’re running out of money to pay their maintainers is scary.


[00:24:19] SY: It’s pretty scary. Yeah.


[00:24:20] JP: I was also struck by how small of a core team they have, one full-time contributor and three part-time contributors, a very, very small.


[00:24:26] SY: That’s not that many people. Yeah. I think also what’s interesting is the pay difference, I guess, between the 11,000 and the 3,000. That feels like a pretty significant difference. I get that, obviously, as we mentioned, it’s not all about green squares and people have different levels of contribution. But I would’ve expected them to get paid roughly the same amount of money. I was a little surprised, but maybe it’s based on hours worked.


[00:24:52] JP: Right. So they talk about this a little bit in the blog post where Henry, he’s basically full-time devoted to the project, and the other three contributors are working on it on a part-time basis. And that’s kind of way at a much lower per month salary, it was almost like a Hail Mary. They wanted to pay them a more competitive part-time salary. So they upped that amount for the three part-time contributors in hopes that the funding would follow, and it hasn’t.


[00:25:18] SY: That’s a dangerous game, man. That’s a dangerous game of, “We anticipate having all these sales come in,” instead of a regular company. So let’s blow all of our money on hiring people before we’ve actually secured and close any deals.” That’s exactly what that is.


[00:25:33] JP: And worse than accounting on sales, they’re counting on charitable contributions.


[00:25:37] SY: Right. Which generally speaking, people are not very good at that.


[00:25:40] JP: Yeah. What do you think about open source projects trying to fund themselves? And I think we’ve seen this with other open source projects when they want to pay their contributors or even hire employees to work on a project full-time and so many of them just cannot make the finances work out.


[00:26:01] SY: Yeah. I mean, I love the idea. I think that if you’re able to work on open source on the side, if you have the free time, if you’re willing to give up your free time, I think that is awesome. I mean, that’s literally how open source has thrived for so many decades. But a lot of people would love to do it full-time, would be able to do an even better job, can’t afford to do it on the side. So I think that the opportunity to make the source sustainable by being able to pay more people to do it I think is a great idea. I think it opens up the world of open source to a lot more people and I think enables us to get better products if we have people like Henry who are full-time focused to these essential gems and libraries and packages and projects. So I think it’s great. I think that what it does though is it forces people to be salespeople. And it makes me wonder, are contributors, are the hardcore coders who are the ones spending all their hours and all that on this, are they the best people to do the sales? Do they need sales help? How are they getting those contributions? Because sales is, in and of itself, its own job.


[00:27:14] JP: Right.


[00:27:14] SY: If Henry’s the ones soliciting all these contributions and reaching out to all these companies, I’m not surprised he has the least amount of commits because like that’s a lot of work. That’s a lot of I’m sure a lot of rejection, a lot of just hitting the pavement, pounding the pavement. And so I think that’s its own skill. So that could be good for the team in terms of long-term sustainability. But the downside is because it takes so much time and energy, it can also detract from the project as well. So that’s kind of the other side of it.


[00:27:43] JP: One alternative I’ve seen in open source is the project is either started or acquired or completely funded by a for-profit company. I’m thinking about React and Facebook. The plus side is there is funding there and there’s a lot of resources. The downside is that you have one company mostly controlling where the project goes. I think it’s a real unsolved problem in the open source community. How do we have a truly open source, independent project? And how do we hold companies that are wealthy and making a lot of money off of the backs of these contributors in this project? How do we hold them accountable and how do we get them to contribute? This came up on my day job at Forem. We were recently running bundle install, looking at all the software that’s coming in, and one of the gems has a message saying, “We require funding. If you love our software, please support us. Go to this address. Contribute. Get your company to contribute.”


[00:28:46] SY: Wow! Good for them.


[00:28:47] JP: I remember reading about that message being included in a couple of open source libraries and there was some debate about whether that’s like spammy or advertising, but I think it’s a really good reminder to developers working in these companies.


[00:28:55] SY: That’s a good reminder.


[00:28:56] JP: Yeah. You’re benefiting from these people’s labor. Try to push your company to sponsor it.


[00:29:02] SY: Yeah, I totally agree. I mean, I think it’s incredible the things that people are willing to pay for and not pay for. I mean, just kind of going back even to just simple iPhone apps, a whole dollar for this thing and then we’ll easily spend $15 on a burrito. Maybe not 15. But you know what I mean. We’ll spend so much money on things that are very, very temporary, but we look at the hard work of open-source maintainers and software developers and how much love they must be putting into these projects to be doing it for free or for really, really cheap and we don’t seem to give it the same value. And there’s almost a certain entitlement, I feel, of like, “I shouldn’t have to pay for software,” kind of thing, which is really disappointing. I mean, it takes time to build these projects and it takes a lot of effort, a lot of brain power. I think that a reminder from these maintainers saying, “Hey, by the way, if you love it, you can help,” I think is absolutely fair game.


[00:29:55] JP: Yes, I agree. I agree. Wow! I liked that Babel is opening up their books and they’re being honest about this. I don’t love that there’s been so much criticism on like Hacker News and on Twitter about like, “What are you spending this money on? Is this enough money for some person to be the head of the project? I disagree with how much money is happening for these contributors.” I think it’s bad luck, especially from a project that is used by so many people.


[00:30:25] SY: Yeah. I mean, when you are trying to be transparent, you open yourself up to other people’s opinions, right? Which is going back to how I don’t want my salary out there, I don’t want to be like judge or analyze or critique for how much I should be getting. I don’t even want to start that conversation. Opening up your books can be great in terms of transparency and in terms of helping communication and hopefully making sponsors feel good about where their dollars are going and feel like they’re being put to good use. But also there’s going to be a lot of people who feel like you’re getting paid too much, you’re getting paid too little, how dare you, how could you, why is the pay different. You’re just opening yourself up to just a lot of stuff that maybe you don’t really want. That’s the downside of transparency.


[00:31:08] JP: Well, if any of our listeners want to donate to Babel, you can find them at There’s some really interesting information they have on their site about where the expenses go, what contributions they take in, really interesting stuff.


[00:31:27] SY:  Coming up next, we’re joined by Principal Engineer at Heroku and Rails contributor, Richard Schneeman, to talk about what it’s like to work on Rails in light of Basecamp co-founders Jason Fried and Rails creator David Heinemeier Hansson’s wall post announcing highly criticized changes at Basecamp, which led many to question Rail’s independence from its source.






[00:31:59] Scout APM pinpoints and resolves performance abnormalities, like N+1 queries, memory bloat, and more. So you can spend less time debugging and more time building a great product. With developer centric UI and tracing logic that ties bottlenecks to source code, get the insights you need in less than four minutes without dealing with the overhead of enterprise-platform feature bloat. You can rest easy knowing Scout’s on watch to help you resolve performance issues with Scout’s real-time alerting and weekly digest emails. As an added bonus for DevNews listeners, Scout APM will donate $5 to the open source project of your choice when you deploy. Visit for more information.


[00:32:35] RudderStack is the Smart Customer Data Pipeline. It gives you the flexibility to choose the tools you want to use without worrying how to connect your customer data. Instrument once with RudderStack to capture event data, then send it to your entire customer data stack. It integrates with over a hundred cloud tools with new integrations releasing all the time. Start building a smarter customer data pipeline today. Sign up for free at




[00:33:01] SY: Here with us is Principal Engineer at Heroku and Rails contributor, Richard Schneeman. Thank you for joining us.


[00:33:06] RS: Hey, it’s good to be here.


[00:33:08] JP: So you recently wrote a post on your website entitled, “The room where it happens: how Rails gets made.” And there’s a lot to unpack in the blog post. Could you explain what led you to write your post and what you hope it accomplishes?


[00:33:21] RS: There’s been all of this like kind of massive controversy and huge like Twitter storm. I’ve been referring it to as an incident at Basecamp. And the blog post covers this. It covers like kind of the rough timeline of a very odd statement by one of the co-founders, Jason Fried, followed up by another statement by DHH. And the original statements were something along the lines of the company, Basecamp, is no longer going to be allowing politics at work, which for a huge portion of people is a big problem because they are walking talking politics. I am a straight white male. If I want to turn off politics, sure, maybe I can think I can do that. But if somebody is trans, if they’re coming from a minority group, just the existence of them, just this concept of being able to separate politics from not politics just really anyway. So yeah, there’s a giant firestorm there. They offer the company to allow people to quit. I think if they had been working at the company for over a certain amount of time, you got more of a severance. And at this point in time, I think a third of the company has quit. And in between, there’s more information, more details a little bit more. There’s some reporting by someone named Casey, who did a really good job covering that. And for people who don’t know, DHH, one of the co-founders of Basecamp, one of the people making these statements and in charge of crafting these policies, he’s also the creator of Rails. DHH has his name as the trademark of Rails. He is largely seen as the face of Rails. He keynotes RailsConf. He still is fairly active with development. In addition to DHH’s involvement, the Rails contribution process, it’s kind of confusing terminology, but I’m known as a contributor because I have commit access. Like I have commit access to the project, then there’s another level that’s deeper that is core and both contributors and core communicate through the Basecamp product. So it’s kind of like this inner meshed, intertwined relationship. And so it kind of seems weird that I would have anxiety and people would have so much anxiety. And personally, I had fear and I don’t know what’s going on about all of this stuff that’s going on at Basecamp because I don’t know how it’s going to turn around and impact Rails, Ruby on Rails, which is all open source. I have a long history of contribution and interaction with it. Some of this anxiety came up in a forum post on the Ruby on Rails forums, and people were saying, “Hey!” In their heads, Rails is DHH, period, full stop, for some of them. And Rails Core, which is 12 people-ish, put out a statement being like, “No, you totally got it wrong. Rails is us.” And David’s name is in there and other Basecamp employees, Jeremy, is in there, but there are also other people. And there’s just this kind of mismatch between this conversation that was happening where Rails Core was saying, “No, this is how we function. This is who we are.” And other people were saying, “Well, that doesn’t seem quite right.” I’m like kind of one foot on each side. I’m not actually in Rails score, but I do have a lot of kind of this insider visibility and I’ve been around for a really long time. And so I kind of just felt like both sides were missing each other. And I wanted to, I guess, flush out and say like, “Hey, this is the state of the world that I see. You might disagree with some of my perspectives, but let’s at least start from sort of a concrete place of understanding so that we can see where we sort of see where we are.”


[00:37:25] SY: So I guess it’s safe to say that you were not a big fan of the original blog posts written by the two heads of Basecamps. I’m wondering, when you first read it, and by now I think you’ve had time probably to process it a little bit, but I’m wondering what was your initial reaction when you first read that blog post and you saw the Twitter storm? And not even on Twitter, right? It was like articles. Media publications were covering this. When you saw that criticism, what was your initial reaction?


[00:37:52] RS: Ugh!


[00:37:54] SY: Got it.


[00:37:55] RS: It was just like utter disappointment and just sort of this like unreal, like, “Is this really happening?” There are no strangers to controversy. They like live and breathe. This is totally normal for them to make these big, bold managerial claims. In my interpretation and impression wasn’t just that they were saying, “Oh, we’re doing this.” When Basecamp does a thing publicly, they’re saying like everyone should do this. This is the right way to do it. This is the world we should be living in. DHH went on to, I forget, one of the news, like a CNN or something. He was interviewed on the news about this and like several days later and had not backed down. My mind is just reeling from like, “How could this be real life? How could this be happening?” Also, at the same time, I’m like, “Well, like if I say what I’m afraid of, are there going to be punitive things? I might get my commit revoked?” And that’s kind of part of the point of the post is it’s a little bit of exploration. In terms of internal governance, it’s very informal, it’s very ill-defined. It’s kind of like almost everybody who touches it has sort of a different perspective on it. And I’ll also say like of Rails Core, like I think that process has served them very well. It’s allowed them to move very quickly. It’s allowed them to not have to think about or worry about having regular meetings or like a cumbersome RFC process or something along those lines. But then there’s all these other side effects that I don’t necessarily think were malicious or intentional. And since I published the post, several of them have come forward and been like, “Wow! Thank you so much.” They kind of had no idea of this landscape of, as I’m sitting here trying to figure out, like, “How do I engage with you?” I have a level of fear because there are rules everywhere. And it’s just a question of if they’re invisible or visible and there are all of these invisible rules and your rules might be different from my rules. And I’m just trying to like navigate the system. I think that’s one of the kind of core points that I wanted to make. Simultaneously, I’m speaking to Rails Core. I’m also speaking to everyone. So it’s a little bit difficult to write for two audiences. But yeah, that was sort of one of the goals there.


[00:40:22] SY: So I actually have to jump off. So Josh is going to finish the interview. Richard, it was great to reconnect with you, although briefly.


[00:40:30] RS: Yeah.


[00:40:30] SY: Cool. All right. I’ll talk to you later.


[00:40:32] JP: See you, Saron.


[00:40:33] RS: Bye.


[00:40:33] JP: So obviously, David Heinemeier Hansson is a creator and many see him as the face of Rails and it makes sense that his actions at Basecamp would lead to concerns within the Rails community. Can you talk about and address some of those concerns that you’ve heard and maybe some of the concerns you have about him being involved with the project still?


[00:40:52] RS: I think that question also brings up, there’s a segment of Rails users and Rails programmers who don’t see a problem actually and don’t see any sort of a connection. It actually makes me want to speak to that first, which some people say, “Yeah, David is Rails. Big whoop. This happened. He can do whatever he wants. It’s like his thing.” Of the people who quit in Basecamp, one of them was in Rails Core. And not only did they quit Basecamp, they also quit Rails Core. Another one was not technically in Core, but a huge contributor to a huge number of libraries. And they also have come out and just said, “Hey, I’m not going to work on this if David is still around.” And so I quoted Kim in my blog post. One of the things she frequently says is like tech is neither neutral nor apolitical. And it’s like this process is already affecting Rails by people who have this long-term knowledge store of how technical internals and how governance internals of Rails work are leaving the project and have left the project. And so that is already impacting us. And then I know, I kind of asked myself a slightly different question than you asked. What was your original question?


[00:42:06] JP: I guess I was just wondering, you kind of covered this, you talked a little bit about the concerns that you had with DHH being involved with the project going forward. Have you heard concerns from other core members or have you heard concerns from other contributors? Was your blog post driven or is it channeling stuff that you’ve heard with the Rails developer community? Or is this all coming internally? I’m just kind of like wondering what kind of basis there is there for the concerns that you’re raising.


[00:42:34] RS: Mostly, what I’m going on is public. And partially, the point of the post was that I’m not hearing a lot and there’s not a lot of conversation. And what there is, it’s kind of very quiet and like back-channeling, and it just makes me uncomfortable and nervous. I don’t know where we are. What I shared about those two developers was public. I haven’t spoken with either of them personally. I did talk with someone who was a former Basecamp employee and was involved in Rails in a lesser capacity and they reached out to me and said, “Hey, yeah, thank you for writing all this up.” And they had said that they intend to step away from involvement. I think, initially, I wanted more conversation with Rails Core. I’ve had some with some members of Rails Core, but I guess I don’t know what the temperature of their situation is. I don’t know how they’re feeling or how they’re leaning. I do know that they have heard some of the governance problems that I’ve sort of highlighted in my post. They’ve heard those. I think it’s kind of an open question for how that resonates with them and how they want to kind of move forward. And that’s sort of also I think the next step for me is perhaps reaching out a little bit more and trying to get some of those temperature checks and trying to see where they’re envisioning, “Okay, here’s where we are today. Is everything copacetic? Is everything good? Do we want to change anything? And then if so, like what do we want to change and then how? How do we get there?” And that’s like a huge process.


[00:44:18] JP: So you mentioned that you drew this distinction both here and in your blog post that you're a Rails contributor and that is different from a Rails Core member in terms of the permissions you have and the amount of changes you can make directly to the code. I’m wondering, how much of that difference is written down somewhere? I think a lot of the interest in your blog post is that the general user of Rails has no idea about those distinctions and where those lines are drawn. And I’m wondering if you can talk about, like, how much are you privy to what happens in the core team versus the contributor team? Do you know how many contributors there are? Do you have a community you talk amongst yourselves? I’m just kind of like wondering where those lines are and what that community is like being a contributor.


[00:45:06] RS: So contributor as a community happens either via GitHub where we are just working and doing the day-to-day PRs and all that kind of jazz and I’ll see a new face and a new name. GitHub has those labels now, I guess, where it’ll say like, “Oh, this person has contributed or like this person has commit.” And so that’s one way I interact with those people. And the other way is through chat on Basecamp. A part of Basecamp is like a Slack, Discord, or Campfire if you’re old school. It’s actually the Campfire product just rolled into Basecamp. And it’s extremely informal. The chat is very dead most of the time and then we’ll go through flurries of activity. And so from what I’ve been told of Rails Core, the vast majority of chat interaction happens on the contributor’s channel because it’s a super set of core. All core members are also contributors. I’ve also been told that not a whole lot happens in the core channel. I also don’t have any reason to not believe that. It’s not like there’s some cloak-and-dagger secret society or something in there where they’re like, “No, we just can’t tell you.” I genuinely believe when they say, “Hey, not a lot happens in there,” because I also have witnessed like the contributor channel and like, yes, stuff happens there, but also not a lot. Then you also ask like the difference between core and contributor. I can answer that unless you had any follow-ups on the community.


[00:46:42] JP: No, no. That explains it. Yeah. Why don’t you go through it specifically like what is the difference like in terms of get commits, I guess?


[00:46:53] RS: So it’s not written down anywhere, the difference, but basically core, the single largest thing that I can tell that is the difference between them is that core has access to release Rails on The other thing I talked about on my post was that they have ownership over different components. The other thing is sort of seniority. I talked about this on the post where I had essentially a disagreement with the developer, like a very minor, like I was trying to have several different pull requests going at the same time. I had a gnarly rebase scenario where I submitted a docs PR as separate from my other actual code change PR and I was trying to like get that in. They left me some feedback. I don’t remember exactly the specifics of it, but essentially I didn’t listen to what they said. They were like, “I don’t like this.” And I was like, “Well, I do.” Disagreement. We both disagree. It’s docs. We’re one revert away from being back to where we started. And so I merged it. I got sort of pulled aside and told like, “Hey, that was a really big deal. You should never do that again. This person is on core. You shouldn’t like go around or behind their back,” which I can see from two perspectives. Like if I am on core, I actually like that somebody has my back. And so it was not the person who I had the disagreement with. From a managerial perspective, if there’s like this manager stepping in to talk to me, but also from my perspective, it’s like I felt like I was coming in from a zero sum. Like at this point in time, I’m already top 100 contributors or whatever. And it sort of felt like I kind of thought I had a lot of clout on the project and they’re like, “No, no, not really.” And I was like, “Oh, okay. Well, good to know. Today I learned.”


[00:48:41] JP: You’re involved with several other open source projects and have made important contributions to them. How would you compare how those projects are run with Rails? And my follow-up question is, are you happy with the way Rails is running their project? I don’t mean to get you in trouble with Rails or anything like that, but I wonder if you just kind of compare, where does it fall on the spectrum of other open source projects that you contribute to and are involved with?


[00:49:05] RS: Ultimately, I would say I am a little disappointed in my own behavior because, yes, I contribute to a bunch of open-source projects. I also maintain a couple relatively popular open-source projects. And I have not really fostered community as well as I would like, if I’m on the other side. Like now that I’m looking at it from the lens of the other side, it’s like I let issues languish and I let pull requests go un-responded to, and I’ve been very even hesitant in the past actually about giving anyone commit to my projects. What if they make the wrong decision? What if they do the wrong thing? And it’s so much work for me already. In my head, it’s like adding two people will actually like slow me down and have to have some of these conversations. And now that I’m doing this, I’m like, “Oh, maybe some of those conversations are good.” It’s good to have some conversations and some community. And so that is an answer to one part of it. A lot of projects are very just ad hoc, right? They just start as one person creates a thing and then, oh, before you know it, they’ve got thousands of users. And then before you know it, companies have been built on this and you have stakeholders. I think in some ways, this is almost an artifact of like you emulate what you see and this is what Ruby itself has done. The governance structure of Ruby as a language is also extremely informal. There’s not really an RFC process. There’s not really voting. We have what is informally known as a Benevolent Dictator For Life, BDFL, with Matz. And so therefore, a lot of the other projects in the same community are also structured in very similar ways. What do I wish was different? My immediate short-term sort of like obvious thing would be just like starting basically where I did of like writing it down. This is Rails. This is how we do things.


[00:51:14] JP: The biggest wow sentence I took away from your piece was where you said writing this all down made it clear to me that Rails is fundamentally built on politics. I wonder if you can talk about that.


[00:51:25] RS: Yeah. So I forgot that I wrote that line.


[00:51:30] JP: It’s quite a statement. I mean, yeah.


[00:51:33] RS: Yeah. It’s like I have just implicitly jumped into the system and navigated it and like I have navigated it in my opinion very well. It’s worked out very well for me. In my head, it all just made so much sense. It was almost like the Rails Core when they said, “Oh, we are Rails, not David is Rails.” But then I’m looking back and remembering, and it’s like, “Oh, if I want some of the features that I wanted in,” I literally was like, “Oh, I’m going to go to this conference and talk to this person.” And it’s like, “Oh, wait, I’m literally going to fly to this other city, go to this thing that costs like a thousand dollars for a ticket or whatever, like have a hotel, and then I’m going to like take this person out, and then it’s like, ‘Hey, do you want beer? Let’s chat about this idea I have.’” On one hand, it’s like, “Oh, well, why shouldn’t I be able to do that?” And on the other hand, it’s like, “This is outrageous that this is how stuff gets done.” Yeah. I don’t think I fully appreciated the landscape until I kind of wrote it down. In my head, I’m like, “Oh, anybody can make a pull request.” And it’s like, “Yeah, what happens when that pull request gets stuck? What happens when you get some like minor negative feedback? What happens when this one whale of a person comes in and says something in your PR that everyone else’s disagreeing with?” It’s just so complicated. So yeah, it’s so wild.


[00:53:05] JP: Well, thank you so much for joining us. This was excellent and we appreciate it.


[00:53:10] RS: All right. Have a good one.


[00:53:22] SY: Thank you for listening to DevNews. This show is produced and mixed by Levi Sharpe. Editorial oversight is provided by Peter Frank, Ben Halpern, and Jess Lee. Our theme music is by Dan Powell. If you have any questions or comments, dial into our Google Voice at +1 (929) 500-1513 or email us at [email protected] Please rate and subscribe to this show on Apple Podcasts.