Building open source communities: decentralisation and empowerment

Speaker 1: Alright. Hi, everyone. Hi. I'm Jade. I'm one of the founders of Sandstorm.

Speaker 1: Have you how many of you have heard of Sandstorm before? Just out of curiosity. Alright. Something's working. We're an open source, private cloud operating system, and I'm going to share with you what I learned building the open source developer community around Sandstorm and also Meteor where I used to work, where I was employee number five.

Speaker 1: So a bit about my background. I I went to Stanford for biology. My PhD is in neuroscience, and then I did aviation research at NASA Ames. Before Sandstorm, ran community at Meteor, the open source web framework, scaling it up to a 100 meetup groups in cities worldwide in under two years. This was like a community team of like two people.

Speaker 1: We ended up with three, but started with one. Before Meteor before my time at Meteor, started ShajJ, which is a hacker house network. And it's it's a network of hacker houses that really brought the hacker house movement mainstream. For Shoe JJ, housing was really always just a nice side effect. It was really about finding birds of my own feather, a place where people can find collaborators and cofounders and lifelong friends.

Speaker 1: It's about building community, and that's what we're gonna be talking about today. So first, let's define what we mean by community and why it's important. There are two things that people usually mean when they say the word community. The first is marketing, and this is the usual marketing kind of thing is the fine thing to do depending on what your product is. But I wanna clarify that that's not what I'm going to be addressing today.

Speaker 1: The second is organizing. And when you're working in open source, when developers are as interested in the community as they are in the code base itself, then your project will be evaluated based on the community, not just the code. That means the ecosystem. That means the app packages. That includes the that includes the other people that they interact with and and how nice they are to each other, and the knowledge base.

Speaker 1: And how we do that is by identifying and empowering community leaders. So these are the two parts to organizing, identifying and empowering. We surface community leaders anywhere we come into contact with them in the ecosystem. That includes GitHub issues. That includes authors of packages.

Speaker 1: That includes people who write really great blog posts and also in real life, like at meetups and conferences, wherever we come into contact with them. And once we've identified these really promising people with a lot of growth potential, we empower them to do more and elevate them as high as they will go. So when we talk about open source projects like Sandstorm or like Meteor, that means there are really two things that each company makes. The first one is really obvious. It's it's a code base.

Speaker 1: It's right here on GitHub. You know, you can in in Sandstorm's case, it makes it radically easier to deploy applications. In in Meteor's case, it makes it super easy to write applications whether you're on web or mobile. And the other thing we build in each case is community. Now when people join an open source community, they evaluate that community and the ecosystem.

Speaker 1: And and at some point, they they ask themselves, can I make friends and find collaborators here and opportunities, and employers, and mentors? Do I have a future here? Can I build great things here? But let's go beyond building things. I wanna preface this next part by saying we're gonna take a radical departure from the standard playbook because after all, team of two people.

Speaker 1: Right? So put on hold all your preconceptions about what community usually means or what a normal org chart looks like. Don't think of community as a separate program from everything else in the company. As you'll see in the examples I'm gonna show you, community is literally the lifeblood of how we do everything. It's our community who are literally our boots on the ground.

Speaker 1: I want you to think of platforms like Airbnb and Indiegogo or Kickstarter or Lyft. Like Airbnb hosts who astronomically outnumber Airbnb employees, the community who vastly outnumber the core team at Sandstorm War Meteor are literally the boots on the ground. The important thing to realize here is that when I travel, my Airbnb experience has very little to do with what my confirmation email looks like. Although I'm sure they put a lot of thought into that. It's it's really all about the host who I'm interacting with.

Speaker 1: And when I contribute to a crowdfunding campaign, my experience is far more impacted by the project than by the platform that it's hosted on. And this is one of the key takeaways. We, the community team, are a bone structure, not the muscle. In Meteor's case, there are entire departments that we did not have in house. Projects led by the community included a testing framework, multiple textbooks, and separate instances of a distributed mini conference.

Speaker 1: Sandstorm is even more radically decentralized. The community is largely structured around our app ecosystem with an overlapping contingent of folks who champion Sandstorm to their employers. Moreover, at Sandstorm, we don't have a habit of keeping secrets. And doing copying this might make some people in your company a little bit uncomfortable, but you could get you could think about it. Like many teams, we have weekly check-in meetings where we announce and coordinate our to do list for the week.

Speaker 1: Unlike many teams, we email those meeting notes to the community mailing list every Monday, and a follow-up every Friday to list the things that we accomplished, the the things that we didn't accomplish, and the non goals that happened to come up and get done. Occasionally, a highly anticipated feature on someone's to do list will create quite a bit of excitement. And the follow-up questions and comments are not only great for team morale, it's really great for collecting user feedback because it's a really close feedback loop. And when a newcomer asks the list, when is feature x coming and how does y work, A community expert will usually chime in with the answer long before any of our team members could get to it. The TLDR here is we created an ecosystem, not a command economy.

Speaker 1: And how did we do that? We identified and empowered leaders within the community. Here's what we do. We prompt we identify promising people in the community, empower them to do more, and elevate them as high as they will go. We surface our community leaders anywhere we can come into contact with them, whether it's on an issue thread or whether it's because they wrote a tutorial or a blog post.

Speaker 1: The thing is, it's incredibly important to create an opportunity rich environment. For instance, Meteor hosts a mini conference, distributed mini conference program in San Francisco, London, and New York, a stage on which authors of Meteor apps and packages can showcase their work. And the talks get shared on YouTube to 16,000 subscribers, which is a lot of a good subset of the community. Likewise, the Sandstorm app marketplace is a place where anyone can package and submit their apps for deployment on a Sandstorm servers. Many of these apps are written by just one or two people in their spare time, like EtherCalc, which is an open source node based clone of Google Spreadsheets, or Wicon, which is an open source Meteor based Trello clone by Maxime Quindel from France.

Speaker 1: I want to emphasize that you should surface these leaders everywhere that you come into contact with them. And it's important to create a lot of surface area because where people can we have this opportunity rich environment. That's where people can really distinguish themselves by making certain choices that make them stand out. So once we've identified these promising people, we empower them to do more and elevate them as high as they will go. So how do you focus your energy?

Speaker 1: Turns out, community leadership looks a lot like a power law distribution. That means that the 8020 rule applies. The 80% of the cool stuff is being done by 20% of the people, and that makes it a lot easier to focus your energy. To that end, it's rather like the YC model or a lot of accelerator programs or investment funds. The goal is not to make every startup or in our case potential community leader uniformly a little bit more successful.

Speaker 1: The goal is to create an opportunity rich environment where it becomes really easy to identify the really promising community leaders and make them go really far. You really have to find and invest in leadership, not just participation. The strength of your community is not a body count. Leadership, not just participation. If you invest in leadership, participation will follow.

Speaker 1: From the same small nudge, a small number of people will rise dramatically higher and create far more value. And here's one of the key differences between community and marketing work. It's not really about how many eyeballs see your brand or how many audience attend a talk. One person who builds their business on Meteor adds dramatically more value and is more impactful than a 100 passive listeners in an audience or viewing a retargeted ad. One app author who puts a killer app in the Sandstorm app store sells their app, and Sandstorm as the installer to an enterprise customer is way more impactful than thousands of readers casually reading hacker news.

Speaker 1: I'm going to take this to an extreme and say, I'm not just looking at the 20% of people making 80% of the impact. I'm gonna say that this 20% is where you should be casting the net to find a fraction of a percent outliers who are your community leaders. See, most power laws identified in nature are capable of black swan behavior, where you get some very special outliers, and community organizing is no exception. And here's another take home message. You should look for black swans wherever you have surface area with the community, because by definition, you won't know where the next one will come from.

Speaker 1: But they will make a disproportionately large impact and take everything in your ecosystem to the next level. The way you find them is by creating this opportunity rich environment, such as an app marketplace or a distributed mini conference. Both are really great ways to surface black swans. It's not to say that the rest of the people in the long tail of your community don't matter, that the random sandstorm fan doesn't matter. Of course, they matter.

Speaker 1: But the things that you do for them in the long tail will eventually be internet scale things, like your content production or your tutorials and things like that. The high touch support and nurturing is for boosting outliers, that is app authors, out of the park. You can do this high touch stuff for them. You can do these things that don't scale because they are rare birds. Just make sure you have ways to find them and identify them.

Speaker 1: I'm going to illustrate how powerful this can be with two examples. The first one is from the Sandstorm community. So we at Sandstorm believe that there should be no first party apps. This means that we do not compete with app authors because as platform authors, we have a really unfair advantage, like the way that Google apps have an unfair advantage in the Google Play Store for Android. I believe that there is a natural boundary of team to team cooperation between platform and apps because individual app authors and app teams enjoy the freedom to choose a language or stack that they that they work in, autonomy over product design, and the kind of visibility for their contributions that's frankly harder for a core contributor to get.

Speaker 1: Therefore, a large amount of community effort at Sandstorm focuses on ecosystem building around the app market and making sure that app app authors and packagers have a great time. So I wanna share a story about an app and the team behind it. So so sand Sandforms is an amazing app in the Sandstorm app market. It's an open source alternative to Google Forms that's one click deployable on on Sandstorm, and there's a whole team at ThoughtWorks working on it with the aim of making it the form apps of choice for activists and journalists who require privacy and security. The sand the Sandform team often gives lightning lightning talk updates at Sandstorm meetups, which they co organize at ThoughtWorks in in San Francisco.

Speaker 1: Jack Singleton, here, the team lead, first got my first got on my radar because he wrote Hacker Slides, which is a minimalist open source alternative to something like Google presentations. I say minimalist because here it is. I I write my start I write my slides and markdown on the left, and it uses Reveal JS to render what's on the right. And then I hit the present button, and it puts my slides up on the screen. Basically, I'm actually using it to present right now.

Speaker 1: Now it's super useful to teams who, you know, are in a regulated industry and can't have their sensitive documents living on Google servers. And prior to this, I we've never heard of this guy before. Right? He just showed up one out of one day out of the blue with an app. Now all app packagers and authors are special.

Speaker 1: But Jack and the amazing task force of other people who are super helpful on IRC and the Sandstorm Dev mailing list who are helping others troubleshoot and offer advice are just the next notch up. And since Jack was local to San Francisco, when Sandstorm core dev, Ashish Loraya, was invited to give a talk at the EFF techno activism event, he transferred that speaking opportunity to Jack since the talk was about developing apps for Sandstorm. And Jack did a great job. Subsequently, he organized a Sandstorm booth at the digital light digital rights for libraries camp conference, and then flew in flew to Berlin where he gave a talk at the chaos communication camp about the ease of writing sandstorm writing, sensor maps. Now between episodes of spreading the gospel, he told us about an interesting conversation with his Thoughtworks colleagues.

Speaker 1: There was an effort to consolidate their social impact work. And so Jack and his colleague Yukira pitched Sandstorm as a project to focus their energy on. And they coordinated with us on what what they thought was, you know, a missing gap in the the alternatives to Google Docs Pantheon, that the Sandstorm ecosystem was missing. And speaking of missing gaps in an ecosystem, I remember a time when the media community really, really needed more introductory teaching materials. So next story.

Speaker 1: Discover Meteor is a really fantastic Meteor textbook. Meteor does not have a tutorial on par with Discover Meteor, and Tom's consulting company, Perklet, has since been acquired by Meteor. It was written by two pillars of the Meteor community, Tom and Sasha. We identified Tom's potential for great work because of his work on atmosphere, which is the repository for third party packages in the Meteor ecosystem. Sasha is a designer by training, and if you use Hitmonk, you'll be you would be familiar with his work.

Speaker 1: Sasha was building a community for designers called Sidebar, which is like a curated hacker news for designers, when the developer he was working with bailed on him. He needed a collaborator fast. And one of the Meteor's founders actually personally introduced him to Tom, who then helps him build Telescope, which is a real time clone of Hacker News. They went on to collaborate on a lot of projects, chief of which is Discover Meteor. So our team of our community team of literally two people at this point watered the seedling as much as we could.

Speaker 1: We organized for them a book launch party. We did a Discover Meteor Day event. We sent them speaking opportunities all over the world. The takeaway here is to recognize really high caliber work when you see it and to realize its potential for growth. Solve whatever is rate limiting that is in your power to solve.

Speaker 1: And here's the thing. Because of Discover Meteor, we no longer have plans to write our own textbook. We rely on the community to do great work, and it's better this way. It's incredibly powerful for the movement, and it's great for the app authors too who earn a mid 6 figure income from writing the book. Unlike us, we like we didn't make any money on the book.

Speaker 1: But wait, there's more. It's incredibly important to keep your eyes peeled for organizing ability in your community leaders because it allows for recursion. So Sasha, one of the authors of Discover Meteor, is a prime example. He made the bold decision to open source a translation of Discover Meteor. As a result, there are 32 translation projects, nine of which have been completed, and many of which are very close to complete.

Speaker 1: The contribute buttons will take you directly to the GitHub repo for each of these translation projects. It's all open source, and it's all community driven. So just to recap what we talked about. Open source projects are about code as much as community, and and community is about organizing people. And we went through two case studies from the Sandstorm community and the Meteor community.

Speaker 1: So what can you do today to grow your community? Remember the power law. The strength of your community is not a body count. You need to create an opportunity rich environment because some people will rise a lot further from the same small nudge and the same opportunity rich environment. And you find and invest in leadership, not just participation.

Speaker 1: Keep your eye out for organizing ability amongst your community members, and give people real power. You can probably on average, for most people here, you can probably stand to give them more control than you currently have. And I mean really real empowerment. Like, hand them the keys to the kingdom and let them drive. So, yes, handing the keys probably makes a lot of people uneasy, and that's why it's important to make both kinds of mistakes.

Speaker 1: That is, handing the keys over too early with too little oversight or not giving people enough rope. Unless you make both kinds of mistakes, you will have no idea where the optimum is. So try experimenting and find the sweet spot. If you're not sure what kind you know, what call to make in in the moment, make the choice that will teach you the most about what decision to make afterwards. So I'll take questions now.

Speaker 1: And if you guys Okay. Or not questions. We'll do discussion later. Out the Sandstorm demo if you want. And if any of you are interested in marketing by integration or integrating with us, talk to me after.

Speaker 1: We have cat stickers on the sticker table.