Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2018 (Copenhagen), 14 Nov 2015

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Building an Open Source Community to Achieve Innovation-Through-Openness - Jonas Rosland

Description

Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18)

Building an Open Source Community to Achieve Innovation-Through-Openness - Jonas Rosland, {code} (Beginner Skill Level)

Building an open source initiative at a large enterprise such as Dell Technologies comes with both challenges and rewards. Making sure the community is engaged and that projects thrive takes time and effort. ""Innovation-through-openness"" around the world has proven that global collaboration on code and inclusivity of diverse intellectual contributions advance the technological state of the art and solve problems faster. In this session, Jonas Rosland, Open Source Community Manager at {code}, shares experiences, failures, and gives a glimpse into how large enterprises can embrace and lead open source communities successfully, and be involved in new trends that are impacting the global IT market.

About Jonas
Jonas Rosland is a community builder, open source advocate, blogger and speaker at many open source focused events. As Open Source Community Manager at VMware, he promotes and helps build communities around several open source projects.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.

A

All right, perfect, good morning, everyone, it's 11:55. So let's kick this presentation off. My name is jonas rosslyn, I'm the open source community manager for the cloud native applications business unit at vmware. This presentation is about building an open-source community to achieve innovation through openness. We're gonna go through a few different things today. So please, if you have any questions, we do have a Q&A session at the end. But if you have any questions during the presentation, just raise your hand I'd be happy to take those questions as well.

A

So the agenda today I got four different things that I want to talk about today. The first one is: why participate in open source I think most of you here are participating in open source in some way, but I want to make sure that you get some some even even more information about why it's important to participate within the open source space within different open source projects and communities and how it actually benefits you and your organization then, of course participating in the open source community. How? How do you do that?

A

What does that look like and what are some guidelines on what to do within the open source community? Because it's not just writing codes I want to make sure that everyone's aware of that, the the 13, a third thing I want to talk about is a little case study that we did for the code team before I joined VMware about a month and a half ago, I was the open source community manager for the Co team at Dell EMC.

A

So I want to share some learnings that we got from that experience of building an open-source team and building an open source community for almost four years, and then I want to finish off with some failures and learnings that I hope you can take away with you to make sure that you don't do the same errors that we did when we built out our team and built up. The community sounds good all right, so the first one first part here. Why participate in open-source?

A

This is taken from a survey done by Black Duck software, where they say that 65 of the companies that answer the survey are contributing to open source projects in some way. That's a lot of companies that are contributing to open source projects, and we saw that today at the keynote as well. This is a two year old survey.

A

They have been following up with the survey, but they haven't produced similar numbers yet, but it's it's really interesting to see that two-thirds of all the companies out there are essentially participating in open source in some way contributing code or sponsoring open source projects in some way.

A

What's even more interesting, though, is that 90% of those that answer the survey say that open source improves their efficiency, their interoperative interoperability and their innovation speed, so open source is definitely making sure that more companies succeed and not become like the juice company that we saw during the key keynote today.

A

When we built out the the code team, we talked to a lot of our users and customers and asked them why they were interested in open source software, why they were interested in utilizing open source software and why they were interested in contributing to open source software, and we collected all those answers and we essentially came up with four different answers that they had depending on their needs. The first one was the freedom to run software anywhere for any purpose. The second was the opportunity to innovate, develop and participate in open source projects.

A

The third one was the flexibility to choose the software and hardware that fits their needs and the fourth one was to be able to integrate software with existing infrastructure and, as you can see, I bolded four different things here: freedom, innovation, flexibility and integration. We call that Fifi.

A

Very, very short: nice acronym. That's easy to remember why our users wanted us to be us to be an open-source team and work with them within the open-source community.

A

So when you look at participating in the open-source community from an organizational standpoint, what's needed well, first of all, you need dedicated people, people that love the open-source community, people that really love engaging.

A

What the open-source community members people that love to contribute in many different ways and making sure that open-source projects thrive, not just writing code and pushing it over onto github, but actually building communities talking to people training, people making sure that everyone understands what the project is all about, how it fits into the ecosystem and how it can be used in a multitude of ways.

A

The second part here is management buy-in. This is really really important. I've talked to many of our community members, many of our partners, many of our competitors, and they all say the same thing- to be successful: to having a successful open source team and for an organization and a company to be successful within the open-source community. You need to have management buy-in.

A

That's really really important, because you're gonna spend a large chunk of your time that you're getting paid for doing open-source stuff so having management buy-in is really really important. Unless you want to just spend your free time doing it and not your primary job time, the third thing that's really important as well, is to have some well-defined goals making and creating an open-source team without goals and just hoping that it will work might be a little hard and I'll talk about that.

A

And when we go into the failures portion but having well defined goals, definitely helps you because then you can be more focused and make it more focus to effort. When you build out the team and try to find those dedicated people that you will be working with looking at established or establishing new processes are also very important, because you will most likely start doing things in a new and different way and having processes that that will help you to do.

A

Those things definitely helpful in the long run, because you can have a ton of dedicated people a lot of management buy-in. But if you don't have any processes you're just running around and doing a bunch of random stuff that might help or might not help so having some processes, even even if it might sound boring having some processes in place to make sure that you're doing the right thing at the right time definitely helps.

A

The the last portion here is, of course, being a good open-source citizen and being a good open-source citizen I think we all can agree as what we all strive to be.

A

So when we look at contributing to open source and contributing to the open source community, there are, as I said, a multitude of different ways. You can do this technical project leadership is always important, leading contributor communities. You can look at the the SIG's for kubernetes for this, for instance, making sure that contributors, new and old can easily contribute to the project.

A

Technical project leadership is also in those six making sure that the project is moving forward at a static pace by having a ton of smart people in these six, then of course, promotion of amazing people and projects that are maybe your open source projects. Maybe you have employees that are just amazing, open source people. They have created really cool things, make sure that they are promoted, not just the projects, but the people behind the projects, because everyone is an individual and everyone likes to be seen in some way.

A

So promoting both people and projects is really really important. Another important piece that we noticed quite early on was to have proper communication tools, having a project up on github and utilizing github as your only source for communication. With your users is really hard, because you will only hear from them when they have an issue or they have created something through a PR. You won't hear the the support questions.

A

You won't hear the the police help me questions so talking to your community using different communication channels might be blog post might be slack channels, IRC rocket chat, you name it, but having more communication channels than just your github repository is really important. So writing blog posts explaining what the project is all about.

A

Explaining the roadmap for the project in a blog post as well, can be very beneficial for the project, making sure that people know where the prod is going who's working on what and what to do with the project and maybe also how it fits into the overall open-source community.

A

Another one that I think we all see here that I find really important is making sure that you have proper artwork and I'm, not talking about just cute logos. Everyone has cute logos, I'm sure, you're gonna pick up at least a hundred stickers here from the conference, with a bunch of different logos for different projects and companies, and those are really important because that's a brand recognition but then also creating artwork, that explains the project might be diagrams, might be, flowcharts might be helping out building out the CNC F landscape.

A

Having someone that helps you create artwork for the project definitely helps you market the project better and helps people understand the project and recognize the project when it's seen answering questions from community members through these communication tools are really really important and as a community manager, I manage the communication tools but I'm, not a subject-matter expert on all the open-source projects that we have so I should not be the one answering questions. The ones answering questions would most likely be the developers first of all, and then the community members I can make that connection.

A

But I can't answer questions for everything, so making sure that your your development team, your project managers, your your testers, are involved with the community members and their questions is really important. Of course, keeping updated documentation make sure that all the documentation is correct. Make sure that you write documentation as you are working on the project and don't see documentation as an afterthought, because if you write and create a project- and you write your code, you push the code and then you're like. Oh, maybe I should have a readme they'll figure it out.

A

No one's gonna use your yeah here's your code, no one's gonna use your project because they have no idea what it does or how it works. And then, last but not least, of course, writing code is really important. Even though projects like no code from Kelsey Hightower, has what 20,000 stars and github writing code is really important and making sure that you have dedicated people that keep writing code and keep maintaining the code. Answering questions on issues and moving PRS along is really important, so it just doesn't die off.

A

The two next parts here is around building your credibility and being a positive contributor within the open-source space building.

A

Your contribute credibility is really important when you, when you try to create an open-source team or maybe launch a new open-source project, you want to be consistent in your vision of the projects that you're involved in it might be that you're involved in the technical leadership of a project, or it might be that you're the primary maintainer of a project but be consistent in your vision and don't just change the trajectory of a project, mid, mid release or mid work.

A

Make sure that you are consistent there and also be involved in conversations where you're supposed to have a presence. So the communication channels are really important to make sure you write those blog post and be in slack also be aware that individual team members have, of course, different behaviors and different contributions and different experiences be aware of all the individual team members, how they act within the open-source community and make sure that they are acting as a team and not just as individual contributors.

A

All of them make sure you have a coherent team that strives to do the best thing for the open-source community for that specific opens project and recognize positive contributions and thoughts, leadership in the ecosystem, again promoting people promoting awesome people within the the open source community.

A

When it comes to being a positive contributor, it's really important to respect open source software best practices when it comes to coding when it comes to documentation when it comes to management, and that can be kind of hard when you start out and you you might not really know what to what you're doing or how to do these things. So it's always good to reach out to other project managers or other contributors to other open source progress and ask them. How are they doing it?

A

Because that way, you can learn from others as well, listen to the community opinions and needs and don't just go your own route make sure you listen to them. However, I read somewhere along ago, a yes is forever and the know is temporary, so make sure that you don't just implement their their new contributions immediately, but make a real effort to think. How will this impact the project in the long run? If you say no to a contribution right now, you can always go back to it later and implement it later.

A

But if you say yes to a contribution right now that might have a major impact on your project so make sure you listen but don't be afraid to say no also collaborate openly on project strategies and goals again having a blog post or your road map up on a wiki on github somewhere where people can see what's going on, so it's an easy oversight. These are the things that we're working on within this specific project or this specific sub project of a larger project is really important.

A

Ensuring that you have a complimentary presence in the open-source communities is also important. You should not negate or detract something from the open-source community. You should always be a positive force within the the open source community and then also be predictable in delivering on your commitments. So if you commit to something and not just commit code, but if you commit to something- and you promise something within the community- make sure that you actually commit to that as well.

A

Next up, let's have a look at the the code team that I was a part of until just recently, we actually did a case study for the code team. It's part of the open organization workbook that you can find on open-source comm. It's a free download. You can also buy a physical copy for standard cost.

A

So if you want to check this out, the code team is in there among a ton of other, really really awesome, open-source team teams and they explain how they built out there they're open organizations, one a few of the things that we noticed, or rather a few things that we found were important principles when we started the code team was to make sure that everything that we did was in the best interest of the community. So all the efforts that went into the open source team was in the best interest of the community.

A

Of course, you always have a responsibility towards the organization that you and that you work for, but the community always comes first. The the project's should always be executed, with complete transparency and openness that comes to roadmap and also discussions around new features. So none of you users are surprised when all of a sudden there's a huge PR coming in with a with a major change that no one knew about, because you've been having all those discussions inside your own private slack or something like that.

A

Also make sure. We also want to make sure that all the open source technologies that we created we're made to be consumable by pretty much everyone all users that we talk to you and all organizations that we so to boswell.

A

So the the overarching code community that we built out was essentially built out of three different things, plus a few more and I'll go into those, but three different things. The first one was the slack team that we had, which is still online, and it has over 6,000 members currently and it's still growing it's one of the largest open source. Slack teams in the world not be largest. Absolutely not, but one of the largest open source focused slack teams in the world.

A

We, we ran programs to make sure that we had internal developers and partners that could easily open source their projects that they had been working on, either as a work assignment or on their free time. We wanted to make sure that they had an easy way to open source those projects, and we also promoted thought leading members of the open source community through another program that I'll go into here.

A

So the first one, the code community will launch this in June 2015, because we saw a need for us to be able to communicate with our open source interested people both inside the organization and externally. At first. We thought, maybe you will have 30 50 people something, and we reached that within the first two weeks, we're like oh cool. We have a lot of people in here awesome. It was mostly people from within our organization, but they wanted to know what we were. We were doing and hear more about our projects.

A

We were really stoked, so we set up a public website, so anyone could join and anyone could invite themselves. And then, two weeks later we were a hundred people like. Oh, there are a lot of people that wanted to hear what we were saying and have more conversations around open source. Just a few months later, we were a thousand people and more and more business units that were working within the open source space actually moved their entire development team into the code community.

A

So all the development from several open-source teams within the organization were being done in public for the first time ever for Dell EMC.

A

So we had a bunch of open dialogues across company boundaries, because this was open to everyone. We had partners in there, we had users, we had customers and we had competitors which was really interesting, and we actually had several discussions with competitors around our open source initiatives where they came with great feedback to us, and we were super thankful for that and that really showed what the open source community was all about.

A

I want to give a few slot a few slack best practices here and first of all, I want to give a big shout out to Kim McMahon, who sits here. She called me up last week and asked me to kind of talk about a few best practices when it comes to managing slack for a big open source community, so I answered, and then I thought you know what that could actually fit into a slide.

A

In my talk as well, you should definitely go and check out Kim's session today at 2 as well make sure you check that out and when it comes to social media engagement within open source communities. So a few slack best practices that we found out some after the fact and some before the first one automate the important things and one of the most important things was to make sure that everyone felt welcome to the the slack community that we have built out.

A

So we we did one thing that was really important to me and that was to have a welcome message for all new members that joined and remember. We had over 6,000 people in there a welcome message through slack bot using a simple zapier integration. Super super simple whenever a new member joins, send them a DM, and in that direct message we outlined what the community is about. Here's the link to the code of conduct that you just signed, because otherwise you wouldn't be getting the seem.

A

This message here are some project channels that you might want to check out if you're interested in these open source projects or if you want to you're looking for a job you can head over to the job board. If you want to post a blog post, you go to reading suggestions and so on, and so on. Super simple: everyone understood what the community was about and how to engage with the community, the second one we actually learned after the fact, which is a fail on our part, but turn off private channel creation.

A

This is really important because I as an admin as an owner of the slack team I, have no visibility with into those private channels.

A

No one does unless you're invited to them, and we saw a huge spike in messages in private channels and I have no idea what those messages were. So we quickly shut down the possibility of creating private channels and I reached out to the community and asked if anyone had created private channels and we finally figured out who who they were, and it was a development team and they were having a lot of private discussions and it's okay, fine, but let me know before you go out and do something like that.

A

It's really important to make sure that your your community is not being abused by external people for something that it should not be used for. The the fourth thing here is to make sure that you're being present and proactive. So again me as a community manager. I should not be answering all the technical questions, but rather encourage questions and discussions and then linking people together.

A

If I see a question regarding a specific open-source project, I make sure that they know there's a channel for that and a specific person, maybe that they should reach out to and I tagged that person to make sure that they're aware of this discussion. So they don't miss it. That makes it so much easier to connect people and also get the right answer there instead of me guessing. So it's really important.

A

The last one was something that we did from the beginning have a code of conduct, first of all, because otherwise you can't have a community in my mind, but also make sure that it is followed and enforced if needed.

A

We we recently had two issues. We had one issue where a community members started DMing a bunch of other community members asking them to decrypt an encrypted file and offering the monetary compensation for that not really cool, because we had no idea what the information was. The the person wouldn't give us any details.

A

So we essentially shut that down pretty quickly I to the individual and said this is not an appropriate behavior based on the code of conduct and based on the the the community itself, and they said well, I'm still gonna do this and they kept DMing users and we banned them pretty quickly.

A

The second one was a user that did a minor error. They used the slack community as a way to sending themselves images.

A

They were sending scanned images from one laptop to their phone using the general channel and all of a sudden, we see all these images of private information. Id cards documents like this should not be in here so reached out again. What are you doing? Whoa sorry I was just sending things to my phones like there are easier ways to do that than publicizing personal information to thousands of people, so ask them to stop doing that, and they were fine with that as well, but yeah.

A

These are a few different things that I really want you to be aware of when using slack or raka chat or another communication tool, like that. The second thing that we had was the dev high-five program, which we used for to launch open source projects out into the open source community going from in-house to open source in a very easy way, something that we worked with our corporate legal team to to create. So we had an easy way to open source new projects.

A

The the last thing, the last program that we created or the last big program that we created rather was the code catalyst program that we launched in December 2016, where we promoted open source focused individuals from all walks of life. Essentially, we ended up having 38 members from 26 different organizations in 10 different countries worldwide. It was a great community of people. They are still heavily involved within open source in and several of them are here at the conference today.

A

So I'm super happy to see them still walking around and being involved in the open source part.

A

We also made it a little more fun by having a smaller program assist one was the code, catalyst interviews where I interviewed these amazing open-source individuals. So you can see some some pictures up there, 101 interviews where I asked them, essentially how they got started with open-source and what they're working on and what their vision is were for the open source community for the next two years or within the open source community for the next two years.

A

We also did code webinars, where we had code, catalyst and other renowned open-source speakers talk about projects that they were involved in, give project updates and so on, and they, the last one that was really really popular, was something that we call the code assemblies. We had several hundred people that we invited to networking events essentially and everyone's invited. Everyone was invited to network with other open-source peers at different events that we held. The this picture down here is from Copenhagen. When we were at dr. Cohn.

A

Last year we had 50 people at war, pigs, networking and eating and having a blast so making it fun, making sure that you reach out to the the individuals within your community and making them feel special as well as really important.

A

Let's go into the the bad part here, the last and bad part, some failures and learnings.

A

The co team started as a grassroots project. We were a an innovative team of really dedicated people and we were essentially tasked with creating the open source team within EMC later Dell EMC, and make sure that the company was involved in in the open source community in many different ways. So we had a ton of really great people dedicated people, but we didn't really have a plan. Necessarily. We didn't really know how the company should be involved in open source that wasn't really clear.

A

So we tried creating a bunch of open source projects, threw them up on github and said: maybe we'll see if something sticks and eventually we we actually found a few projects that became pretty popular, one of which is Rex ray that you might have heard of so that became really popular and we found out that the container community was, of course, really innovative as well. So we wanted to tie into that one.

A

So we essentially created a plan after the fact after the team started to make sure that we were involved within the container space and heavily involved within the container space. Then we had other open source teams join the the effort as well, and they were involved in in other areas of the open source community. But we didn't really have a plan at the beginning and I think that was definitely something that that we should have had.

A

Another thing that we didn't have, because we didn't have a plan, was that we didn't have any metrics, so we came up with metrics again after the fact and of course that makes it harder to justify why you're doing this and why it's important to the business, because you don't have any metric to show. So after a while, we found out that we actually have some really good metrics.

A

We have community member engagement, we have open source project engagement, we have a code, a number of lines, written things like that blog post, published Twitter, Twitter followers and so on. So we found out that we actually had a ton of metrics that we could utilize, but we didn't know what those metrics should be from the beginning. So all of this all of this, the plan, the metrics, the the engagement models, the the the programs. All of that we had to write from scratch- and that was a lot of writing.

A

That was a lot of thought process going into actually building out this team and building out the community and building out all these plans and programs. So what I? What we?

A

What I would have loved to see are things that are actually accessible now there weren't a lot of open source teams that had shared how they were built four years ago when we started this now there are so there are a lot of great resources out there that I highly recommend you to check out if you're looking to get your organization involved within the open source space. The first one is the open source guide which I really enjoy I. Think it's a fabulous site.

A

It has a lot of great information and links to more information, after that. The second one is the Citizen code of conduct org, which is a great starting point. When you're looking to create a code of conduct for your community and your community engagement, the to do group is also heavily involved in creating guides for starting open source team and community engagement, so again highly recommended, and then the open source program office at Microsoft is actually having they actually have a lot of resources published as well VMware.

A

Of course, we are also involved with in the open source space in many ways. So if you want to check out how we are involved and how we are building out, the open-source teams within VMware I, highly recommend you to head over to via Mirage github, il also check out our cloud native and our open source blocks where we don't ascend chily talked about how we build out the open-source program office, the open source technology center and also the open source community engagement from the cloud native apps team.

A

Alright I got one minute left. Do we have any questions.

A

All right, well, it's lunchtime and I- want to thank you all so much for coming and I wish you all a great cucum. Thank you.