The ReadME Project // @GitHub

Here’s what’s in store for this episode:

00:00 - The hosts discuss GitHub Universe and highlight some of their favorite sessions.

02:30 - First Commit: Neha and Martin discuss the US presidential election of November 1952, which was the first time that a computer was used to predict winners.

05:55 - Features Story: The ReadME Project Sr. Editor, Klint Finley, joins to discuss his recent story Building the future of the command line.

18:30 - #AskRMP - Friend of the podcast and GitHub Senior Software Engineering Manager, Helen Hou-Sandi, joins to answer this month’s listener submitted question.

22:15 - The Interview: Appsmith Co-Founder and CTO, Arpit Mohan, joins us to discuss the myth of the lone hacker and what it takes to manage an open source business.

Looking for more stories and advice from the open source community? To learn more from the authors and experts featured on this episode, check out:

• Building the future of the command line by Klint Finley

• Marie Kondo your software stack with open source by Mike Melanson

• Look beyond lock-in with open source observability by Michael Hausenblas

• Documenting knowledge: a guide to successful note-taking by Cassidy Williams

---

Voicemail audio: At the tone, please record your message. When you have finished recording, you may hang up or press one for more options. 

Neha: Hi Martin, it's Neha. Just calling to check in, see how you're doing. Hoping Universe is going okay. All right. Call me back, bye. Hey, Martin. I just saw you on the main stage, so I'm guessing that's why you're not returning my calls. Seems like you're kind of busy, but, you know, you're doing great. Get back to me when you can. Okay, bye. Martin! I know you're busy, but you can't be that busy. Hey, it's Neha. I’m starting to feel like you're screening my calls? So just, you know, call me so it doesn't feel personal. All right. Bye. I'll just call to say… call me back. 

Martin: This is The ReadME Podcast: The show dedicated to the topics, trends, stories, and culture in and around the developer community on GitHub. I'm Martin Woodward from the developer relations team. 

Neha: And I'm Neha Batra and I lead GitHub’s community engineering team. 

Martin: Hey Neha, how's things?

Neha: Hey, Martin! What's up?

Martin: Oh, man, I'm recovering. So we had GitHub Universe last week, and, yeah, it was a great week. It was lovely seeing everybody in person. But boy, talking to people is tiring. It's quite nice to be back here in the cockpit doing the podcast with you.

Neha: Yeah, not going to lie. I had a little bit of FOMO because I wasn't able to attend Universe in person, but as an introvert, I was also pretty excited to be able to save up my social energy and use it on some other things instead. Instead of that horrible recharge period, you know.

Martin: Yeah. And, well, not to do a gratuitous Universe Plug or anything, but all those sessions are actually available online. If you go to GitHub Universe dot com, you can actually go and download all those sessions, which is great. Anyway, with that, let's talk about what we've got coming up today. This month's feature story is all about the command line. We'll hear from senior editor Klint Finley about why that blank screen and blinking cursor can strike fear in some, but get others all jazzed up. We'll get another question from the “ask RMP” hashtag answered for you, and we'll speak to Arpit Mohan, co-founder and CTO at Appsmith, on why building a platform for others to create on is just as exciting as building the thing itself.

Neha: All right, everyone. It's that time. First commit.

[Jingle] On your mark, get set. We're writing on the Internet.

Martin: So, now we know that by now we use computers and AI to predict all sorts of things.

Neha: Yeah, seriously, I've been hearing a lot about the Tik Tok algorithm and how you can get boosted and go viral and how to get on the For You page. I feel like it's a hot topic.

Martin: Well, my For You page is mostly just cat videos, so that tells you everything you need to know about me. But it's not just about the individual level, of course. We use computer modeling to predict some actually important stuff. If we go all the way back to 1952, in fact, November 1952, there was a pretty important moment in computer and political history.

Walter Cronkite: Good evening, everyone. This is Walter Cronkite speaking to you from CBS Television election headquarters here in New York City.

Martin: CBS News, one of the major U.S. news organizations at the time decided to be pretty cutting-edge. They brought in a ringer for that presidential election coverage. This was the UNIVAC or Universal Automatic Computer. That's a thing you used to see in old black and white movies, with the blinking lights. As the night got down to the wire, the race was tightening between Adlai Stevenson and Dwight Eisenhower. And heading into the election, opinion polls were strongly predicting a Stevenson victory.

News audio: Better we lose the election and mislead the people, and better we lose than mis-govern the people. I know something like the solemn responsibility of leading a crusade. I have led one.

Martin: Spoiler alert: I had to Google how to say Adlai Stevenson’s name, so I'm pretty sure it wasn't him that won, and UNIVAC actually correctly predicted those results.

News audio: You got anything to say to the television audience? You're a very impolite machine, I must say. Have you got a prediction for us, UNIVAC? I don't know. I think that UNIVAC is probably an honest machine. A good deal more honest than a lot of commentators who are working, and he doesn't think he's got enough to tell us anything about yet, but we'll be back with him later in the evening.

Neha: Martin, I'm familiar with this story, and there's actually more to it because even though UNIVAC correctly predicted the results, veteran newscasters Walter Cronkite and Charles Collingwood couldn't bring themselves to trust the computer's prediction. So instead they waited a bit, and they didn't announce the computer's prediction to the world until it was pretty obvious that Eisenhower would win the presidency, which was around 8:30 p.m. on election night, 1952. By that point, UNIVAC was predicting 100 to 1 odds that Eisenhower would breeze into victory.

News audio: As they predicted, as more votes came in, the odds came back, and it was obviously evident that we should have had nerve enough to believe the machine in the first place. It was right. We were wrong. Next year, we'll believe it.

Neha: So, there you have it. One of the earliest computer predictions of an election—70 years ago. A lot of us didn't really trust it back then. And today, well, maybe not that much has changed.

All right, Martin, I'm excited today because we're going to be talking about something very near and dear to my heart: We're going to be talking about the command line.

Martin: Oh, boy. So, funny story. We've got, different levels of busy in our house. You know, when the kids know not to come into the office and disturb me sort of thing. And then if I've got a big screen that's all black with white text on it, the kids know I'm properly busy, and know not to come in.

Neha: Yeah, it's funny because the command line really creates some joy and mystery for some people, but it can also be really intimidating, maybe like with your kids. So we have The ReadME Project's own senior editor, Klint Finley, who decided to look more into this in his recent article Building the Future of the Command Line.

Martin: Hey, Klint, thanks for being here.

Klint: Hey. Yeah, I'm excited to be back to talk about this.

Neha: All right, Klint, why don't we just start with the basics. Can you paint the picture for me for the command line experience?

Klint: Sure. Yeah. I mean, for a lot of us who are a little bit older, like Martin and I, the whole experience of using a computer was the command line. You turn on the computer, it boots up to a black screen or a green screen. There's a flashing cursor and that's it. You don't have any icons to click on. Maybe there wasn't even a mouse. It was just: You type stuff into the computer and see what happens. So for a lot of people, that was really exciting. Like you said, there's a joy to it. There's a mystery figuring out what can you type in, what will it tell you, and that sort of thing. But like you said, again, it's really intimidating if you don't know what you could type in, if you don't know if you might break the computer by typing the wrong thing. And the experience is, you know, not that different today when you're actually using the command line. Now it's in a window, probably in a windowed environment. But, you know, it's still just that flashing cursor on a blank screen. In terms of what we talk about when we talk about the command line, there's kind of three different components to it, or three different things that people refer to, all with that term, “the command line.” First, there's the shell. And so that's both an environment and a language, and the environment processes the language. That's kind of the core thing. It's Bash or PowerShell or Zshell, or some of these new shells that we'll talk about later. And then there's the terminal, which is a client for interacting with that shell. And then there are the actual command line applications, things like Git or curl, the things that you're actually interacting with in the command line. And while we're talking about definitions, my friend Chris, this might be a little pedantic, but in the article, I contrast the command line with graphical user interfaces. He points out that technically the command line is a graphical user interface because there's a screen you're interacting with. It's not just punch cards. I think most people today, when they say gooey, they mean a windowed environment, a windowed application, icons, that sort of thing. But it is graphical in that sense and that it was a step forward back in the day. You know, well before my time when punch cards were the main way that you interacted with the computer.

Martin: Yeah, I was about to, you know, take great umbrage at you calling me old back then. And then I realized that I still have all my terminals set to 80 characters wide because that's how many characters fit on a punch card. And so I must actually be pretty old. And so why is there so much innovation still happening in the command line?

Klint: Well, so for one thing, it's just a lot more efficient for certain tasks, where you can just put in all the steps into one line of text, enter it into the command line, rather than digging through a whole bunch of dropdown menus and that sort of thing. You know, it's also just easier to create them when developers are trying to build something for themselves. They don't have to go through and build a complicated interface. They can just focus on a text-based interface with a command line interface. So a lot of apps that people just kind of build quickly for themselves just end up as command line applications. And then it's really just part of tech culture in general. You know, people spend a lot of time customizing their shells, picking the right color scheme, getting the right plug-ins to tweak the experience to be just the way they want it. And people are hard pressed to let that go. Though, in terms of efficiency, a big part of what's really brought the command line back into focus over the last few years is the cloud and cloud automation. I talked to Chrissy LeMaire—she maintains a project called dbatools—and she explained the efficiency side of it this way.

Chrissy: So I am an automation engineer in Europe and the thing that I was hired to do was security, right? So you open up a web browser and you go to your tenable server, which is like a vulnerability analysis, right? But man, there's so many clicks in the process because it hasn't been codified yet. I went and looked at the API and then I created a command line tool in PowerShell that actually did an entire deployment that, like, before, whenever I was doing deployments, it took about two and a half hours and I kept messing up in the same parts because you had to repeat information. But in the end, what I did was I created an automated deployment via the command line. So, every single time that it would run, it would do the same steps, and it did it properly—and it did it in like just 2 minutes instead of 2 hours. It actually made a very boring process extremely fun. You know, the development of it, executing the command is thrilling, but developing the entire thing and codifying that process is one of the most exciting parts of my job.

Neha: And we also talked about how it might kind of seem old school to be working in the CLI in the terminal. But you said you started to see a trend of ambitious new open source projects. And I saw that myself when we were building GitHub CLI as well. What are these new open source projects that are changing the game?

Klint: There's a company called Charm and they have a bunch of different open source command line tools, both for making text-based interfaces for applications, making those applications look a little bit better, adding support for markdown into command line applications to make it a little bit easier to format text. In that experience, things like dropdown menus, all the things you would need on the user experience side of it. And they're also working on back-end frameworks for command line applications, things like automatically generating SSL certificates for authentication. Part of their big vision is more cloud services, more APIs that are command line first, where the idea is that instead of interacting with them through the browser or through a, you know, a rest API through scripting or whatever, that people would be directly interacting with these things from the terminal. So it's, I think it's pretty early to say yet what that's going to look like, but that's part of the idea of the big future.

Martin: Awesome. Yeah. And, you know, big fan of Charm. I've definitely been sort of admiring their work. I must have seen a ton of open source projects come up around this. Windows terminal, Microsoft's project, is one of the most popular kind of open source projects on GitHub, along with ohmyzsh, you know, what are we seeing developers doing in this space?

Klint: Yeah. Another interesting one is called Nushell. That's "Nu" as in Nu Metal, and it's inspired by PowerShell, which has been around for, you know, well over ten years now. But it's still new-ish in the grand scheme of things. And one of the interesting things that PowerShell brought to bear was using structured data in your input and output from the command line. So that's something that Nushell is trying to bring into their project as well. So there's, you know, some limitations, though, in terms of how much you can change existing shells, like Bash or Zshell, without breaking compatibility. So that's why we're starting to see some of these newer shells come along. And then on the user side, there's a new terminal that, it's not open source yet, but I think it's really interesting, called Warp that tries to change the terminal interface quite a bit.

Neha: Yeah. I feel like, you know, even when I think about the terminal and the CLI products that I use, it is contained to this 1D or 2D space, which I find kind of comforting. Right? It reminds me of my roots and when I got started. But are you seeing that a lot of terminals are still kind of stuck in the seventies, or like, feel very seventies right now?

Klint: Right. So the way Warp works is that it presents a more modern interface that's sort of like a chat room where you enter text, there's text scrolling in another part of the screen. There's just a lot of opportunities still to modernize or enhance the experience of using a terminal that will hopefully be really useful for new users, while still preserving a lot of the more powerful features for developers who've been using the command line for decades.

Martin: Awesome. And speaking of terminals from the seventies, if you go to GitHub, there’s a project called Cool Retro Term, where you can actually download a terminal emulator for both Windows and Mac that'll emulate all the sort of different historical terminals, including a monitor and degaussing lines and all the interfaces and things like that—if people are feeling really nostalgic for the old days. So what other sorts of cool tools and applications for the command line should people be on the lookout for Klint, you know, things that people might find useful?

Klint: Yeah. So there's a lot of projects that I wasn't able to actually work into the story that I think are really interesting. So the Cobra Library is another library for just helping developers build command line applications, text-based applications. I believe it was used for the GitHub command line application, tmux, the terminal multiplex server that helps a lot of people manage multiple terminal windows. There are some other interesting newer terminals, Kitty, and Alacrity, that are worth a mention. So, yeah, there's still, you know, tons of activity, lots of interesting stuff happening. So I'll leave you with this thought again from Chrissy LeMaire.

Chrissy LeMaire: So I've actually been using the command line since I was a child back in the eighties. My family had a DOS machine and I was encouraged to use it and pretty much type everything except for format C colon backslash. So that was the start of it. But whenever I got on the internet and Linux was there, I wasn't scared at all of it. I was really excited about the possibilities. But all in all, I have loved the command line. It's been an integral part of my entire computer experience. The command line not only introduced me to faster ways of doing things, but also the process, right? Whenever people are using these pipelines, then they're going and they're using tests and they are doing things in a repetitive way. So the way that the command line is far superior to gooeys is when you have these repetitive, important tasks that have to be tested and repeatable. Without a doubt, I think I would feel very disadvantaged nowadays if I didn't understand the command line to the degree that I do. The cloud has absolutely made it more important.

Neha: All right. Thanks so much, Klint. I feel like I learned about a lot of different apps to check out and to try, and to kind of see what's going on that's new. Before you go, can you give us another preview? But this time of the new stuff coming up in The ReadME Project. 

Klint: We've got some great stuff out now. There's a new featured article from our senior editor, Mike Melanson, that discusses stack creep. That's when your tech stack gets ever more complex because you could just keep adding more and more libraries and things so that you end up with a lot of unnecessary complexity for the scope of your project. Over time, hardware limitations have become less of a factor, and this has allowed for this proliferation of a maximalist approach to software development, which could be wasting developer time and resources. We also have a new guide that digs into the history of open source observability and examines how microservices and distributed systems have elevated the importance of meaningful performance insight. Lastly, Cassidy Williams shares her insights on team knowledge sharing and why using a predictable system for capturing notes can help future-proof your team's collective knowledge base. As always, you can find all these articles and more on the ReadME project at GitHub dot com slash read me.

Martin: It's time for “ask RMP,” the place in the show where we grab a listener question from you, and get an expert to give us their advice. This month, Christina from Washington asks “How do you grow into a leadership position in an open source project?”

Neha: And to answer this question, we reached out to a leader in the open source space, Helen Hou-Sandi, who, by the way, was on the podcast last season. She's a WordPress lead developer and a senior software engineering manager at GitHub. Here's what she had to say about gaining a leadership position in an open source project.

Helen: So the simplest answer, really, is to create one yourself and have it become a major open source software project. But in reality, even if it's your own project and you've kind of grown into making it a major project, you do have to show certain things that help if you want to grow into that role. The first one that I can think of is consistency. Right? You consistently show up, you're predictable, you're consistent. And that creates that trust with that contributor community, right? Where they know that not just that you're able to make smart decisions. Right? Like we tend to think of, you know, our good old friend meritocracy, right? Where we're like, oh, if you're smart, if you're, you know, doing the work, you know, you'll rise up to the top, right? And whatever you may think about whether that's problematic, I think the truth is that being consistent, being predictable, for that contributor audience builds that trust with them. It is being willing to be there for the things that are not easy, for the things that are maybe a little bit annoying, that feel tedious, and that frequently allows you, as an individual, to show that you are ready for leadership. Another thing that you can do is kind of pick up a big initiative. So you show that, you know, once again, you show up consistently, you work on the thing, you're able to gather other people to help you work on it, where it makes sense to be able to break down the work that you're able to give regular updates. Right? So in WordPress, frequently, when we have these larger projects, these maintainership areas, we expect weekly updates about what's happening in that area, right? That outward communication is such a big part of what being a maintainer is, right? And what being a leader is.

Neha: There are technical things you need to be great at to succeed in leading an open source project, Helen argues. But it's the other things that really get you ahead.

Helen: I think that I thought about for a long time is our habit of calling things soft skills. My preference is to call those professional skills, because they are right? And maybe we can think of the hard skills as more like academic skills, right? But those soft skills as professional skills are also really critical. But when you're talking about open source, frequently that communication is online. Right? And so really practicing your communication and taking advantage of some of the asynchronous nature of contributing to open source projects, to working on things that, you know, span places, span time zones, really take advantage of that. It's that thoughtfulness that also sets apart somebody who is in a leadership role. The leadership ends up being about how you tie those things together with other skills that you've learned over time. 

Martin: Do you have a burning question about open source development or GitHub? Share it on social using the hashtag “ask RMP.” That's a-s-k-R-M-P, or send us a voice memo to the ReadME project at GitHub dot com, and we'll answer it in our next episode. Now, Neha, you and I are obviously pretty pro open source now. I don't know if you've always been that way?

Neha: I've always been interested in the concept of open source. Back in the day when I was getting my degree in biological engineering—before I switched over to mechanical—there was this concept of OpenWetWare, where how to open source the processes you used in the lab. And so I was always kind of like curious about it, but I was also really intimidated. I remember going to OSCON, when I was speaking at a conference and they were asking me if I actively, you know, participated in open source. And I said that I really wanted to, but I was so scared about putting myself out there. And conference speaking was kind of my avenue to get myself more out there and more comfortable with my words before I started to venture into open source. And I got to do a lot of that working at GitHub, which was just the opportunity of a lifetime. What about you?

Martin: Yeah. I actually owe my entire career to open source, believe it or not. I was really getting involved in some early projects back in the day that directly led to the job I've got now. So I'm very pro open source. Today's guest is someone who's been on a bit of a journey themselves on opening up. He started out thinking he wanted to work on hardware, then changed his mind. He moved his company over to open source and he's going to open up a bit to us today about what went into that decision.

Arpit: I've always been, for a very long time, been a builder at heart. So from unscrewing the Tamagotchi for the first time, I came across this little green chip that came out of it, and I don't know, maybe the eight- or nine-year-old me part of me thought there was a little dinosaur that's going to come out at me. I was very, very disappointed to see a little green chip. And the more I would unscrew and take apart devices, there was this recurrence of the little green chip, and that's when it kind of struck that, oh, you know, you can build these entire walls.

Neha: Arpit Mohan is co-founder and CTO at Appsmith, an open source platform to build, deploy, and maintain internal apps. He's based in Bengaluru, India, and he joins us now. Hi, how are you doing?

Arpit: Hey, Neha. Thank you so much for having me. I'm doing really, really well.

Neha: Well, great. Why don't you start by telling us a little bit about your current job and maybe a little bit about your background.

Arpit: So currently I'm the co-founder and CTO at an open source local project called Appsmith. It allows developers to build admin panels, internal tools, dashboards, etc. really, really quickly by connecting the UI, by dragging and dropping UI elements onto the screen, connecting it to an API or database, and just publishing a web app really quickly. So things that used to take, at least me, it used to take me like a week or two to kind of get out of the door. Now takes me, today, you know, 5 to 10 minutes. And that was the reason that we built it and also why we open sourced it, because by trade, I'm a backend engineer, I'm a distributed systems engineer. So I've enjoyed working on systems that have web scale, like 30 million transactions a day of web scale, and for the life of me, I struggle to center a form horizontally and vertically at the same time on a screen. I am quite CSS-challenged. This was the reason why we built Appsmith was because I struggled personally.

Martin: Now, you haven't always been doing something as complicated as centering devs, you know what I mean? You sort of started off, as you said, there is a kid kind of in hardware, and you know, similar to me kind of started from there, from the hardware up sort of thing. What drew you to that? The physical manifestation of computing and hardware, robots, that sort of stuff in particular?

Arpit: So hardware is really cool. I mean, it's objectively really cool. And in university we worked on India's first humanoid robot and it did the two things that actually matter in life: It danced and it played football.

Neha: Good choices.

Arpit: And I still remember the first time we got the robot to stand for the first time on its own two feet in the lab. It was about 1 a.m., 2 a.m. in the night, and it kind of stood up. And since then, you know, my love for hardware was sort of sealed. So I always kind of dabble in robots because robots give you that lift, softer. It is abstract, but a robot is a physical, you know, touch-and-feel thing. So when you see a robot physically stand up on its own two feet for the first time, there's a different sort of, I call it the “builder's high” and the builder's high—that dopamine—there's very few other things that kind of give you that dopamine hit. Obviously now I do a lot more software than I do hardware. 

Neha: So interestingly, I'm also a mechanical engineer by degree. And in high school I also did robotics. And so one of my first brushes with software was with robotics and being able to connect those two. Was there like a moment of connection or transition between working on robotics and software for you all? 

Arpit: Absolutely. So when I was sort of deeply invested in the hardware side of things, I was working on the robot itself. At that point, the 16-, 17-year-old me always looked down upon software engineers as, you know, “not real engineers” unless you had a solar gun, at least a spanner, or a screwdriver in your pocket at all times. You weren’t, you know, like a true engineer, that that's what I kind of always believed. But once we actually got the skeleton of the robot up and running with all the server motors and etc., after that point, the true magic of, you know, dancing to a particular tune or, you know, kicking a ball into a goal. After that point, it was, you know, many, many years of software. So it wasn't the hardware that was actually making that difference. It was just software after that point. So I think that's where I kind of drew the line and I was like, okay, you know, hardware is the base thing that you need. You need this car, the Tesla, the four wheels and you know, the hood, is great. But what makes it magical is, you know, the software inside it. It's a computer on wheels. 

Martin: So what's so exciting really about sort of, you know, software and kind of what's really changing in how it’s working in robotics right now? 

Arpit: I think for me, at least with software, there's that famous quote, right? “The more things change, the more they seem the same.” To me as, you know, as open source has sort of taken center stage in the last ten, 15-odd years. It's become, you know, GitHub has grown, the community of developers across the globe. The more we kind of see that, the more we see that it's about people coming together to build something, you know, create. And most of the, you know, open source projects, if you look at the Apache Web server or the Kubernetes project, Engine X itself, etc., these are all open source projects which could not, cannot, i's impossible, for a single person to kind of build. And the more we kind of, as we distribute ourselves globally, you know, geographically, the more it becomes important for us to be able to figure out ways of working with each other. 

Neha: And I think like, particularly kind of coming back to Appsmith, right, I think what's fascinating about the applications, right, is that you are creating this foundation for other people to be able to do things—maybe robotics, maybe hardware—right? And applications that you can't even imagine. Right? And I was curious, since you're in this space and it's open source, have you seen a trend towards different areas of, you know, applications of software? Appsmith allows you to build things that you might not be able to do normally because you're lowering the barrier for them. Right? And so have you seen a trend towards, you know, more open source in like software and hardware and other different applications in recent years? 

Arpit: Oh, yeah, absolutely. And with the advent of, you know, a low-code platform like Appsmith, it obviously has a very broad surface area. So you can build a lot of different stuff. So we see some very quirky stuff being built by people who wouldn't be spending 10 minutes of their day doing this. But because we've made it, you know, it's so simple, it becomes possible. And on the other side, you have some very serious stuff. So on the quirky stuff, for example, what I've seen is there was one engineer who, for their icebreaker sessions that they have within their team, they chose Appsmith to build a “Trump or not” quiz. And you know, you're shown a code and you just sort of choose whether Trump said it or not. Right? And it was just something like a little stupid, if you will. But one of our engineers, he has built an auto-watering plant system. So because he's going on vacation for about a month or so, two weeks or four weeks, and he didn't want his plants to die. So now he just has, he's connected it all to the web. He's built it on Appsmith. So now, wherever he is across the globe, he presses a button, his plants at home are getting watered. And on the other side, we've seen very traditional software being built on top of apps, and we've seen a lot of them, especially around customer support dashboards or customer help desks, because that seems to be a very prime area where you're trying to pull in data from multiple systems. So you want your ticket information to come from Zendesk. You want your order information to come from Salesforce, your user information from your Postgres, maybe put it all on a single screen and then manipulate all of that data together. 

Martin: Yeah. Makes sense. Now, you're kind of living the dream here, you know, building a company on top of open source. I know a lot of people who've tried to thread that needle, and it's not easy. So how hard was that for you? How have you managed that transition, you know, to building a company that's based on top of an open source project now? 

Arpit: Yeah. So one, as you said, you know, super lucky, super privileged to be able to do that. And me and my two other co-founders, we had very, very long discussions about whether we should or should not open source Appsmith. In fact, for the first six, eight, months or so of our existence, we were just building, you know, like a normal startup, you know, in a room together, around a table, close source. And there was this switch that kind of flipped inside us and we said, “Hey, you know, we're building for developers. What do developers want?” And the overarching answer was open source. And that's what kind of flipped that switch for us. That was one. And the other one was working in software for like more than a decade. I have, as you said earlier, you know, build on the shoulders of giants. So I have liberally used open source, but not been as liberal in giving back apart from Hacktoberfest every year, my contributions have been quite few. So this is a way of us sort of giving back to the community what we've gotten over a decade of our professional lives. 

Neha: So I'm hearing like this combo of, you know, give the people what they want, about giving back, right? It feels like this transition is about embracing community, which obviously is what we're all about. Why do you think that the myth of the lone hacker still permeates then?

Arpit: Or that you have to blame Hollywood. Hollywood has ruined… that's my beef with movies. Because it's so cool, visually cool, to kind of watch somebody, you know, “Oh, I want to hack this system.” So you're going to type faster. If they actually shot our day-to-day lives, that would be quite the snoozefest watching people in a stand up and then, you know, following up with five other people on the code reviews. Yeah. Not the most interesting, you know, you wouldn't pay $10 to go watch it. And the other is you have the cult of let's say it's Steve Jobs, Linus Torvalds, you know, fantastic folks in their own right. But what you don't see is Steve Jobs has 100 people behind him and they are the ones who are kind of driving this forward. Without them, it's impossible. You want to go far, you better go with somebody. 

Martin: Well, your life might be a snoozefest for Hollywood, but mine definitely needs Bollywood to come and film my life. There's lots of song and dance numbers in my day-to-day work. So, yeah. So, yeah. And it is all about that team you have around you for sure. You've talked a lot about open source and how it's kind of, you know, you're contributing back to the community that you've built from. Now you're part of that community, how's that helped you? How’s it improve the teams and the entire, you know, company that you work with? 

Arpit: Well, like I said earlier, it was a little difficult transition to make that switch because, I think, going open source for the first time or at least, you know, going open source seriously with the project, there is always this fear of vulnerability where, you know, other people will see my code. They'll probably realize that, you know, I've been faking it all this time. That is secondary. But just being able to open it up to the world in the first place, I think that was the first hurdle for all of us in the team, and it was a huge learning experience for us, where in the first few weeks and months, if you will, we realized nobody cares. GitHub has so many repositories, so many people, you know, it's a massive platform, so nobody really cares. I mean, so you can do whatever you want. It's okay if your code is crap, it's okay because you have time to kind of fix it and etc.. That was the first thing is focusing on making the project better instead of being worried about, well, what will people think? In Hindi it's लोग क्या कहेंगे. The second one was when people actually started to take notice of Appsmith, the project. The community at large was super kind. They were honest with us, and they were kind about it. So they did tell us that, oh, you know, you can do better at X and we, yeah, absolutely agree with you. And more often than not, people would be like, hey, here's a pull request that shows you how to do it. The community is a mirror of what you put out into the world. So if we are kind of putting out a welcoming tone, or an accepting tone, or liberal tone, to everybody and saying, hey, you know, we are here for this purpose and here's our Code of Conduct. This is how we conduct ourselves. And we do this with empathy with each other. That is what you will kind of get back, you know, 99.9% of the time. When I think the team also started to realize that, it actually increased the empathy within the internal team as well, where people I could legitimately see the language change on our Slack three months after we went open source. 

Neha: I think it's so fascinating you started with like, you know, having that vulnerability, understanding that you're putting yourself out there, and then opening yourself up to what could come back, right? Which is that community, that kindness, that empathy, and then seeing, you know, because that is role modeled by the open source community, you can then take it back internally to the team. What are some best practices that you would recommend for open source given your experience? 

Arpit: For maintainers? A, I'd say one is, be kind. I understand that there are some projects which are, maybe, here, I'm speaking from a place of privilege. I face all of this. I have the privilege of having a team do a project. I am not a solo man developer, but being kind to folks gives you 10x the returns. And any particular bad actor person conversation that, you know, if you're not comfortable with, shut it down immediately. Be kind. And this reflects in right from the README to the Code of Conduct to maybe some bought passages welcoming you for your first PR for your first issue. I think GitHub has a checklist as well. Like when you open a repository where you have, you know, you have a Code of Conduct, do you have a license? Have empathetic messages put up that would go a very, very long way. The second is having a regular cadence of responses to your contributors—whether it's issues or pull requests. At times, we kind of get into a place where all, you know, I'm going to do this open source project. So every issue, every pull request, etc. is exciting, and you'll respond to it in like 5 minutes. And then at other times, fast forward a week and then you have—you’re busy a little bit with your life, with your family, with your job or whatever—and you haven't responded in like two weeks, three weeks. And issues are now dead, it's a graveyard in the repository. So, so that sense, especially if it's a long-term project that you're trying to sustain, that sense of very difficult or sort of confusing message to the community, or that you're trying to build. So even if you feel that you can respond in like 5 minutes, they'll figure out what your SLA and your cadence is, and then just stick to that cadence. And that cadence could be 5 minutes, 24 hours, 48 hours, one week, whatever works for you in your life. Because it's not a sprint, it's a marathon. So you don't run 100 meter dashes, you kind of pace yourself for the long haul. Yeah. So having that cadence for maintainers I think is important to measure themselves. Lastly, I would say the vulnerability thing is overhyped. Trust me. Everybody's code is crap. Everybody writes not so great code, or has written great code or not so great code in their lives. It's okay. 

Martin: Thanks for joining us today Arpit, and sharing some of those best practices you've learned as you move towards open source. Really appreciate it. 

Arpit: Thank you so much, Martin. It was an absolute pleasure to be here. 

Martin: If you want to check out Arpit’s work, head over to Appsmith.com. 

Neha: That's it for this episode of The ReadME Podcast. Thanks so much to this month's guests Arpit Mohan, Chrissy LeMaire, Klint Finley, and Helen Hou-Sandi. 

Martin: And thanks to you for listening. Join us each month for a new episode. And if you're a fan of the show, you can find more episodes wherever you get your podcasts. Make sure to subscribe, rate, and review, or drop us a note at The ReadME Project at GitHub dot com. You can also learn more about all that we do and get hooked by heading to GitHub dot com forward slash read me. 

Credits: GitHub’s The ReadME Podcast is hosted by Neha Batra and Martin Woodward. Stories for this episode were recorded by senior editors Klint Finley and Mike Melanson. Audio production and editing by Reasonable Volume. Original Theme Music composed by Zander Sing. Executive producers for The ReadME Project and The ReadME Podcast are Rob Mapp, Melissa Biser, and Virginia Bryant. Our staff includes Stephanie Morehead, Kevin Sundstrom, and Grace Beattie. Please visit github.com/readme for more community-driven articles and stories. Join us again next month and let's build from here. 

Martin: Hey Neha, Martin here. I'm afraid I missed ya. I'm just at the airport now. I’m actually sat at the gate waiting to board, I’ll have to catch you next time I'm over. I’m gonna hit a karaoke bar next time I'm over. You've got a great voice. I’ll speak to you later. OK bye.