On this episode, Austin Schaefer, Jerel Miller, John Vajda of New Relic talk about the company’s decision to open source their docs, how they did it, and some of the interesting technical challenges they faced while doing so.
Should you find a burning need to share your thoughts or rants about the show, please spray them at email@example.com. While you’re going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you’d like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @ObservyMcObserv.
Docs Level 9000 – Open Sorcery with Gatsby with Austin Schaefer, Jerel Miller, John Vajda of New Relic
Jonan Scheffler: Hello and welcome back to Observy McObservface, proudly brought to you by New Relic's developer relations team, The Relicans. Observy is about observability in something a bit more than the traditional sense. It's often about technology and tools that we use to gain visibility into our systems. But it is also about people because, fundamentally, software is about people. You can think of Observy as something of an observability variety show where we will apply systems thinking and think critically about challenges across our entire industry. And we very much look forward to having you join us. You can find the show notes for this episode along with all of The Relicans podcasts on developer.newrelic.com/podcasts. We're so pleased to have you here this week. Enjoy the show.
I am joined today by several of my friends from New Relic, actually. I want to kick it off with Austin. Austin, why don't you go ahead and introduce yourself?
Austin: Hi. Nice to meet you. My name is Austin Schaefer, and I'm the manager of the tech docs team here at New Relic. And I'll go ahead and hand it off to Jerel.
Jerel: Thanks, Austin. I'm Jerel [Miller]. I am one of the engineers actually that have worked on the docs website. With that, I'll hand it over to John.
John: Thanks, Jerel. I'm John Vajda, the senior product manager of Developer Enablement in New Relic, and I'm really excited to be here, Jonan. Thanks for having us.
Jonan: You are very welcome. Thank you all for joining me. Again, in order, Austin is the manager, and Jerel is the engineer. And John is the other different kind of manager who does the product managing on a new project that New Relic has. Did I get that right?
Austin: Yeah, I think you nailed it.
Jonan: Yes. I'm basically a computer expert. So you three have all been working together on open-sourcing the New Relic docs, if I understand. And when we took this project on, first of all, I'm curious to know when we started and how long it took us to do this but especially what the motivations were to make that move.
John: Back in 2020, in around March, April, we actually open-sourced and released our open-source website, opensource.newrelic.com, on Gatsby, and that was the first site that we open-sourced. And then, we decided to then open source a developer website which is developer.newrelic.com, and that was also built on Gatsby. So we are teasing out the idea of open-source documentation and open source websites built on the Gatsby platform. Those two projects were very successful. And then the goal was to really showcase that platform and allow us to decide if putting the documentation site docs.newrelic.com onto Gatsby would actually work for us. And after those two successful projects, around August of 2020, we kicked off this project. So, it's been going on for a while. So we're really excited that we're at the finish line.
Jonan: This entire project, though, is a pandemic baby. [Laughter] There is no portion of this that has been completed outside of a pandemic, right?
John: That sounds about right if you put it that way, yeah.
Jonan: So we are experimenting with Gatsby. I want to hear about why we chose that in a moment but maybe Jerel can speak to Gatsby and why that was an ideal choice here. But then we started off with the open-source site. So we have opensource.newrelic.com came over to Gatsby, and then developer.newrelic.com came over to Gatsby. And now, finally, docs.newrelic.com has made the move. So the motivation for all of this was…? Blank.
Austin: I think, well, first, from New Relic's perspective, we're really moving to open source in general. We've open-sourced our instrumentation agents. We're open-sourcing more and more of our code. But then, more broadly, I think we're just seeing documentation become open source almost as a standard in the industry. You see it all the way from smaller companies like startups by default almost seemed to put their documentation into static sites and open-source it, but then you're really seeing the giants do it too, Adobe Microsoft, these mega-companies that operate documentation portals with thousands and tens of thousands of pages are also moving to open source. And then, back in September and October, we finally saw GitHub make that move as well. And so I think as more and more of the industry moves to open source, we're seeing users just expect by default that the content is going to be open source and that they'll be able to contribute to the content just like they would the code. We actually asked our users about that earlier last year around June, and around 40% of our users said that they contributed or PR’d to documentation sites besides for the project or company they work for. And 50% to 60% were interested in PRing our docs. And so I think this is really a broader industry move that we're part of.
Jonan: I would agree with you. I think that as a user of New Relic and of other products, I am often frustrated by documentation that becomes out of date. I think if we take a purely cynical view, this is an opportunity to get the internet at large at work on your documentation and helping to improve it. But I actually don't take that view very often around docs, especially. When I come to a site, and I see docs that need an upgrade, it's really a high barrier to entry for me to actually email someone. I've maybe done that two or three times in my whole career. Like, “Hey, this copy-paste line of code that you have in your docs actually doesn't work; it causes a segfault. So you should probably change that.” I'm much, much less likely to send an email to some customer success organization than I am to actually just make a PR myself and make the change. So I think it makes sense to do it that way.
Austin: Yeah, and I think it's a two-way street too. It's not just about getting contributions from the community. It's also giving people an opportunity to tell us, “Hey, this is wrong,” in a way that's really low-friction and that we can then respond to. We have that a little bit today where people can say, “This doc wasn't helpful, and here's why.” What we don't have is, “Well, tell us more. You said our Java docs aren't good. But can you tell us more about what specifically is not good?” I think having that conversation at GitHub is a much better user experience.
Jonan: Absolutely agree.
John: To add to that, the beautiful thing about open source is that it comes along with transparency and accountability. So by having something open, you're not only asking people to contribute. You made a great point: it's a lot easier to contribute especially if you're more technical and familiar with contributing PRs to GitHub. But there's accountability on our side and transparency with all that we're doing so that people can follow the documentation, the updates, and when they've been released and what's changed. So if anyone has any questions around the accuracy or the intent, it's right there in front of them. And that's what I love about open source documentation: it's just transparent and accountable on both sides.
Jonan: So, Jerel, maybe you could tell us why Gatsby was chosen as the solution here.
Jerel: Yeah, absolutely. We were actually pretty impressed with the ecosystem around it. So a lot of us had heard of Gatsby before this. We heard of static site generators, and it was built using React, which we're all familiar with. The New Relic platform is built on React, for example. And so that was something that drew our attention at first, but the more we looked into it -- you go to their plugin ecosystem, for example, there are hundreds of plugins that do all kinds of things. A lot of really core plugins that you use are part of Gatsby's core as well. And so we were just pretty impressed with all of the different things that you can do. Its data layer, for example, is in GraphQL, which, again, we're all familiar with, and we absolutely love GraphQL here at New Relic, and so we wanted to keep going with that. And then lastly, just playing around with it, we were pretty impressed by its speed. It obviously builds out an HTML page for you. So you get that nice snappiness of when you visit the page, you get a page right away. But on top of that, you still get that SPA-like experience navigating around pages. You don't see page refreshes, and it's what you expect with modern React apps these days. So yeah, we fell in love with it pretty quickly.
Jonan: So, in reference to this SPA acronym that you dropped without explaining, I'm calling you straight out for it.
Jonan: We're not talking so much about the cucumbers on the eyes kind of spa. We're talking about single-page applications.
So you mentioned GraphQL. We are big fans of GraphQL and of React because we, of course, use those in the platform itself. You can build Nerdlets and plugins and things on top of New Relic that uses this GraphQL React structure. But we also have a tool that I made my first change to the documentation of New Relic. When I joined New Relic, I was reading through the docs, and I did actually email someone in this case or submit a request for a change because I saw somewhere that you had written GraphyQL instead of GraphQL. So, of course, that was a typo, and I submitted a request to fix it, but it turns out that was not a typo. Tell me about Graphy.
Jerel: Yeah. So GraphyQL, I think it's pronounced graphical, I don't know. That's at least how I pronounce it. So it's the tool of choice right now for exploring GraphQL schemas. So GraphQL being a statically typed query language for your server, you want to know what data is available and what the fields what type they are so that you know how to query that. So Graphical, GraphyQL, I don't know, pick your favorite way to say it. Maybe somebody out there knows exactly what the pronunciation is. But GraphyQL gives you a great window into what's available. So you can take a look at oh, here's the data I can query. I can go get my accounts or my username, whatever the case may be, and there are all kinds of use of it for GraphQL, so yeah, really useful tool. You'll see it used in almost everything that offers a GraphQL schema. There's generally a GraphyQL instance that you can go browse to understand more of what's available to you.
Jonan: Graphical makes a lot more sense as a pronunciation than GraphyQL. I think that's probably the correct way to go, with the possible exception of jraphical I think. As with JIF and GIF, I think this might also be jraphical. We should ask the person who invented it.
Jonan: So we have this way that you can explore the data and figure out what components you can include using GraphQL and React. And when I go to actually make an edit to this documentation, I come to the docs page, this statically generated site using Gatsby and all of these other technologies. And the end result for me as a user is now I see an edit button in the corner.
Jerel: That's correct. So using GraphQL, for example, we're able to tell what page you're on. And so that edit button really allows you the ability to say, okay, we know what page you're looking at because we know the HTML page that has been built. We have a link to it in GitHub where you can go view it and make changes to it if you want to. So yeah, we'll link up that edit button to a link in Github where we can show you the source code for that page and allow you to make edits if need be.
Austin: And the other thing I'd add to that is we also have this create an issue flow. So it’s an even lower friction way for someone to tell us, “Something is wrong here, and this could be better.” Someone could just file a GitHub issue directly from there. And we'll again pull in that context of what page you were on and what browser you're looking at. And what we've seen talking to users is there's a lot of interest in editing. And then perhaps this isn't surprising; the interest in filing issues is even higher. People really like the idea of being able to file issues in public as a really low-friction way to give us feedback.
John: And I wanted to build on that both what Jerel and Austin said is that the cool thing is that this is all on GitHub. So when you create an issue, it goes right into our project. And this is the project where our team looks every day to see what we should work on next. In the case that you referred to earlier, Jonan, when you had to email someone from a customer success team and that usually goes through a support workflow, and it can take a while to get to the product team or the team that actually is going to maintain those docs. So we've removed that barrier of communication interaction so that customers of New Relic can either edit the page if they want to make the change themselves or just report the problem like Austin mentioned. So that’s what's so cool about the connection in the GitHub.
The other thing is to go back to Gatsby real quick; we’re going to probably talk about Gatsby throughout this conversation. The other thing about Gatsby that was so cool is that there are a lot of static site generators out there. There are other flavors of it like Hugo or Jekyll, but Gatsby was really appealing because they're a fully funded company. They've taken 46.8 million, and I just checked that on Crunchbase, so that should be a valid number. So they have money behind them as a company, and they also have a team of people that we've already interacted with. On the engineering side, it's open-source; Gatsby is open source. But it's a fully-fledged funded company behind it that supports that infrastructure and technology.
Jonan: So the point being there that we don't have to worry about Gatsby going away; we just have to worry about their exit strategy and whether or not they are charging by the bit.
Austin: Yeah, I'll tag onto that to say I have a personal blog on D&D that hasn't been updated in five years, and the main reason is I built it on Octopress, which became abandonware about two years after I started working on it. So that’s definitely a risk with this kind of thing is just seeing the maintainers move on.
Jonan: Yeah. Well, and I think that in that vein, the open-source movement generally is I think from an enterprise perspective often impacted by this perception that open source can't be trusted to always be there like a company's product would be that if you choose a vendor, you decide to stick with them. But I will also point out that those same problems are suffered across the board. There are many vendors in all of the spaces where we operate observability alone that come and go or fall into and out of fashion. So there is always a risk there, but I think that for all of those reasons, Gatsby makes a lot of sense. It's also very common stack of technology these days. So it should be something that most people can work with. But if I go to edit the docs, I don't actually need to do that much with React or GraphQL. I don't need to know those things to actually make changes to our documentation today, right?
Austin: Yeah. And you actually don't even need to pull down the site locally. That's always an option, you know; people can pull down the site and build it locally and really see their changes. But what we're expecting for a lot of simple changes is GitHub has a pretty sweet in-browser editing experience now where you open the page, and then it just creates a branch for you right there. And you don't have to really worry about what's going on behind the scenes at all. And we're expecting that for a lot of those smaller contributions, people will just be able to do the whole thing in a couple of minutes and not have to worry at all about what technology we're using under the hood.
Jerel: I'll add to that as well. We're working with tech called MDX, which stands for JSX in Markdown, I believe, or Markdown in JSX, one of the two. But what's really neat about it is you get the terseness of Markdown, which is really a great writing format, especially for documentation where you have a lot of things like paragraphs and titles and things. But on top of that, we're able to layer in actual React components to that document, so we can provide rich experiences. So, for example, our doc site has a collapse component where you can hide and show information similar to Accordion but slightly different. And so we can provide really rich experiences within our docs themselves using React components but still provide the terseness of Markdown as well.
Jonan: Yeah. I understand this MDX thing is the hotness now; everyone's very excited about this. But it's not something that I can use in place of Markdown in all places. If I make my README and MDX on GitHub, it's not going to just render correctly. That's not where MDX is as a technology now. It does require that it is part of a React site.
Jerel: That is correct. Yeah, it does require a runtime in order to convert that. JSX is something that may turn into HTML in the long run. General Markdown needs some tooling around it in order to be able to layer in those JSX components because they are not just regular HTML. READMEs and things, general Markdown does allow you an escape hatch to regular HTML in this case, MDX not so much. You definitely need some tooling around it.
Jonan: Interesting. So we have our stack, and we have why we have chosen it. But the question, I guess for me, is from a shareholder's perspective, why did they care? Why would I if I'm sitting on Wall Street care that a company had opened sourced their docs? I as an individual developer, I'm obviously on board with the dream in open source. I think most devs today are. They understand the value intuitively of something like this. But I think that occasionally, it's possible for someone who analyzes companies and tries to predict their success to look at a move like New Relic has made where we've open-sourced all of the things across the board, including our agents, which represents hundreds of millions of dollars in R&D investment over the years and from a perspective of someone who really doesn't understand open source, that looks like we're just giving away the house. But maybe one of you could speak to why that's not the case.
John: So Jerel and I really think what it comes down to is if you're looking at New Relic from an external investment perspective or Wall Street like you said, we want to appeal to developers of all kinds across all different industries. And developers inherently love open source technologies, and we've all used them throughout our careers to build amazing and cool things. So by doing things in open and being transparent, I think it just appeals to developers who look at our product suite and say, “Hey, New Relic solves this problem for me with observability, but it also is open source, and a lot of the stuff they're doing is transparent.” And I think it adds a lot of value and credence to what we're doing. And it just helps, I think, be more appealing to a developer who's looking to solve a really critical problem. I think it's like icing on the cake so to speak, to have things in the open and just be transparent with the code.
Austin: Yeah, I love that, John. And just build on it, the other two things I would add is it's I think there's both a perception or a participation thing that John is speaking to. And then I think there's also just a real direct user value of things like this dock is wrong, and I'm having a bad experience, and I'm going to file an issue, and hopefully, within a day or two, somebody is going to get back to me and help solve my issue and make the content better. I've had that experience with other companies where I'm using their docs, and I PR’d it. It's actually not a company, but I did it with the Magic: The Gathering site called Cube Cobra a while back. I was reading their docs, and I was like, this is just straight wrong. And I PR’d it, and they merged it a day later, and I felt really good about the tool. I felt like, oh, this is a site I already cared about, but now I know the people who maintain it are actually there for me, and they want to make it better, and they care about my feedback. So in terms of a shareholder perspective, having users have an experience like that where they see that somebody really cares and they're here to make their life better, I think, is great.
And then the other thing that Jerel might be able to speak to more is I think we're also just doing this because we're getting a really great stack. We’re able to do things on this new Gatsby-based architecture that we just couldn't do before, things like services where we're exposing the content from the site in GraphQL and using it in the UI and using it in other places. And so the open sourcing is part of it, but there's also a deeper technical change that we're also really excited about where the open sourcing is really incidental to that.
Jerel: I'm personally really excited to show this off. We have definitely lots of different challenges within the doc site that we had to take into account, for example, what we call auto-generated index pages, which basically mean you can remove part of a URL. There’s not already an authored page; we'll generate one for you and show what’s in there. We can automate all of that process. So from a contributor standpoint, all you have to do is author a doc, and then we'll do the rest for you behind the scenes. But by keeping this in open source, it also helps us teach other developers, and also those developers that are really interested or know a lot about Gatsby can come in and say, “Hey, by the way, I have this suggestion. I can see that you're doing X and Y here. Maybe this can be a little bit faster, and maybe your builds will speed up if you do Z in this spot.” And so I think there's a lot of opportunity for that as well, not only just the content itself, but we have a lot of stuff in there that I think we can offer to the broader Gatsby development community. And also, we're still learning what to do with the Gatsby site. We'd love to get suggestions as well from a technical development standpoint on things that we could do better ourselves. So I think the potential there is pretty exciting.
Austin: Yeah, and I think we're already seeing that, right Jerel? We're already talking to Gatsby, and they're seeing, for example, on localization, we localize our docs into Japanese. We’re really having to explore the limits, I guess not limits, but new frontiers in terms of how those workflows work and how much automation we can get in there. And we've had great conversations with the Gatsby folks about that. And so I think we're already starting to see that we're benefiting from the open-source technology. In turn, we're giving back, and then, in turn, that'll make our site even better in the future as some of those things get upstreamed.
John: Yeah, and just to add to that about Gatsby's interest in what we're doing, our site happens to be one of the larger projects running on Gatsby, and they've been really interested in looking at our builds, looking at our open source code and on their side they’re benchmarking, so they can optimize their build process and caching. We hit some build and some caching limitations with what we were doing, and they were really helpful in working through that with us and saw a lot of value in what we were doing. And also the fact that it was all open and available, they could go fork the repo and start playing around with it, which is really cool. So that's really where open source is awesome and why I think developers love it.
There's also this inherent connection and feeling that someone's on the other side. So if you've worked at any open source project or you've ever engaged with someone through an open-source repository, you just know someone's out there willing to help you or just respond to a comment or people that might not be even working on that project also share in your pain with the issue. They'll thumb it up; they’ll like it, they'll drop in comments of how you can work around things. So I just think it really appeals to developers because we're all in this together, I guess, would be the kind of open-source mantra, and that's one of the main reasons why I think it's awesome that New Relic went down this path with so much of our technology.
Jonan: So we have a couple of pieces that I want to unpack here and call out; one is that open sourcing your stacks, open-sourcing something like a doc site preserves momentum for the project to some degree because everyone is able to jump in and continue contributing. It no longer becomes the obligation of however many people you employ explicitly to edit and create documentation to move a project forward; they get some help from the community. But beyond that preservation of momentum, you have this really important piece which I think when people think about open source, they think about individual developer comes along and finds a typo in the code, and then they change the thing, or I find a typo in the doc somewhere and then I can fix it. But from a company's perspective, being able to partner with organizations like Gatsby and collaborate across projects, it's, of course, invaluable to have your code out there and shared. You don't need to coordinate with people to get access to things and have meetings, blergh, in-person where you talk to each other. You can just go in and make the changes. They can run their benchmark suite against our version of Gatsby, and we can all grow the project together. I think when I worked here at New Relic on the Ruby agent team, that was a really frustrating part of the whole process of debugging someone's issue because you're trying to instrument inside of someone's application, and if you don't have access to the code, it becomes a much more difficult process, that black box disappears in a world with open source.
Jonan: So we talked a little bit earlier about Gatsby being a choice of project because we didn't think it was going to become abandonware. But I think that a lot of people felt that way around a lot of things like Angular. I know that there were meetings back in the day to decide which front-end framework we should use. We were looking at Angular. And what else was in there? Ember was on the list and one other at the time. I can't remember what it was, but that one is long gone. And I know that we initially chose Angular, and very shortly thereafter, Google decided that Angular 2.0 was a thing. They initially started Angular as a toolbox. This is a toolbox; this is not a framework. So we're not going to tell you how to do things. We're not going to have these opinions about it. We're just going to provide the tools, and you can go on building it. And then they released Angular 2.0, and they said, “Never mind, it's a framework. We're throwing away all of the things. So what in our case prevents that from happening? Does this represent any kind of risk to us going forward? If Gatsby disappears, if it vaporizes in two years, how are we going to be able to transition to a new platform? And why would you expect that would go better than if we'd chosen another technology?
Jerel: I'll talk just a little bit about that. One thing that I think is interesting is Angular didn't necessarily go away but what they did is they did an entire architectural shift. And so when you're talking about the cost to migrate from Angular 1.0 to Angular 2.0, it's a very high barrier to do because you're essentially asking all companies that had worked with Angular 1.0 to essentially throw away everything they knew and everything that they've built so far and actually adopt this entirely new stack and way of thinking. And so we're hedging our bets obviously that Gatsby is not going to do the same. There are no guarantees; they’re in control of that destiny. But being that it's open-source and that they've got a lot of developer community around that, we can only hope that a lot of different places have learned from that Angular 1.0 Angular 2.0 type debacle and won't do the same. I know they've got Gatsby conf coming up tomorrow. They're going to announce a bunch of new, really exciting things. We don't know what those are yet, but we only hope that moving forward that they give us paths to migrate to their new greatest and latest versions of things.
Jonan: It is, actually. I think Gatsby is leading. I think the transition to statically generated sites has been really rapid over the last couple of years. I'm seeing a little bit of snapback right now. I'm not sure if the future of the web is entirely static generated. I'm not sure that I buy that case, but I do think that for use cases like this, it makes a lot of sense. And I think in choosing a technology like Gatsby, you also have to realize that you're selecting a set of component technologies and whether or not Gatsby lives on as a project, which I certainly hope it does; the technologies underlying Gatsby will still be there. We talked about MDX and JSX, and React. Those are not things that are going away. GraphQL is still going to be here even if Gatsby closes their doors. So the possibility certainly exists that another framework comes along that is Gatsby API compliant, and you could just use it out of the box with our existing documentation flow. So I think from that perspective, it maybe is less of a risk than one might imagine specifically for this case and all the technologies that roll up into Gatsby.
Jerel: Yeah, that's a really good call-out. Gatsby is more or less a glue between several technologies. Webpack as well is being used under the hood to compile everything and, as you said, React to actually author some of these pages. We chose MDX. It doesn't mean we're limited to MDX. We could just as well choose tomorrow to author these in just regular React components for everything. And so, being that there's heavy investment in those other tools, Facebook overseeing React, we know React is not going away anytime soon. It's built on top of a lot of really popular tools, as you mentioned, that really helps us out as well.
Jonan: So if people want to come along and check out this project, I wonder if you have a URL to suggest for them.
Austin: docs.newrelic.com. And then, if you want to see the repo, just click on the big old edit or create an issue button.
Jonan: docs.newrelic.com, which we have mentioned before but went live officially today. As we are recording this, we have just launched this new version.
Jerel: Yes, we have.
Jonan: Awesome. We are just about out of time, but I wonder if you might share a bit of advice for our listeners. I think that it's become something of a tradition on this show to give advice to people who are just entering the industry as we close out the shows. And you all have had long and interesting careers that have led you to this point where you find yourself here at New Relic. So maybe if I can get each of you, in turn, to take a moment and share a bit of advice for your younger self when you were just getting started, what do you wish you would've known?
Austin: I would say as someone who's been in the tech docs field for a while, I would say just get involved in open source. And that might sound really obvious after this chat, but one of the things that's so great about this movement to open-source is you can get in and contribute to content for really big projects. It could be something that's just a passion, like I mentioned this Magic: The Gathering site earlier, or it could be some of the largest companies and websites in the world. You could go contribute to Microsoft's docs right now. You go look at GitHub’s repo and go find issues which in terms of building your portfolio, building your experience as a writer, getting your name out there I think that's an amazing opportunity that honestly just didn't exist when I was becoming a tech writer just a few years ago. So I'd really encourage anyone who's aspiring to get into software to pursue that.
Jerel: And I'll build on top of that too. I remember early in my career, I've used a lot of open-source tools in my career up to this point, and contributing to open source seems a little bit scary and daunting. You're essentially asking people to change code in a space that you've maybe never interacted with the people behind it. And so it took me a long time to really realize open source is not as scary as it seems. Now that I'm sitting on the other side of it as an open-source maintainer of these websites like really making sure that the maintainers create a great community as well as a great experience for those that are looking to contribute, maybe for the first time.
We've actually had some great feedback so far on some of the contributions we've gotten from others out in the community that said, “Hey, this is my first contribution to open source. Thanks for making this a great opportunity.” So I think there's a lot we can do to make sure that others have great experiences. But then also, I want to reiterate it's not as scary as it sounds or seems and just play around with things. I think being curious and saying, “Hey, I've got an idea for this thing.” From what I've seen, a lot of the developer community out there is really great to work with. So go for it. If the worst comes to worst, if something doesn't get merged, that's okay. It’s not the end of the world, but keep working on it. And there are a lot of people looking for contributions out there, including us.
John: Those are great points and tips. And one thing I'd add to that is if you're getting into technology if you're on the fringe of it, if you want to get into tech and look at management roles, product managers are a great example of people that work in technology that don't necessarily come from engineering backgrounds all the time, but sometimes they do. It just depends on the type of company or the type of product. But I personally wasn't an engineer by trade, but over time, I just worked on code, and I got into code. And I highly suggest to anyone who wants to get into technology and let's say you haven't taken engineering or have an engineering degree or done a lot of engineering courses, just work with code, get into it. And one of the best ways to do that is to work in open source projects and help contribute. Some of the people that work in open source are just some of the most awesome, friendly, helpful developers and engineers you'd ever come across. It just comes with the territory of working in the open. So if you're wanting to learn and ramp up, contribute to our projects, contribute to any open source project that you're passionate about, and you might find that you'll get a ton of great feedback and help and experience just by doing that. And it's a resume builder because you have your GitHub profile or GitLab if you go that way. But you can build up your GitHub profile with your contributions. And it's really appealing for companies to see people that are working at open source because it's a good trace record for their contributions and what they've done and the code they've written.
Jonan: Get all those green boxes, but don't actually; instead, maintain a nice work-life balance, and you'll be much happier over your entire career. Don't spend your days chasing green boxes is my advice for you just starting out. But absolutely getting involved in open source is a really valuable way to start to understand the software ecosystem and to put yourself out there and build up a bit of a resume in public. I actually desperately need to redo my personal site. I've done it once in the 12 years-ish that I've been in tech, and it's well out of date at this point. And I thought briefly for a moment of just including a let me Google that for you link as my resume, so you click on it, and it just Googles me. [Chuckles] Because working in developer relations, I have the advantage there that most of my work ends up being out there in public.
So this is a really exciting project. I am excited not just to have our documentation level up but for New Relic generally. I think too few companies today make the investment in open source in the way that I'm seeing us do it, and I'm actually really proud to be a part of that. I think that there are a lot of consumers of open source. There are a lot of people, it's been in the news lately, with all kinds of licensing issues where a company swipes an open-source project and keeps it internal to their company and makes all sorts of changes and improvements on it that they go on to sell and generate revenue with and never contribute anything back upstream. So as you mentioned with the translation changes and helping Gatsby level up their build and their caching because of the size and scope of our particular use of their platform, I see already not just in the case of the doc site, but across the company how we are pushing the rest of open source forward, how we're paying it forward and giving back to the community that we are so fortunate to be a part of. This project is another big step on that road, and I'm so pleased that you all could join me and talk about it and thank you for all of the hard work on it. I'm excited to see where it goes.
Jerel: I'm super pumped to get this in the hands of our customers for sure. Thanks for having us on today. Really appreciate it.
Austin: Absolutely. Thanks for having us on. And if you're listening to this, please go check it out and give us your feedback.
Jonan: Always a pleasure. Thank you all. I hope you have a wonderful day. Take care.
Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. Right now, we're running a hackathon in partnership with dev.to called Hack the Planet, where we're giving away $20,000 in cash prizes along with many other fabulous gifts simply for participating. You'll also find news there shortly of FutureStack, our upcoming conference here at New Relic. We would love to have you join us. We'll see you next week. Take care.