Please introduce yourself.
Hi! I’m VM Brasseur, but because we are all friends here, you can call me Vicky (the virtual machine jokes have gotten old). I’ve been in the tech sector for more than a couple of decades and in free and open source software for more than thirty years. I’ve been all over the place in free and open source: former VP of the Open Source Initiative, current vice chair of the board of directors of Linux Professional Institute, and more.
While all these things sound all fancy and highfalutin’, I’m pretty casual. It’s important to me to do important things and things that matter, but do them in a friendly, approachable, casual way. This is why I think working with Prag has just been so lovely: they have a similar philosophy. Do things that are meaningful, and do them in an approachable way.
Tell me about the book that you wrote for Prag.
Ooh, the book. First of all, never befriend a book editor, because he will absolutely convince you to write a book. My editor, Brian MacDonald, is a fantastic human being. Brian came to me, saying, “Hey, Pragmatic is interested in a book about how to contribute to open source software.” Brian and I had been friends for several years by then, so he knew what I did, my capabilities, and that I knew how to write. It took me a couple months to finally say yes, but I did. So far it’s the only book currently in existence all about how to contribute to open source software.
But it’s not only about the how, it’s also about the why. What can you get out of this? How can you make not only the free and open source software ecosystem better through your contributions but how can you make your life, your career better? How can you do things to scratch your own itches while also helping others?
The book is inclusive of all roles for software development. One of the things that we in software dev tend to do is focus on just programmers, just the people who are slinging the code around. And they are absolutely vital to the process, but they’re not the only ones. Any successful software project needs multiple roles in there. You’ve got documentarians, and program management, and security, and infrastructure, and accessibility, and design, and just all sorts of different roles.
This is important to me because I’m very invested in having a healthy open source ecosystem. It’s important to me that those projects, similarly, be healthy because otherwise you get toxic and difficult projects that really pollute the overall ecosystem. To have a healthy ecosystem, you have to support all of the roles for a successful open source project. So the book is inclusive of that. It works very well for programmers, but it works just as well if you are a user interface designer, for instance.
The book doesn’t get into a lot of the really technical nitty gritty things because, frankly, you don’t need that. I’m not going to go out there and write a book about how to use GitHub to send pull requests. GitHub has already done that. They have plenty of documentation that can show you how to use their interface. What my book will tell you is why you would want to do that. Also, what are the unwritten rules of interacting with open source communities? The ones that people expect you to know when you show up, and then when you transgress that rule, they get really angry even though they didn’t bother to tell you what the rule was to begin with. So it really helps you to do better, without transgressing on those unwritten rules. Because now they are written. Yay.
There are the phrases “open source” and “free and open source software.” What are the differences between these, and what are the philosophies that drive them?
This is actually chapter one. I had a conversation with Brian about this when I was writing the book. Because he doesn’t come from my world, he doesn’t understand how confusing these terms have become over the years, and how many times I’ve had to explain to people what they are. So if you set the Wayback Machine, Sherman, to the 1980s or so, that was the beginning of free software. Free software came first, and it has the underpinning philosophy that software should be free, and that this is for the good of mankind. It has something it calls the four freedoms. Four freedoms of free software. You have the freedom to run, study, modify, and share the code of any software.
This is not simply something that’s good to have. This is something that is absolutely a moral imperative. That’s really what free software is. It’s freeing the software, allowing everyone to run, study, modify, and distribute the code. That is a human right.
Now, free software started to get a lot of adoption, and started to get a lot of really interesting things happening in that space. In particular, the Netscape browser was released under a free software license, and this really got the attention of a lot of companies, as they’re seeing that it’s possible to make money out of free software.
But they weren’t really comfortable with the philosophy behind free software. It just didn’t feel very corporate, very enterprise-y. In many respects, some people felt like corporate reluctance over the philosophy was holding back the free software movement.
In 1998, some movers and shakers in the free software world got together and essentially rebranded it as open source software. Not only does that name kind of get it one step removed from the moral philosophy involved with free software, but it also sidesteps that complication of the English language, which is the word “free.”
That has caused so many problems over the years for people in free and open source software. When people show up, they assume that “free” means you don’t have to pay for it, which usually you don’t. It’s not required that you charge any money for your free and open source software, but you’re allowed to. That’s totally valid, as long as you make the source available for others, so they can run, study, modify, and redistribute as much as they want. But you can still charge for the software. That’s totally cool.
For the most part though, it is freely available. It does not cost any money. But that’s not what the “free” means. The “free” for “free software” is “free” as in “freedom,” not “free” as in, as we say, beer. So you’ve got “free” as in “freedom,” “free” as in beer. You don’t have to pay for it. Everybody loves free beer. But that was really confusing. People couldn’t understand which was which. So the term “open source” sidestepped that.
Also, at the same time, they launched the Open Source Initiative, which is the keeper and warden of all things open source. It is essentially—though it doesn’t call itself this—a standards body where the standard that it maintains is the definition of open source. There is a definition, and it is recognized around the world as the canonical definition of what it means to be open source.
There are ten items in that definition, which I will not list out for you right now, but they’re very easy to find at the Open Source Initiative website, opensource.org. That really is what the Open Source Initiative does: it maintains that definition, and it verifies that licenses for software provide each and every one of those ten items on the Open Source Definition. If you use a license on your software that provides all of those rights and freedoms and is approved by the OSI, then you are guaranteed that it is open source software, rather than just some fly-by-night, code-available sort of thing.
So that’s the way it splits out. Free software is the “this is the right thing to do for humanity” side of things, and open source is “yes it is, but let’s make it more palatable for business.” That’s a long story long.
What are some reasons why people and/or organizations might want to get involved in open source?
I’m going to split it into two pieces: individuals and companies. So why would individuals want to get involved in open source? And in the “lingo”—could you see my air quotes there?—in the “lingo,” we call this contributing to open source. Why would you want to be an open source contributor?
Now notice, and remember, hearken back, contributors can take many different forms. You don’t simply have to be a programmer. You can write things, you can design things, you can secure things, you can manage things. Lots of different ways to contribute, but why would you even want to do it?
Well, there are great things you can get out of open source contributions. You can learn an immense amount. You can be on the cutting edge of technology. This is where all of the newest, hottest innovations are. They are coming out of open source.
And if you learn these as they’re coming out, man, you are going to be so employable. And to get that job, you can get it through the open source projects you are a part of, because you’re a member of a community. Those people…that’s networking. They’re going to help you find your jobs. And that is so incredibly valuable.
You will potentially travel the world, and meet people all over the place. You will learn how to coordinate and manage projects across a distributed team. That’s more important than ever now, after COVID. That’s super important.
You can move your career forward by learning things you didn’t know before. If you would like to get more experience in, say, accessibility, you can go to a project and say, “Hey, I’ve got just a little bit of accessibility experience. Can I help you get your project to be more accessible?”
And you can start to iterate on that, and learn more, and then bring on other people who know about accessibility, and you can learn from them. And the mentorship. I mean, you can gain so much in your life and your career.
But you also make friends that are going to last you forever. They will be all over the world. There’s nothing quite so wonderful as flying to the other side of the world and meeting someone you’ve only ever seen on IRC, or in issue trackers, or anything like that, and just meeting them for the first time and sharing a cup of tea or something. That’s just so amazing, where you’ve known each other for so many years, but you’ve never met. And it’s just like anything online now. You meet someone you’ve known online, same thing. Except as open source, you’ve got all of these shared experiences and all these people you know as well. And it’s really so valuable, the community you get out of joining open source projects.
So there’s a lot that you can get out of it as an individual. And I really just hand-waved there, because there is so much you can get. And each one of those items can, of course, be just expanded so much.
Now, from a business perspective…this is actually where I spend most of my time. This is what I get paid for: corporate strategy, specifically around free and open source software. So how can you make your company more successful by using, releasing, and contributing to free and open source software in a way that’s good for the community but also for your bottom line?
Companies that say they don’t use open source right now are frankly just ignorant. Not intentionally so, but they just don’t recognize the fact that they are actually using open source. Are you running something on Linux anywhere in your stack? You’re using open source. Kubernetes? Open source. Writing in Python? That’s open source. Have any JavaScript in your website? That’s open source. So there is open source everywhere in your stack already. What are you doing as a company to make the most out of it?
First of all, if you don’t even know you’re using it, that’s a big problem. Because you don’t know whether the projects you’re using come from sustainable communities. And if they’re not sustainable and they go away, what are you going to do when that software you’re using also goes away? That’s going to be very bad for your business. So you need to know what you’re using, whether you’re complying with licenses, and whether you can contribute anything back up.
Let’s say you fix something in your version of the software. It takes a great deal of development time and effort to maintain that patch if you’re doing it internally. But if you push it upstream, if you contribute it and participate upstream, then it’s free. You just get that fixed from there, without any additional software development time on your side. No release engineering or anything like that. You just get it.
Can you release software under a free and open source license to get the jump on your competitors, to start or build a new market, to steal a market from a competitor, to gain mindshare, to get marketing, to rebrand? You can do all of these things through free and open source software, if you’re doing it in an intentional way.
What I find is most companies are doing it in a haphazard way, if that. I mean, more often, it’s just developers randomly grabbing stuff from npm or PyPI, and using them, and companies don’t know it. Then you end up in situations like the Log4j one, which we just had, where we are still…. That was in November, I believe…. There was a massive vulnerability in the very critical Log4j logging library for Java, which was disclosed in November.
We still have companies to this day that don’t realize that they’re running compromised software, because they don’t know what’s going on with their open source. Well, if you were more engaged with your open source, if you were doing this intentionally and strategically within your company, that wouldn’t be a problem. You would’ve known already, and you would’ve had it fixed within the first day, if not the first week. So there are just lots of really good strategic business reasons why a company would be engaged with and paying attention to free and open source software.
This is not purely software companies either, because there are a great deal of companies out there whose primary business model is not selling software, but they still rely upon it. You’ve got financial services companies and healthcare companies, and just pretty much everything now runs on software. This means pretty much everything now needs to be paying attention to free and open source software, because that’s what they are using.
It’s very important, from a strategic perspective, to look at this. If you want to be a high-performing athlete, you don’t just eat any junk that crosses your table. Well, if you want to be a high-performing company, you don’t just use any software that crosses your table. You need to pay attention to that menu and what you’re putting into your corporate body.
“If you want to be a high-performing athlete, you don’t just eat any junk that crosses your table. Well, if you want to be a high-performing company, you don’t just use any software that crosses your table. You need to pay attention to that menu and what you’re putting into your corporate body.”
That's where knowledge and experience with open source really can make a huge difference, and can help your company perform better and more efficiently than your competitors. I'm just going to stop babbling right there on that one. That's book two, by the way. That's the book I'm currently writing right now.
What do you consider to be high-performance open source?
That depends on what you, as an individual or company, need to get out of it. The thing about free and open source software is there are literally millions of projects out there. Millions of them.
What is defined as valuable, and therefore high performing, is in the eye of the beholder, frankly. I could come across a small npm or Python library that does exactly what my company needs, but the number of other companies that need it I could count on one hand. Maybe two. Not a lot of companies need that, but for my company it’s priceless. That might not look like a high-performing project, because it’s not getting written up in all the mags, it’s not getting written in blog posts, and conference talks, and books on Pragmatic Bookshelf, because not enough people need it. But for me it works incredibly well, it saves me a great deal of development time and overhead, it’s well maintained, it has a healthy community, it’s got structures in place to reduce single points of failure in the contributor base. To me, for my needs, that is a really high performing open source project. Those are my needs.
But I’m aware of my needs. If I’m not aware of those, I can’t determine what’s a high-performing project from what’s rubbish. I could see something that’s being written up in all of the tech magazines, and blogs, and stuff like that, and think it’s high performing. If it’s not going to do anything useful for my tech stack, for my company, for the value I have to deliver to my customers at the end of the day…if I go bringing that “high-performing,” flavor of the week, popular project into my stack, what it’s actually going to do is hold me back.
So determining what’s high performing really matters a lot, and knowing your own needs. This goes back to the whole corporate strategy thing. What are your goals? What are your needs? Make decisions based upon that and upon the direction you need to go and the trajectory you need to take rather than on some analyst’s article or some cool hallway conversation you had at a conference once about, “Oh my gosh, everyone should be using the next version of Kubernetes.”
Let’s assume we’re at Kubernetes 3.0. It’s way in the future now. “I should definitely be using Kubernetes 3.0.” But it might not make sense for my stack. So “high-performing’’ is defined by your needs, and whether the project can meet those needs. Same thing for your customers and your product. If they have needs, and your product isn’t meeting those needs, it’s not valuable and it’s not high performing.
What are the characteristics that you find in the best functioning and the best operating open source communities?
So, the characteristics of high-performing and well-functioning communities…these are also largely what we call sustainable communities. “Sustainable” is a word that we pay a lot of attention to—some of us—in free and open source software lately. Sustainable communities, and that’s not about throwing money at the problem. It’s about looking at the overall ecosystem and the health of the ecosystem.
Just like any other ecosystem, you have to make sure that you don’t have polluters in there. If you’ve got a chemical plant upstream in a river, and it’s just dumping out a bunch of pollution, then you’re going to have a very unhealthy ecosystem downstream. Therefore it’s important for any open source project to have a code of conduct and also to have taken the time to train their contributors on how to enforce it. And that enforcement doesn’t have to be anything really formal most of the time. A simple, “Hey, we don’t do that here,” can do a lot for a community.
Having a healthy community where people know where the boundaries are and they know to respect others, that is really valuable and is something that you see in every truly sustainable community.
Some good examples of this are, for instance, Drupal. They’ve been doing a really good job. They had problems earlier on, they recognized the problems, they turned them around, and it’s now a really sustainable, good community. Python had a similar moment where they looked at themselves, at the community, and they didn’t like what they saw. Then they went out of their way to make themselves a more inclusive and friendly community. And that’s worked wonders. I mean, Python is probably either the top one, two, or three programming languages in the world. That’s largely because of this work they did to make themselves more welcoming.
Sustainable communities also will have good governance. That’s not simply things like who’s making the decisions, that sort of governance. That certainly is important, but they’re also going to have documentation around how you’re doing things and why. So how do we merge pull requests? How do we accept patches? How do we launch our website? How do we do these things? Having these things written down not only shows the community that you’ve thought about them, which is super valuable, but it also scales in a way that individuals don’t.
If an individual has to leave, because let’s say they’re a lucky European and they get a month off every year, they can go away for that month and not have to worry that the responsibilities they’ve taken on will fall on the ground, because they’re documented. Somebody else could pick that up if they wanted. Similarly, you’re going to see succession plans in projects that are sustainable. If you’ve got somebody who is, say, the project lead, they will also have a vice lead or a co-lead so they can share the weight and they can pass the baton back and forth if need be. So you don’t have that single point of failure again. Succession planning is really, really valuable.
The best projects, the most sustainable projects, have a ton of documentation—more documentation than you can shake a stick at—and keep it up to date. Because just having docs doesn’t matter. Documentation should not be where things go to die. To keep your project sustainable and useful going forward, documentation should be as equal of a citizen as the code itself, if not higher. Because more people are going to look at your docs than are going to look at your code, most likely. So you probably should document a lot more.
“More people are going to look at your docs than are going to look at your code”
You'll find that the really sustainable, healthy communities and projects have a lot of documentation, because they've learned about that. The usability factor, that just goes through the roof when you've got documentation. That's a really great way to help a community be more sustainable.
More and more projects are starting to recognize the importance of accessibility, but few have the resources to implement it. So if you do see a project that is putting effort into accessibility, you can be pretty sure that’s a project that’s also going to look good from an overall sustainability perspective.
So these are just some of the things that you can look at to see whether a project is healthy and welcoming and sustainable.
What are some of the universal rules of etiquette to be an effective open source contributor?
Universal rules of etiquette, gosh. Well, assume good intent. Everyone has different experiences. Everyone has different backgrounds. So what you think might be the wrong way to approach something, to them, might be the way they were taught. So don’t assume they’re being a big jerk face.
But on the other hand, rule number two, always assume you are wrong. If there’s something going on, and it’s going in a direction you’re not happy with, before you start stamping your princess foot and getting all cranky about it, look at yourself first. Is this something you are misunderstanding? Is this something where you communicated expectations incorrectly, or didn’t communicate them at all? Look to yourself first before you explode, because that’s going to help you a great deal. Just in general, always look to yourself first before you explode at somebody, or unleash on someone.
Before submitting changes to an open source project, regardless of the change, let people know it’s coming. Open something in their issue tracker, saying, “I’ve got this new feature. It meets these needs. Is this something that you’re interested in?” Don’t them a big patch and then leaving after it merges, or give them a massive patch that’s like 1,500 lines when they weren’t expecting it. That’s a lot of work you just dropped on them with absolutely no warning. Would you like it if somebody did that to you? Probably not. Don’t be a pigeon (fly in, drop a lot of shit, then fly out). Do give them warning. Usually you can do that by going to wherever they have these conversations, be it their Slack channels, or Discords, or mailing lists, or GitHub discussions, whatever they use. Go there first.
That’s another rule: always see where they communicate and use the methods that they have chosen. Don’t assume that they have not thought this through. If they’re using IRC rather than Slack, they have made the informed decision to do that. Don’t get your knickers in a twist. Use the method that the community has decided is best for their needs.
But in order to use that, you have to have read the documentation, or otherwise have asked someone. If they haven’t got these things documented, please find some way to ask, even if it is opening an issue in their issue tracker, and saying, “Hi. I notice there’s no documentation about communication methods in the project. If you can list them here for me, I’ll write up the documentation.” Then you learn the answer to your question, and you get to make a contribution by writing up documentation, and you don’t make an assumption that they’re going to use the method that you think is best. You will have asked, and that’s very polite. So those are some good things that you should do.
Always, before sending a contribution, make sure you’ve checked the issue tracker first before sending it. See whether they have a roadmap. If they do, does your contribution fit into the roadmap?
Don’t get really cranky when people haven’t reviewed your request, or your issue, or your pull request as quickly as you think they should, because you don’t know what’s going on in their lives. They could have family issues. They could have a really busy job. They could be traveling. Maybe they took half a year off to go down to the Antarctic. You don’t know unless they’ve told you. And unless you’ve been around for a while, you might not have been around for that notification that they were going to spend half a year at the Antarctic. So ask before demanding.
And frankly, never demand at all. Because even if people are getting paid to do this work, they’re not getting paid to do this work for you. So be understanding, be empathetic. The golden rule, treat others as you yourself would like to be treated, if not better.
I guess that’s a good start. I could probably ramble on about that for a while, but that’s a good start, I think. Will get you at least 80 percent of the way there, if not more.
What are some of the culture shocks that you might expect people to encounter if they’re moving from a closed source enterprise sort of environment, a traditional coding role, and stepping into the open source community?
That is such a great question. I don’t think anyone has ever asked me that question before, and frankly, with all the companies I’ve worked with, they really should have.
So I actually see this all the time right now, in the spaces I’m engaging with: individuals from companies that have not really worked in open source too much in the past. And the first thing everybody does is they show up and ask, “How can I contribute?” Or they show up and say, “What can I do?” Or they just show up and say, “Hi. I am here.” This isn’t your standard sort of employer world, where somebody’s going to assign you a task, necessarily. You don’t have to ask permission. You don’t have to be invited to participate.
You just have to know where work is happening, and then you show up to that space. And you either first lurk for a while—I advise you to lurk for a while, to get a sense of how things are going and where they need help—or you can just contribute. You don’t have to ask for permission to do so. Nobody’s going to assign you work.
So if you are transitioning from a more corporate space, and you’re going to be contributing to open source for the first time, especially in the context of your job, show up to the community: start showing up to their meetings, start participating in their conversations, volunteer to do some of the easy things, volunteer to do some of the dirty work.
One of the best things you can do to contribute, and simultaneously learn more about the project, is to offer to take notes during calls, meetings, anything like that. It’s incredibly useful, nobody wants to do it, and you can learn a lot. Everybody will be really grateful to you for having done so. So that’s a great way to get started, and everybody will be really thankful to you if you actually do it. But do say at the start, “Hey, I’m happy to take meeting notes.” And most often, people will be like, “Oh yes, that will be great,” or, “Oh, we have a round robin, but we will put you in that list, so when it gets around to you, you will be next.” But do make that offer.
I guess that kind of rambled a bit, but the bottom line is, don’t expect people to assign and don’t expect people to invite. You have to really make your own way there. But don’t be a pushy jerk about it. You’re the newbie here. Even if you’ve been working in that particular technology for thirty years, you’re still a new person to that community. So don’t get all “Don’t you know who I am?” on people. Just be humble and be helpful.
How do you convince people in the corporate world to step out, on their own time, and get involved in open source? Where will it take them? What are the benefits for them, which may or may not include financial, which can be a thing that people worry about with open source?
I mean, it’s not really people in the corporate world. It’s any people. There is so much out there in life. While it might not seem like it when you can’t make rent, there will always be more money. There will always be another job. There will always be new things to learn. But once you use your time, it’s gone forever. So, therefore, choosing to contribute some of that time to an open source project, that’s incredibly precious. And you would like to know that you’re doing it for a good reason.
That good reason could be volunteerism, and contributing to a project that makes the world better. Ushahidi is a project for coordinating disaster response. It’s also been used for elections and things like that, but it’s largely for disaster response. You can help save lives by contributing to open source projects. And that might be something that’s really important to you. You might want to learn a new technology or a new skill that can help you find a new job. Free and open source software can help you do that. If you know the direction you want to go, the goals you want to take, contributing can really help you do that.
If you have an idea for a project yourself, and there’s something you would like to release into the world, you can do that, and then you could even maybe start a company around it some day. I have some friends right now who are working on that, with this great technology they’ve created. They did it because they needed to solve a problem for themselves, and it turned out it’s solving a problem for others as well. So they’re shifting their focus of their lives and their company to focus more on this new technology that they released. That’s something that can be potentially very lucrative, and can really change your life.
So there is lots of potential that you can really…that phrasing isn’t quite right, but there are lots of opportunities out there. But you do have to look for them and/or make them yourself, and know what you want to get out of it. That really is key with all these people who are trying to contribute to open source software. Sometimes they’re doing it because people say they ought to, but they haven’t done that introspection to figure out, “What do I want to get out of this? What will be a good fit for me?” Instead, they just try to go to some of those really popular projects that everybody’s heard of, and participate in them. They don’t have a good time. They don’t really learn a lot. They don’t get to meet very many people. They don’t stick around for very long, often.
Instead, figure out what you would like to get out of it, what scratches your itch, what makes you feel good and accomplished. If you can figure that out, I guarantee there’s an open source project out there that can help you, that you can participate in. It can help you meet your goals. It can help you feel good about yourself. It can help you help the world, frankly. You don’t even have to put that much pressure on yourself. Because that’s a lot of pressure. “I’m going to change the world.” Well, you know, you can change the world just one thing at a time.
Maybe you’re just going to make somebody’s life better for this project that is for laying out music, like music composition. You fix a bug in that, and that person, an end user, picks that up and writes this beautiful composition that really affects people in a wonderful way. You contributed to that, and you made that difference, and you did make a change in the world by making a small change for an open source project.
“You contributed to that, and you made that difference, and you did make a change in the world by making a small change for an open source project.”
So these things have ripple effects, but you do need to know, "What's good for me, and what can I do to make a difference in that way, that will be good for me and the project itself?"
There are some projects that have very strong voices, very strong opinions, even if you’ve read all the docs. And so how do people from a wide range of backgrounds, and cultures build the confidence not only to contribute, but to dive in there, and have their voices, and their technology, and their abilities heard?
Well, if you are in a project where you don’t feel comfortable being heard, if you don’t feel you can be heard without putting a lot of time, and effort, and mostly emotional energy into it, I would recommend, first of all, you take a good, hard look at this project, and see whether it’s worth you spending your time there at all.
Again, your time is valuable. Once you use it, it’s gone. Are you going to waste it somewhere where people won’t allow you to be heard, where a project isn’t going to give you the space, or the respect to acknowledge the valuable contributions you can make?
I mean, the answer could be yes. It could make sense for you to stay there, for whatever reasons. It might make sense. But you’ve got to prepare yourself at that point to start pushing a boulder up a hill. Because changing the culture of a project in that way, that’s not something you can do alone.
So if you do want to make sure your voice is heard, it helps a lot to have a…I mean, mentor is not quite the right word, but have somebody else in the project that you can partner with. Ideally, somebody who’s been around for a while and is already well-respected in the project community.
So they can say, “Hey, would you listen to Erica? Erica had something really great here. Could you have a look at her work?” They can really help lift you up and use their expertise and authority to share what you’re doing and bring you into the limelight. And that can be really helpful.
But in communities that are toxic enough to push people down, because they are different, because they don’t speak the language the same way, because they’re a different gender, because they are coming from a completely different background, they just learned software development and they didn’t go to university…if they’re going to be bigoted in those ways, if you’re in a project where that’s happening, I would recommend getting out. Honest to god, I just tell people to get out. It’s not worth your time. It’s not worth your effort. You are way better than that. And there are projects out there that are legitimately good, where you can make a difference, and not have to exhaust yourself dealing with insecurities, bigotries, and bullshit.
Sorry. We’re supposed to be keeping this positive and upbeat, but I have a no-asshole policy. And when I can’t fire them, I will get out myself, frankly. Because it’s just not worth it. And I don’t recommend anyone else suffer through these things. You’re not going to save the world by trying to change this project. It’s not going to happen.
How does an open source project create and build trust and safety for its end-user consumers?
Actually, I just had this conversation in a working group. Do we want to call ourselves end users or consumers? It ends up being six of one, half dozen of the other. It pretty much is the same sort of thing. You are the person at the far end of the open source supply chain. You are the person who is bringing Firefox up on their browser, for instance. So end users need to know that your software’s reliable, it’s not going to keep crashing on them, and if it does crash, they have a way to let you know, or to vent, and hopefully not be too mean about it. But we know when unfortunate things happen, people can get emotional, and that can slop over into bug reports. They want to know it’s reliable. They want to know they can reach someone if they need to. And they want to know it’s secure. So when you do get your next Log4j/Log4Shell situation, they know that they’re not affected, or if they were affected, you fixed it so quickly.
So communicate, communicate, communicate. Where do your end users hang out? Do they follow your Twitter stream? Do they follow a blog? How can you get the word out to your end user? Figure that out. Meet your end user where they are. Don’t expect them to come to you.
Then make sure you are getting that information out. Information that’s important to them. That is going to be, “Here’s where you can reach us. Here’s where we’re working on our next update. Here’s some news about the project. Here’s some security thing.” If you are doing things like, for instance, having a security audit, publish that. As soon as you’ve fixed any vulnerabilities they find, publish that. You don’t want to publish something that’s full of vulnerabilities, that somebody can take advantage of, of course. But as soon as you’ve fixed that, publish the outcome, and then what you did to remediate any problems. Be really open about that sort of stuff, so people see that you care about it, and that you’re doing something about it. That can be so valuable.
Also, have forums where people can ask you questions. Now, this can take a lot of time and take a lot of energy from the community. But if you are able to do so, try to have some sort of a forum where people can have their say, where end users can tell you, “Here are my concerns.” Maybe that’s just once a quarter, once a year, “Hey, we’re going to have this online meeting. Everyone can come together, and we’ll tell you what’s going on. And then you can tell us your questions, and we can tell you as much as we can.”
Find a way to have that open dialogue with your end users, because you are an open source project. When you get right down to it, it’s not all about developers. It’s about the value that you’re giving to your end users. If you’re not keeping that in mind, then do you even agile, bro? I mean, really, come on. You’re not paying attention to your end users. What are you doing? Why are you doing this at all? Just for yourself, so you can then practice typing? No.
You need to provide value to your users, and you’re not going to know whether you’ve succeeded if you don’t talk to your users. So you have to provide a mechanism to do that. You see how all these things kind of roll together.
So these are some of the things you can do to help build trust in your end user group.
What are ways to help open source contributors get fair compensation?
I mean, this kind of goes back to the—and this one might get bleeped as well—but this really kind of goes back to “F*ck You, Pay Me,” which is a talk that Mike Monteiro did several years ago, many years ago at this point, about designers, specifically. People die from exposure, that sort of thing. And that’s been a hot topic in open source ever since 2014, when Nadia Eghbal, with a grant from the Ford Foundation, published her “Roads and Bridges” study, which looked at some open source communities and really the terrible single points of failure, and at some very critical pieces of open source infrastructure. For instance, PyPI had very, very few people who were maintaining it, OpenSSL famously had just one or two people maintaining it for a pittance. Just all these really critical pieces of infrastructure that weren’t being maintained adequately, and were really burning people out.
So since then, people looked at this problem, and they were like, "Well, obviously, since we are technologists predominantly residing in the Bay Area, and so therefore very focused on VC, the way to fix this is by throwing money at the problem.” That really is the beginning of the “pay the maintainers” movement. And I am all for people making money out of open source. Yes. Heckin’ yes. I mean, that’s what I do for a living: help companies be more successful through open source, and help advise people in their open source startups, and things like that. I am all for this.
But I am not all for simply throwing money at the problem, when I have seen situations where maintainers receive money they weren’t expecting to get, and they don’t know what to do with it. And they don’t understand that there are tax ramifications from that. And they didn’t want it in the first place. They are just doing this as a side project.
Throwing money at a project that might be critical for your company doesn’t necessarily mean it’s the right thing for that maintainer to receive. Maybe what makes the most sense for that maintainer is that they need someone else to help them, someone to triage the bug queue, someone to maintain documentation, someone to answer user requests. Getting help might be more important. So ask projects and maintainers, “What do you need?” Frankly, maintainers aren’t stupid. They do this a lot. If you say, “Would you like some money?” They’re not going to turn it away. “Of course yes I would love some money thank you.” But there’s a difference between donating to a project and getting paid to maintain a project. Those are two completely different things.
There’s never going to be a one-size-fits-all solution to this. There’s no one way to help people get paid for open source, because not everyone needs to get paid for open source, and some people don’t want to get paid for open source. And other people who do need and/or want might need something else first to allow them to have the freedom to do that.
There’s just so many different variables and so many different ways to approach the problem, that that’s really what you have to look at first. And look at it in a small piece. “I, as a maintainer, would like to get paid for my work." “Awesome. I support this. How can we help you do this? And is that you getting paid for your work on this project, where there’s 15, 20, 80, 1,000 other maintainers? How’s that work?” Well, each one of those numbers has a different approach to it. It’s not simply you getting paid for your work. You are a single maintainer project, okay, that’s the easy case. We can figure something out there. It’s called starting a company. That’s how these work. You can absolutely make money out of free and open source software companies. But the moment you get another person in there, okay, you want to get paid for your work, but do they? How’s that going to work out? And so it’s really complicated.
So I want to help you be adequately compensated for your time and effort, but compensation varies by person and “adequately” varies by person. So let’s figure out what those are, and then we can figure out how to get you that.
Sorry, that’s the consultant’s standard “it depends” sort of answer. Apologies, but it’s the only right one. You can’t get into details of answers until you get into details of problems.
How can people keep track of what you’re doing, with books, with talks, and with your open source work?
How can people keep track of me? Well, the best way to do it is my Twitter. I am @vmbrasseur on the Twitters. You can also follow my blog, anonymoushash.vmbrasseur.com. Now, both of those haven’t been as active in the past year, but real soon now I will have some exciting announcements that I will be able to put out there. They are definitely places to go for the latest and greatest information on what I’m working on and what I am helping other people promote right now, which I tend to do a lot. Everybody knows who I am. Well, not everybody, but a lot of people know who I am right now. There are other less well-known people doing good work. What can I do to help share that with the world, and get them a broader readership, or attention, or eyes, or whatever they need?
Thank you so much for taking the time to talk with us. This has been wonderful.