Skip to main content
Gun.io Home

Keeping The Open Source Community First Priority with Jason Lengstorf of Gatsby

Jason Lengstorf runs developer relations at Gatsby, a free and open source framework based on React that helps developers build blazing fast websites and apps. 

By addressing the problem of app launch from the perspective of progressive disclosure of complexity, Gatsby’s entire ethos is designed around shipping fast React components generated from and requiring the lowest possible config overhead – in other words, dig deep into the config if you like, but only if and when you want to. 

Jason and I talk about keeping the open source community first and foremost in their mission, and the critical seat that’s being filled by the dev rel community as the role and monetization of open source software heats up.


David Ledgerwood
David Ledgerwood
· 25 min

Transcript

Ledge: Jason, good to have you on. It’s really cool to have you.

Jason: Thanks for inviting me. It’s great to be here.

Ledge: Can you give a two- to three-minute background story of yourself and your work so the audience can get to know you?

Jason: Sure. I’ve got into tech in a pretty unconventional way. I don’t have a college background; I didn’t get a degree. Instead, I dropped out of college and tried to be a rock star. I was in a pretty terrible band and we spent a couple of years living in a van and touring around. And during that time, because we weren’t good, we didn’t make any money.

That meant that somebody had to design and the websites and all that stuff. So I just kind of took over that duty. I was kind of our de facto booking agent, designer, web developer, and all the things that we couldn’t afford for somebody to do.

At the end of that two years, I probably rebuilt that website ten or fifteen times, and I enjoyed doing it. I was always like, “Oh, what if I tried this?”

I started out by building this horrible sliced-up table, no CSS website. I had a bunch of IFrames and then I was like, “I want to be able to play music.” So I dug into Flash and learned ActionScript so that I could embed a music player on the side.

I just kept going deeper and deeper in the stack. I learned PHP in my SQL so that I could give the band a dumb admin interface so they could post tour updates. And it just kept kind of rolling that way.

Through my experience, I started realizing more and more that I was very bad at music and pretty good at tech. And so, when the band broke up, I decided to go full time into web development.

I was a moonlighter for a while. I was working at Kinko’s or something and doing freelance jobs on the side. I, finally, got my break to go full time. I ran a freelance collective-type agency for about ten to twelve years.

I couldn’t handle the admin overhead like it was killing me so I, eventually, sold the agency and did some contract work. I worked at IBM for a little bit and, ultimately, ended up at Gatsby where I am now.

Ledge: Off-mike, we were talking about the plight of the freelancer, that more and more of your success gets consumed by the admin overhead and the business development and all that stuff. It’s good for us to hear those stories because that’s the value that we provide.

Jason: The admin overhead, being a freelancer, kind of made me fall out of love with technology. I had a pretty bad bout of burnout. I was working so hard that, at one point, my beard started falling out in patches. It was pretty rough and I was thinking, okay, maybe I should just quit and get a job at a bar and have a job that when I’m done, I go home.

I took a little bit of time off and readjusted things. I started focusing on “What did I like and not like about tech?” and trying to make sure that my life lined up more with things that I did like.

And my beard grew back. I’m definitely healthier now than I was then.

Ledge: He does have a beard.

Jason: Since making that switch and getting that admin overhead off of my shoulders and that need to be constantly on like that client management burden, it’s made my life a lot easier.

Ledge: You’re right. It sounds like you found your “home” for the time being at Gatsby. You’re doing some awesome stuff. I know the audience will care about all the things that that toolset framework ─ I don’t know what you call it ─ can do and the advances that you all have made.

Jason: We’re super excited about what’s happening at Gatsby right now. We have just seen such an incredible interest from the community. We’ve got support that I can’t believe and it makes my job really easy.

I call myself a “human duct tape” at Gatsby but I’m mostly filling the role of the head of developer relations which means that my job is the easiest job in the world ─ that is, go on Twitter and retweet all the nice things people say about us.

The thing that people talk about a lot is JavaScript fatigue, and there are so many frameworks and tools. Just to build a site, you have to set up Webpack and Babel and ESLint and get everything running with the build process. And you can spend a day just getting to the point where you can get a “Hello World” up on screen.

And so, with Gatsby, we wanted to build the best possible developer experience. And the way that we did that is we just kind of abstracted that complexity away in such a way that you can still get at it. If you want to get into your Gatsby site and mess with your Webpack, cool, do it. Do your thing. You’ve got full control.

But by default, we’re going to do everything for you. So when you get a new Gatsby site, in about 15 seconds, you can go from “gatsby new my site” to something up in the browser with the “hello world” so you can actually start writing some code.

In addition to that developer experience, we want to focus on the user experience. The sites that Gatsby builds are made completely of static assets but once they get to the browser, they rehydrate into React apps which means that they’re extremely performant. We’re doing a ton of performance tuning under the hood, all the code splitting, and we follow the purple pattern, if you’ve ever heard of that, that kind of makes it HCTV 2 compatible.

That means that the average Gatsby site is loading in one to three seconds ─ incredibly fast.

And we started to see companies like Nike. Harry’s razors has a women’s line called “Flamingo” so shopflamingo.com got moved over; and we’ve talked to them about the “why.”

“Why did you go to Gatsby? There are a lot of frameworks out there that are pretty good.”

And what they keep coming back to is “We are able to build better things faster.” Their dev velocity went up. They are able to get more work done in a shorter period of time which means that their turnaround goes down which means they can beat other people’s bids because they’re able to charge less; and because they’re spending half the time, their margins go up but their time to delivery goes down which means their overall price goes down.

So it’s like everybody wins by using it. Agencies, especially, have really been really excited about that.

Ledge: Right. It makes you think ─ there’s a proliferation movement now. Low-code, no-code tools from agencies and people like that. And, obviously, you give up a lot of control. Everybody says, “You can use my tool to build everything in the browser.”

But there’s still a spot for developers that is necessary and more control. Where do you see yourself in that conversation?

I can appreciate that someone would want to abstract their dev from their design.

Jason: There’s term that I love which is “progressive disclosure of complexity.” And so, the general idea is that we want to start with zero requirements. In theory, you should be able to start a Gatsby site with nothing but a folder full of markdown files. And that’s possible now behind an experimental.

And what we’re working toward is making that kind of the default experience. You say, “I want to blog.” You have a blog folder. You drop markdown files in it and that goes up on the Internet. That’s your blog.

But as you find yourself needing more things, you want to customize something, you can progressively dig deeper into the stack. So maybe you want to override the header component and change that up. Well, cool! You can just override that. You don’t have to get into the data layer or the configuration or anything beyond that.

But as you go deeper and deeper and deeper, you can ultimately get to the point where you’re messing with the data layer; you’re combining different types of data; you are getting underneath that and playing with the Babel config so that you can use TypeScript or Reason or whatever it is you want to do.

And you can go even further than that, if you want, and start actually playing with Webpack and change up everything.

We kind of look at it as you having all the control you need. You’re not giving up control to get that low-config environment. You’re just only dealing with the complexity that’s necessary to deal with to solve the current problem instead of opting into ─

One of the problems you see with something like Create React App is that one of their known limitations is that they start you with something that’s great until you get off the happy path. And as soon as you get off the happy path, you have to eject which means now you’re responsible for the whole stack. So you go from this zero config to one hundred percent config.

And our goal is to make that more progressive. You can go from zero to ten percent config to maybe sixty percent config and, ultimately, all the way to a hundred percent if you want. But we hope that enough defaults that you never see the need to go there. That’s really our hope.

Ledge: It’s a broad vision. You’re well on the way there. I think this is the kind of thing that everybody hopes for. I would think of it as managed abstraction. It isn’t such a beat down and it’s the same kind of conversations that we’re having with the folks who are thinking about the orchestration or choreography of DevOps.

You have a million things that play together and some of that we should be able to go “I just want it because it’s the default configuration.”

So you, guys, are like client and the server side which is pretty interesting there.

Performance, speed to launch, ability to launch code more quickly ─ obviously, those are key hallmarks of dev team performance.

What’s changed along the path for you all?

You set out with a broad vision. Sometimes, there are speed bumps and failures, learning opportunities, if you will. I think those are the things that we try not to revision its history out of the way.

Jason: We’re a very small company. Gatsby only had funding for about a year. Prior to that, it was a completely community-driven project almost exclusively led by Kyle Matthews, the CEO. He was working with a team of volunteers, and that was great. And the reason that we are where we are is that the community was incredible before we got funding.

Now that we have funding, we’re trying to figure out “How do we do something that follows the spirit of the community that we have and doesn’t cause that problem that you see with a lot of companies where they’ve got this excellent free offering, and then they come under pressure to make money and they hobble their community?” They do something that kind of breaks things down.

And so, early on, we were like, “What are we going to do to make sure that doesn’t happen?”

We’ve been trying really hard to double down on ways to make sure that the community is at the forefront of Gatsby. One of the ways that we do that, for example, is we’ve got the swag store and anybody who commits a PR to Gatsby ─ as soon as it gets merged ─ you’re going to get a message from our friendly robot that says, “Thank you so much. We’re going to invite you to be a maintainer on the org and we’re going to give you a coupon code to claim an item from the swag store.”

People who contribute more items get a second coupon code. It’s like five contributions that you get. We’ve got all sorts of stuff. We’ve got custom mugs; we’ve got custom pajama pants which I think was probably the most important thing I’ve ever created in my career. We call them “freelance pants.”

It’s trying to make sure that when people get involved in Gatsby, it’s the most welcoming place they can go. We try to be extremely open to beginners and first-time contributors. If you’re looking to get started in open source, we want to be the best place on the Internet to get started in open source.

And we see that as being the way that we grow this community. The goal isn’t to build the largest customer base. It’s to build the largest community.

Along the way, we’ve made a couple of mistakes where we accidentally alienated an older contributor or we super overwhelmed the PRs and ignored people who were trying to contribute; and we had to go back and try to do damage control; but we’ve damaged that trust and lost those people.

So a lot of what we’re doing now is trying to control that. How do we make sure that we are giving the community the attention it deserves, making sure that people feel taken care of and heard and listened to and we’re not raining down executive orders from on high, from the Gatsby corporate team or whatever?

The open source project is open source and will always be open source. We’re not going to stick any kind of paid stuff into it. We’re not going to pull chunks out of Gatsby open source and try to monetize them. We’re building a platform around the open source project, and that’s what will monetize the stuff that can happen without infrastructure.

So we’re just basically going to charge you for managing infrastructure and not necessarily for using Gatsby tool.

Ledge: I think that’s exactly right. It’s a very important time in open source. There are a lot of important debates around the licensing and the comments and all the stuff that is going through and leading the charge or maybe kind of off the road.

And I think maybe people don’t really know yet what’s the path because you can certainly appreciate the mandate of “Hey, we’re a company. We need to make some money. We’re not going to walk around with placards on our backs selling advertising or whatever it is.”

You need some kind of real revenue model and, yet, honoring the idea of open source came from the community. And that’s so important.

One thing that strikes me as progressive is ─ you described is as “We’re a small company” and yet, you’re the developer advocate.

I talk to developer advocates from Microsoft and Google and it’s like, of course, they have budget for that. So it does speak to investment and community that “Hey, that’s kind of cool.” For a small company, it does speak to the culture.

It’s not all that common to have sort of the advocate role ─

Jason: It seems like it’s becoming more common. A lot of the companies that we’re coming up with have invested in this kind of community outreach. And we’re not unique in recognizing that the community is super important. I think we’re maybe unique in having the ability to double down on it the way that we have.

But I’m very happy to be able to say that I think we’re in a minority of companies but we’re definitely not unique.

Ledge: And maybe it’s to say. It’s establishing how important that is. And it’s somewhere in what traditionally in a textbook in business school you might have said is a “marketing function” because it’s just so critically important to get our voice out there in an authentic way and take care of the customer and fight for the users.

What’s that like? Maybe some of our listeners are in a position where they’re considering doing such a thing for their own companies. What’s the feedback path like?

You’re out there speaking and writing and retweeting with your feet up. And you must get personally a ton of feedback and input and you have to process that in a way that’s useful to the organization.

What does that knowledge management framework, if you will, look like?

Jason: We’re fortunate to be small in that I can just grab the people that the feedback is relevant to and kind of do a debrief now.

As we scale, I think we’re going to have to find ways to get more of a process involved. But one of the things that I think is really interesting is you said that companies have traditionally looked at something like developer relations as a marketing function. And there were some kind of hubbub on Twitter not too long ago about the function of DevRel and just kind of the general “Is DevRel a good thing or is it just somebody who doesn’t know how to code trying to tell you to use their platform?”

I hope I’m not rekindling this argument but I feel like one of the things that has really been beneficial with all the developer relations people I know who are doing an excellent job is that they’re imbedded with their product. They use the product all the time. They’re building with their product. They can empathize directly with the people they’re talking to.

So, usually, when somebody comes to me with feedback about Gatsby, I’m in a position where I can try to solve their problem. If they’re like, “Oh, I got stuck when I did this thing,” I can, most of the time, kind of handle that Level 1 support on my own. I’ll just say, “I think that’s this bug. I ran into that before. Here you go.”

And I think what’s really important in developer relations is to make sure that it’s a product that you’re excited enough about and that you are willing to use it all the time.

Because if you don’t, you end up with this kind of gap. There’s tech that you’re excited about and tech that you have to talk about; and it’s very difficult to be engaging and to really support people if you can’t say that the tech you’re using is exciting to you.

That’s definitely a luxury. There are going to be things like if you get hired to run something that sets up once for an enterprise company and just kind of runs in the background forever, I don’t know how you could use that everyday. I don’t know what that looks like.

But I do think that, in most cases, people have passions. They really care about infrastructure. They really care about efficiency or decreasing the error rate or something like that. So whatever your thing is that you’re really into as a developer, find a company that’s aligned with that passion.

Before I came to Gatsby, I was at IBM kind of working in a frontend architect role. The thing that I kept doing was finding things that bothered me about our developer experience which I saw as inefficiencies in the dev process and building small tools to correct those inefficiencies.

And Gatsby as a service is finding and correcting developer workflow inefficiencies and performance inefficiencies.

For me, that’s right after my own heart. All the things that I was doing, anyways, got bundled up into an open source framework and they just happened to be hiring for somebody to talk about it all the time.

And I was like, okay, that’s the job I need because that’s what I do, anyways.

Ledge: If anybody looks at your writing and work and thinking, you spend a lot of time on that soft reflection and just “What actually do I care about in my craft?”

I think it’s the kind of thing where you attract maybe the type of situation that is meant for you when you start to actually pay attention to it. So there is this sort of self-driven destiny out of that kind of thinking. It’s like “I’m passionate about this tiny little niche of stuff.”

And it can be terrifying if you’re not prepared to get out there and seek that stuff.

People say, “Well, you can’t always work in your passion. There’s only one museum curator role for every two hundred art majors.”

But I do think that there are opportunities in our craft, in engineering, and around the edges and so many ecosystems ─ if you can tap into that one area that you’re good at.

Jason: I’m about to get really philosophical so feel free to push me back here. You said that not everyone can follow their passion and I both love and hate that phrase because I don’t think that if you ever ask me what I’m passionate about that I would say “developer tools.”

What it is for me is ─ my friend Nate and I talk about this all the time. Nate Green is another author whom I’ve been friends with for years. And we talk about this idea of “You don’t find your passion; you build your passion.”

And so, when you’re looking at “What does your career look like? What do you want to do forever?” you shouldn’t try to go for the career that you already like. You should go for the thing that you have skill in and that you can provide a unique value with and get really good at it because what will end up happening is that that skill becomes a platform that lets you do the things you’re passionate about.

The thing that I love more than anything is helping people feel more in control ─ being able to take control of their own lives and their own happiness. And if you read my blog, that’s pretty much all I talk about. I don’t talk about tech at all.

But the reason that I’m in the role that I’m in is because by building these tools and by working on the system, I’m giving developers the opportunity to do that.

If you use Gatsby and your passion is hanging out with your friends or being with your family or just not being at work all the time, by building these tools, you can do the same amount of work in half the time so that you can have that extra time to be with your family.

And so, to me, that’s kind of what I’m looking at.

Or even if your passion is “I want to build more cool stuff on the Internet,” you can still use Gatsby to get the work you have to get done in half the time and then spend the rest of the time on stuff you’re excited to build.

I would never say that Gatsby is my passion or that developer relations is my passion. It’s the platform from which I can pursue my passion which is helping people live better lives. And that is really fluffy now that I’m saying it out loud. But that’s kind of where all my direction has led me.

Ledge: I can’t do better than that. I think we’ve got to wrap on that note ─ fluffy and coffee. And we’re doing good.

Thanks for coming out, man. I totally enjoyed your thoughts and we’re definitely going to make sure that the community knows about Gatsby.

Jason: Thanks, Ledge, for having me on. I really had a good time.