VM (aka Vicky) spent most of her twenty-plus years in the tech industry leading software development departments and teams, providing technical management and leadership consulting for small and medium businesses, and helping companies understand, use, release, and contribute to free and open source software in a way that's good for both their bottom line and for the community. Now, as the Director of Open Source Strategy for Juniper Networks, she leverages her nearly 30 years of free and open source software experience and a strong business background to help Juniper be successful through free and open source software.

She is the author of Forge Your Future with Open Source, the first and only book to detail how to contribute to free and open source software projects. The book is published by The Pragmatic Programmers and is now available at https://fossforge.com.

Vicky is a moderator and author for opensource.com, an author for Linux Journal, the former Vice President of the Open Source Initiative, and a frequent and popular speaker at free/open source conferences and events. She's the proud winner of the Perl White Camel Award (2014) and the O’Reilly Open Source Award (2016). She blogs about free/open source, business, and technical management at {anonymous => 'hash'};.

Links

Mike Julian: This is the Real World DevOps podcast and I'm your host Mike Julian. I'm setting out to meet the most interesting people doing awesome work in the world of DevOps. From the creators of your favorite tools, to the organizers of amazing conferences. From the authors of great books, to fantastic public speakers, I want to introduce you to the most interesting people I can find.

This episode is sponsored by the lovely folks in InfluxData. If you're listening to this podcast you're probably also interested in better monitoring tools and this is where Influx comes in. Personally I'm a huge fan of their products, and I often recommend them to my own clients. You're probably familiar with our time series database, InfluxDB, but you may not be as familiar with their other tools. Telegraf for metrics collection from systems, Chronograf for visualization and Kapacitor for real time streaming. All of this is available as open source, and they also have a hosted commercial version, too. You can check all of this out at influxdata.com.

Hi folks, I'm Mike Julian your host for the Real World DevOps podcast. My guest this week is VM Brasseur otherwise known as Vicky, an expert in open source strategy and the author of the book Forge Your Future with Open Source. She's previously the Vice President of the Open Source Initiative and currently Director of Open Source Strategy at Juniper Networks. Well Vicky thanks for coming on the show.

Vicky Brasseur: Well thanks for having me Mike, I'm very happy to be here.

Mike Julian: I want to start with a seemingly simple question, but I have recently learned in the past half hour that this is more complex than it seems. What is open source?

Vicky Brasseur: Yeah, can't imagine how you learned that. No, it's a question that a lot of folks in technology think they know the answer to, but unfortunately they're usually wrong. That's because they usually don't realize that there is a legitimate definition of what it means to be open source software. It is called the open source definition. It is maintained by the Open Source Initiative. If something does not adhere to each of those 10 points on the open source definition, it isn't really open source.

Unfortunately people just sort of assume, well if my source is out there, if my source code is out there, it's open, right? Well, not really, because if you restrict it in any way or if you don't put an appropriate license on it, then people don't know it's open source. If you just put your code out there without a license for instance, it's all rights reserved. You have the copyright over that code or your company if you developed it for your company. It's all rights reserved as far as copyright and no one else can use it, unless you put a license on and that's what the license does for you. Only an open source license, one that is approved by the Open Source Initiative, that's the only kind that you can be assured actually gives you all of the things that the open source definition guarantees.

Mike Julian: What's really interesting about that is, there's always people that go around GitHub onto like the main project and say, "Hey, I noticed that you don't have this license, you should really have a license file." I'd always thought that that was just kind of an oversight, like, "Oh yeah, it's fine, it's totally open source. There's just no license. There's no license file." What you're actually telling us is that, if you don't have that, if you haven't specified what license this is under, by default it's not open source. Like, it is “all rights reserved.”

Vicky Brasseur: It is, exactly. It is all rights reserved. The best you can call it is source available. You still retain all of the copyright over that, and therefore it is all rights reserved. You retain all rights to that code, no one can use that software at all unless you give them the rights to it. That means somebody could use your software and put themselves at legal risk by violating the copyright of your software and you. If you don't put a license on it, that's what they're doing. Therefore, they are at legal risk, they can get sued and if they are running a company and they're using your software, they can't really get acquired frankly if they are using software that is encumbered by somebody else's copyright. That's why it's so important for multiple reasons to make sure you have a license on there. It really takes care of all those legalities. It's a relatively short list of OSI approved licenses, you've got the Apache and the MIT and all your GPL flavors and LGPL and AGPL and yeah. There's a bunch of them and they cover a broad swath of things. If you just use one of them, you don't have to care about the legalities, somebody has already taken the time to figure that out for you.

Professional lawyers have written these things, gotten them approved by OSI. You know they give you everything from the open source definition and you know it's legal. Just use it. It's pretty easy.

Mike Julian: You just named off a whole bunch of different open source licensing. I'm always confused when I release a project, like what should I license this under? Screw it, I'll go with MIT or Apache and call it a day, and I never really put any thought into it. There's a lot of these licenses, so presumably I should probably be putting more than two seconds of thought into which of them, if I'm even doing open source at all.

Vicky Brasseur: It depends. I mean if you're a business, you're going to put a great deal of thought into this, because you have specific business requirements and strategic needs for releasing that software at all. If you don't care, put GPLv3, put MIT, just slap that on it and throw it over the wall. If you don't care, don't think about it. GPLv3, MIT, that's great. If you care about software freedom, if you care about the morality of allowing other people to look at and manipulate and redistribute your software, use a copyleft software, use GPLv3.

If really you could not give two farts about that, then put MIT on it and just get it out there, but license it appropriately otherwise you're screwed. If you really have a lot of other considerations as far as a some sort of patent concerns or something like that, that's when you need to take it to your lawyer and have them look at it and figure out strategically what makes the most sense. If you're just an individual, default to GPLv3, default to MIT, you should be fine.

Mike Julian: It sounds like there's actually a whole lot more to open sourcing something than just slapping a license on anything you throw in GitHub.

Vicky Brasseur: Yes.

Mike Julian: Especially if I'm a company.

Vicky Brasseur: So much more. I mean if you're an individual even, it's very important that you do more than just a slap a license on it. I know I've been saying that the past I know five minutes, just slap a license on it and move on. Unfortunately it is slightly more complicated than that, but not much. That's because most softwares compose of multiple different pieces of code. You've got this module, that module, this library, that library. Now with open source as you release it, someone doesn't just have to take your whole package and move on. If they want they can cherry pick individual pieces of your code. They could just take one module if it does what they want for instance.

Now if all you do is you slap a license file in that repository, then you walk away, if someone just takes that one piece of code, then later on when they're under a merger and acquisition situation for instance, that piece of code is going to be found. Nobody will know where it came from. You won't have some sort of path showing that oh I wrote this. You won't be able to prove it via version control and you won't have a license file. You won't know who wrote it, you won't know under what license you're using it, so you're going to be in a big buying depending upon the software. You might have to completely re-architect to get that out of there or rewrite it or something like that. You don't have that copyrighting encumbrance, because while it was originally open source, you don't know where it came from, you don't have that provenance.

As you are releasing software, make it so much easier for everyone. At the very top of each file, I know and developers roll their eyes every time I say this, but come on people, we have tools now that can avoid this. You can zip that up, and you don't see it. At the top of your file, just have a commented out section, which is a simple copyright statement. Copyright Mike Julian 2019, done. Then underneath that you put licensed under GPLv3, say that. Those two lines at the top of every single file you know now if that file gets lifted out and used elsewhere, somebody will know under what rights they are allowed to use it and who wrote it.

They have their legal butt covered because you have put a copyright and a license statement in there. Then you have the full copyright file elsewhere in your repository. I have a nice big section on this in my book and how to release your software as an individual. As a company, yeah, there's a lot more concerns. I personally at Juniper, I don't want to release software A, if it has IP concerns that we can make money off of. I need to talk to legal, I need to talk to the product teams. I need to figure out how to get this released appropriately, because just throwing it over the wall as an open source project but appropriately licensed is one thing. My company is not going to get any benefit out of it if we don't treat the community properly, if we don't actually engage in it. All we're going to get is people looking at it and saying, "Yeah, hey look, Juniper released code isn't that cool." There's a lot of benefit in that, don't get me wrong, but there is so much more benefit in building a community of users and of contributors. That can gain companies a great deal.

Mike Julian: Yeah, that makes a lot of sense. I've definitely been in companies where they have a strong culture of being and working in the open source community. They have software they've open sourced and they're maintaining it. There actually growing communities around it and that brings them so much good will in the community. Not to mention it brings them more business as well as recruiting. It's a huge recruiting magnet too.

Vicky Brasseur: It's a massive recruiting magnet. Why would you not do this appropriately and build a community for recruiting alone?

Mike Julian: Right.

Vicky Brasseur: I used to run software engineering departments at the BP level in various companies. The amount of time and effort and money that goes into the recruiting is spectacular, depending upon the whatever employment firm is putting up the study. It can be anywhere from 150 to 250 or more percent of that person's salary. That's how much it costs to replace them. A, you want to manage appropriately so they don't leave in the first place, so you don't get that 150 to 250% hit on their salary. Also, you want to make it as quick and easy as possible to get the right person in there.

Now if I'm using open source software strategically within my company to build my products, and I'm releasing software appropriately and I'm engaging with all of these communities in an authentic way, then what I am doing is I am meeting a lot of people who already are familiar with my stack. Who already know ECO and Kubernetes and name your flavor of the week. They'll know that and they'll know my company. When I come knocking saying, "Hey, I have an opening," I'm going to have people lined out the door. Not only will they be more qualified to come on board, but since they already know the stack, their onboarding time is dramatically cut. Therefore, they can get more productive more quickly because they already know the software. They don't necessarily know all the special little delicate snowflake things of my stack, but they're familiar with the software. I don't have to teach them YAML and stuff like that. I'm not going to get there is my company isn't being an authentic community member in the free and open source software communities that my company is using and participating in and really relies on.

Mike Julian: Right. You've been talking about these concepts of open sources strategy for years. It sounds like a lot of what we're just now discussing is part of that idea, like the open source strategy is there more to it?

Vicky Brasseur: Yes. What a leading question, yes, oh my gosh.

Mike Julian: Yes. What else I'm I missing? Please tell us more.

Vicky Brasseur: I mean there's using open source software. If you look at the various studies out there, it's anywhere from 70% to 90% of the software that's being used and written right now is relying on free and open source software in some way. We're not just simply counting Linux in there, but it's everything else. It's the entire node ecosystem and it's Python and it's PHP, it's everything. It's huge. Everything relies on free and open source software. That frankly, that's not really strategic. That's just a gimme, yeah, whatever. You're going to be using free open source.

Mike Julian: Of course, we're going to use Apache.

Vicky Brasseur: Exactly, right, exactly. That's what we're going to do. Everyone does this. It would be stupid for us to roll our own at that point. Like are you going to roll your own SSL libraries? Not if you're wise and that sort of thing. You're going to use …

Mike Julian: I sure hope you aren't.

Vicky Brasseur: Oh please and if you are, stop now. Just stop, back away slowly. You know you're using these things, but some of them are more important than others. What makes the most sense for your business to be looking at, to be investing in, because you could just throw money and people and time at every single thing you're using your stack, but that doesn't make a lot of sense. You have due diligence you have to perform and you have to look at this strategically. It's not just releasing software strategically such that you can get the benefits of it, but it's also supporting software strategically. It's contributing to software strategically. You have to know how to do that properly and how your people have to be trained appropriately. You have to have policies in place for compliance and various things like that. There's just so many different moving parts to doing open source well from a business point of view. A lot of companies think they know how to do it and as a now former, thank you Juniper, free and open source software business strategist, I'm here to tell you most companies do it wrong. They're putting themselves at massive risk. They just assume they know what they are doing, but it's as though they learned about open source software like most open source practitioners now learned about it via the telephone game.

They heard from someone who heard from someone who heard from someone who heard from someone, who heard from I don't know Stallman 40 years ago this is what it's about. Therefore, they know what they're talking about, and I'm sorry they don't. They just don't. There's a lot to this to do it properly.

Mike Julian: I guess on that note, shifting gears a little bit, let's talk about open source business models. This has been a hot topic in the news in the past couple of years with Amazon trying to kill Mongo in the names of trying to kill Elasticsearch. Well basically Amazon just trying to kill everyone. What's going on with these concepts of an open source business model, why are people suddenly changing their licensing now, what's going on there?

Vicky Brasseur: You can't see me gritting my teeth because this is radio so to speak. There is not now and there never will be an open source business model full stop. People who say there is know absolutely nothing about business and my goodness it's difficult not dropping F bombs right now because I'm pretty passionate about this subject. There is no open source business model. Open source is one of the many tools you use to make your business successful. Just like any other tool you're using, just like your marketing team, your sales team, all the tools you're using, sales force and the people who are cleaning up your office, they're helping to make your company successful. Your support team is incredibly useful that make your company successful. Open source software is just another one of those things.

If you as a business are going to release your secret sauce and you're going to put it out there for the world to see and take and put it under an OSI approved, free and open source software license. Then you're going to get your knickers in the twist because someone else takes it and does something with it, I'm sorry, the license you put on there, you have given them permission to do this. They're doing exactly what you told them you could do. It is not their fault if you can't run a damn business. If they take this open source software that you have released and they make a more compelling business and product offering out of it than you do, that's not their fault, that's yours. That's you not listening to the market. That's you not listening to the users. That's you not able to deliver on your particular business prospect. That's not the fault of open source, you've got to learn how to do some business honey. There is no open source software business model, there is only business models. Open source is one of the many things that can help contribute to a successful business model. Sorry I did say I was a little passionate about this.

Mike Julian: I really wish I had an applause sound effect right now would be great. Yay, like that was all very enlightening. There's no such thing as an open source business model, instead we use open source as a technique for growing our business, but really we still need a business model to begin with. Open source is just a component of that.

Vicky Brasseur: Yes.

Mike Julian: Looking at companies like, I really don't mean to be calling out Mongo and Elasticsearch, but they're the two most recent ones. In those situations, I actually read this too, what should they have considered doing instead of as you say getting their knickers in a twist over something they told the market was totally fine? What is the other option?

Vicky Brasseur: Well, I can't say specifically what these companies could have done or should have done because I don't know what they did do.

Mike Julian: Let's come at it from a different angle rather than telling some other company what they should do. Let's say that I'm writing some software that is kind of along the same lines of I want to open source it for the world to use and use that as a lead gen to sell my commercial offering. You know that sounds an awful lot like what everyone else has already been doing and now they're getting their lunch eaten. What are my other options? What else could I consider?

Vicky Brasseur: Well there are multiple business aspects that you could take there. I mean yes, a lot of other companies are going the open core model and there's not necessarily anything wrong with the open core model. Now for the listeners who don't know what that is, it is essentially where you have the core of your software be under a free and open source software license. It's freely available. Then you can have an enterprise version that you sell that has value adds on top of it. You have your core version that's free and anyone can take and do it with. Then you have your enterprise version that people pay for and they get increased support or they get more features and they get more speed or more seats or whatever it doesn't matter what it is. That's part of your business model, that's part of your business.

There's nothing wrong with open core in that way, that's perfectly fine. Part of what these particular companies are complaining about is as you mentioned earlier, saying that other companies are eating their lunch by taking these things and not contributing back to the software itself. I am going to take your database software and I'm going to have another offering. I'm going to build a better product on it, and so I'm going to take your customers. That's fine, and that's perfectly okay, but using that software and not getting back to it is kind of dirty pool. The free and open source software world we call that the free rider problem where people are using the software and not contributing back.

Now these companies that are recently switched licensing and said, "Oh my gosh open source business model doesn't work," yawn whatever your business model doesn't work, there is no open source business model. It's like saying unicorns don't work. They all complain about this, but none of them have ever once said, "And here's how we reached out to these other companies and ask them to contribute to the community." None of them have said, "And here's how we ask how we can make it easier for them to contribute to the community." None of them are talking about the attempts they have made to try to get other community members. Frankly if you look at their repositories for their core software, it doesn't look like they've done that for anyone. You can't point fingers at a large bookstore to the north of me saying that they've been doing bad things.

If you haven't been running a good community, if you are just doing things where you are the only people who are playing in your little sandbox, you're not letting anyone else in. Then you really get pissed off if someone else builds their own sandbox next door out of the same sand you're using? I'm sorry that doesn't make any sense to me. If you want your free and open source software project to be successful, you have to build a good community around it. That means reaching out rather than expecting everyone else to reach in. Meet the people where they are and try to figure out how you can make it easier for them to become a part of the community, because that becomes the rising tide that lifts all boats. How many metaphors could I throw into this particular rant? A lot of them.

Vicky Brasseur: That's something that I think a lot of companies do very, very poorly when they release the software, is they just assume if I release it they will come. No, that is not what happens. Community takes time, community takes effort. If you want your open source software to benefit you more than just word of mouth of look at them releasing something, you have to put a lot of effort into it to get it right. Sorry little mini rant there.

Mike Julian: It sounds like the community is really the core facet of all this. If you want good software and you want people to really like using your software, you need to build a community, you need to foster that. What are some tips for, if I'm launching an EP software, how can I grow my community from there?

Vicky Brasseur: How do you grow your community? Well there's lots of different ways to do this, and Mary Thengvall has a really great book that's come out recently that's related to community. You should check that out. It's officially about developer advocates, but there's a ton of community work in that and Mary does really great work in community. She is your community specialist. However, being a free open source software for 30 years now, I have picked up a few things about community, so I feel more than qualified to talk about this. Number one, documentation for love a dog, write everything down, document all the stuff. Documentation is going to scale so much better than your developers. Make sure you have stuff documented before you release it. By stuff, I mean how to stand up your developer environment, how to get started. Why would I even want to use this software, here's our glossary and very importantly how do we contribute? How do I as a user of your software, how do I show up and even just make a simple bug patch? How do I send a documentation patch? How do I do even the simplest stuff? Where do I communicate with you?

Document all of those things as well and really just throw open the doors. Also, it's absolutely vital, it's table stakes now and people who say otherwise are probably jerks you don't want in your community anyway. It's table stakes to have a code of conduct and to enforce it, because if your community, if your project is not friendly to people, if it doesn't treat people with the basic level of respect that a code of conduct and allows them to be insured, then your community is not somewhere that anyone wants to be at which means you don't have a community, you have a cesspit. Get a code of conduct, learn how to use it.

Mike Julian: Completely agreed.

Vicky Brasseur: Yeah. There's many different other things you can do as far as building community, but those are some of the starters.

Mike Julian: Yeah, those are some really great tips. Shifting gears a little bit, you and I were talking before we started about this, we started this call about a concept you've been talking about called open source sustainability. Could you tell us more about that? What's your idea?

Vicky Brasseur: This is a big buzz word in free and open source circles lately is all about making free and open source sustainable. This started, well we've been kind of been talking about it for a long time, because of this whole free rider problem. With free rider you can't see my air quotes, but that's been something that we talk about in free and open source software for a very long time is people using, but not contributing back. That's a problem and that's something that we can potentially work to not fix, but at least shift a bit. That's something, but this is really, we've been talking about that for a long time.

A few years ago Nadia Eghbal came out with a study through the Ford Foundation called Roads and Bridges. It was about I guess the crumbling infrastructure of free and open source software and how so much of what we use is not well maintained. That's led to a lot of conversations around this. We've all seen problems with this around openSSL and heartbleed how there just weren't enough people there to go maintaining it. They were just killing it themselves almost literally to maintain this off.

Mike Julian: Yeah, turns out it's like one person is kind of doing most of the work.

Vicky Brasseur: There was a lot going on there. When that started the conversation around, what does it mean to make sure our free and open source projects in which we all rely because we've all built our businesses on them, what can we do to make sure that free and open source software is sustainable and will stay around? Frankly to me it's a business risk to be using something that's not maintained.

Mike Julian: Absolutely.

Vicky Brasseur: I can't put my company's money into something that I can't guarantee is going to be maintained for a long amount of time. Now because we're in technology, and because most of technology is run by VCs, most of the conversation around open source sustainability has focused laser, just laser focused on money. What we're going to do is, we're going to get a ton of money and we're goin to pay these maintainers. If we pay these maintainers, it'll all be better because money fixes all the problems. What money doesn't fix technology does and no, no, for crying out loud, no that's not the only way to solve this problem. This is a social problem as well as a financial problem.

I have, in the past, managed a team where people were paid to contribute to free and open source software projects. That's all they were paid to do, is make these open source projects better and whatever makes sense for you. These projects were very strategic for the company. Made sense for the company to be paying people to make these strategic things better for them, which was brilliant for the company. I'm really glad they did that, but at least one of those people was the only maintainer on an absolutely vital piece of internet infrastructure. Like something that ran so many different things. I know exactly how much this person made because they reported to me. I also know that throwing more money at the problem was not going to solve the fact that they were working 70 to 80 hours a week to try to maintain this. That is not a money problem, that is a resourcing problem. It's a standard sort of management issue. What we have to do if we want things to be more maintainable is you fix that, you fix that bottleneck. You fix that incredibly horrible bus factor of one. That's what you have in a lot of free and open source software project.

Now how do you fix that? Is you as a company need to contribute back. By contributing back I'm not just talking about throwing money at the problem, you have to contribute resources. Those resources can be human, they can be technological for servers to help scale things out better. They can be more people to document, they can be people to design. They can be people to market. It doesn't matter, but get these vital free and open source software contributors support and that support is not necessarily money. Money helps and certainly all these people would love to get paid more and get paid full-time to work in their free and open source software projects. It's not going to help if they are still the only one, and they're still working 80 plus hours a week to save your ass sometime. Give back and contribute to, and learn how to contribute to these projects, which is where I'm going to plug my book frankly because we didn't talk about this, but I'm going to do it.

Mike Julian: Please.

Vicky Brasseur: It is the only book on how to contribute to free and open source software projects. If people don't do this properly, free and open source software will not scale. It is growing at millions of new open repositories in GitHub alone every single year. That's just GitHub, that doesn't count GitLab, that doesn't count Bitbucket, that doesn't count all the things that Apache and all these other projects are running. Millions of new repositories every year, who's going to maintain that? We need to train people how to contribute to open source software and that's why I wrote my book. Otherwise, we are going to collapse under our own weight. Please learn how to do this.

Mike Julian: On that note, where can we find your book?

Vicky Brasseur: Where can you find it? Will there be show notes?

Mike Julian: There will be show notes.

Vicky Brasseur: Okay, good, well there will be a link in the show notes then. The link which will go directly to my publisher is fossforge.com, so F-O-S-S-F-O-R-G.com and that will go directly to the Pragmatic bookshelf page for this. I love the Pragmatic folks.

Mike Julian: Wonderful.

Vicky Brasseur: They've been so amazing to work with. If you ever need to write a book, man go with them, they're so fun.

Mike Julian: Yeah, that's great to hear. Aside from your book, where can more people find out about you and your work?

Vicky Brasseur: Oh about me, well they can go to my blog which is anonymoushash, one word .vmbrasseur.com. You can also just find it from my website which is vmbrasseur.com and I do way too much of the twittering, so that's probably the best way to keep up with all the things that are on my mind right now. You're not going to see this is what I had for lunch or OMG look at the cute kitties. That goes on a different Twitter account, but you will hear all about …

Mike Julian: Open source all the time?

Vicky Brasseur: Yes, this one is open source all the time, management all the time. It's a lot less dull than that, but trust me, I hope.

Mike Julian: Yeah, all right. That's awesome. Well thank you so much for joining us, this has been an absolute pleasure to have you.

Vicky Brasseur: It's been super fun. I love talking about this stuff and I'm very grateful for the opportunity to do so.

Mike Julian: Well thank you. To all our listeners thank you for listening to the Real World DevOps podcast. If you want to stay up to date on the latest episodes, you can find us at realworlddevops.com and on iTunes, Google Play or wherever it is you get your podcast. I'll see you in the next episode.