Ep. #9, Getting Users To Give A Damn

Steve: Welcome to Don't Make Me Code. We're here with Mikeal Rogers, Community Manager at The Node.js Foundation and we are going to talk about building communities today.

Mikeal: Awesome. Nice to be here. It's a beautiful, beautiful studio.

Steve: Thanks.

Steve: As we were saying before the top of the show, you have some really interesting experience to both of us. Building communities of developers around lots of products and companies. You've been doing it for a long time now and so I would be really interested just to get a history of you and how you got into this and why you do what you do.

Mikeal: Well I think when I was really young and started to get into computers, I ended up getting involved with the hacker communities because there was a community there and there were people online that I could kind of connect with about things. And so, part of doing something and getting really into it has always been in that community aspect, so when I actually started to work in software and build in software, there was a natural kind of attraction to do Open Source.

So a little over ten years ago now, I got, like a job basically doing full-time Open Source at the Open Source Applications Foundation at the time, and even there, there was just a huge draw to the kind of community aspect of it, so not just the development, but how do we get people to care, how do we get people engaged? Like what are the, what's the methodology there? How do we think about this?

So, an amazing guy there called Ted Leung, he's kind of the guy behind the guy, with a lot of Apache stuff and a lot of Open Source, but he was amazing; was kind of a mentor. And then from there, you know worked at Mozilla, and the CouchDB company, and Digital Ocean, and all over the place, really doing a lot of just Open Source work, a lot of community stuff, a lot of outreach, a lot of evangelism. And yeah, I think that's kind of my background as far as that goes.

In terms of Node, I got involved with Node, really like the first week that it was released, and right away just loved it. And then to be, you know, involved with the community so early, you see a lot of like, kind of opportunity to do this and that, and to really bring people together, and to drive things in a really positive direction. So, I ended up doing a lot of that work. Until now, you know when the Node Foundation started, I was asked to come on and, you know, do Community work in both kind of healing a fork, and creating more sustainable practices around the contribution policies and that kind of stuff, and as that's, you know done better, and that's really working, and is kind of phenomenal now, turning more my focus to the foundations internal execution around, you know, communications and events and, like a much kinda higher level role.

Steve: And so you were involved in Node, even before there was an official Foundation, or really even official community around it?

Mikeal: Yeah, oh yeah, yeah, I mean, it was released at a JS Conf EU, which was a conference that my friend Jan Lernhart was running, and I so I knew that it was announced, like right away. I watched the thing. I got like, I think an early video from Jan about it, and that weekend I asked just on Twitter like, "Hey has anyone written a proxy in this yet?" 'Cause nobody had written an HTTP proxy in Node yet.

I'd spent like four years working on an HTTP proxy, in Python that was very, very smart and advanced and did all kinds of things to make it faster. It was thousands and thousands lines of code . It had all these dependencies and stuff, and was just massive. But it was pretty quick, so I sat down and I went, "Ooh, I wanna check out Node. "I know how to write an HTTP proxy. "I'll see how far I can make it." And then like four hours later I had a full HTTP proxy that was maybe 40 or 50 lines of code, and it was faster than my Python proxy. So, that made it pretty easy, to just be like "I don't think I'm gonna write Python anymore, I'm gonna write Node from now on."

Steve: That's an amazing story for a couple reasons. One, I mean it's a testament to the power of Node, in the community around it, but also like, I mean, you know we talk about developer experience on the podcast, and that was what sold you, that--

Mikeal: Yeah, yeah you know ... You know what is was more than anything? It was very fast, and I didn't have to jump through a lot of the hoops to make it iterative and quick, kind of in IO, the way that I did in Python. But the real thing that sealed it for me was that every time I hit Ctrl+C, it fuckin' stopped. Like, every time you, Like when you--

Steve: Like four times.

Mikeal: Like when you hit Ctrl+C in the Node process, it actually ends. There's nothing you can do to make it not end. At that point there wasn't even a way to hook into an event to stop it, right? And, oh god, Python, like I had so many, you know, alternative threading libraries, and duh, duh, duh, trying to make Python just stop, like all these things called killable whatever the module was you're trying to do, and still you just could not get Python to stop sometimes. So, that was really like the best piece of DX in the early days.

Steve: Wow, so they were able, I mean for lack of a better word, they were able to land you that way. And then, you know, you come on, and help the community grow. Is that a show-stopper ingredient to having a community, is having a good developer experience in code base to start with?

Mikeal: Yeah, yeah. I think that that's important to attract people, but I'm also a big believer in, especially when you're starting something new, and you're building a community. People will show up to provide competencies that you show that you value, even if you don't have them, right? So, if you have terrible DX, as long as you're really nice to people that show up to make it better, you'll attract people and those people will show up, especially around something like a platform or a new language.

There are a million people that wanna be the first people to write this particular thing. As long as they know that that thing is valuable, and that the community is going to embrace it, then people are gonna show up to do it.

David: It's pretty interesting to me. I mean, we heard your story about how you started writing Node. I'm interested to hear how did you go from there to actually working on the Node project itself? What was the impetus for that?

Mikeal: Well, I mean back then, it was, you know, a really ... I don't even wanna say it was a small team. It was one person. Like, you know, Ryan Dahl was running the project, and writing all, pretty much all the code. And so, there was some really early code around streams. Like, you know, we were trying to unify the interface by which you would kinda iteratively process data, right? When Node was first released, it actually was really inconsistent. So, if you wanted to say, take data from a file descriptor and send it to an HTTP thing, it was totally different API that you would have to kind of mull between. And so, you know, I wrote, Ryan had written an example of what would it look like to have a standard way to put these two things together? And so I wrote a patch that was "Hey, here's a pump utility." So, that's like part of Node.

Later, Ryan made the .pipe argument, or the .pipe on streams. And back then it was really, you know, you just pull request to router. Maybe pull request didn't exist yet, but you just send a patch to Ryan on Github. And maybe pull request did exist, but they were like really shitty at the time. And so you would just, you would send the code to Ryan, and Ryan would look at it and talk to you and accept it.

Especially that first year, there was probably between 6 and 12 people, that were in the San Francisco Bay area, that would get together periodically, and really whiteboard out some of the more hairy parts of Node. And, you know, it was like me, and Tim Caswell, and Isaac Sluter, and Ryan Dahl, and Matt Raney, and Paul Cuerna, a couple of other people, that would, you know, this was when Ryan was breaking entire API for all known programs every week, right? There was a lot of iteration going on. So, back then we would just kind of all get together and knock it all out.

Steve: I thought what you said about values of the community was really interesting that if you express a certain set of values even if you don't have those skills, people will come to the project. How do you communicate that? Does that come across in code? Or at events?

Mikeal: It comes across in people's behavior more than anything. I think that there's a lot of things that you can do to a project that may seem like a really good idea, that are actually kind of counter incentives for these kind of contributions, right? So, for instance if you hand out committments to people, that do code work, or do API work, but you don't for tests or documentation you're not actually valuing that skill set. And so people are, you're not gonna grow a community there.

You're not gonna have a ladder for people to get more and more involved in the project. And, you know, you're not going to end up getting a lot of those people. A lot of the areas in the Node project where people said, "Nobody's ever gonna show up to do this kind of stuff, it sucks, we're gonna have to pay somebody" are some of the biggest growth areas that we now have in the project, just because we decided to really value those skills at the same level that we value, you know, someone really understanding crypto library.

I think that to some extent, especially in the early days in the Node community, it was growing so fast, that it created this vacuum, right? Like there was really nobody doing community events, and so when I stepped in to do community events, there was huge amount of support for that, and a lot of people that wanted to attend, and then because I did it in such a way that I wrote a lot about what it was like to run it, and tried to help other people up get them up and running and grew it.

It was very helpful for other people to know that they had the support of somebody and some semi-established brand like NodeConf that they could also run an event with, and so we were able to grow the community event space that way.

Steve: And beyond the actual contributions that, that part is really interesting, like, you disseminate this kind of cultural rule, if you will, like, these are the things that are important to us right now and so to get the community to grow, we want these kinds of contributions, but then I think that also touches on the process and politics and like, how you, as an organization, go about getting people to contribute. Like, how do you make the developer experience of contributing to the Open Source project better?

Mikeal: Yeah, I mean, it's not always even what you do, right? You can say, "These are my values," or, "These are the kinds of things we would like to have in people," but if other people don't care about them, that doesn't really matter. Like, this is why Node.js doesn't have a road map right now, right? The reason we don't have a roadmap is because we're not gonna say, "Hey, these are the things that we care about, but we haven't written yet."

The Node.js roadmap is whatever people show up and write code to do, that actually makes sense to have on the Node platform. And it will land when it's ready, and it will get released on a standard timeline that we have for major releases. And that's actually been a huge incentive for people to show up and do things that we didn't think that people would show up and do. And a lot of things that people thought were very, very important, it turns out that nobody actually cares about enough to write, so why have that blocking a bunch of other features in a roadmap, right?

Steve: That sound like a really fantastic way of doing product prioritization, actually. If you have a community large enough to decide for you and they're able to contribute effectively, there's your roadmap.

Mikeal: Yep, yep, and, I mean as long as there's not a lot of huge artificial barriers to contributing. Then yeah, you're gonna be able to grow community really well that way. My favorite trick, actually, is that, like, if we want, like a new microsite, or we want some kind of like new utility in the Node project, I will go in and I will write the worst code.

It'll barely work and it'll look terrible and it won't follow any kind of guidelines and that's a great thing for other people. Now there's a bunch of things for other people to do. If you want to get involved in this project, you can definitely clean up this code, 'cause it's terrible.

A lot of people, too, especially once you're kind of established as a developer and people are sort of like, you know, asking you to speak at conferences and stuff, people are like, "Is it okay if I touch this?" I make it bad enough that it's clear that, yeah you can you can touch it and fix it. Like, this is clearly not intentionally this way.

Steve: Yeah, I remember hearing somewhere that the best way to get someone to answer a question is not to just ask the question, but to actually post an incorrect answer to it and then you'll get a ton of people flooding in to correct you.

Mikeal: That's true. Yeah, yeah, yeah. And I mean, like, the way that we treat pull requests in the Node project now is that the default is for every commit to land and if it's not going to land, it's a process by which you say what needs to change or why it shouldn't land. The person submitting the code has to convince us that it should go in.

Give us the changes that need to happen and why and then this is the educational process. And every person that sends code, we don't think of as somebody smart enough or dumb enough to do this thing. We just think of it as, if it's not right yet, then this is an educational opportunity for us to get them to the point where it is.

Steve: This is kind of side tracking, but is there, like, you wanna probably keep things pretty lean and mean in the code and like, do you ever have bloat issues that result from...

Mikeal: No, one of the reasons why we don't get this and we don't think about it as much as code bloat as we do API bloat. We have a lot of API that we wish that we could get rid of that we will never be able to get rid of because people depend on it. So we're very, very cautious about taking on more stuff. Most of the value in Node is in the ecosystem. So, the smaller that we can keep the core API, and the more work that we can do around performance and stability the better.

The codebase is growing, but a lot of it is like crazy performance optimizations. One of the reasons why I think people get into this is that if you have BDFL model, or you have a model where just a few people are kind of maintaining the project and a bunch of people are sending them stuff, they feel like they're trying to review too much shit, and at some point, either they're telling so many people that they can't get in code, that those people are going to wash out and not wanna work on it anymore, or they're just gonna have, like, you know, a lot of pending things and then just land them all at once.

We've found that the more people that we bring into the decision-making body, which is like, so, hard decisions get made by the TC. Most things land without the TC getting involved, but if it's like controversial, then the TC gets involved.

Steve: TC?

Mikeal: Yeah, the Technical Committee. So, the Technical Committee, so we've, in the Node project, since the foundation started, we went from about five to 70 committers and then most commits land w ith an easy consensus between the committers that care to review it. But like, maybe 5% of contributions end up being a little bit more complicated, a little bit more controversial; they can't reach a consensus.

It bubbles up to the TC, which is about 18 people that are, and that's constantly growing as well, and those people are just like more like relied upon deep decision-makers, people that have a longer history with the project that we count on as like a tie-breaker. The more that we expand that body, the less anxious they are to take on more API, right?

When you start to share the actual responsibility for something, people view everything that comes in as something of a liability

something that they're gonna have to maintain for a while, and people are just a bit more cautious and it's just a lot harder to get, you know, 18 people to agree that this giant new feature is a good idea, than it is, you know, one person over drinks, because at this conference, they decided that it would be totally rad to add all of the Python Standard Library to something, or whatever, you know?

Steve: Yeah, I was gonna say if nothing else, just getting a consensus among a growing number of people gets harder.

Mikeal: Mmhmm. W e're still seeing contributions go up in general and that's because we've made it really easy to get the things done that are supposed to happen. And also, I think that Node, at this point in Node's life cycle, the community has a much better understanding of what is in the ecosystem and what is in Core, and we're not really trying to grow Core if we don't have to, right?

We have an amazing ecosystem, let's rely on it. Nobody has an application that only uses Node Core, and not stuff from NPM, right? Like, that's not a thing. We don't need to feel like we were competing with our own ecosystem with what goes in the Core.

Steve: So, yeah, another thing, since you've been talking about the growth and the changes in the Node community over time, I thought was really interesting when you were talking about the kinds of contributions that you're seeing and the changes there.

Mikeal: Yeah, yeah. One of the things that's really changed in this kind of Github era of Open Source is that the majority of people partaking in Open Source don't identify as, like, Open Source people, right? There's a lot of people doing a lot of stuff and most of them are engineers that work in a start up, or they're doing whatever and this is like a part of their life is just sending a pull request every once in awhile to a project that they depend on or logging an issue or whatever.

When you look at the total number of commits that are happening on Github, the vast majority of them are actually happening from people that have less than 100 commits a month, right? And it just grows as you go down that. So casual contributions account for, you know, the largest amount and also the fastest growing amount of contributions that are happening in general in the ecosystem.

Steve: Is that, partly, do you think, an offshoot of the package system? Like, someone can write a single package, like left-pad, and then that's a relatively small contribution?

Mikeal: I mean, JavaScript definitely has a fatter tail than some of the other ecosystems, but this is like an Open Source-wide trend on Github. This isn't just Node. I have a graph with this cut out by language and it's not just Node and JavaScript. It's almost everywhere. That small package thing is certainly true in Node, but also, I mean, Github made it easy to make a repository, a project, right? And also to collaborate between projects. So, rewind like 10 years ago, right?

And say you depended on an Open Source project and you wanted to get code in, well, you might have to learn a new version control manager, you were definitely gonna have to learn an entire new contribution flow and how to get that committed and you're gonna have to figure out where to send it. You're gonna, you might have to sign a CLA, you might have to read a giant amount of docs on just, like, how to configure and pull it down.

And every project is different, so there's not a transferable skill set between all these projects either, right? So you know that just, it was very hard to get involved with Open Source. The barrier to entry was very high. That's why everybody involved in older Open Source identifies as an Open Source person, because like part of the barrier to entry was also like adopting a philosophy and a set of values.

Now people in software in general are involved in public software. They're working and doing things on Github and are engaged in some way. If you really wanna have a sustainable project nowadays, you really have to gear more towards these casual contributions. You have to gear towards people that may not show up again, that may show up just to do four lines or whatever. You can't have a bunch of big barriers to entry in the way. And this is a really hard thing for projects to do, because

The people who design the contribution process are the ones that are heavily engaged, they're not the ones that are casually engaged. So you have to get people to design a process that is not for them, it's for everybody else.

David: So, it's interesting, I've noticed this a lot with the Open Source work I've done, too, where you talk about this sort of fat tail or longtail contributions, like, that's definitely a trend. I'm sort of curious, how much time do you spend actually trying to design a process whereby some of those people can become more serious contributors or even maintainers, or part of this Technical Committee, or is it kind of just expected that some of these people are just gonna come by and give one commit and disappear?

Mikeal: Yeah, I mean, you have to be okay with them leaving, but retention should definitely be a goal, right? You want some amount of them to stay around and to continue to level up. This is definitely a goal with the Node project, and at every level, we've grown and had more people. There's a chart that I have in an article that I wrote called Healthy Open Source, but basically it says, like,

as your user base is growing, the list of people that you can identify as contributing in some way needs to be growing and then also, the people that can review that needs to grow, and also the people that can handle high order decision-making needs to grow.

You're probably looking at an order of magnitude between each of these steps, but, you know, they all need to grow in proportion to each other, or else you're gonna burn out some amount of those people.

In the Node project, like, this has gotten really difficult because of the size of the project has grown, so not all of this is entirely transferable, if you have like, a single small project, but one of the things that we did that was really effective was that we started to cut up the project into more slices, including things that traditionally maybe wouldn't have been a community resource.

So, like the website, for instance, like, we're the only project that's involved with the Linux Foundation that like, we, our community runs our website. But the website is like a great place for people to initially get involved, right? There's a lot of people coming that, you know, know how to do some kind of web development, that see something they can change and that's really their first, kind of, entry point. There's also an evangelism working group where people just, you know, write blog posts and try to promote Node.

There's two buckets of barriers to entry. Some are technical and some are cultural, right? So, part of it is that people are just worried about being vulnerable and, like, trying to get involved with these people or how to get involved with people and how to acclimate to this culture and if they'll be accepted. And then there's all of the actual technical stuff, like, I don't know how to do this, I need to learn it.

So, having an area like a website or like an evangelism working group where people can acclimate to the cultural side and then all they have to do is learn the technical stuff to get more involved, we see a lot of people make that path. In fact, one of the earliest people came in through the website, got involved in Core like messing with tests I think, and then started taking on more and more stuff, and now he's, like, on the TC for Core. And I think she may have been the first female comitter ever at the Node project; came through the evangelism working group to the website to Core, I think, on Docs, and is now getting more involved as well. So, you see people break through these barriers that way and it's really, really good to see.

Cutting things up this way allows us to vary the contribution process a little bit between each one, right? So, for instance, in the Node project, there's this very sophisticated kind of branch structure because we, everything lands in master, and then we port them off to these branches. So, the cleanliness of t he sign off messages and all that. Like, in order to make this actually work, we have to have some cleanliness there. And that is a barrier to entry.

It's one that we have to kind of live with and that we have a lot of, like, on-boarding and documentation and kind of soft skills to get people through, but it is a barrier. On the website, you know, like, master deploys, who cares? Like, I don't care if it's, you know, what kind of merge that you do, or, like anything else. We're not really worried about the cleanliness of the commit logs and stuff like that in the same way we are around Core. And so, that's another lower barrier to entry for people to get more easily involved, and then from there, we can easily level them up.

Steve: So, you talked about growing the community and growing the foundation and also having healthy organization around it being a critical part of that, that you can't really have a healthy community without healthy company or organization behind it and so how do you ensure the health of the organization and making money, basically?

Mikeal: Well, I mean, it also depends. We tend to talk about like, you know, the 1% of Open Source projects that need this kind of infrastructure. I mean, most Open Source projects are like a library that a bunch of people use that maybe 10 people will contribute to. That's the majority of what's going on out there. And that's really valuable, but, yeah, for the projects that really do need some kind of institutional support for whatever reason, or, a project just becomes enough of its own ecosystem that people are depending on it in a way that they can't rely on a single company anymore, so they need a foundation or some kind of neutral body that's gonna outlive some other company when they get involved.

There's a lot to talk about there and it really depends on the project, to be honest. The way that the Node Foundation is structured is very different than, say, like, the Free Software Foundation, or, the OSI, right? Most of our budget goes to marketing and PR because we're competing with Java and we're competing with proprietary platforms that are huge and it's good for our community, for Node to win and in order to for Node to win, we're gonna have to spend money on these more traditional areas and so our structure makes a lot of sense and that's why we're very, very different than, like, the Python Foundation, for instance. Like very, very different. T hat's our particular need.

And that's also why we have this giant wall between the foundation board and the technical side, so that the technical side, the committers and the contributors can own the project and they really do have a wall for all their decision-making authority between them and like the foundation's board.

Steve: What would your advice be, then, to a company that's starting out trying to build a business on top of Open Source software?

Mikeal: Yeah, I mean, it depends. It depends on your relationship to it, right? I think all businesses are built on Open Source, right? All technical businesses are built on Open Source. There's nobody who's not relying on Open Source in some way. I think that you need to understand how closely your business is tied to a Open Source project or an Open Source platform community, right? Instagram was highly dependent on Postgres and Python, and if those technologies failed overnight, like they wouldn't necessarily fail overnight, they had a product.

But if you're Cloudera, like, you're heavily tied to this one particular Open Source project, so you probably need to take more responsibility for it and make sure that it's in a really particular place. So yeah, I mean it really, really depends. I've seen it go every way that it can go. The one rule that I would say is that, if a company is supporting an Open Source project, right, it is paying for the majority of developers or it is providing the majority of the leadership in some way.

The company needs to be able to scale its investment with the growth of that community and so you start to see tension take over when the company and their, or at least their investment in that project is not growing at the same rate that that community is growing, right? You know, Node had a pretty famous kind of thing with the contributors and Joyent, who was owning it at the time, with the io.js fork and everything, and a lot of that really just came down to like, no company is growing as fast as Node is growing.

No company could ever keep up with the level of investment that you had to do with something that was growing like that, and still growing like that. So, yeah, I've seen it go many, many ways. Joyent eventually did the right thing and put it in the foundation. Now the foundation isn't scaling the amount of money that comes into the foundation with the growth of the community. What we are doing is we're scaling the community with that, right?

The community is now running the project and the project can grow contributors as fast as the community around Node is growing. What happens more often than that, though is a company shows up to a project and they go, "We need to build the community around this. We need to grow a community; we don't have one." And that's a really awkward position to be in, right? Where it's your responsibility to make people excited about this.

Guy Kawasaki, who's sort of like the original evangelist for software, he has this great saying that's, "Everything that is gold, Guy touches," which is very different than "Everything Guy touches is gold." Which is that he doesn't try to evangelize things that aren't amazing.

I think that you have a lot more control over that when you're a developer focused company and you're working on an Open Source project because if it's not gold and it's not great, you can fix it.

You can actually make it better and make it more attractive. And you need to meet people where they are, right? Who are the people that would care about this, and why don't they? I think databases have the hardest problem with this. I say this with love, because I worked in the database world for a while, but so many times, a regular developer, like, web developer is like, "So, wait, why do I have to care about, like, CouchDB or this or that?" And the answer from the other side is like, "Let me explain the cap theorem to you." And then, you immediately lost them, right?

This is why MongoDB won this whole fight, right? Because they didn't try to explain the cap term to people, they just assumed that they wouldn't know it and then just didn't write things to disk sometimes.

Steve: Because it's gotten so much easier to contribute to projects like this, because there are so many more projects available, is that the downside? What is the downside of this enormous growth?

Mikeal:

The competition for people's attention has never been crazier.

No, you have to really put it out there. I mean, you're not only competing with other projects for attention, you're competing with "Well, why don't I just fuck around and do my own thing," right? With the lovely ecosystem inside of Node , I could just sit down and write my own database. Like, why do I want to run your database? And especially on Github. A lot of the activity is in people's own repo's, just doing their own thing.

They have the skills to contribute to your project. If people are using your project, and there is some momentum behind it, there's a lot of incentive for people to get involved. The majority of the reason why people don't get involved is just that it's actually hard to contribute to and there's a lot of things that you can't see because you're so invested in it and you're working on it all the time, that are making it really hard for other people to get involved and it's really hard to step away from that and recognize that.

Steve: Did Node, or any other community you've been involved with, have designers involved early on, or was it purely developers?

Mikeal: No, not that I can think of. People have come to the Node project and done various, like, little design work and stuff like that. I mean, we've had fun with it. In the io.js days, we said like, "Hey, what are people's crazy logo ideas?" And then the thread just blew up. Most of them were totally hilarious and unusable and there was so much passion there that we just said, "We're not gonna pick a logo. We're just going to use a random logo every time. We're gonna pull one out of here whenever we need a logo for something." And that was really fun for, like, the short amount of time that io.js was not merged into Node.

I can't think of any projects where designers were really, really heavily involved. Designers show up and provide that skill-set all the time. If you value it, people will show up. People have shown up to do design work on the Node website and my library request got a logo just because we put itout on Twitter, like, "Hey, we'd love to have a logo," and people do that. The thing about design skills, so often, project only uses a design er for a certain amount of time.

It's not a skill set that has to stay around indefinitely. And so they don't stick around enough to be like in the decision-making role, which is unfortunate. I wish that there was a better way to work on that. I'll think about that one actually.

Steve: Yeah, it came up in our last conversation how, I mean like you've been saying that there aren't many designers contributing to Open Source software, and I think part of it is the finite nature of the need, but there are some of us who have been involved as product designers for a long time who maybe could make substantive contributions to the nature of the project, or like the way the developer experience and the the toolset is created.

Mikeal: Yeah I think a lot of projects probably do have a hard time evaluating the skill set, though, like honestly. I mean everybody's, you know, a back seat designer, like on the internet, right? Everybody has an opinion about this thing. And that becomes really, really difficult to manage. When I was at OSAF, like a decade ago, it was Open Source project run by a foundation, and then we had a community, kind of in the design process. What that essentially ended meaning, is that the designer just spent all of her time explaining her UX flows to a mailing list.

Steve: Or to a committee.

Mikeal: Right, right, and well it wasn't even a committee. It was just like, you know, it was a consensus-seeking process, but when you're paid full time to send emails, you're always going to win. And you're generally just gonna be annoyed with people asking you the same thing over and over again. It was open. I wouldn't call it participatory.

David: It is interesting though, thinking about, like how do designers contribute to Open Source in general? W e talked about this our last episode a little bit, and part of the thing that we talked about was that, you know when a designer often approaches an Open Source project, sometimes it's just really hard to get the thing running, or like figure out where to even start, or how to contribute to begin with, and so there's probably something we can be doing better there to encourage those types of contributions.

Mikeal: I mean, as you work your way up the, kind of up the skill set chain, barriers to entry become more and more and more of a problem. So with the designers, it's gonna be more of a problem than like somebody you want to come and work on the crypto stuff, right. And the people who understand how the crypto libraries work are not gonna be like, "How do I use pull requests?" But you may actually get that from a designer.

Steve: Mm-hmm. Yeah, so you now achieved a level with Node, where you're not, not only have a community around a language, but you also have a conference, there's several conferences.

Mikeal: We have a community of conferences.

Steve: So, how do you manage that next level of community?

Mikeal: I think that the Node conferencing has changed with the changes in Node, right? As Node has grown, the needs of the community have changed, and so, conferences show up to fill those needs. If you're thinking about doing an event, for something that you're into, you really gotta go like, "Why am I doing this?" It's amazing how many people don't actually ask themselves that question and run a conference.

Like you see a lot of product conferences, the products that aren't platforms, right? Like where you can use it, and you can't like, there's no API, you can't build some stuff on top of it, you just use it, and people will build a conference around it, because, you know, "Slack had a conference" or whatever, whoever else that you wish that you were has a conference. A conference is a beautiful thing when you do it right, and you have a mission. If there's a need in the community that is not filled, right? Like, we have a community. We can define this community. And bringing people together will allow us to do something that we can't do online.

A lot of that, a lot of the time, is just you creating tighter bonds between those people by getting them, like together. That's why un-conferences are still a thing, right, is that you don't actually need formal talks, and catering in order to get people to connect with each other. In the early days of Node, I was focused a lot on opening up people's ideas of what Node was, and the breadth of Node and the identity of Node, because people most attracted to the project in the earliest days.

The people that shepherded it on for a while were really interested mainly in back end stuff. Really early on, that started to shift. Like, you know there was IoT. There was a lot of stuff that fell outside of that identity that people were doing with Node.

So, I worked a lot on that. And continue to work on it now, that's actually part of the identity of Node. Inside of the foundation, there's like this Node-everywhere thing where we're talking about that. In those early days, that was why I was doing talks. And then it shifted a little bit more into like, educational stuff. Node was growing so fast, I could not run enough events for all these people, and so I started writing a lot more about how to run an event, and then other people ran events, and I supported those people running events, and now there's a bunch of people running those events.

Steve: Oh wow, so you created a framework for other people to run events.

Mikeal: Sort of, yeah. I mean, I wish that there was more support, but it's much more complicated than you can imagine to give support to somebody in Brazil running an event. I can't offer them my LLC to help them set up anything like that. One is sitting down and talking with them and like they'll ask a bunch of questions, and you just kind of answer them.

When I ran my first event, Chris Williams from JSConf worked with me and basically did this for me, and so when people started asking me, it was like okay, I need to do this 'cause Chris did this for me. Chris is still doing it for a bunch of other people as well so I can't pawn them off on him.

There was this real community-led effort to do a bunch of small events in a bunch of places. Small events are interesting, because they attract the people that are kind of most invested in the community. So the social ties are part of it, the actually connecting with people part of it, is really, really strong. I'm glad that we went in a direction that was like, almost all of these events are single track.

Almost all of them are really intimate, really big breaks. Like we really prioritize that. I think that now Node is at a place where you can't do one big community event, because there's just too many people. And events have gotten much more regional, right? So there's a lot of smaller events now that are really great for all these communities. And they pull in people like me to speak or whatever just to get people there.

Steve: I like that model to, because Amazon by contrast has this massive, you know, re:Invent. It's so big, it's impossible for a small company to get involved in an event like that, and more smaller events seems to be a better way to get more people involved.

Mikeal: Yep, yep, and I think think you also do need those big events, like re:Invent, though. T hey address a totally different set of people, right? The Node Foundation now runs two events called Node Interactive, which are 1000 people events, right? One in Amsterdam and one in Austin this year, and the amazing thing about that event is that it gets a bunch of people like me, and a bunch of other core committers to Node, because we, you know we do a board meeting and a couple committer things there, and we have them speak.

They also get to meet all these people that write Node all day every day, but they sit behind a desk. They don't talk on Github. They're Node users, part of our community, but we have no other access to them, because unless their company buys a lot of 50 tickets and sends all of them, they're not gonna show up. In a lot of those companies, they're building all this stuff around Node, really need to connect with those people as well.

It's very, it's a totally different purpose. Like I wish that it had a different name. Because it's literally that different. The only thing that's the same is that you're bringing people together, but the goals are just totally different. And I think that they're both really important to have. And they need to be structured really, really differently.

Steve: What you said about the un-conference, I thought was also interesting that it's not just the getting people casually together is important, but you can run entire events that way. And they have just as much value.

Mikeal: Oh yeah, oh yeah. I mean, some of them, the most valuable things we've ever done at the Node conferences. I think like, you know Node streams API, and I think like the domains you get. Like all these things were worked out in like a summer camp in Marin, where I do NodeConf.

Steve: Yeah, NodeConf, I saw that this one too is gonna be up in Marin.

Mikeal: Yeah, yeah, NodeConf Adventure that we do up there. And it's just a little Node conference. It's the last one, but yeah, it's been great.

Steve: And so the people that are coming to that are very like heavy contributors for the most part or people that are deeply involved?

Mikeal: Traditionally, yes, yes. I mean, we've always tried to broaden it a little bit, and get more people out, but the reality is that you're not gonna go and sleep in the woods with a bunch of people from a community that you're just like a little bit into, right? Like that's not a thing that people do. You're not gonna like, sleep on bunk beds in a summer camp for kids if you're not pretty into it.

Steve: That's funny, this all sounds so obvious as you say it now, but I've never really heard someone explain this all rationally before, like you know the giant event where you have multiple tracks and talks. Those are educational events, and you try to bring the masses in. It's just really interesting to hear about all that and that stratification.

Mikeal: Yeah, and one of the things that you know we can do as a foundation that I think you know, if a media company, or a just a for-profit corporation, is running like a giant event like that, is that you know they're just there to make the technology grow and get more people from the business world involved and engaged. And that's certainly a goal that we have, but also like, we can think about each of these people that's behind the desk all day as a potential future contributor, and a potential future person that is much more engaged in the community than they are now.

So we can gear the content and some of the engagement in such a way that we kinda pull them in that direction, because that's, you know, part of our mission, and one of the reasons we exist. So, you know it's not purely just "what are people asking for, let's give them that". It's also like a healthy dose of like, you know people also need this, and it would be good for the community if we did this.

Steve: The one that we kind of touched on, the relationship between that business and an Open Source project. And I still feel like there's a missing conversation around how, like David, your use case. Like you're trying to build a company on top of an Open Source platform that you're creating.

David: Yeah, yeah, and it's sort of the you know like there's different kinds of Open Source, right? There's something like Node, which is a giant community of contributors now, and then there's something like Convox where we essentially bootstrapped the project. We built most of the code. We've now opened it up to the community, and we're starting to see some participation from other people, but still the bulk of the work is done by us.

Mikeal: Yeah, yeah. It really, really depends. And like, you know, is your community mainly gonna be on the user side, or is it mainly gonna be on the, on the developer side? Like do you need a ton of people engaged in the core of it, or do you really need people building on top of it, building a platform on top of it, and that's where you need your engagement, because you need a pretty different strategy for each of those things right? And you need to figure out what you're gonna optimize for. I mean if you're optimizing for people to build on top of it, then you're gonna optimize a lot for saying no to things, right? Like, you want them to be built on top and not in it. You're really just gonna be taking all of thi s feedback for features that people want into, like, "Oh, well, how do I make that something generally applicable to a bunch of people, and allow people to build that on top of me?" It really varies between them, right?

I think that the most important thing is that it's participatory. I mean you want to encourage participation at all the levels that you can in order to compete. Open Source is much, it's more and more of a loaded term every day. Open Source is a license and so much of what we talk about usually when we say Open Source is really, we're talking about participation, we're talking about, you know, collaboration, to some extent. And that's really the marker of like you know, a project that is growing and healthy, versus one that's not.

At the end of the day, like, it's whatever works for you and your community. There are a lot of people totally happy to use Go and to never ever be able to get any real changes into Go, if you don't work at Google. T here's a ton of people that don't mind that. Like, they're okay with that relationship and Google is putting a ton of resources in to Go, so if you agree with that direction, it's not like they're leaving you hanging out to dry, but there is like a lack of participation from people outside of Google and Go, in the core of it.

There's a huge amount of participation in people building on top of it, right? And a lot of people building great libraries and applications on top of it. So yeah, I mean it's, to some extent, it's what are you optimizing for? I think, you know, for me, what I've tended to work on is cases where the community growth is outstripping what can be sustained by whatever the structure is underneath. And so, you have to break apart that structure and make it more participatory. And in some cases, also, you've got to bring it into a neutral body. You're a victim of your own success. Like if enough businesses depend on you for their business, then they need to know that that technology is going to outlast a business.

Steve: Yeah, they're gonna stop trusting you as an individual entity.

Mikeal: Yep, yep, yeah. You can be too successful.

Steve: Is there a clean line somewhere? Like, hearing you talk about the distinction between contributing to Core versus building on top, that when I, just off the top of my head, when I think of businesses built on top of Open Source software that they've created, I see a lot more of the companies where they're managing the Core and then people are building on top, whereas Node or other communities where people are actively contributing to core, those seem to go more the foundation route.

Mikeal: I think the most successful businesses optimize for growth, right? And if you're a platform, you can grow quicker than you can invest in it. Maybe not your value, but the value of the platform can grow much quicker than you grow the business around it, right? So something like Slack. Slack makes no qualms about the fact that they are platform. I think that they even said recently that, like, their goal is that the value on top of it is worth more than Slack is, right? That's a very specific thing that they're trying to do.

With Node, the value on top of it is hugely valuable and shared by a ton of different companies and so, for Node, it needs to be in a body that is neutral, that is not, you know, particularly around one company. There are other analogous platforms as well. If you're building a new business, like a brand new one, and especially if there isn't another company and another piece of software in between you and your customer. It's much more natural to have a slightly tighter grip of control of it.

I think one of the problems that you have though, is just like the growth thing, right? Like, how are you going grow to meet all these needs? Are you going to invest all of those resources or is a community gonna built around, like, doing those resources? And as that community grows, if you can't grow the investment that you're putting into it, then you're gonna end up getting into a contentious situation.

Steve: There's this is one, like, looming last thing left on the board there: fake it till you make it. I guess we kind of touched on that. Just like, you have to kind of create inertia however you can and I don't know if you have more to say about that specifically. Was there any early effort at Node or any other place that you've been to really spark inertia by getting a team to...

Steve: So, let's talk a little bit about the evangelism side of that, right? Because I do think that's important when you're promoting something. When you're promoting something, you're not talking about how many people aren't using it. You're talking, specifically, about the people that are using it and how rad it is and how positive it is. But, also, when you're building your community, you're really only talking about the positive stuff.

If you're trying to build a community by flaming something else or saying that you're better than it - don't. You're going attract a lot of really negative people and people that have a really high tolerance for negativity, which is really gonna screw you up down the line. Like, always stay positive. That's the number one rule is like always stay positive.

Always be saying positive things about yourself, about your community, about other people doing stuff.

Part of fake it till you make it, in terms of evangelism is like, just talk about the people doing cool stuff, even if it's not that big a deal. Make it be a big deal. Make it like an interesting story that people care about, you know? It could be, you know, one start up, you know, doing some stuff with five people. And sure, you're not Java. You're not some giant data center somewhere serving a million people but like you could be, and you might be someday. The path to that is a bunch of other people getting engaged and inspired by the stories of people actually using your software.

Steve: Yeah, as a small company, I think it's really important to elevate people so that they feel important and at whatever scale you're at, that does seem like how you grow, not just by staying positive, but also by celebrating the level that you're at and making sure that you're helping everyone along with you.

Mikeal: Exactly, exactly. This is a really small thing, one of the things I started doing in request when I realized I did not have enough time to continue maintaining this library, was people would send really good pull requests, like really solid, and I'm like, "That's awesome!" You commit this now, you can commit, please. Please do that. And so it's not just saying like, "Oh yeah, you can get in stuff." Just like, "Here, you do it now. You are now the expert on this." Just deferring to people, when they know things, deferring to your community, to ask about a thing on .... Even if just on social media, right. If somebody asked "Oh, hey, this thing." You may know the answer, but if somebody else knows it really well, or is really proud about it, point it at them, and elevate them as well.

Steve: Thanks again to our guest, Mikeal Rogers for joining us. Mikeal, if people wanna get in touch with you, how do they find you online?

Mikeal: Just go on Twitter. I'm @mikeal that's how you spell my name.

Steve: Alright, thanks again for being here, and we'll see you next time on Don't Make Me Code.