From recruiting and outreach to awareness and adoption, engaging with the open source community has a number of significant benefits, believes Cloudflare’s Jade Wang. She explains why building good will in the open source world is a wise business decision in her talk from DevXCon San Francisco 2018.
Hi, I’m Jade and today I’m gonna be talking about open source engagement, and the ammo you can take back with you to your employer to help you in that journey. So, a bit about my background and Tamao had done a great job talking about a lot of the recent things. I lead developer relations at Cloudflare, I founded a company called Sandstorm, I was at Meteor, and I started a network of hacker houses. But before all of that, my background is actually in neuroscience, main language being MATLAB. I’m gonna rewind quite a bit back to the ’90s.
So, who here was alive in the ’90s or remembers the ’90s? That is great. I am not old. So, when I was a little girl, I was a bit of an open source fanatic. I was a bit of a very like copyleft hardliner. And my father, who taught me to code didn’t see the world the same way that I did. And, you know, that’s a little bit of an understatement. You know, he lived in this very enterprise software world. He, you know, he worked for a big five consulting firm and they, you know, what would happen is some Fortune 500 Company would hire them, and the CIO, or the CTO, or the CSO had read a Gartner Report and said, “We need this thing and this is our checklist,” and his employer would have him go implement them.
There were a lot of things that we didn’t see eye to eye on when it came to the open source world and engaging with the open source community. And as a child, I always felt like, you know, you should do things for the right reasons, like it was just obviously correct that information wants to be free, and we would talk right past each other. And, you know, that’s no good because neither of us convinced each other of anything.
Fast forward to the world that we live in today. My world still looks quite different from my father’s world, right? Like, you know, he still uses the tools that his employer tells him to use and his ergonomics are more or less an afterthought. But more and more, my world has sort of started encroaching on his world, right? Like as much as I would like to think that I just make my own decisions in the ether, I’m actually very socially influenced, right? Coming out of the research world where my main languages had been, you know, MATLAB and R….you know, Ruby on Rails had been all the rage among my friends, and, so of course, it made sense to look at those tutorials. And then suddenly, Nodreas was all the rage among my friends and so, of course, you know, with the launch of media, it made sense to build a startup based on top of media.
And if I experience a lot of paper cuts, it was very easy for me to make changes based on my own ergonomics. And that has influenced the kinds of choices that I make and the kind of technologies that I choose based on my own ergonomics, based on my own preferences, based on what my friends have told me about because they have had good experiences with those technologies.
And the world in which I care about my ergonomics and recommend things to people in my father’s world, this is partly why developer relations exist as a field. So, I want to give this talk the correct framing so to speak. Everyone here works in dev rel in some capacity. So, you are in a very good position in your organization to champion forms of open source engagement, and of course, it is up to you, since you know your organization best, what’s going to work for your organization. But what I hope to do is provide you with the ammo that you need to champion open source engagement in your organization. And, you know, this goes back to things me and my father talking past each other. The real reason why I couldn’t convince my father at the time was companies often need selfish reasons, self-interested reasons to engage with the open source community.
So, I’m gonna start with one, recruiting. So, everyone here works in dev rel. How many people here in dev rel often interface with the recruiting team? You’re in a pretty good position to help them, right? Because you’re talking to developers all the time and they need to hire people. Well, you know what? Recruiting is a really great ally when it comes to open source engagement, because….let me tell you a little story. When Samsung was deciding which company to join, it all kind of falls back on some memories of, you know, how many of you have heard of Cap’n Proto? It’s a serialization protocol. Samsung was built on top of it.
It’s what my co-founder Kenton had written to replace protocol buffers after leaving Google. And it’s infinitely faster than protocol buffers. Engineers at Cloudflare had contributed two different language implementations of Cap’n Proto. One in Go and one in Lua. And not only had they made code contributions, they wrote blog posts about it and talked about it at conferences. This brought Cloudflare to a higher level of awareness to us than every other competitor, right? Like, Cloudflare was very much top of mind, and when it came to the decision of whether we were going to join Cloudflare or another company, you can bet this very much put Cloudflare at the top of the list. Positioning the org as an attractive place to work is very, very, good for your recruiting team.
And so, to the extent that open source contributions are, you know, encouraged, you know, you have internal projects that could be useful to a bunch of other people, and your internal engineers get to open source that, that is incredibly powerful as a recruiting tool especially when they’re able to talk about it. And it’s also great for the careers of the engineers who have written those projects. There’s another story. I have a few friends who work at ThoughtWorks, which is a large consulting shop that does projects for clients. And one of my friends there, her main role is QA so, you know, she finds a lot of bugs and files issues. She comes from a math background but she really wants to be a web developer. And one of the things that ThoughtWorks did, I think is really admirable is, you know, when their employees are between projects, and in her case, she is…you know, her main role is QA, they didn’t feel like she was ready for web development projects yet. Because she had some downtime between projects, she could work on open source projects in capacity as a web developer and that allowed her to level up her skills.
And so, the fact that they did that as an employer, you know, making code contributions with extra employee time that was between projects, that was really good for her career, and as a result, she also told her friends about it and they, therefore, want to work at ThoughtWorks more, because it was good for levelling up their skills. So, yes, open source. It makes your organization a much more attractive place to work.
So, another thing that your organization is probably very interested in is its own survival, and stability, and the dependencies that it has. Now, a lot of open source projects that are key pieces of infrastructure that make the internet continue to function are often volunteer-run and, you know, written by one or two maintainers on a volunteer basis and it’s not their full-time thing necessarily. And what would happen to your organization if they didn’t have the time or resources to fix a security hole, right? What would happen if they were to suddenly…if there was a bus factor? Your organization can do things like financially support some of these projects directly through a nonprofit called OpenCollective, for instance.
They can also do things to upstream their paltriest and make contributions to the projects that they depend upon. Engineers at Cloudflare have gone out of their way to let me know about which projects we depend on, and I reach out to them and give them free upgrades. And I’ll talk more about that later, but if there are projects that are in the critical path for your organization, and you’re gonna have a bad day if something goes wrong, then, yeah, your organization should help them out and you probably have a lot of allies in the engineering org if don’t already report it to the engineering org to help you out in that regard to help out the projects that you depend upon.
And thirdly, widespread adoption, right? This sort of like awareness. So, you know, when… In my father’s world, he uses whatever tools he is exposed to because his manager told him to use that set of tools for the job to implement the project. In my world, I use tools that I’m already comfortable with when I’m starting a new project, right, like I use a link which is a language I’m already familiar in. And in the case of open source community engagement, if, you know, like if a student or, you know, or if I’m talking about myself, I got familiar with a particular toolchain, a particular workflow because of contributing open source projects because they’re already using those things. You know, I am much more likely to use the things that I’m comfortable with. So, there is a very good awareness factor in giving free upgrades or doing that kind of open source engagement just giving away your product to the open source community because in a generation growing up that is, you know, my world compared to my father’s world, we are heavily socially influenced. And the social influence of open source projects is by the very nature of their collaboration.
And this is especially true for developer tools and things that you might use in your workflow, any kind of product management software, any kind of bug reporting tool. Those things are all… It behooves you very much to engage with the community.
So, hopefully, I have, at this point, made the case for open source engagement and generosity within your organization. The specifics of your org, and the specifics of the products in your org, and what you can or cannot give upgrades to, those are gonna be dependent on the culture of the organization in which you work. But we should totally have a discussion afterwards about what good ammo has worked for you.
Feel free to make note of these, but there’s a lot of ways that you can support the open source community in addition to just free upgrades or code contributions. You know, we buy pizza for meet-up groups that are open source, that are based around any open source technology. You can help them with filing bugs, you can give them designer time. I know that lot of open source projects just don’t have the design talent, so like, make them a nice logo. It’s cool. You can support them directly through an organization like OpenCollective. And there are a lot of other things that you can do that I haven’t necessarily just like listed up here. And not all of them have to come from your dev rel budget, right? Like for instance your free upgrades, like they don’t necessarily impact your dev rel budget. So, there are a lot of things that you can do without and having to make a lot of tradeoffs.
And before moving on, sometimes you might get some potential concerns from the organization as you champion like, “Hey, we should give our product away.” Because what if you are cannibalizing revenue, or like how do you address those kinds of concerns is a thing that frequently comes up. And, you know, there are a lot of open source companies that, you know, like that are VC-backed startups in a growth stage, and how do you separate the crunchy granola open source projects from the larger enterprises? And there’s a number of ways you can do that. For instance, you can filter by nonprofit or 501C3 status, but that is quite limiting because what if they’re not US-based or what if they are a very young project? What if they are just a repo and they don’t actually have an org structure yet or is like one or two people somewhere?
Volunteer-based is also another very good way to filter. It’s a safe line to draw in the sand but it could be a little bit on the conservative side. You could also do things on a case by case basis. That is much more time intensive for your dev rel team, but it goes a lot faster if you just have clearly written rules for what passes or won’t pass the filter. An example…so Cloudflare gives free upgrades at pro-level for open source projects. If it’s a nonprofit or if it’s volunteer-run, it will qualify and if it’s a developer tool or serving the developer community, it qualifies.
So, anyone here a maintainer of an open source project? Sign up for your free upgrade. Parting thoughts. So, this doesn’t have to stop at open source engagement, right? like you could actually take on other causes that are important or pertinent to your organization, right? You could be helping out net neutrality, for instance, or, you know, at Cloudflare we also have Project Galileo and the Athenian Project where we also give free upgrades for governmental entities in support of democracies. So, for elections, which is the Athenian Project and also organizations that are at risk for…who are working on civil rights or human rights. So, if you have friends who are working on causes that might qualify for either of these, let them sign up.
All the fun stuff happens with shiny new tech, right? Nah. You can get audiences excited about older tech, if you serve them well.
Are dev rel teams just here to make everyone feel good about using a technology or is there a deeper responsibility?