#55 Yehuda Katz on how framework design influences communities
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Tim Bourguignon 0:06
Hello, and welcome to developer's journey. The podcast shining a light on developers lives from all over the world. My name is Tim Bourguignon, and today I received Yehuda Katz. He is one of the creators of ember, js and retired member of the rust, Ruby and Rails and jQuery core teams. He's nine to five home is at the startup he founded coattail. There they are, he works on skylight, the smart profiler for rails, and as Ember JS consulting, but he's best known as we will probably discuss tonight, for his open source work and his work traveling the world doing open source evangelism and web standard works. houda Welcome to a tech journey. Hello. So you have done so much. I don't really know where to start. But I guess I would like to go back to the Genesis and start there. Where do you passion for for coding originated from?
Yehuda Katz 1:06
Yeah, so I have a few different origin stories I'll start from when I was a kid, even though it's not really exactly the starting point, just because there's something to say there. So when I was a kid, I lived with my parents, I had three siblings, my mother gave birth to my youngest child under four years from when I was born. So it's a very, very close family. And as you can imagine, we didn't have that much money. So it was also a very, it was a struggling family, obviously, giving birth to four kids in four years as also, as an adult, it's like mind blowing to me that this was even possible. So growing up, we didn't have that much money. But my father was a computer technician. He wasn't a programmer, he repaired computers. So we always had some computers around from when I was young child. And I noticed, like, when I was maybe six or seven, something like that, we had das because like everyone had baths, and I noticed that there was qbasic on it. And so I did a little bit of I wouldn't I wouldn't call programming necessarily right away. But I know I went in and there was a game called nibbles, which is snake. And I, you know, I would go in there and say I, I figured out how to make myself have unlimited lives or something like that. So I learned enough programming to like hack the game. And the coolest thing about das and qbasic was that they gave you the source code for the games that came with it came with two games, it came with nibbles, and a game called gorilla. And you could just like, open it up and look at the source. I wouldn't say that I was, I really knew what I was doing. But it was or even that I understood the importance of Wow, I have the source here. It was more like, Oh, I'm playing this game. It's fun, but I keep dying. And if I figure out where the the life meter is, I can give myself more lives. So that was like the first program I did. I also did a little more programming. After that, try trying to make my own games. But when I say games, I really mean ultra simple. I learned enough hat to draw like circles and squares and rectangles using cube basics, drawing stuff. But I never learned enough programming for me to even in retrospect think that I was programming. I was programming but it was like really basic, no pun intended. And at some point, a relative was like, Oh, you're programming that seems cool. And he gave me a C book, the cane RC book. And I opened it up. And I said this has, I have no idea what any of this means. I was like, you know, maybe I was like eight or nine. I had no idea what any of this means. But I guess people are telling me that the thing I did so far as like not real programming. But this other thing, this can RC book, that's the real programming, and I have no idea what it is. So I guess I'm not a real programmer at night, just stop doing anything for probably like 10 years at that point. The only other programming I did before I did it professionally was in high school I was I was always a very big Star Trek fan. And I found on the internet a thing that described and more or less accurate algorithm for computing a start date from any era of Star Trek universe from a date. And I remember I used Visual Basic, to create a form and then to run like, implement the algorithm from the FAQ. And I had a similar experience back then, which is I had I learned enough q basic. Sorry, I learned enough Visual Basic to write that program at night. enjoyed writing it, and I enjoyed having it. But when I started looking a little more into it, what I learned was that the real programming was the wind 32 API. And I looked at more into it. And at the time, it's not like there was a ton of online. When I say real programming, by the way, I mean, quote, air quotes, real programming, it's how I felt at the time. So and the internet existed. But first of all, I wasn't that good at using it. And second of all, it wasn't like the kind of flowering of materials that existed today existed on the internet, I learned that the only real way that I could really learn the wind 32 API was to buy this book by
Yehuda Katz 5:40
petalled called,
Yehuda Katz 5:42
which is the book that exhaustively documents, the 132 API. And it was like $100, and I couldn't afford it. So I sort of had a similar experience, which was, I guess, I have once again, learn the fake programming, and I can't afford the real programming. So I just gave up at that point. And sometimes, so that was in high school. And just to be clear, I'm not as far as I can recall, I'm not really exaggerating, either of these stories, I think roughly, it's what happened. I'm putting a fine point on the fact that I gave up for bad reasons, because I think that's the lesson of those stories. But it's, I wouldn't say that it was what I was even feeling at the time, it was more like, Okay, that was fun, I can't really do the other thing. The other thing seems like what I would probably do if I was being serious by hand, so Oh, and but moving on to do other things. Now in I went to college, in college, I took a few computer science classes, but I felt like computer science was like very abstract and didn't really connect anything I was interested in. And I what I did more of is I ran the student newspaper for a few years, and I was also involved in student government. And I became a plausible designer running the student newspaper. And so when I finished school, I was looking for work. And I was able to get a job as a designer web designer. And that that job, this is the real like what I would call the real origin story. That job didn't really know what it is that they wanted. What they wanted was someone to do, quote, unquote, design work. They had an external firm that had a bunch of people working on their design, it was a nonprofit. And they figured they could get rid of the whole external firm and replace it with a one with a one half time designer. And so they paid Okay, so I took I didn't have that much money at the time. So I took the job. But I quickly discovered that web design and print design that I was used to had really not much to do with each other. I mean, I would say they, like in retrospect, have something to do with each other. But I really, really, really needed to learn how to program. So I learned at that point, I didn't have a choice. And the good news is, when you're writing when you're doing web design, the real programming is the programming that people pay you to do. And the and the program that people pay you to do has a lot in common with the fake programming that people tell you is fake when they're trying to dissuade you from programming. So you know, what I did was I made I made a few websites for various fundraising activities that they worked on. And the the thing that really got me into programming and and then I will let you ask for a while, the thing that really got me into programming is I was so I was doing this form for a basketball tournament that was a fundraiser for this organization. And it was just the forum just went on and on and on. I had all these questions. And I remember thinking, there's really no reason why this form goes on and on and on. First of all, there's a lot of questions that only make sense if you answer the previous question that particular way. But I don't know how to make that happen. And second of all, and I still, I still find this frustrating to this day. Second of all, it's basically true that if you know somebody's zip code, you know, their city and state in the United States. So why am I forcing people to type in the city state and zip code when zip code should be enough? And at the time I investigated, it wasn't like today where I'm sure there's like a GitHub repo with the information in it. I couldn't actually figure out how to get the database for no money at the time. Like maybe it was possible but I couldn't figure it out. But it but those questions like Surely there's a better thing to do here than just a giant form. Like Surely, if I can program it and I guess it was less like, I don't think I knew for sure, but I just felt like I really really need to learn how to program so that I could try to do a better job at presenting this forum to users. Because I don't, I wouldn't want to fill out this form. And I'm sure there's, there's some better ways than what I, what I can already do. So that's more or less how I started programming.
Tim Bourguignon 10:17
When was this approximately?
Yehuda Katz 10:21
I was 2005, which was a prop, it was within a year after both jQuery and rails were.
Tim Bourguignon 10:28
So you're already working with JavaScript and, and rails at this point?
Yehuda Katz 10:31
No. So the, my very, very first work was, I was handed a cold fusion app for that was used the year before for their annual dinner, and I was told to update it. And that was actually pretty easy. Because I was just like, more or less, I was updating text. But I had to learn enough to understand what was going on. I wouldn't like cold fusion was terrible, and it not to undermine people who are using it. But like, I don't think I I didn't enjoy using it. And it didn't feel clear to me that there was a path to becoming a better programmer, more advanced programmer through cold fusion that was sort of this hard line between using tags and making tags, you make tags and Java use tags as a user. And so I that wasn't a fun job. But it was the first job. And then after that I didn't know JavaScript, I remember going to Barnes and Noble, which is a popular bookstore in the United States still. And I just went to the computer section, and I picked up the book, PHP, five and MySQL, or maybe it was PHP four. And I learned enough to just put together from scratch the the the basketball tournament website, as well. And then I had to do a golf tournament website, which was sort of a similar story. So I, I didn't know any JavaScript, I just knew I and I wasn't writing rails at all, I just knew that there was a better way. And I sort of had heard rumblings from just being around that JavaScript was a way that you could accomplish more than what I already knew how to do. So that was what it got. It drove me, it drove me to learn more about what JavaScript was capable of. Just because the thing that was in front of my face was, I really want to make this form less horrible to use. So I like dug, and I dug into learning JavaScript, so that I could build a form that was more progressively revealed than the one I was already building.
Tim Bourguignon 12:31
Now, that sounds like a very good problem to have, and something like you're passionate about, and you really want to solve it as always the best thing to to get you learning. That's cool. That's cool. So you didn't stick to to PHP and MySQL and MySQL, and you went over to to JavaScript. And
Yehuda Katz 12:50
is it That's correct.
Yehuda Katz 12:53
I wouldn't say that I stopped. Basically, my entire career I wrote, I was both a back end and a front end person. But I would say that I, PHP and ColdFusion, were both short lived, things that I used, I started, there's more of a story to it. But I started using rails pretty early, like pretty early in my career. And I started using jQuery also pretty early in my career. And I stuck with those two things for a pretty long time.
Tim Bourguignon 13:22
What's what attracted you to rails?
Yehuda Katz 13:24
So I was really excited about JavaScript. And at the time, like I said, there wasn't it wasn't like, there was a lot of Stack Overflow, you know, there was experts exchange or whatever, which you have to pay for. And again, I had not much money. And just in general, there wasn't a lot on the internet to teach you anything. It was still an era where you really learned a lot by buying books, which again, cost money. So I learned that there was a workshop, which cost like $500, or something, to teach you how to write a what was called Ajax at the time. And I somehow convinced my boss to send me by the time I actually got there, I already had gotten interested in jQuery, because through a project call at the time called interface, which was a it was a UI library written on top of jQuery. And I found it on through slash thought, I think. And I was just like, Wow, this is so cool. This is I really, I'm like really impressed. I didn't know you could do a lot of these things on the web. What's it built on? And it turned out it was built on jQuery. And I eventually I quickly learned jQuery and got into it. So by the time I ended up going to this workshop, I already knew jQuery, like, okay, and it turned out to be a workshop about prototype by Thomas Fuchs, who was the creator of script calculus, which was a prototype ecosystem project. And so I would say I got there and it was like kind of a waste of 500 bucks in most ways, because I was just, I kind of already by the time I got there, learned everything I needed to know in in jQuery, and I wasn't Going to use prototype. However, at the very end of this seminar, Thomas Fuchs said, by the way, if you think all that is cool, there's a project called rails, Ruby on Rails that is, makes a lot of it easier, and you might want to check it out. So basically, the 500 bucks resulted in me learning the existence of rails, which I would not have learned on my own. And I pretty quickly looked into rails and was, it was one of these things where I was so new to programming, I didn't know anything. And I could just look at DHH is 15 minute blog video, and sort of follow along. And I had working systems, and I had a, I had a working, I was building CMS for this nonprofit, I didn't really know what I was doing. But within, you know, weeks, I already learned enough to make a working CMS for for this nonprofit. In retrospect, in a lot of ways, it's not that hard. But a lot of what is important, a lot of what's important about programming, and like the most, the greatest things about programming are taking things that are not that hard, and making them accessible to people who know almost nothing, right? So I was I was one of those people, I knew almost nothing, and rails made building a CMS tractable and made it something that could I could reach out and do. So within like, you know, a very short amount of time, I was feeling incredibly productive compared to what I do before. And, like, unfortunately, I was working for a company that thought that one person half time could be worse, it was a massive company with hundreds, it was a the nonprofit ran houses for people with various disabilities. So it ran over a dozen or dozens of homes for people with disabilities. And so the it was just a large employer. And there were a lot of departments and all the departments were now given carte blanche to ask me to do stuff. And so I was like, sort of sitting there with 20 1520 hours a week with an overwhelming amount of new projects. And even rails at that point didn't make it possible for me to complete the projects in the amount of time that I had. So that didn't really work out. But on the other hand, if I hadn't learned rails, I think I would have just been immediately overwhelmed. I don't think I could have I would have gotten anything done. And it was just, it was just striking to me that this technology that I didn't, I never heard of until you know, 234 weeks ago, suddenly is allowing me to do things that were that seemed to be completely out of my reach. And that was just that I will never forget that the emotion of that like that was not only Well, I never forget the emotion of that. But it really, like trying to recover that emotion for other people, is what drives my work,
Tim Bourguignon 17:52
I can't I can relate to that. The rails, the Rails framework makes it very, very easy to fall into the pit of success, as it's called. And this convention over configuration approach really helps you to to get really fast in, in productive in what you do. That's, that's, that's very true. But I guess the community work, or the community has done a lot to make the framework very accessible for for newcomers, is it something that you that you felt as well.
Yehuda Katz 18:26
So I actually think that it was much better than than it is now. When I first started, what was kind of interesting was when I started rails DHH had just sort of extracted it from his work. So he did some work, he built Basecamp. And he said, Wow, there's like really a lot of really general stuff in the work I did. Let me pull it out into something that other people can use. And for I think practical reasons. I think there were two things going on. One of them is the other the alternatives at the time, were really miserable. So, you know, when you're writing PHP and MySQL, you're literally writing handcrafted SQL queries. And as much as that's not the hardest thing in the world, it's like tedious as all hell right. And, and something that especially as a beginner you don't getting fluent with even the equivalent of you know, find post number one, getting fluent enough so that you do it correctly. Is is a big project. So both because the end Java, which was like maybe more about abstractions was just miserable, right? It required you to DHH calls it XML setups at the time it made you do so much work just to do the basics. So, like on the on the first hand, rails was just so much better than its contemporaries at cutting away a lot of the tediousness of being a programmer, especially as a relates to beginners, but second of all, because it was so new It's sort of intrinsically lacked a lot of the a lot of the quote unquote serious business that builds up in a framework over time. And I can give you I can give you some, like two really good examples of this that I think are really unfortunate and show that even rails isn't perfect on this front. So the first one is a feature called strong params. And the the, what strong params are trying to do is prevent you from accidentally creating exploits where people can send any arbitrary parameters they want to your app. And suddenly, you're, you know, mutating your database in unexpected ways. And like Rails is already resilient to basic SQL injection attacks. But there were more elaborate more involved ways that people figure out how to use the looseness of the early rails experience to exploit applications written in Rails. And they were usually not like general purpose exploits, but they were nonetheless, fairly general. So what happens in what happened in early days of Rails is DHH would mostly be like, I don't really care. And that was clearly wrong. It's clear on say, he doesn't really care. But what happened later on is that DHH would say he doesn't really care until the urgency level of something became high. Until In other words, until a lot of people he trusted and respected, were telling him, you can't ignore this anymore, this is really important. And then he would, then I think DHH, would become a lot more willing to accept a lot of what he would originally have called XML setups. So I just, I just think the solution that they write that for fixing that particular vulnerability, took what originally when I programmed rails, felt,
there's a phrase that the Python community sometimes uses, which is like, it's like pseudocode. rails when you first started in 2005, in a lot of ways, just felt like oh, it's like, what's in my head, I'm just putting what's in my head on the screen. And strong params makes you whole rails, a lot of things makes you explain to rails in a kind of imperative way, what you're expecting. And what that means is that if you're a brand new rails developer, instead of sort of thinking about stuff, I'm putting it on the screen. Now, you have to also know about these extra pieces of work that only matter. They only matter as a security to fix security problems. And I should be very clear about something. I don't think that the solution is to ignore security. But I do think that there are tasteful ways of making things secure by default, that don't expose the guts of the security problem to users. And if you do expose the guts of a security problem to users, that bit, you the biggest impact is felt by by new developers, right? Because an experienced developer already knows that they should care about the security issue. And they already know enough to understand what this what the elaborate solution is doing. But and therefore, if they feel strongly enough that you have to fix the problem, they might be willing to accept things that feel okay, they feel low impact for a person who understands things. But now all the sudden, instead of the smallest thing that you could possibly do in Rails B, you know, you wrote a template, and it worked. Suddenly, the smallest thing that you could possibly do requires you to enumerate all of your parameters and explain what types they are and things like that. And that's a from the perspective of an advanced developer, maybe that's something you would have wanted to do anyway. But from the perspective of a beginner, it's a big jump. So that's, that's one. The second one, which I'll try to say, in less words, is, when rails first came out, if you just put a like you made of controller, and a view in your app, and you didn't say anything else on the router, it would work by default. And again, this was another thing where people notice like you can make an act, people could send a controller and action, which is like rm rf, your stuff. And with enough creativity, you can trigger bad results. So again, there's a security issue here. Because the security issue was very severe, the solution that rails decided on was, we'll just make everyone enumerate all their controllers in the router. And, again, a lot of people already thought especially experienced developers thought that's a pretty good idea anyway. But now, instead of a beginner developer, just making a little controller have a few lines of code and a view template and having it work. Now, a beginner developer has to remember to put a route with the right syntax and the right spelling, they have to remember to write strong params. Right. So suddenly, you go from Oh, I can sort of imagine that. What I'm thinking is what I'm typing to a whole bunch of stuff that makes it harder. So I think, I guess, I think On the one hand, people can learn anything. On another. On the other hand, early rails was just almost perfectly suited for somebody who only knows HTML and CSS and wants to add a little dynamism to it. And today's rails has a, I wouldn't say it's a massive chasm to cross. But I would say for a lot of people, it's a chasm that they're not prepared to cross either for, for time reasons or skill reasons. And so I think that's too bad. Hmm.
Tim Bourguignon 25:32
That makes sense. Makes sense? Um, I was this particular problem influenced you and when creating you frameworks or being part of core teams for for new frameworks.
Yehuda Katz 25:45
Sure, so So first of all, I am talking about it a lot, because it's probably the thing I care about the most. Not at every point in time, but at most points in time. And I also want to say straight straight up that I think that Ember isn't a perfect representation of what I think what I think it reflects the values I'm talking about here. And just to lose a little bit of color there is when Ember first was created, we were working in an environment that had virtually nothing, just as a reminder, like IE six was still if I think was still the most popular browser, but if not the most popular browser, it was still a very important browser that people have to think about a lot. And IE six, for example, like rape puts up a warning if you reach 10,000 statements, right. So it's not like how much time it takes, it's like, it counts how many statements that executes. And then it prints a warning, right? So there was in the environment was just pretty different than it is now. And so a lot of the early days of ember was a compromise between trying to build something that would be really, that would make it really accessible to build applications. So Ember was always different than everyone else in the sense that its job was to make it easy to build applications, not like widgets. But at the same time, we in order to make that work, we had to take on a lot of the responsibility of abstracting over the world and the world was unpleasant. So a lot of embers history has been dealing with that compromise in a way that I don't find satisfying. Like I feel like it for all, for everything I talk about. Wanting to make things very accessible to beginners, Ember, historically, historically hasn't been the most accessible. One thing I'll say about that is that it's easy to not notice that. So Ember is a is a whole app framework. And so in order to really compare it to other things, you have to look at the set of things that you have to put together to build a whole app framework in backbone or in Angular one or in react or in view. And I think when you do that, apples, apples, usually Ember looks pretty good. Because most people with no experience can't really get over this out of the starting gate with something that requires you to build a lot of stuff yourself, right? So and I think these days, things like create react app, or some of the vcli tools are getting like inching those systems a little bit closer to being in the right scope to even do an apples to apples comparison. But for a long time, people would talk about, like, Ember has a big learning curve. And really, all they were saying, I think is Ember has big scope. And I think we had a big scope, because we cared a lot about people build making it possible for people. without, you know, not in the top 0.1% of web developers, we want the people to be able to build applications. And even to this day, that's still pretty hard. So I just want to caveat everything I'm saying with I don't think Ember is the best example of the values until like, really recently. But the way I That said, the way I think about things is, I really, I want to prioritize, there's actually a thing I haven't said here, which is sort of the natural consequence of everything I've said, which is, I think it's very important for communities to share solutions, not just across the entire community and across all experience levels. And what I mean by that is, a lot of times when you have a tool that's pretty good at doing a thing. But what everyone is actually doing is a bigger thing. So in this case, like react is very good at being a component layer, but everyone is building apps. What ends up happening is that a lot of companies have their own tools for building applications. And a lot of really advanced developers put together their own sort of tool sets. But what that means is that if you're not at a big company, or if you're not already an advanced developer The project of learning enough to build an application in react or backbone is often out of your reach. And it also means that the people like that even and it doesn't even help the big companies, right? So if you're a massive company, and you built a lot of your own infrastructure, what ends up happening is that now you're responsible for maintaining all the infrastructure yourself. And before long, the person who made the original infrastructure leaves for greener pastures, or there's just a different thing that the ecosystem decides is the right thing. And now you're stuck with all this work that you did.
For what you thought was a good idea, or the previous guy thought was a good idea. So I think it's, I just think a thing that Ember cares a lot about, and it's hard to pitch but is really connected with everything I've said so far is Ember cares a lot that everyone uses the same tools. And that means I one of the creators of ember, and a brand new Ember developer who doesn't have never really written anything in Ember, both use Ember see a lot, right, everybody uses Ember COI. And that means that when somebody makes an ad on that ad on uses NBC a lot, and that means that if I, if I need to build an ad on for to make deployment easier for me, that add on is accessible to somebody who's just starting out. And it's, it's kind of a subtle point, right? It's kind of a subtle point. Because if you're a super advanced developer and trying to decide what to do to you, it doesn't seem like it makes that big of a difference, whether you built it yourself, or whether you use off the shelf components, maybe you even think you prefer to build it yourself. But there's just a nice virtuous cycle from everybody agreeing that what we're doing is building stuff together. We're not, we're not all off in our own corners building, building stuff for ourselves, we're all trying to make the whole community of people building Ember apps better. And that's something that rails, you mentioned, the community rails really believes in that. It's something that the Ember community really believes in. And it's frankly, something that a lot of communities either believe, is wrong. There's a lot of communities that think that the thing I just said is actually wrong, or struggle to do it. It's something you have to like really believe in.
Tim Bourguignon 32:22
Yeah, I can really see how the to the two environments or the two, the two frameworks really align in this philosophy. That's really makes sense. This is very open ended, opinionated. But in a good way. That's, that's cool. I would like to speak about about your your work in core teams and how you, or maybe why you wanted or decided to, to, to go that route and work for for us Ruby on Rails and jQuery as a core team member?
Yehuda Katz 32:53
Sure. So there's not like one satisfying answer. So I'll just talk a little bit about each of them. So I joined the jQuery core team, the earliest I was using jQuery at the time, there was just a wiki. So john resig, the creator of jQuery, maintained a media wiki instance, that had the documentation in it. And I was a user and I was just finding it frequently out of date, frustrating, hard to navigate. And I asked john, very naively, I didn't really know what I was talking about, like, surely there is some way of automating that process. And john said, Oh, yeah, I know how to use a tool to dump out an XML file of the inline documentation. And at the time, I didn't know what any of these words meant, like, I didn't know really what XML was or what my documentation was. But the next day, he emailed me, so this is before Get up. The next day, he emailed me an XML file that was just the output of running some tool that I still don't really know what it is what it was at the time. And I learned enough, I didn't know how to run how to put servers on the Internet at the time, except if I was working somewhere and they paid for the servers. I didn't really know what I was doing. But what I learned was that there's a language called XSLT, that you can use to turn XML files into other things like HTML, and even Internet Explorer six would apply the XSLT stylesheet to the XML. Again, I didn't know what XML was, I didn't come to like XSLT or anything, but I was just really wanted to get documentation on the internet without, you know, without having to learn a whole bunch of server stuff. So I took a very popular there was a cheat sheet that was meant to hang on the wall, and I stole the style of the cheat sheet, which I think was on Reddit, and turns out and basically use X's LP to translate the XML into an interactive version of that cheat sheet and uploaded it to like probably Some static file server that I don't remember the location of, and didn't have to know anything about, like, running PHP, there was no possibility of it being exploited or anything like that. Not that I knew much about that at the time. And I think john just said, okay, like, I don't really have a lot of help here. But you're doing work. So john invited me to be on the core team. And something I'll never forget about John's management of the of the jQuery core team is that john cared a lot about people's willingness to do important work. But he didn't prioritize people with a lot of existing skills, nor did he prioritize people doing the kind of work that a lot of open source people prioritize whether or not somebody was on the jQuery core team was entirely about people's willingness and ability to do work that advanced the project. And so that included that could include things like running events, or doing really beginner level documentation work. So me joining the jQuery core team was
Yehuda Katz 36:07
just,
Yehuda Katz 36:09
it was just me saying, Yes, I'm interested in continuing to do whatever I can do to help make jQuery successful. I think at the time, I was a little designer, and I made an issue of a magazine, an internet magazine. And I was doing things like that. And I think it's really to John's credit that he, he not only tolerated, but really, but really cheered the work that I was doing and other people and the work that other people were doing that wasn't quite it wasn't that hardcore programming, that sometimes open source projects, sheer something that I've taken. So so that's how I got involved in jQuery. I think basically, the answer to that is it's John's fault. The rails, the rails core team was a little bit of a different story. So I was working my first real job, I was working on a Rails app. But for various reasons, rails didn't prove to be workable. I mean, we never stopped using rails, I think they're still using it now. But it proved to be really awkward for some things we were trying to do, we had a very complicated in a good way, mailing system, and the mailer, part of rails at the time was quite limited. And so we had all this extra work that we do, we forked rails, to try to add some features and things like that. And so at still at a pretty early stage of my career, so this must have this was in like 2007. And I started programming in Oh, five. So sudden, early stage of my career, I didn't know what I was doing. But I did recognize that the way that rails implemented convention over configuration, which was basically to make opinions and then bake them in at a very deep level, like for whatever reason, wasn't working well for me. And so I joined a project called merb, which was a competitor to rails, when it first when I joined it, it wasn't much of a competitor to rails, it was maybe more like Sinatra. But I was both like, kind of head over heels in love with the idea of convention over configuration, which Sinatra has sort of the opposite opinion of, but also really strongly believed that there was a software architecture that would make the opinions less hard coded, right. So the opinions are more of a curation, more of a more of a surface layer than they are super baked in. And DHH, at the time, didn't consider that to be an important distinction. Because DHH, his view was there's an 8020 rule, you're either in the 80, or the 20. If you're in the 20, use something else. And my view, my view was, it's more nuanced than that. There's a lot of 8020 rules. And if every single person who's in the 20 of anything, has to do something else, then you don't have much of a community after all. So again, I don't think I knew much what I was talking about at the time, but I felt strongly that you could build a version of rails that was more modular, and by all I really meant by modular at the time was, it was more amenable to more granular at 2820 rules. And so I built that and I like started going out and getting people to use it. We had some big rails people started to use it. We had a training seminar that people paid for, I started going to rails comps, I they never accept any of my talks because people there was a competitor. Be like giving a real fuck out like Django conference me. But yeah, I wish I actually have given Ruby talks at Python conferences. But But that wasn't VHS thing. But I did birds of a feather sessions at night that got hundreds of people. So there was I would say that that there was a strong pent up demand at the time. And what eventually happened was that DHH and the rails core team sat down with me and the merb core team, which was a smaller group. And merb had done things like really insistent On a stability story, it wasn't quite cember. December didn't exist at the time. But we were, you know, we ran the 1.0 tests in 1.1. Like we were serious about stability. And so we sat down with the rails team and DHH said, and we had been trading back and forth, we've been, we've been cutting into each other on the internet, and and DHH and I both decided, we don't like it turns out that I really agree with the core values, and DHH isn't one to turn down free work. So there's no real reason that the people working on merb can't work on rails.
I, unlike the Sinatra team, the merch team wasn't interested in making it less conventional. We weren't interested in making it less opinionated. We were just interested in making the opinions less deeply rooted. Right. And that's it. That's an implementation question. That's not a that's not a philosophy question. We In fact, had the same philosophy. So we sat down, it's a weird thing to describe, because it sounds like a miracle. But we basically sat down, realize this, and DHH said, that's fine, you you, you are welcome to join my concern on free work, basically. And he made me a member of part of the deal was that he made me a member of the rails core team. He didn't make anyone else members, no one else eventually, like eventually, everyone else sort of floated away, except for Carl, who really should have been a member of the rails core team from the beginning. And that wasn't fair. But ultimately, I became a member of the rails core team as as part of a project to make rails more modular. And I think these days if you ask people were been around for a while. The rails three project which was basically make rails more modular was a, it took a while, but it was it's I think, considered today to be a try to try not oversell it, I think it's considered wildly successful, but I don't want to oversell it. I think at minimum, it was technically successful, we managed to build something that in the rails to era, every single version, every minor version of rails would break our spec, which was a very popular testing framework. And DHH would say, That's not my problem, you shouldn't use our spec. And as a Rails from rails three onwards, including today, every version of rails works with R spec, because they're all using stable public API's. Right? So that that we did that project over and over again, we built bundler, which was the first, the first package application package manager that I know of, certainly was the first application package manager that had a lock file at all. And so we did a lot in that era that was really, I think, technically very successful and showed the path for building the idea of convention over configuration and opinionated work without forcing everyone into a much, much narrower set of use cases that I think is appropriate. So I would say that so my me joining the Rif, I'm answering the question in a long winded way. But me joining the rails core team was basically because I felt strongly that there was something good that we could do with rails to set it up for success long term. And, and I think that's a lot of what I do these days. So that was, that was why I joined the rails core team. What I learned from rails was DHH asked me over and over again, while I was working on rails, he said, What app Are you working on? And I said, What are you talking about, I'm not working on an app, I'm working on rails, and I'm pretty busy. Thank you very much, I don't really have that much time. And DHH would say that's nice, but you're gonna, you're not going to be able to prioritize correctly, you're not going to be able to understand what you're doing, if it's not coming from a real sense of pain of your own work. And I at the time, I thought that was wrong. I thought that was silly. But after 18 months, two years working on rails three, I started to notice that DHH was just right. So the reason I left the rails core team, ultimately, the reason I left Prague, the reason I stopped working full time in a project was that I really, really felt like I needed to work on something real. And let the work that I do be driven by problems that I have that I can understand at a deep level. So basically DHH was right about that. The reason I joined the rust core team. So I've done a lot of things, but those are probably good examples. The reason I joined the rust core team is I felt so rough at the time was a project that was run out of Mozilla. And by the time I joined the rust core team, I was already I already had a very strong sentiment that came I think largely from jQuery and rails and Eventually Ember that projects run out of one big company are they're far inferior by virtue of being far less fair than projects that are, that might have a host company that might have you know, a BD, maybe even I have a BD FL, benevolent dictator for life, but where the effort to decide what the project is doing, what it's about what its priorities are, that comes from a coalition of multiple companies and individuals that are all trying to
advance the project for their needs. And I just, I felt strongly that that was true. And so the reason I joined the rust project in the first place was because I had started using rust at my company. And I, I was noticing that this the difference between a project, you know, am I going to want to use rust in two years, three years, I was noticing that the difference between the answer being yes and no, had a lot to do with whether or not rust will end up being a Mozilla project or a community project. And so I had already started working on Ember at the time, and I was evangelizing the idea of it being a community project where Mozilla was, was a partner was a support. It was a sponsor, but not an owner. And the like, thankfully, the people who were around at the time, Dave Herman was a director of Mozilla research at the time and a few other people, Nico ma tsakos. And Aaron turon. And Patrick Walton. People who were around at the time, more or less were willing to accept. I don't know if they agreed necessarily wholeheartedly, but I think they were willing to accept that it was that there wasn't much to lose. There's a lot to lose organizationally. But there wasn't a lot to lose in trying to be a more community project. The main, the main consequence was that we have to say no to Mozilla a lot, right? We have to, we have to say, we're gonna, we're not going to let Mozilla own all this infrastructure, we're gonna make sure that the infrastructure is owned by the community. And the reason for that is that if somebody stops being a Mozilla employee, or someone isn't a Mozilla employee, and they want the help, it's like important that they don't need to get credentials for Mozilla Slack, or get access to Mozilla's internal infrastructure, right. So there was all in the beginning, there was a lot of effort that was just, let's make sure that the project isn't, is owned by the community, let's make sure that we're being honest about that. It's not just something we say in our heads, but it's something that we're checking, we're checking to see if someone's not a Mozilla employee, how much authority can they have? Are there reasons that they don't. And so I would say a lot of the original reason I joined the project was a governance thing. I helped with the RFC process, I was the person who advocated for the six week release cycle, which, honestly, regular releases are so important for community leadership, because when you have releases that happen, only one like only when they're ready, that creates a sort of a bulk of people in one place that have to do have to turn the screws. And so what ends up happening is for not any good reason, but like the people who work at Mozilla, or the people work at Facebook, or the people who work at Google are the people who can actually exercise control over what the releases are. And so one of the things that's awesome about making the releases regular and short, like a short in time, is that you're forced to set it up so that there aren't there's not a lot of power that's derived from being at a particular company, it sort of takes care of itself. So I advocated for six releases for the stability policy, and other governance things. And I think, for rust, and I and then I would say I spent a lot of time on technical details. But and I still I'm not on the rust core team anymore. But I'm still have all the projects I've been involved in, I'm still the most in touch with individual people at rust and like still trying to help give advice when I can when people are interested. But for us, for me, the reason to join was to really push it in a direction of being a community led project, as opposed to a company own project. And
at the time, Steve cloud, Nick also joined at the time, even one or two extra people makes a big difference, right? Because if all the decisions are made inside of one company, then it's just easy for things to sneak in I An example is there would be meetings inside of Mozilla that were effectively core team meetings, but you could just drop in if you were not on the core team because they were effectively Mozilla meetings. But as soon as we had people as soon as the core team was was not just a subset of Mozilla employees, as soon as as soon as there was a Venn diagram, we have to get real honest about what the core team is like what the what what things should be private to the core team. And if they are private to the core team, then they shouldn't also be randomly accessible to everyone. And again, there's not a ton of privacy is not the higher bit. But just creating a group of people that isn't just a group of people at the company, it's not, it doesn't report up the management chain. Right, I think that's a good way to, that's a good a good heuristic to use. If a team if an open source project effectively reports up the management chain at a company, then it's not really a community project, no matter how many community pull requests they accept. So being a person with a lot of a lot of control over the direction, a lot of ability to provide feedback, and even be part of the consensus process. But a person who didn't directly report up the management chain, again, it just it put it shone a light on ways in which the management chain was already involved. And so so for me, I was getting really excited about rust, but I really wanted to make a bet on it as a company. And I felt that whether I was whether I got involved or not, might have a big impact on the health stability, community ness of the rust project for all the years to come that I will expect to use rust. And so
I felt it was worth getting involved.
Tim Bourguignon 51:26
I find it fascinating how the community work, or the the focus on the community really is the the underlying value of all he said, it's really it really seems to be the focus of your philosophy.
Yehuda Katz 51:41
I think that that's the only thing. Like I think that if you think that your project is going to be successful on the basis of one person's the strength of one person's ideas, or personality, or the size of a company's large s how much money they have, as it as opposed to wanting to build projects that are the property of humanity, or at least a community, I think I think you can do that I think you can be successful as as strong as the force of the personality is or as as large as the, as the treasury of the company is. But I think ultimately, projects that are successful, can be shaped, they can be molded, they can be moved, they can be transferred, based on what is happening in the wider world, whereas companies that are really tightly connected to one person or company, those projects end up their fortunes are very tied to the success or failure or motivations of that company and I are that person. And I just don't see the point of that I think I think we like I care a lot about making impact. I care a lot about empowering people to do things that they couldn't do before. And like Who am I as a single human being to know what that means? What my as a single company, you know what that means? I think we need people to take some ownership of it. Are we in order to do that we need to empower them to take
Tim Bourguignon 53:06
lunch. That's a fantastic way to to close this discussion. I guess the time box is running away. And I don't want to end on anything else in this. This is this is so great. Thank you very much. Okay, where could people continue the discussion with you? Where would be the best place to, to to start a discussion.
Yehuda Katz 53:26
I hesitate to say this, but I do read Twitter and I if somebody wants to say things that are nice, not nice to me. But like if somebody wants to have a conversation that is in good faith and polite, I have no problem doing it on Twitter. My DMS are open. I respond somewhat to emails. I don't have comments on my blog, just because it's not 2005 anymore. And the comment sections are just nearly impossible to maintain. And I also don't like talking to people on Hacker News because I don't I think Hacker News is just a it's both a polarizing place and a very, very focused on things that Silicon Valley people in companies care a lot about. And I don't care about a lot of those things. I guess what I would say is, I'm always I liked I like talking to people on Twitter, if the conversations are, are sensible. I like talking to people in private if the conversations are sensible. And if somebody like if there's a if there's a bigger debate to have or a bigger conversation to have. I also don't mind writing a blog post and letting someone reply to the blog post. I've done that.
Tim Bourguignon 54:35
Okay, so dear listeners be nice. And then you can talk to him on Twitter.
Yehuda Katz 54:43
Yeah, yeah. VMs are always open.
Tim Bourguignon 54:46
Great to hear. Is there anything coming up for you in the next weeks or months that you want to would like to plug in?
Yehuda Katz 54:53
at nothing in the next few weeks, I think that I'm very excited about is the Ember octane project. So octane is a version it's a it's a version of ember that sort of rolls up all the improvements that we've been making over the past few years to make it more usable, more friendly, more accessible to new developers to update the documentation. And just generally to try to shed a lot of what is frustrating about Ember from its early days, it's not the end of the story. But I think if people have looked at Ember in the past and and felt like it was too much, in the next couple of months, we'll be releasing a version of ember that we will call octane. And that would be a good time to take an open.
Tim Bourguignon 55:36
Sounds Sounds good. Yehuda, thank you very much. That was very insightful. And thank you for this, this deep dive into it on the other side of open source development and those, those frameworks that was very, very insightful. Thank you very much.
Yehuda Katz 55:50
No problem. Thanks for letting me talk.
Tim Bourguignon 55:53
That was great. And this has been another episode of Deputies journey. We'll see each other next week. Bye.
dearly listener. If you haven't subscribed yet, you can find this podcast in iTunes, Google music, Stitcher, Spotify, and much more, head over to www dot journey dot info. To read the show notes find all the links mentioned during the episode. And of course, links to the podcast on all these platforms. Don't miss the next developer's journey story by subscribing to the podcast with the app of your choice right now. And if you like what we do, please rate the podcast, write a comment on those platforms, and promote the podcast and social media. This really helps fellow developers discover the podcast and those fantastic journeys. Thank you.