Different projects attract different communities and your job is to recognise how to support them, say Elizabeth K Joseph and Judith Malnick. In this talk from DevXCon San Francisco 2018, they compare and contrast the architectures, user bases and governance histories of various open source projects and look at ways to nurture and sustain differing communities.

Transcript

Judith: Hi. So, we are here today to talk to you about the factors that shape open source communities. Different communities are structured differently and a lot of the time when you go to open source talks it says, “Oh, your project should be modular. Your project should be totally open with an open road back. Your project should be this or that.” But the question we’re trying to answer today is what if your project isn’t all those things, what kind of community do you build?

Elizabeth: Yeah. So, we had a wonderful introduction there. Thank you. But just to expand my background, I’ve been working at open source communities for over 15 years. I started with Linux users groups on the East Coast, moved out here about eight years ago. And so I’ve worked on a bunch of different projects, which we’re gonna sort of go through today that vary on the scope from like open source entirely and very corporate.

Judith: And my background is in biology, but at my current job I’ve worked on three different open source project, which span the entire gamut between super open and pretty company controlled, and those are Apache Mesos, Marathon, and DC/OS. So, what we’re here to tell you today is that the right kind of community depends on the project that you have. And we’re gonna talk about some of the factors that will impact the kind of community that you want to build.

Your flexibility and the factors that have an impact

Elizabeth: Yeah, and one of the things I wanted to touch upon is how important it is to be flexible in these roles of developer advocacy and such in your communities because what works really, really well in one community can totally backfire in another. So, your experience as you move between communities won’t always be the same. And just to sort of give you what we’re gonna go through here, we’re gonna talk about the factors real quick, and then we wanna go through examples in depth of a few projects we’ve worked on, and then share some of our conclusions from these.

Judith: Sweet. So, those factors are, to start out, your project structure. So, projects can be integrated, which means that if you change one piece you change the whole thing, or they can be pretty modular. They can be made up of pieces that people can break off and work on independently. And how easy it is to break off a piece and work on it without having to understand the whole project is really important for whether or not you’re gonna be able to take contributions and how much work somebody has to do before they have a successful contribution. And how your open source project relates to any enterprise projects that are on top of it is also really important. So, if your open source project is totally independent and your enterprise project sits cleanly right on top, you’re gonna have a very different community than if your open source project is a little bit squishy with your enterprise project.

Elizabeth: Yeah. And so another thing we want to talk about is how your project is structured to who your users are. So, we split this sort of into three categories. So, B-to-B which is going to be…these are open source projects that are built by businesses for businesses. So, you can think of something like OpenStack in this regard where it’s a lot of companies investing in it and companies who are using it. Not many people have an OpenStack cloud in their basement. I do but…and then there’s other ones that are like B-to-C. So, you can think of something like Mozilla where they create a web browser and that’s very, very much for community members and users. And then there’s also like community-to-community where you have like, you know, the open source example’s an egg timer. So, you have an egg timer. It’s a very personal thing. You use it to cook your eggs but that’s not something that businesses necessarily use. It’s gonna be something that’s built for community members for other community members.

Judith: This is the classic like “scratch your own itch” model of open source software. So, the other thing that’s gonna make a big difference on the community you’re gonna build is the governance model. So, if you are grassroots, you are basically the classic open source software project, right? People get involved. They get to say what happens in the project based on how involved they are and everybody kind of gets a return on the effort you put in is the effort you get out. Then you have foundation controlled open source projects. And I’ve put up example of this as Apache Mesos where there is a really defined roadmap of how you get to impact where that project is going. And so people kind of go through this process and can expect to get influence that way. And then some open source projects are open source but they might not be open source governance. So, good examples of this are projects where one company controls where the project is going, what’s gonna go into it, what’s not gonna go into it, but the source code is still open. You can still make contributions but you don’t get to define the roadmap.

Fully open source means fully open engagement

Elizabeth: All right. So, we’re gonna dive right into some project examples and show how this actually bears out in projects that we’ve worked on. One of the first open source projects I got involved with is Debian and that is not necessarily an easy project to get involved with but I had a really good mentor who was a Debian developer. So, one of the factors of Debian is it’s fully open. There’s not some enterprise version of Debian unless some company makes it separate outside of the project. It’s very modular because the way you contribute to Debian, for the most part, is by taking a piece of software and making a Debian package and adding that to Debian. So, you need to know about Debian packaging and you need to know about the piece of software you’re packaging. So, you could have these really modular projects, and that’s how I started.

I say that it’s sort of community-to-community because in Debian, while there are a lot of companies using Debian, when you get down into the community, it’s very much individuals working with individuals. I rarely see a lot of company affiliations in the Debian community. And it’s very grassroots governance. There’s no real companies involved. People are elected as the project leader and then they delegate from there but it’s actually pretty casual. And the way you nurture this kind of community that’s very grassroots is you have open engagement. Everything in the community is done in the open. You show personal interest in people who are working on the project. So, I mentioned that I had a really good mentor when I started working on it and that was incredibly valuable.

In the project they also recognized contributions. So, there is this idea of people who are members of the Debian project based on some of the work they do and there’s also Debian developers who actually have access to upload things to the Debian archives. And if you were to build a community sort of around supporting a project like Debian, you’re gonna want people who are really technical, who are honestly comfortable with old-school tooling because the bug tracker, you still interface it with email. There’s a lot of email for communications and IRC and stuff. You wanna have packaging experience and you also wanna be using Linux yourself. There’s a lot of people who come to…not a lot, some people who come to Debian developer conferences and use Max. That’s okay but to really be part of the tribe using Debian on your laptop is gonna be important.

Company controlled: creating chances for contribution

So, the next project I worked on was Ubuntu. This one, again, it’s fully open. Again, it’s very modular. It’s based off of Debian and so the involvement is very similar to Debian. But there’s also these really strong communities of teams doing documentation, translations, organizing local conferences. So, there’s these ways you can get involved really easily. It is more business-to-business. There are lots of individual community users of Ubuntu, but for the most part, most of the Ubuntu deployments in the world are run by companies, and it is company controlled. There are parts where you can have influence in the community, but for the most part, you need to…Canonical actually drives the direction of major decisions.

You want to nurture this kind of community, identify chances for contribution. So, finding contribution bits and then telling your community, “You can go work on these,” has been really valuable. And also you wanna recognize contributions just like in Debian. So, Ubuntu has a membership program for people who have been involved for a long time. And then another, you know, if you’re building a team around this, again, people should be using Ubuntu just like they should be using Debian. You’re not gonna get very far as a developer advocate if you’re not using Ubuntu on a day-to-day basis. It tends to be a younger community so there’s a lot of tools coming out all the time. You want to be sort of social and upbeat and excited to be there to attract the type of contributors that contribute to Ubuntu. Also, you wanna be someone technical so you can build supporting tooling for community members. So, Mesos, you wanna…?

Judith: Yeah, so, Mesos is an open source cluster resource manager. So, if you have a bunch of servers, Mesos pulls the resources from those servers and then offers them to frameworks on top. Mesos is fully open source. There is no enterprise Mesos. It’s integrated, meaning that if you change something in Mesos you pretty much…it could interact with like other aspects of Mesos. So, there are frameworks that you can build on top that are very modular to Mesos but the technology itself is really integrated. And that means that contributors and committers really have to have a good understanding of it before they start contributing and committing. It’s B-to-B so people don’t have Mesos clusters usually just hanging out. Businesses use it for big computing projects and it’s foundation controlled. It’s controlled by the Apache foundation.

Finding ways for people to get involved

So, the way that you nurture Mesos is basically by finding ways for people to get involved, and by flattening the onramp to contribution, and by helping the community make more noise. So, one thing you can do is identify places where there are easy wins and sort of help people get involved there. You can look at the current contribution roadmap and see places where it’s a little bit frictionful where it’s hard to contribute and you can take the, like, unnecessary barriers out. You can help translate ongoing work. So, the pace of Mesos is really fast but they don’t have marketing people. They don’t have like dedicated dev advocates. So, being able to read a blog, or read the documentation and turn it into a blog, or read the release notes and turn it into a tweet is something that helps the Mesos community a lot because they don’t inherently make noise even though they’re developing really quickly. And, of course, recognize contributions that do come in.

Apache Mesos has this to a certain extent with the committer workflow. So, when you start committing, you build your portfolio, you eventually, hopefully, become a committer, but there are many small contributions that we can make and recognize like contributions to the documentation, to the website, to blogging about it. So recognizing those places where there are low friction contributions is really important. So, community managers and dev advocates that you want to help Mesos out are going to be able to translate technical information into human-readable information. So, one example that I like to give is that the blog used to be entirely a list of changelogs. So, every release blog was just a changelog and I was like, “Wouldn’t it be great if people could read this?” And they were like, “Oh, yeah. That would be great.” So, stuff like that.

In contrast, we have DC/OS. We call it the Datacenter Operating System. It’s not really an operating system. It’s basically a platform that lets you manage the lifecycle of workloads that you’re running on top of Mesos, which is like the kernel because it manages resources for those. So, DC/OS is open core, there is enterprise DC/OS that Mesosphere offers. The open source project evolved from the enterprise project. So, in contrast to a lot of open source projects where you start out with tons of users, tons of contributors, and then build a business on top of it, we kind of did the opposite. We said, “Hey, we want to get more feedback. We want more people using this platform. How do we do it? We open source part of it.” So, because of that, it’s still pretty integrated with the enterprise product. So, a lot of our workflows still use private tracking mechanisms, for example. There are a lot of those tight integration points. And it’s B-to-B. It’s business-to-business. So, obviously, you don’t run a DC/OS cluster just for yourself, you run it to run big workloads on top and it’s controlled by Mesosphere.

Recognise contributions and identify small wins

So, what you can do is, in contrast to Mesos where you’re helping them make more noise and helping reduce friction for the external community, the opportunities to help DC/OS are very different. You can find places where it is possible to expose much as you can and advocate for that, obviously. You can find opportunities for people to contribute that don’t necessarily interface with the big, giant blob of DC/OS. So, a great example of this is that our community was really passionate about installing DC/OS with Terraform, and wrote their own scripts for that, and shared it out to the rest of the community, and it was hugely valuable but not a part of DC/OS itself. So, that was a great opportunity.

Set expectations and create opportunities for non-code contributions, and also recognize contributions, obviously, because, you know, when you get something in, you wanna celebrate it. So, as Liz mentioned in the beginning of the talk, when you’re looking for a team for DC/OS, you want somebody who’s comfortable with ambiguity, who can say, “Let’s go there slowly,” who can say, you know, “This process is a little opaque. Let’s document it.” And identify small wins where you can like slowly turn the tide.

Elizabeth: So, the last example I wanted to give was OpenStack, you know, this is a big cloud platform. So, again, OpenStack itself is a open source project. It’s fully open. There’s lots of distributions built on top of it by various companies. It’s quite modular. If you ever looked at OpenStack, you’ll see lots of crazy names, Nova, Neutron, Horizon, and what are those? Those are various projects that are focused on different parts of the cloud. So, you only need knowledge in one of those spaces to start getting involved. You don’t actually need to know about all of OpenStack when you’re going to get started. It’s very much business-to-business. The OpenStack foundation sort of controls direction, handles all the money and all the stuff going on, but it has a very strong governance structure but these people are elected from the developers. And, of course, it is supported by companies. Very few people work on OpenStack for fun. It’s something they’re usually paid for.

Nurturing the very technical community

So, in nurturing the community, OpenStack’s very technical. It’s all about gathering technical contributions, code reviews, and patches. There is, of course, documentation teams and other things, but it’s a very technically driven project. One of the things a lot of companies do, as we just heard from the last talk, was like financial support for events all around the world. So, we have like big OpenStack summits as well as smaller meet-ups, OpenStack days and things all over the world. And just like with every other community here, recognizing contributions is really important. So, it’s done in two ways in the OpenStack community. We do individual-style contributions where an individual can be recognized for the work that they’re doing in the community, but there’s also companywide because the companies who are paying money to support these organizations want their company name out there and want to be recognized for it. So, in this community, there’s sort of two levels of recognition. And that’s important to remember because you don’t always want to recognize the individual. Sometimes it’s companies who need to get these big awards to continue contributing.

So, to support this sort of community, again, since it’s such a technical project, you need developer advocates and evangelists who are very technical and you want them to be comfortable not being super loyal to the company that they’re working for. They need to be able to work with lots of different companies. So, when I worked on OpenStack, I worked for HP, but day-to-day I was working with people from Redhat and IBM. Like those were my actual colleagues. It wasn’t the people at HP. I never worked with them. I don’t even know what they did. So, that is OpenStack. So, we just wanna finish up with a few conclusions from this.

Judith: Yeah, so, the openness of your community should inform your approach to nurturing it. If you have one of those communities that’s a true old-school, open source model where it was built to be contributed to and its success or failure depends on that, then you need to nurture that community in a very different way than if you nurture one of these kind of more corporate, open source communities. Recognizing the type of community helps you target your efforts to things that are gonna get you the most impact for the structure and also the things that are gonna be the most effective so you don’t spin your wheels. And…

Elizabeth: Yeah, just recognizing contributions. It’s like important wherever you are. So, yeah, that’s all we’ve got. So, thank you.