a16z Podcast - Turning Open Source Developers Into Superfans

Episode Date: August 10, 2020

In this episode, we continue our community series with a recent discussion that applies to many kinds of community building. Today’s topic: How do you create a platform that people not only use, but tell their friends about? One that goes beyond just being useful and actually connects deeply with the user? In this discussion, which was recorded at our Crypto Startup School in April 2020, a16z General Partner Chris Dixon talked about building communities — specifically, communities of open-source developers — with GitHub cofounder Tom Preston-Werner. They discussed how to engage early users, how to turn them into your biggest advocates, how to create superfans, and more. Today, GitHub is the leading community for open-source developers and others. They also discuss in-person communities vs. distributed communities, a topic that is very top of mind today.

The content here is for informational purposes only, should not be taken as legal business, tax, or investment advice, or be used to evaluate any investment or security and is not directed at any investors or potential investors in any A16Z fund. For more details, please see A16Z.com slash disclosures. Hi, welcome to the A16Z podcast, I'm Zorn. So this week, we're continuing our community series with a recent discussion that applies to many kinds of community building. You can find past community pieces at A16C. Z.com slash community. Today's topic, how do you create a platform that people not only use, but tell their friends about, one that goes beyond just being useful and actually connects deeply with the user? In this episode, recorded at our Crypto Startup School in April 2020, A16Z general partner Chris Dixon talked about building communities with GitHub co-founder Tom Preston Werner. They discussed how to engage early users, how to turn them into your biggest advocates,

how to create superfans, and more. Today, GitHub is the leading community for open source developers and others. They also discuss in-person communities versus distributed communities, a topic that's very top of mind today. So here's Chris and Tom, starting with the beginnings of GitHub. And so how did the idea for GitHub come about? That was while I was at PowerSet, and we were using Git internally a little bit. I was working on an internal project with Erlang, and a coworker that I was working with,

Dave Farum, introduced me to Git. He was like, this is the greatest thing. Like the Linux kernel uses this. It has this really nice branching and merging model. And he showed it to me. And I was like, this is pretty awesome. It's, you know, the command line stuff is a little hard to use. And like, you have to have an account on a Linux server somewhere.

And pushing and pulling from repository to repository is a bit awkward. But I definitely saw the potential. And so we started using it internally at PowerSet. And going to the Ruby Meetups in San Francisco, I just started thinking about how great Git was, but nobody was using it. Nobody could really harness the power. What was the dominant? What were you using? What were most people using then?

So version was the most prominent open source. Some people would be using CVS. Some people were using Perforce. Yeah. But it was really about trying to make it possible for people to harness the power that I saw. And being a web developer, I was like, I know to make websites. I know how to write code that can read from a disk and pull,

get objects off of disk and get them in terms. Ruby so that they can be exposed in a Ruby on Rails website, and I thought that would be a cool project that I could work on that I could then use to share open source projects with people that I knew and just started showing it around the community. And so you built this website and then you put it up and did it immediately kind of get popular or did it take a long time? We did a thing that we stole from Google, a marketing trick that they did with Gmail where you had some invites.

gave people five invites, and then they could invite, they could send invites to their friends. And so there was this, this kind of artificial scarcity. I mean, it was real scarcity, too, because our cert, you know, we had some very small server that we were running this thing on. And, and so it was sort of a dual, a dual effort to, to leverage some of that artificial scarcity that, you know, that makes people want to, you know, they're like, I want, I want in. I want to, you know, everyone could see it, but not everyone could have an account. And so we managed the accounts that way early on. So anyone could read. Anyone could see it and pull the repositories,

but you couldn't necessarily sign up, right? You had to have an invite to sign up. So that worked. I don't know if that works anymore. I haven't seen people do too much of that anymore, but at the time it was quite successful. Like, it created a lot of buzz, people just talking around. I think Twitter was quite early then,

but people were talking about it on Twitter. And people really seemed to like it. And it was, I don't know, just people started signing up for it, pushing up random bits of code here and there. And it immediately, I think, struck a chord with people as far as the capabilities of version control. And what you could do once you realize that you had easy branching and merging, offline capabilities, it was super, super fast. And now with a website where you could push up code and collaborate on it and make it so that you could use Git and have it not be the hardest thing in the world. It just, it grew linearly, our user base grew linearly for almost the entire time that I was there.

This was not a super exponential curve like you see in a lot of startups that you're always like, I need that exponential growth curve or I'm doomed. For us, it was quite linear. We'd grow by some X thousands of users a month, and we sustained that for months and months and even into the years. And those numbers would grow, so it wasn't exactly linear. And then, you know, over time, it would get faster, but it was mostly, it was quite linear. But the income was also linear, which was nice. The income just kept coming as well.

Did you have the business model at the beginning for the sort of pay for privacy, free for public? It was always that. I think that you were the pioneers. I still think of that as like one of the cleverest models, business models. Yeah. I'm trying to remember if we pulled that from somewhere else. I don't think we did. I think it was just, it felt right where it would be free for open source because we, were open source developers. We loved the open source community, Ruby on Rails open source, Gets open source. We wanted to give back to the open source universe. And so we thought, hey, what if we made this free for open source? That would be great for the community and also great for marketing, where if you have all these open source projects on GitHub, and especially if we can get some prominent ones on there, then people will come to GitHub to use those

projects and then you get some viral element of it. So that was all win-win on that side. And then if you're a company, you have money that you're willing to spend to solve problems. And so if you want privacy, then you pay for privacy, right? And so it always was that from the very beginning, and it just, because it just felt right. Today, I think of GitHub is not only a great kind of front end for Git, but also really a social network and sort of a global collaboration tool. Did you think of it that way in the beginning? Was that kind of your vision all along, or did that emerge? I think initially it was not as much as it became,

but we always from the very beginning did namespace the URL by user. So it's always GitHub.com slash username and then project name. And I think that's one of the biggest reasons that GitHub was successful. Like that one decision in order to do that. Really? Using user slash project versus project slash. So putting the user first as a sort of the interesting. Because what you saw in the other, in the other,

hosting, code hosting platforms at the time, which were SourceForge and Google Code, they both had top-level namespaces that people would use from projects. And especially on SourceForge, if you recall, you had to get permission to use one of those top-level namespaces. You had to write to them and say, hey, I want to use this project name. And then three days later, they would write back to you and tell you whether you could use it or not. And so we thought that was ridiculous and we wanted an easier way for you to get code up and any code and on the google code side they forced you to have a license and they forced you to make certain decisions that that that we thought were unnecessary whereas like why do we make you do anything just put code online

just get it up there if you don't want a license don't put a license i mean you should have a license right it's helpful to have a license but there's no mandate that says that you have to have a license right the default license for anything that you put online is that you maintain copyright, but that, you know, other people can't use it without your permission. So it just, we were trying to reduce the barrier to entry as much as possible. Just strip every possible thing away that we could think of to make it easy for you to get code online. And the social elements came from that. Then that was, that was now the way that you would share your repository. So if you go to a conference and someone gives a conference talk about an

open source project or anything that they're working on and they want to share something, they put a GitHub URL on the screen and then that gives it this really, really beautiful viral element that also supports the social aspect. But to be fair, GitHub does not have a tremendous number of social tools built in. Yeah. It's also interesting, the business model. As I recall, SourceForge was in this kind of death spiral of like more and more banner ads. They didn't have a business model, right?

So they, I mean, like as elegant as yours. And so they, they, they, it was more, it was a little bit like a lot of, frankly, websites today that are just sort of more and more, right? There's more and more croft to support them. And I think they're in sort of a death spiral where the more cruff they have, the less people to go there. And then the more cruff they have to add. And I feel like source forger's in that, you'd be called much better probably, but it was in that desk spiral. And you guys came along with this really clean experience. And you had a, and you had like a kind of a pro user business model.

Yeah. Yeah. Yeah. It wasn't exploitive. I think that was a, that was a really important distinction. People could look at GitHub and say there's no ads. This interface is designed for developers. We put the read me in front of you.

Like when you go to a GitHub URL, it's a file listing and then the read me. And that was extremely rare. Now you see that everywhere, but we were the first really to do that. And when you go to SourceForge, it was like some download page or some marketing stuff, like a description, but in a different way that wasn't close to the company. code and and ads everywhere and it was it was that but it over the next couple of years after github started to be available source forge kept declining more and more rapidly and just they made a lot of bad decisions and so they sort of destroyed themselves i think they could have they could

have made it better but they made the wrong decisions and google code google code was never a priority for google it always felt like kind of a side project for them for them yeah but they came at you at GitHub pretty hard at one point, right? Like, why did that not work? Was it the thing you described that it just never sort of was a social network? Or, I mean, it wasn't the top priority, but it was a real project. It was, yeah, I mean, it was, I think it was probably the leading place that you would put and share your code, but it was subversion. And so they, I don't, I think, I can't remember if they added Git support or not. But if they did, it took them forever. And so it was almost, the point was moot by the time it mattered. Everyone had already switched over to GitHub. And then at some point, Google, Google, code shut down and they're just like just go to GitHub like we don't have time for this yeah what um were there sort of big milestones like for example i don't know like Linux moving over or where there's some like you know big projects i assume there were some you know the open source community is very strong opinions on things and i assume there's some pushback at some point and maybe at some point people sort of said hey this is a great solution yeah i think the most there's two projects that really

paved the way for many more the first first was many people probably won't even know. It was called MIRB. It was a Ruby web framework that was kind of trying to compete with Ruby on Rails. So it was much smaller. It was much more kind of less code, more streamlined. But it was kind of popular at the time as an alternative to Ruby on Rails. And so they came over quite early on and started using it. And that brought some people and people are like, oh, like that's a real open source project. People use it. Like this is legit. All right, let's come over. But then the bigger one and the most important one was that Ribion Rails came over. And it was only maybe six or eight months after we launched publicly that

they moved over. So they were quite fast movers, even though to us, we reached out to them and we're like, hey, you should consider putting Ruby on GitHub. You know, the GitHub's built with Ruby on Rails and Git is way better than Subversion. The community would love it. And initially, they were like, no, we can't. Like, we have way too much tooling built up around subversion and the whole community knows how to contribute that way and it's just not feasible so they initially said no and then three or four months later they came to us and they're like all right we're moving so help us do that and we were like yes absolutely we will help you do that and uh and that was amazing because then the entire it felt like almost overnight the entire ruby all of ruby on rails community

and and ruby on rail sort of you know drags a lot of ruby the ruby the broader ruby community along with it and so almost overnight it was just like shook and everyone and Ruby went from subversion to GitHub, to Git Hub, to get in GitHub. Did it go sort of language by language? Like you got Ruby first and then whatever, Python or something? Yeah, it was. In the early days, it was very much sort of language by language, or it would be an open source community.

So maybe a part of a language that would come over. Maybe some PHP project came over. I can't remember the sequence of all the project that came over. But, you know, one at a time, you know, some projects that are more cutting edge would say, well, if Ruby on Rails can do it, like we can do it. they have good taste. They seem to be having a lot of great velocity and the developers like it. So that reduces the risk equation for them, they can come over. And the more that that happens, the more that other companies and organizations and projects see it and start to say, this is less

risky. If everyone's doing this and a lot of developers know it and really love it, then we can do it. Open source projects did it. And then companies started seeing that it was possible. And the developers in those companies were demanding it. They were starting to say, like, we need to be using Git and GitHub for our company because we can't work with subversion now that I've tasted the sweet nectar of Git like the taste of subversion is just the worst and I can't tolerate it anymore and so the developers really drove the demand within their own organizations everywhere and what you got besides building besides sort of building a developer you know a product that you yourself wanted as developers you know clearly you did a lot around the product

to make it appealing to developers. What did you do on the sort of quote marketing side? Did you do, I mean, you know, and by that I mean that in a broad sense of like, you know, talks or direct reach out or like, and I guess, you know, we're obviously getting to the topic of like, you know, what are the kind of lessons, I guess, that you learned on the kind of on the developer sort of relation side? There were really two main things that we did marketing wise and neither of them were

traditional and we didn't spend a ton of money on them. The first one was in San Francisco, we did what we called at the time, drinkups, which I don't think you can really do anymore. But this was a different era. We did drinkups. So basically, we'd go every two weeks, we'd go to a bar in San Francisco, and we'd message people in San Francisco, and we'd say, hey, the founders are going to be at this bar. You should come and we'll buy you drinks. And so people from the community would come and join us at the bar, and we'd just hang out and have some beers or whatever and just talk. And it was, in the early days, it was amazing because bringing a community of people together

where it's not huge. These things would be 40, 50 people sometimes, but they were never massively big. But you'd get a lot of people that had a similar interest. They all cared about Git. They were all like, get is great. And then they're probably using one of the languages that has come over to Git. So they're probably doing Ruby or JavaScript or PHP or something. And so you'd get 50 developers in the room together.

and you just have amazing conversations. Whoever you talk to, they're doing something interesting. And they're all cutting edge. You know, because if they're on GitHub, they're on the cutting edge. Because we only did this for the first couple of years. But it was really, I think, powerful to create super fans. And we talked a lot about super fans and how we create super fans. And how do we serve super fans?

What can we do to surprise and delight our users and turn them into super fans? And so that was, we did these drinkups. We also went to conferences. So we would pay for anyone in the company to go to conferences every year. And at first we didn't cap it. We're just like, if you can get a speaking slot at a conference to talk about whatever you want, but we love if you talk about GitHub related things, then we will pay for you to go to that conference.

And we will pay for someone to go with you so that you have a buddy. And then we would often have those people that would go be ambassadors and hold their own drink up. So we'd often then sponsor one of the after parties, or we would just pick a bar in the vicinity of the conference and not even be a sponsor because many times at these large conferences, the sponsorships were super expensive. And we were still bootstrapped. And so we would kind of hack the model by being like, hey, we're going to be at this bar. come over and we'll buy you beer if you want to come to this party that happens to be happening at the same time as these other sponsored events so we did a lot of that and I went to many of those and they're just

it was the same experience but now it was all over the world and so we went to conferences everywhere and we had employees kind of being like laying down the seed planting the seeds of GitHub in various locations and then you could see that those seeds would grow into communities of and GitHub users in all these places around the world. All we had to do was go and talk about it in front of some developers, and they'd be like, why haven't I heard of this before?

This sounds awesome, and they'd start using it. And then they'd start asking their friends to come and collaborate with them on their open source projects, and then they'd go to conferences, and then they'd put their GitHub URL on the screen. And other people would be like, GitHub, what's that? And then they would go to that URL, and they'd be like, wow, I want this too.

I want to be able to show everyone my open source code. And so that was our sort of plant the seeds model. When you say super fans, like this, it's interesting because you're able to directly reach out to them, so there can't have been that many, right? So we're talking like thousands, not tens of thousands of people, is that right? Yeah, in San Francisco. So we, so in GitHub, you can put in your location address. So we would look at that and we'd like find all the users that had put in San

Francisco or somewhere nearby. Or when we went and did a conference somewhere else, we'd like look through the list of, user locations and then we would send them a message. I'm not sure that that's GDPR compliant. Things are a little more tricky these days, but it was great. People loved it. I mean, it was early enough that nobody was angry at us for, you know, spamming them or reaching out to them. They were always just super excited to hear from a founder of GitHub and be invited to go grab drinks or meet up and talk about the stuff that they loved. So I think the things that you can do when you're a small company end up being quite different than the things that you can do when

you're a large company and you can you have to take advantage of that it's a it's a superpower that you can that you can take advantage of and you guys were gethub is often cited as a example of a success story that was a distributed team um i'm just curious like how do you think about that and and what have you learned about sort of you know distributed teams over time and how do you we we ended up quite distributed did, but we did not start that way exactly. So in the beginning, everyone was in San Francisco, but we did not have an office. So we had a chat, we started on IRC, and we had an IRC chat room that we coordinated with, and we'd be working from home, or we'd often get together at a coffee shop. And so the four founders were all in San Francisco, and then we, our first

non-San Francisco hire was our first tech support person who lived in Colorado. And he was in the IRC channel and just he was loving GitHub and he'd be just giving people technical support for free. Just he would like hang out in the channel and and just help people out. And so when it was time to try to free up some of our time from doing tech support, customer support, so that we can concentrate more on the product, we reached out to him and said, hey, do you want to work for us? We had never met him, never seen his face, never heard his voice. And we hired him because he was doing the work. He was already doing the work. So we were like, we'll just, we'll just pay you to keep doing this and then do more of it. And so he was our first non-San Francisco person. And so,

but it was fine because we were all in chat all the time anyway. That was our primary way of communication. And then over the next couple of years, we did most of our hiring in San Francisco, almost exclusively, until we were maybe 20-ish people. Then we'd hire maybe one or two that weren't co-located in San Francisco if they had a skill, that we really needed and we thought they were an awesome person. And then after that, we became more and more distributed. But we always had the San Francisco office and San Francisco was always the hub. So it wasn't a fully distributed company like you see today where there is no office.

We always had the office, well, after the first two years from working coffee shops, we had the office. So to fast forward to today, I think when you were doing GitHub, there were other kind of very interesting kind of developer-focused startups. I think there's many, the sense I get is there's many more today. There's a whole kind of broader category. I think you're involved, like you're, I believe you're, you're an angel investor in like Netlify and a whole bunch of these, right, and kind of developer-focused startups. Now that it's sort of more crowded and maybe you can't just kind of go do a meet-up and get, you know, I guess what, how do you think today about how startups should reach out and to developers?

I think you can still, I think you probably could still do that with the right community. I think if you have a community of people that's, that's cohesive enough, that is a small enough, like where everyone shares the same interest, then I think you can still get people together in person, maybe right now in history, that's not the best time to do it. But we have all these great tools to do things online. And things like podcasts, I think, are now a really great way to build communities as well, where you, you. You go and you ask people who are experts at whatever your subject is or people in the community that your user base might want to hear from, and you go and ask them to, hey, come on a podcast and chat. And you could replicate some of that same feeling. You could have a Discord server or something going where your community can talk to each other. I think there are still ways to replicate that without necessarily doing it in person.

But there is something really beautiful about the in-person thing. I don't think, I don't know that it wouldn't work, assuming that, you know, we can all actually leave our homes. I think in San Francisco and other places that have enough density, it could work for whatever you're doing. But if you're not in one of those locations, that's obviously much more difficult. And then you would want to draw on online communities. But it's all about finding the people that care a lot about one topic. Get them together. Like Jamstack as an example.

Precisely. And it's a relatively small, I mean, not relatively, you know, thousands. thousands, let's say, not maybe, or maybe thousands who are like the most influential. And do you think those people tend to be kind of concentrated still around San Francisco? And that you can, you know, hopefully the pandemic ends and we can have meetups again. It's, I think it's less concentrated in San Francisco than it has been before. And I think it's, I think the trend will be to continue that. It's just, it's very difficult to, to be in San Francisco and do a startup.

I don't, I don't know how people do it. The startup that I'm building now is based primarily. in Berlin because it's too expensive to hire in San Francisco. It's just you can't give people the quality of life that we want to give them. And we, you know, we hire people. So my current startup is called Chatterbug, and it's a language learning application. So foreign language learning, if you want to learn French or German or Spanish, you can check out Chatterbug. We do all our own curriculum. And so we hire curriculum developers. We have a team of 12 curriculum developers. And you can't, if they lived in San Francisco, there'd be no way that we could, it's just it would

be unfeasible for them to live here. They couldn't do it. The salaries that they would demand would be too high. We'd burn through capital three or three times faster than we do right now. And so I think you're seeing less and less concentration of these types of technologies in San Francisco, as San Francisco has sort of maxed out its ability to do this as well as we used to. People used to come here. And now it's people leave because it's, it's almost become unsustainable to live here. And there's a lot of work to do in San Francisco. I'm still, I still live in San Francisco. I'm in San Francisco right now. I love San Francisco. Don't get me wrong. It's just become a different place than it used to be. And the challenges are much bigger.

But I think that I think the community is everywhere. Yeah, it'll be interesting. Like, like, we see different models. Like there's people that just say, you know, I'm going to be based in Berlin, right, or some other city. There's people that sort of, I think, kind of what Stripe maybe is done, where they have the headquarters in, you know, San Francisco or South San Francisco or some Bay Area, and then they have a whole bunch of other offices. You know, we see other people that just go fully distributed. I think the fully distributed, my sense is fully distributed.

It's much, you have to be, it's like an advanced level management skill to run that. Yeah, it's definitely harder in some ways to be distributed. We have, so we have essentially, two bases. We have the founders, mostly are here in San Francisco, and then everyone else pretty much is in Berlin. We have one or two people also in the Berlin time zone, but it's tough because I'm managing a team of product designers right now, and I get about two hours of overlap in the morning where I can talk to them, and I have kids, so I'm taking them to school under normal circumstances. And so it's like that's the time that I get to to do meetings

is two or two or three hours in the morning and then and then the rest of the day. So I have to my mornings are always packed. And and so it's challenging. You have to be able to work asynchronously where they're doing work and then they're putting it online and then making asking things or making comments and then you come in and do the same thing asynchronously afterwards once they're done for the day. And so things like GitHub, things like Slack, things like Zoom become really critical. The advantage is that you can hire in wherever you want to hire. If you want to have a multi-office setup, certainly you can do that. And GitHub did that as well. So we had San Francisco is the main office. Once we got to 200, 300 people, San Francisco is the main office, a bunch of

satellite remote people on their own. But then little one, you know, offices here and there where you'd have three or five developers and more now. I mean, GitHub's thousands of people. So they do this more, a lot of salespeople now. But it's a challenge. It's always easier when you're co-located. When you can just sit across the table and just have a meeting whenever you want and you're in the same time zone, that's easier communication-wise.

But again, it's harder hiring-wise. And payroll, total payroll cost-wise, you're, you're dependent. Depending on where you are, it gives you advantages. I don't know how many San Francisco startups you're funding these days, but I don't know how anyone does a startup here anymore. It's very hard. It's very hard. I think a lot of people are trying to be creative about new models.

But the sort of so-called Israeli model is popular, I think, where you have R&D. And we have a bunch of in our crypto portfolio, a bunch of people that actually, Berlin's very popular, for example, as an R&D head headquarters. but then maybe you put kind of business slash marketing, you know, et cetera in San Francisco or something. Yeah. But yeah, I mean, the rents have just maybe that will change if the economy changes. But up until recently have just been unsustainable, right? Yeah. I'll just add one more thing about distributed or remote working.

One thing I think we did really well at GitHub to solve for this was we always thought of ourselves as as primarily as distributed first, remote first. So all of the things that we did would always be streamed. So we had a, every Friday, we'd do in all hands. And when I was CEO, I'd get up in front of the company and I'd give kind of a speech about philosophy or something that was on my mind or that I needed to communicate to the employees. And it would always be streamed live to anyone in the world. And it would always be recorded. And it would go up into a place where we had all of our talks and anyone could watch them or rewatch them whenever they wanted. We'd have a segment beforehand where we'd bring in people that were remote on video.

I think we used blue jeans at the time or something. We'd bring them in and they'd be on the screen and you could talk to them and it'd be like a chance for a remote person to get some FaceTime with the rest of the company and feel like they were more involved, as well as all the things on GitHub. Everything that we did at GitHub was on GitHub as much as humanly possible. All of the content creation, all the legal work. Everything went through GitHub. which is asynchronous, really good for asynchronous communication just naturally.

And partly because we work that way, that everything goes through. That's the coordination point for most work. And so if you are going to have multiple offices, if you're going to do anything but just be everyone in one office, I'd say you need to shift to that way of thinking where you're really serving the remote people. That's the first thing you think about when you think about the company and how it works. that you have to serve people because otherwise there's remote people will they'll never be as effective as you need them to be they'll always feel left out if you don't kind of go internet first

with everything exactly yeah i know like stack overflow i believe they have a culture where they just leave like google hangouts on like all day like it's just a normal thing to do you're sitting in your office coding and you've got you know this sort of this kind of environment we have here um just all sorts of other i mean just i think there's a lot of my my understanding is a lot of ways to make it work but you have to be very thoughtful about it in a way you don't have to be when everyone's just sitting in the same room together yeah and the other the other caveat would be so for chatterbug our all hands also look like this we don't you know even though we're 36 37 people right now almost everyone's in berlin 30 30 of the people are in berlin we still do all hands this way

everyone gets on a computer and the same should be true like when you're doing meetings with people. If you've got, say, five people who are all co-located in one place and you've got a meeting room, it's very tempting to be like, all right, let's, you know, the five of us go and jump in the meeting room together and then we'll conference in, you know, Susie, and then she'll participate. But the fact is that she won't. She'll be the, you know, the spectator, hard to get a word in. The much better solution, when anyone in a call is remote, everybody's remote. That's awesome. So we have a bunch of questions here from the students. So I think we have about 15 more minutes of you.

If you don't mind, I'll go fire away. Okay. From Francesco, once you have the code, it must be tempting to build a whole array of services around that code. While GitHub is very pluggable, it does abstain from providing infrastructure for deployments, for example. How do you think about what to build versus not build? So while I was there, and I haven't been there for a number of years now,

While I was there, we wanted to be fairly agnostic because we wanted the ecosystem to sort of flourish and build tools. So it was like GitHub could be the core of developer collaboration. But all of the things that people want to do around that collaboration, we want people building as much as they can. We want as many tools as possible for people to plug on top of GitHub to make their development. experience better. And so we thought by taking a more agnostic, a more language agnostic stance on that, and even some of the tooling.

I mean, GitHub does have, at the time, you know, it did have a number of things like issues. So there's a simple bug tracker that you could have. But that felt sort of a thing that you would want to integrate very closely. But for things like continuous integration, you're like, let people build different kinds of solutions. We don't want to build one ourselves and then discourage people from building their own. Because what if we get it wrong?

What if we don't do it? What if our imaginations are not as great as the sum total of our community when it comes to building these things? The idea being that then eventually, maybe years down the road, it would be interesting to start bundling some of those things in once the territory had been explored. And you'll see this in technologies a lot. this sort of cycle from debundling and pulling everything apart, having all the pieces separated, to then integrating and taking a bunch of tools and pulling them all back together. So you can see this happen at Apple all the time where for many years now, they've been on an integration run where they want full control over their hardware.

So they now make their own chips and they make their own RAM and they make their own, you know, eventually they'll probably make their own screen. they want to have control over as much as possible because the value is in the very slick integration of all of the pieces that go into something like a phone. But before that, it was more interesting to have a lot of choices, a lot of plug-able, modularizable things. You look at servers, at the world of servers, or even in looking at computers. It's like, do you want to go out and have a million pieces of a PC that you can put together and build? or do you want one slick computer?

I guess that is kind of the PC versus Mac. That's that division, right? Which one do you want? You can get a better experience when you control everything, and everything is beautiful and perfect and works together. And so this is a question for Redwood as well. You see this all over the place. So Redwood, in the JavaScript world right now,

if you write any JavaScript, you probably know this. In the JavaScript world, there's a million choices for everything, and nothing is together, right? you want to create an application in the JavaScript world with React? Well, you're not only choosing React, you're choosing React plus about 50 other technologies that you're going to then try to integrate together to create one application. And each of those things, there's like 50 choices for each one of the, how do you do CSS? How do you do state management?

How do you do what's your API look like? All of these different layers have choices. And Redwood tries to do the integration work, to say, enough has been done in the exploration phase. Now what people crave is a fully integrated experience that makes everything super easy. And so the same was true at GitHub. It was let the community build as many choices as possible and then eventually we can start integrating. And now you start seeing GitHub to do some of that integration work with things like GitHub actions. They're still, it's very choosy in what it's pulling in. And there's still a big ecosystem on top of it that you can hook into and plug in

and GitHub takes great advantage of that. So I think it really depends on the context and what people are craving. Are people craving integration or are they craving debundling and having choice? Great. Another question from ARIA. Most for-profit companies rely heavily on open source code. How are you thinking about the future of open source incentives and economics? Do you have thoughts on how to do sustainable funding for open source?

GitHub donations is an interesting take on funding public goods. Have you looked at ideas like quadratic funds? just like more broadly like what's yeah I guess more broadly like you know future open source how do you fund it I'll just add to the question there's all these interesting things going on now where the the cloud platforms are kind of sucking a lot of the value of the open source and maybe not always giving it back and and so I don't know so you know editorializing you take from there yeah open source I think is still is still is probably more vibrant than it's ever been so I don't think open source is in any danger of collapsing or of there being like an open source apocalypse of

some sort. And I think that's because this prime element of open source still holds true. And that's that people love writing code and helping other people accomplish things and are very happy to put open source into the world with no idea that they'll get some great advantage out of it. I think that's still true. And I think that's still a really important part of open source. So I don't think it's like super broken. I think that what about like you know, but as you know, a lot of these things are helped by corporate like, you know, Intel contributes to Linux and whatever, Mongo and Elastic, have these sort of corresponding for-profit companies. Right. So but so most open source still starts with that model of, hey, I had an idea and I hacked it up and I put it,

you know, out there and people started liking it. Now there's another phase of open source. That's exactly what you're talking about, which is open source that gets popular enough that people want to monetize it and work on it more. And so you'll see things like Gatsby, for instance, which I mentioned before, they started as an open source static site generator and then became a company or elastic search, same deal, or EngineX. All of these things started as open source, got popular, and then it was like, oh, there's opportunity here. Let's turn you to do it a company. Now those companies support the open source, which I think is a beautiful, that's also a beautiful model where you have companies working on open source. And at GitHub, we did the same thing. We hired several people to work full time on Git itself, which was great because, A, we get to give back to this project that is the reason that we got to exist.

And so we can be good citizens of the world of Git that way. And two, it allowed us to have more control over the future of what Git became, because GitHub had. demands of Git. There were certain things that we needed Git to do that literally nobody else in the world needed because of our scale. And so nobody was going to work on those parts of Git unless we worked on them. So we'd work on them and then we would contribute them back to the Git project itself. So either a company can be monetizing an open source project and then paying, you know, they pay for its development and also take contributions. Or you can have a company that uses something that they didn't create and then hire people to work a on it full time, which I think is one of the most underutilized versions of people working on open source. I wish companies did a lot more of that, that they would say, have a critical technology that they use, and they would hire several people, one or several people, or at least give some people time to work on those open source projects. And many companies do. A lot of people do give back to these open source projects that they use, but I think it could be an order or

several orders of magnitude more of that style. And to me, that's working. I think there are other really creative models for people to work on projects through crowdfunding and other things. There's now some foundations that are collecting and distributing money to, you know, like you as a company can pay into this collective. I can't remember the name of the specific one, but into this collective and then they will distribute the funds to these various projects. depending on what you're using. So you just give money to one party and then they can handle the distribution. Because the thing is for companies to give money directly to projects is really hard.

Like that division between a company and an individual, especially a large company, is almost unsurpassable. Like how do you do that? What do you pay for? And this is where support models can be really valuable too. Like if you want to go down that route professionally and you have an open source project that you think is getting popular, one way that you could do it is to offer support and say, and say, hey, big companies, I will provide you support if you give me money. And the companies, it's a lot easier for companies to pay for that than it is for them to just be like, we like your project here's 10 grand for nothing, right?

They need to buy something. Makes sense. So from Sarah and Danny, love how you prioritize community and superfans at GitHub. How are you carrying lessons learned there over to your current ventures? what are the things you would do to create superfans and, quote, surprise and delight superfans? You could maybe here, not just, you know, feel free to talk about any startup you're involved with or cool things you're seeing today. Yeah, I think it's about scale. This is something that Paul Graham has talked about a lot in the past, but doing things that don't scale at first,

and I touched on it before with things like the drinkups or whatever. So one thing that we've always done at chat, that we did at GitHub, and now we're doing at Chatterheader, bug, and I'm even doing it with Redwood, is sending physical things to early users. So with GitHub, we sent stickers. With Redwood, I'm also sending stickers. So when I launched Redwood on that same day, I was like, I'm just going to send stickers, like some Redwood stickers. I'll send stickers literally anywhere in the world.

I don't care where you live. Anywhere in the world, I'll send stickers to you for free. And there's just a URL that you can go to that I can send people. and they can get stickers. And it's not that expensive. I've sent a thousand stickers and it's cost me $300, $400. So, I mean, it's not super cheap.

But it's, those people are going to put those stickers on a laptop. And I always send five. So once they're allowed out of their houses, they'll give them to their friends who will then put them on their laptops. And it's this really simple and cheap way to get your brand more exposure through people that love what you're doing.

And if they're willing to put your sticker on their laptop, then they're willing to endorse what you're doing to their friends and kind of vouch for you. So this touches on branding, which is one of my favorite things in the world. I love a lot of the branding that work that we did at GitHub. We have the OctaCat. We really leveraged it.

But one thing I think that people don't understand as much as they should about branding is that it's never about you and your company. It's always about what you are providing for your customer. So there's a woman, Kathy Sierra, Kathy with a K, who I encourage you to look up and read some of the blog posts that she did. They're quite old now, but they're timeless. And one of her big things is when it comes to creating product, it's not about being cool for the sake of being cool, whatever.

It's always about how can you help your customers kick ass? how she puts it. Help your customers kick ass because when your customers succeed, then you succeed, but you succeed in a much better way than if you're just like, hey, look at how awesome I am, look at me, look at me, this is great, right? And you try to get people's attention that way. But if you can say, let me help you be better, let me help you be more awesome, then that is a much better thing to do. And that, that is the reason that people would put a sticker on a laptop. It has nothing to do with your company as such. It has to to do with what they believe they are communicating to others with that sticker or with

that shirt or with that whatever it is. When someone wears a GitHub shirt, it's a signal to other developers to say, I care about open source, I kind of like it to be fun, and I'm just, I love coding. I love being part of the community. And they're sharing, it's a shortcut for communicating values. So if people share the same values as GitHub or Chatterbug or Redwood-J-S, then they can communicate those in a shorthand way by putting your branding, the branding of the company, on something that they own, whether it's their body or a laptop.

And so it's always about that communication of values. So for your own companies, I encourage you to think that way about branding. Like what are your values? Because if you have no discernible values, then nobody will care about your brand because it's not communicating anything. There's nothing to believe in there. There's nothing to, there's nothing to, there's no reason for them to ever put it because it's not a shortcut for anything, right? So you have to believe in something and you have to communicate that belief very strongly. And then the branding kind of takes care of itself. That makes sense. Well, that's awesome, Tom.

Thank you so much for running out of time now, but thank you so much for taking the time. It was great. Absolutely, happy to do it. Stay safe and hopefully it'll get some. good coding and other things done during this time. I try, but we have a seven-year-old, a four-year-old, and a one-year-old, and that makes it a little bit hard to get a lot of coding done. Awesome. Well, thank you so much, Tom. All right. Thank you, Chris.