Karan, GitHub

Trust me, Kin, your editors are going to love this.

Nice, so whenever you’re ready, go ahead.

All right, we’re ready, let’s start this. Breaking Changes, take one and the only one we’re going to do. Well, welcome back, we’re here for another episode of Breaking Changes, and today I have Karan from GitHub joining us. He’s a developer relations professional, but he’s more focused on DevOps and really focusing on what developers need when it comes to what they’re trying to accomplish in each of their day. So welcome, thanks for joining me.

Hello everyone, and thanks for having me out over here, Kin. I’m really, really excited to be out here on Breaking Changes, discussing a lot about what we have in store, and hopefully we can have a nice conversation.

Great. So you’re at GitHub, and I think a lot of us in the developer realm just assume everyone knows what GitHub is, but with this show I really want to reach outside the echo chamber, so for non-technical people, for business leadership, what’s GitHub?

That’s a good point. So GitHub is essentially a collaboration platform for software developers and their teams to work together on creating software. Of course, most of them might know about it as hosting code, but it’s more of course an entire collaboration platform.

So I think a lot of folks think of it as open source, but it’s much more than just open source. In your experience, what do people understand or misunderstand about GitHub? What does it do beyond just code?

Yeah, I think, like you said, most of them think about GitHub when it comes to open source or hosting code, etc., whereas GitHub is a more powerful development and collaboration platform that includes a whole lot of other features as well. For example, you can do things like automation, you have security features built into the development workflows, a whole lot of collaboration stuff as well. So it’s not just about, go host your code and forget about it, but that’s where all of the development really happens, on GitHub. So it’s a whole lot more than just hosting code.

So is GitHub just for developers? If I’m a non-developer, should I be concerned with GitHub at all?

In a way, yes. If you’re a non-developer you don’t really have to be concerned with it per se, but many people who are not a developer or technically not writing code might find themselves using GitHub, because they would usually be collaborating with other developers and other folks and working together as a team to develop software. And most of the software happens in a collaborative fashion these days. So you might find folks like designers, marketing managers, content writers, documentation writers, etc., working very closely on GitHub with all of the developers, because outside of just the code aspects there’s a whole lot more to GitHub on the collaboration aspects as well. In fact, I know of people who are even in finance using GitHub while collaborating on a whole lot of things with developers.

I mean, that really gets at what I think is the important thing about open source. It’s easy to think that it’s just the code that makes open source, but it’s really the people, the collaboration, the communication around it that makes it work, and I would say the automation and the other things that we use to manage the process. So I think we need to work on getting folks over there, non-developer business-type folks, over their fear of GitHub and realizing that there’s a place for them even if they’re not doing pull requests and pushing code. So before we go too far down into the GitHub and developer rabbit hole, how did you end up at GitHub? What were you doing before, and what brought you there?

It’s a good question. So first of all, I’m a developer by heart, so I’ve always been interested in helping other developers, which is what led me into the profession of developer relations. And I’ve been working with various developer-focused organizations in different segments, often wearing multiple hats. Right now I just have one, but often multiple hats, on advocacy or evangelism or relations or marketing or developer experience, etc. So I’ve been doing this for quite a while now, and as a developer, I realized that I’m able to help other developers as well. And on thinking about it, I strongly believe that developers, all of us really, have the power to build software and to do things that can advance human progress. And personally and most recently as well, we’ve seen this in action, where the many open source projects built by contributors around the world were used in the Mars helicopter project by NASA. So we as a developer community kind of helped enable that, so that’s how awesome it is. And I’ve always realized and seen the impact that GitHub creates among developers, and the way it empowers them, it’s always been fascinating for me. And that’s when I realized that this is where I could do the most impactful work, of helping millions and millions of developers.

So you’re based in India. Is your reach for this just in India, or is it much wider than that?

So developer relations at GitHub is a global function, where we cater to developers across the world, and just like any other collaboration team or an open source team, we work as a distributed team in various time zones as well. So since I am in India, and India is one of the largest developer ecosystems in the world, a large part of my work involves India, but I work on projects globally as well.

So developer relations has been, I would say it’s not new, it’s been evolving over quite a few years, it’s actually getting very mature and professional. There’s most companies who are doing things in the tech space realize they need developer relations, they need to increase investment in developer experience, but this also means there’s a lot of us out there. So how do you differentiate yourself? What makes your brand of developer relations unique and, I would say, helpful to developers?

Yeah, good question. Like you said, there are a lot of folks who are doing some amazing work in developer relations, which is helping all of the developers. For me personally speaking, it’s a work of empowerment. It’s really about helping millions of developers know what’s at their disposal, how it can help them better their work, and helping find a platform to showcase their work as well, sometimes, and of course to listen to how all of the organizations and the teams can help each other do their best work with what we know and what we have. So of course we as developers sometimes need help when it comes to what’s available, how can I use it, how can I showcase my work, etc., and I think that’s where the importance of developer relations comes in. And to me that is what developer relations really means, of empowering all of these millions of developers.

Well, I think what I do in my job reflects what you just described, but I would say my unique is pretty hat-based, that helps me stand out and I’m remembered for what I do, but hopefully I touch folks and help them out in similar ways as you do. So let’s dive into the details of how you do that. So DevOps, you’re a professional that lives at the intersection of developer relations and DevOps. What is DevOps, and why does it matter today?

I really love this question whenever it comes up, because while it’s still being adopted, DevOps is essentially a culture, mainly, and a set of practices that helps bring development and operations teams closer together for a common objective of achieving better delivery velocity, higher reliability, and agility. So most people think that it’s just tools and bringing them together, but it’s essentially more of a culture and a practice. So in today’s world where consumers anywhere face tons of options for their needs, especially in software, you have so many options for literally everything, that’s where quality and velocity would be of really high importance to businesses. And to meet these increasing demands of quality and velocity, and also have an edge over others, companies have realized that adopting DevOps practices and cultivating that culture is important for the business needs as well, because it helps them have that edge on the curve for quality and velocity with whatever products or services that they have to offer.

Yeah, I mean, you touched on this before, it’s like we talked about with open source, it’s much more than just the tool, it’s culture, it’s how people work together, and that’s why I would say developer relations and that kind of enablement really fits well with this. So when it comes to that overall toolbox and culture, how does GitHub fit into that, how does GitHub help companies realize DevOps?

Right, so DevOps in itself of course is a practice and a culture, like we mentioned, but it’s supported by various tools that developers and ops engineers often use. So the way that GitHub fits in is, it sits at the center of all of these tools, often acting like an orchestrator. So for example, teams use features like GitHub Issues, Projects, and Milestones for the planning cycle of DevOps, they use things like the CLI and Git itself and pull requests, Codespaces, etc., for the coding part, and also of course the powerful automation platform GitHub Actions for some of the rest of the life cycle, like builds and tests and releases, deployments, etc. So it’s almost like, how I mentioned, GitHub sits at the center and acts like an orchestrator.

And how do APIs fit into that picture, GitHub APIs but also other APIs?

To put it in really simple terms, without APIs DevOps practices would have been a nightmare, a total nightmare. Because in today’s world, teams and organizations use multiple tools, a plethora of tools, as a part of their DevOps practices. Now if these tools weren’t able to integrate well and communicate with each other using APIs, it would beat agility, which is one of the fundamental existential reasons for the DevOps culture itself. So without APIs DevOps would really be a nightmare. But today almost every developer and ops engineer knows about APIs, and thanks to organizations like Postman helping make APIs more easily accessible and consumable as well. So APIs really sit at what helps make DevOps realizable.

Yeah, and for me, GitHub is, I would say when I realized GitHub was more than a coding platform, it was a social platform, a people platform, and that I could manage using issues, I could do projects, I could manage content in a repo, that it wasn’t just code in there, that took it to a new level for me. But then once I realized all of that had an API as well, that I could automate and orchestrate with the GitHub API on top of that, it just blew my mind. And Actions, I would say as well, once you realize, one of the most common Actions that I use is the ability to run a Postman collection, so a Postman collection pointing to a specific API with a certain set of keys, run as an Action, so basically any API out there I can run as an Action. But, as usual, I’m getting too excited and I get ahead of myself, so let’s backpedal a little bit and stick with what I had planned. So I dove into Actions. What are GitHub Actions?

It’s a good point. So of course I’ve teased it a little bit around what it is, but GitHub Actions essentially is a workflow automation tool. This can be used to automate various tasks in a development workflow. So people use it for continuous integration, continuous delivery, we use it for project management, administration, and a whole lot of other use cases. So you can use the thousands of GitHub Actions that the community has built and published on the GitHub Marketplace, or you can even build your own Action to suit a very specific use case. So to put it in simple terms, what GitHub Actions provides is a way to automate things. What you automate is up to you. So you can automate a whole lot of things.

Well, when I first read about GitHub Actions I was like, okay, this makes sense, this is just GitHub trying to take back a little bit of the CI/CD market share, but it’s much more than that, right?

Yeah, of course CI/CD is indeed one of the most common use cases of GitHub Actions, but it’s not the only use case. Like I mentioned before, it’s used to automate a whole lot of other parts of a developer’s workflow as well, such as managing issues, like you mentioned, or even scheduling certain tasks, or administering users within a team, things like that. So Actions is intended to help a developer automate most of the common tasks that one encounters as a part of their regular development workflow. So if you already have Jenkins or something in place for CI, then they’re great solutions, so why fix a problem if it’s not causing pain. But you can also use Actions in combination if you want to automate those other aspects that are causing pain, like the automation around your issues or releases and things like that. So it kind of plays in however you want it to be, however you want to use it. But I would say Actions has some distinct advantages as well to some teams, due to the way you can easily provision new Mac, new Windows, or even Linux build machines on demand, and you don’t have to keep them up to date as GitHub can also host them for you. So it’s totally up to the team, totally up to the developers, of how they want to use it, because it’s not a zero-sum game. More people are doing CI/CD now because we made it easier to get started.

Yeah, that was the holy grail moment for me when I actually dug into Actions, and I should have known this was coming, is the essence of GitHub being Git, being the core, you need to accomplish version control, source control. But then GitHub brought this whole social, people, collaborative environment to it, that something like Actions would reflect that, is there’s a network effect, and you touched on it with the Marketplace, so it’s not just about what it enables for you, it’s about others influencing you, learning from others, reverse engineering other people, or, I don’t have the time to develop this, I’m going to go find something in the Marketplace. So can you talk a little bit about that, the continuation of that network effect? I didn’t know about the Marketplace, and I didn’t know that I could just find people’s Actions, so talk to me about that.

Right, so that’s really interesting. So looking at how a developer can make use of Actions today is by writing simple YAML files, and one can create their own Actions as well using the fundamental building blocks that the platform provides. Now if you bring marketplace into the action, pun unintended, developers today have created thousands of Actions and published them on the Marketplace, and now these can be used by developers just by including it in their YAML workflow files. So you have an Action that’s published, you just reference it, and you can use it. So it has made developers’ lives easier and GitHub’s platform as well more extensible for the use of all. So it’s continuing to create a community of creators, and actually this is where the power of the community around GitHub comes in, which reflects in that there are more than 9,000 Actions in the GitHub Marketplace today, compared to something around 2,000 or so that Jenkins has. And that means if you’re trying to get started with automation as a part of your DevOps culture, the likelihood is you can build on the work of others around you, because of this huge number of Actions and the really large community around it.

Yeah, when the light went on for me is when I was trying to deploy an API and I needed the code that was in a repo to be published as an Amazon Lambda, and I was like, man, I’m going to have to figure out the Actions, how to do this. And I was like, wait, no, I’ll just search the Marketplace for Lambda, boom, there it was, I didn’t, I went from something daunting that could have been hours or days, depending on how much, two minutes, and I was up and generating code and publishing it as a Lambda and my APIs were deployed. So like, taking me from potentially a lot of work and just saving me time, and that’s that network effect that I really find valuable. Now I’m still learning about the automation capabilities, so talk to me about how you can automate your world, and maybe some examples of how you use GitHub Actions to automate.

That’s a good point. So essentially Actions has this very simple structure of how you can automate. You look for certain triggers as to what can trigger a workflow, and then how do you respond to it. So essentially you can say that, okay, this is the cause that I want an automation to be triggered, and this is the effect that I want to happen. It’s as simple as that. And when it comes to the triggers, there’s a whole lot of things that happen on GitHub itself that you can trigger the Action workflows, or even from outside of GitHub. If you have an event that happens somewhere else, you can trigger an automation workflow with that. So for me, I use it for a whole lot of things. I use it for certain project management, for example, just managing all of the issues that’s out over there, and opening them at certain times, closing them, adding comments, etc., and also I use it to do some of the builds, etc., that I have to do for certain software and things like that. And it’s also, what I touched upon earlier, really easy to go build your own Action as well. So there are of course multiple Actions that are already available on the Marketplace, but if you find a use case that you think doesn’t already exist, you can go build your own Action for yourself, or you can go easily publish it on the Marketplace also for others to use. So Actions has almost become like second nature for me, where I’m continuously and consciously using it and interacting with it on a daily basis.

Yeah, that automation in my world, I think we’re all looking for that kind of meaningful augmentation of the work we’re already doing. How do we get more out of our day, how do we be more efficient in what we’re doing, and maybe get a little bit more free time in there as well, because things are being automated away and we can focus on reading the latest article or book that we need for our career. So moving on from Actions and going into, I would say, open source is what a lot of people associate with GitHub, but I think there’s also a lot of misconceptions around GitHub, a lot of misconceptions around open source and how you get involved in open source and what you need to do to do open source. And not every enterprise organization I come across is ready for open source, but I would say there’s a lot of open source that companies can learn from. And when we talked previously, you shared with me some insights on what’s called inner source, and this is a concept that I’m fairly new to, so can you explain what inner source is and how it applies to enterprise organizations?

Right, that’s a really good point, Kin, because it’s something that enterprises are really excited about, and what it’s called is inner source. So essentially it’s where enterprises adopt the practices of open source development for private code held internally. So that’s how I would put what inner source is. And this is usually a collaborative effort, and it needs alignment with all of the stakeholders of a software that is being developed within an enterprise, because it’s not just the usage of a certain set of tools but a practice and a culture, that includes things like how does collaboration happen, how developers make their code reusable, how the rest of the teams help in contributing, etc. So what enterprises usually do is they learn from other large open source projects, or through resources like white papers, case studies, and workshops that organizations like GitHub have organized as well. So in a nutshell, it’s about bringing that culture and bringing the practice and bringing those benefits of open source to internal private code within enterprises, so that you get all of those benefits that open source has for your enterprise as well.

So it’s not just about the licensing of our code, it’s much more than that?

That’s right. So it’s not just about licensing, because even if you look at open source generally, many folks usually think that it’s, okay, it’s just about licensing, how a software is licensed. Licensing is indeed a key aspect that differentiates open source software, but there’s more to it. Like I mentioned, the key part is the collaboration, the culture, and really the impact of open source that differentiates it, and these are the exact same components that enterprises really want to bring in within their organization as well, to improve the collaboration, to improve the culture of development, to make code more reusable, and to reduce waste, aid resources, drive rapid development, reduce silos. All of these benefits that we already see in open source are being brought into enterprises as well. So it’s a lot more than just licensing, because it’s a culture.

Yeah, and I think a lot of organizations realize they can use open source technology and software, it’s very valuable to put to work across your enterprise organization, but I think a lot of people draw the line when it comes to applying open source concepts. But this opens up a whole other doorway, I would say, that you can learn from, apply, grow, and evolve your teams in an open source way, but you don’t have to be building open source software or giving away code, that you can really tap into all the benefits of open source. And then over time, when you’re ready, maybe you can start contributing to existing projects that you use, or, like you said, contribute GitHub Actions to the Marketplace, maybe some of the Actions that you’ve implemented to automate your world are a little bit more mature and you’re ready to put them out there. So I think it’s very much a learning and evolutionary process. So does DevRel apply in the same ways? Can you do developer relations with inner source within an enterprise?

Absolutely, because many of the enterprises, of course depending on their maturity, they work very differently when it comes to how they want to have inner source practices set up, etc. And essentially DevRel on most of the stakeholder sides, be it the open source projects or the organizations behind these open source projects, or even these enterprises and companies, have all of these several teams which talk very much to each other. So say for example, for me as a DevRel person within GitHub, I would be able to help enterprises connect with say certain projects that they want to learn more from, understand how they implement their development practices, etc., or help with things like the white papers and the workshops or case studies, so that enterprises really understand what it really takes to bring in that inner source culture. So DevRel also forms a really key part over here in not just advising but also providing all of those resources to the enterprises and developers within enterprises as well, to help grow this inner source culture within their organizations.

When it comes to reaching a community, whether it’s external or internal, what’s your most effective tool out of all those things that you utilize? What’s the favorite one for you to employ in reaching your community?

That’s a good point. I am part of the community. That’s the really nice thing about being in DevRel, because we are already a part of the community. I myself am a developer, so I’m using all the same mediums as all of my peers and all of the other developers are using, be it Twitter or LinkedIn or YouTube or Twitch or even Clubhouse or Meetup or whatever it is. So it becomes really easier to go and listen to peers, talk to peers, what they like or what they don’t like, what they need, and what it is that we can do supporting the community, etc. So like I mentioned, it’s whatever the community is using is what I use as well, so it becomes really easier.

So it’s not just adopting some other tool for the sake of reaching, it’s actually being part of a community and understanding what tools they’re using, and being a genuine part, making those tools a genuine part of your daily workflow and what you do.

Absolutely. That’s something, because I’m talking to the same set of contributors, because I’m contributing to some project or I’m doing the same stuff of building Actions or using Actions along with all of the other folks, or I’m there in similar meetups or live streams, etc. So I am a part of the community.

And this reflects the global nature of what you do as well, because you’re publishing and demonstrating your work on a blog, on GitHub, these things can be engaged with asynchronously, people can tune into your work, and it doesn’t have to be in your time zone. I mean, we reflect this, it’s evening for you, it’s early morning for me here, we’re still able to do live streams and work together and share information and help each other out and engage. So it’s really about understanding how your community works, but it doesn’t mean time zone or culturally that this is really a global approach to what it is that we do. So how does GitHub enable that from that standpoint? What are your favorite parts of GitHub that enable you to have that global reach but remain part of your community?

Right, so for us as GitHub, and especially DevRel folks who are part of the community but constantly listening to peers, inclusion and also the global experience that we provide to developers, it’s not just a company culture but also a platform culture for all of us. So when we look at GitHub, it’s used by developers from almost all parts of the world today, from every nook and corner. So we’re continuously talking to our peer developers across all of these regions, and also the product team, the engineering team, and of course all the other teams are working on continuously improving the developer experience for all of the developers around the world. And there are multiple dimensions to this. So it could just be the technologies, or it could be accessibility, or it could just be supporting developers through many open source programs. So for example, just an example is our GitHub meetups, developer meetups, so we do meetups in so many different regions, talking to so many developers and celebrating the communities over there. So that’s what I meant when I said that it’s not just a company culture but it’s also a platform culture for us. And also, like you mentioned, Kin, because of the collaborative nature of open source, you can easily work asynchronously on it. So there are folks who work through issues, collaborate through issues and then project boards and everything else, etc., to get work going. So there are these various dimensions of really enabling developers from across the world on GitHub.

Yeah, I would say issues are my favorite for that. I think issues are the most powerful, widest-reaching aspect of what GitHub does. But when it comes to meetups, are you looking forward to going back in person when it comes to the meetup scene?

Absolutely. I think I’m really very excited, because when a lot of these things come into play, events are one of the ways how we as GitHub help developers connect with each other and also learn from others, and also for us to meet the community and have a dialogue. So for a DevRel person like me, it’s one of the best experiences, wherein I can meet with and learn from developers, make real connections, even friends, with them as really people. So of course the current pandemic scenario across the world has made meeting people in person difficult, and I think that’s why we’re doing Breaking Changes as well, virtually, but I think that’s when the role of GitHub as a collaboration platform is becoming more important, because we’re meeting and interacting with others virtually. But what about you, Kin, are you also really looking forward to going back out there and meeting your peers and meeting other developers?

I’ll be honest, I’m a little nervous about it. I’ve been doing this for a decade, so I’m really good at the in-person, but I really have grown fond of these virtual engagements, and it being, you know, to make this happen we had to do some scheduling and work around each other’s schedules, and that works out nice. But with that said, I do miss the bonding, the strength-building of relationships that in-person. And I have a variety of virtual calls that I do with people who I’ve met in person, and they’re old friends, you know, they feel like they’re lifelong friends because I’ve seen them at so many meetups, I’ve seen them at so many conferences, I know I can count on them to show up for a talk. So I’m a little bit of both camps, I would say, I’m a little nervous, but Breaking Changes is very much about working through my Rolodex, talking to people, building relationships, and opening up doors with folks like you, with the intent to bring folks to Postman, Postman Galaxy, which is our flagship event, and really cultivate and find interesting people like you who are working on things and have those conversations, so that when we do the next event, whether it’s in person or virtual, we don’t know yet, I’m hoping it’ll be in person, that you can come and you and I can hang out together. So I know, like Postman Galaxy, GitHub has the Universe, so GitHub’s bigger obviously because you guys have the universe and we just have a galaxy, but can you talk to me about the role that GitHub Universe plays in what you do as a developer relations professional?

Right, so that’s a nice play of words, Universe and Galaxy. So Universe is one of our flagship events where many developers from across the world come together. Of course this is something that we used to do in person before COVID, but the last year has been virtual. So that’s how Universe has been, wherein it’s where we bring many developers from across the world together. And I know I touched upon this a little bit, but be it Universe or be it the meetups or be it all of the other events that we do, it’s one of the ways where GitHub helps developers connect with each other. Because I know many of the developers or speakers, or even just folks who are just participating or hanging around, attend these meetups or events or even Universe and then walk back with a whole lot of learnings, a whole lot of connection to the speakers or to their peers in discussion forums, or just hanging out by a booth or networking areas in in-person events, and really form that bonding and then go back. I myself also have walked away from events with such really nice takeaways, not just in terms of learning and content but also in terms of relations with a whole lot of people. So that’s one of the things that Universe does at a really large scale.

Yeah, and it’s nice to have that milestone every year where people come together, it can be something you look forward to, something you prepare for, something you’re thinking about and cultivating towards, so you have your best people there, your best talks, your things that really grab people’s attention, and people really look forward to coming and being part of that. So in this, I mean, Breaking Changes is about reaching outside the developer community and trying to reach other folks, and you and I have had this conversation today all without looking at any code or doing anything very technical, and you keep talking about how it’s about relationships and talking to people and helping people. This seems like what you do is way more about people than it is about just writing code or anything specifically technical. Is that true?

The way that I look at it is, technology and people kind of go hand in hand. So what we’re seeing increasingly is that the culture of a company or a team plays a huge role in the end product of a software. So culture and practices are what are driven by people. So in today’s world everyone has access to common developer tools and technologies, and even students can learn it, practice it, master it, and start applying it, but if you look more closely, some of the secret sauces behind great software products are the people behind it, because they are the ones who influence more about how the software gets developed, what it means to an end user, and ultimately impacts how it helps other people, and in our case, how it helps developers do a lot more with our products. So I think that’s where people become a lot more important, and that is one of my key things that I am passionate about as well.

Yeah, I mean, for me, I saw this early on, that I was a database administrator, very technically focused, and I saw what APIs did for breaking down the walls around our different groups and forcing us to interact with other human beings, which was a good thing, because we needed to do that, we were very closed up, and then I really got into evangelism and developer relations and storytelling around it because of that, and it’s what keeps me going. I wouldn’t keep doing it if it was just for the technology or writing code, I’m just not that passionate about code anymore, I’m more passionate about people and connecting with folks like yourself. So when it comes to, I’m always trying to pass the torch to other people, because developer relations is a real career, it’s a real job you can have now, and there’s different areas that you can go into, you can go more evangelism, more marketing, more developer experience and other areas that you mentioned. Where do you get your knowledge? Do you have books that you read, do you have sites? If I was just getting going in the space, one of our listeners, what do I do, how do I obtain the knowledge that you have now?

It’s a good point. I’m actually a very avid reader, Kin. Usually I might be around my bookshelf, but that’s not over here right now. I read books from a whole lot of genres, like biographies or business or technical or self-improvement, etc. And this really helps a lot, because, like you mentioned, when we are working with people, there are a whole lot of dimensions that come in, a whole lot of stories that come in, and ways that will help us do our work better. So for me, I’m reading a lot more about how to do better conversations or how to make better presentations, or learning a lot more on certain domain aspects. For example, things like reading more on open source. There’s a really nice book, one of my favorites, by Nadia Eghbal, which is called Working in Public, where there’s a really nice illustration of how did open source really evolve, what does it really mean, what is the role of people really when it comes to open source collaboration and open source projects, etc. So I tend to read a lot of books around various different topics and domains. So in fact that is one of the things that you would find me doing, if I’m not working I would probably be reading a book.

Yeah, that one book you mentioned, Working in Public, it really emphasized how much the maintainers behind most of the projects we know are like one or two really strong personalities, and you may not see that if you’re just focused on the code, it’s one person, and then the community itself contributing as well, that’s the secondary human aspect. So lots to learn there. So what do you want to be remembered for in doing all of this, what’s the mark that you want to make on the space?

I’m glad that you asked that. So I’ve been a really big follower of the late scientist, president of India, Dr. Kalam, that’s who you can see out over here in my photo over there. So he once said that, in a sheet of paper write down what it is that you want to be remembered for, and that will be the most important piece of paper in your entire life. That really struck a chord with me. And for me, in a really short way, that paper would read, or that sentence would read, is, to be remembered as a helpful human being and a technologist who helped impact millions of people through technology. So hopefully that’s something that I would like to be remembered as.

Yeah, I mean, if I could leave something with listeners here that are our business leadership folks who are making things happen within enterprise organizations, is people like you are super valuable, they should be carving out the space. I think a lot of organizations have trouble connecting the direct return on investment from hiring developer relations and carving out the space, and all I can say is, figure out a way to map it to your business, figure out a way to come up with the payroll you need to hire folks like you, because it matters. That type of enablement will impact your bottom line, will create new products and lines of services, and it will enable developers to be more successful, whether they’re internally within inner source, whether they’re externally within open source, or just even proprietary development you’re doing. So definitely carve out the space for folks to do what you’re doing and what you’re so passionate about. And a good example of that is organizations like GitHub and Postman itself.

Yes, yeah, I think GitHub is a model, I don’t think you’re a model, but I think what you’re doing at GitHub and the kind of, what I spoke about with GitHub, with Actions, it’s not just about the Actions itself, it’s about a community, the network effect of Actions, me being able to find other Actions, that’s the benefit of what you do. And I would say, back to your DevOps definition, that it’s culture, DevOps is not just a series of tools or changing access level between developers and operations, it’s changing culture, and it needs folks like you helping to not just change that culture but sustain it, grow it, evolve it, invest in it. So what you do matters at that level. So, absolutely. With that said, I think we’ve hit our time, we’re closing on an hour. Anything you want to leave for our audience and our guests before we close up?

Well, I would just say one thing probably, is that there’s a whole lot more that’s to be done. And like I mentioned as well, that developers really have the power and the tools and most of what they need available today to really go make that change for all of us as humans. And for a lot of the business leaders or the management, etc., I think it’s largely in the power of all of you as well to help all of the developers in your organization as well as the community to really get this whole thing to a really different level. So that’s like one thought I would leave with all of you, because of course there are things that would help your own organizations, that would help your developers, that would help your products, that would help your community, that would help your customers, etc., but overall, kind of encompassing, is this larger power that many of the developers and businesses have to take human progress itself to a whole new level when done rightly.

I think amen, I think that’s something that could be applied across many different industries. This isn’t just something for the tech sector, so whether you’re in healthcare, finance, wherever you’re at, I think that’s a good piece of advice. Well, thank you, I appreciate your time today, and I look forward to seeing you either at Galaxy and/or the Universe.

Yeah, GitHub Universe, and we’ll talk more. Thanks a lot, Kin, for having me out over here, and thanks to Postman. So it was a really nice conversation, we spoke about a whole lot of things, right from GitHub as a community to open source to inner source to DevOps to automation to communities. This is a really nice conversation, and I hope all of you listeners would have found this valuable as well. And this is just a start in terms of what can be done and what’s out over there. So once again, thanks a lot, Kin, and I hope to connect with you and all of the listeners and all of the folks out there really very soon. We’ll keep the conversation going.

Definitely. Thank you.