Author Spotlight:
VM Brasseur (@vmbrasseur)
We have a treat for you today! We turn the spotlight onto Open Source as we sit down with VM Brasseur, author of Forge Your Future with Open Source, a book that helps you build your skills, your network, and the future of technology as a whole.
This is also an AMA. Everyone commenting or asking a question will automatically be entered into our draw to win one of her books!
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.
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 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.
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.
Drop any questions or feedback you have for VM Brasseur into this thread. Everyone commenting or asking a question will automatically be entered into a drawing to win a copy of her book!
If you donât want to wait, you can pick up your copy of Forge Your Future with Open Source today!
Donât forget you get 35% off with the coupon code devtalk.com!
Corresponding tweet for this thread:
Share link for this tweet.
What a completely riveting interview!! 
I read all of it while on my exercise bike and ended up staying longer on it because I wanted to finish reading it! (So thank you for that as well! 
)
I think every new developer should be directed to this interview, it contains so many pearls of OS wisdom. And I reckon every tech company should give their employees a copy of your book as well if this interview is anything to go by! You talk about so much that is interesting and insightful - from the reasons behind the transition of âfree softwareâ to âopen sourceâ, to why and how people can get involved. I loved it, youâre an incredible ambassador for OSS and I really do think every dev should at the very least check out your interview above - and I donât say that lightly!!
Thank you both for a brilliant interview, and thank you for all you do for OSS Vicky! 
Hear hear!! 
Thank you, Aston! It means a lot to read this. 
Hi Vicky @vmbrasseur ,
I agree with Aston â you gave a riveting interview. It really made me think about how participating in open source projects creates better humans. Aside from the programming experience, people can develop better communication skills, work on introspection, and find value in solving problems and donating time. Being able to separate value from monetary compensation is not something most people will learn working in the corporate world. Working for yourself, yes. And from what you say, working on a open source project does that as well. Hereâs my question for the AMA:
For those of us who are not programmers, but are tech-adjacent, how can we get involved? For example, are editors needed to copyedit the documentation?
Thanks for all you do!
-Margaret
Like Aston I must say it was a great interview, thanks!
These days âsustainabilityâ (as in demand for) seems to blend into everything, mostly in the tech sector it is in the hardware that it should be possible to repair it and it should last for a long time so it does not quickly end up in a land fill with rare earth minerals or cause other problems for planet or inhabitantsâŠ
In my mind it seems Open source is such an important component to keep software sustainable with not enough developers to meet demand so we should all work together and share freely and build on each others work.
With proprietary software I often find myself running buggy software (if you install it at release time) that you need to spend a lot of time to bug report and follow up on only to their work so they can charge you (again) for the new version with your problems (hopefully) fixed (and new ones introduced;)
With Open source software I feel there is more we and even if you might have to do more work yourself you could hire someone in the know which might adapt it for you.
Another classical problem is the âembrace and extendâ where you take something open source, extend it with some proprietary extension that might be nice to have, but instead of contributing them back to the community you keep them for yourself and sell the software as a proprietary solution that sadly seems to work if you are big enoughâŠ
Looking forward to reading your book, thanks for writing it!
Iâm your friendly Devtalk bot 
Thank you to all of you who participated in our Spotlight AMA!
This is now closed and all of those who commented above have been entered into the draw - meaning weâre now ready to pick a winner!
The process will be initiated when somebody clicks the special link below:
Devtalk - Dev forum at Devtalk - the forum for developers! 
Donât be shy, we need one of you to help make the magic happen! 
And the winner isâŠ
Drum rollâŠ
Congratulations @thoh you are the chosen one!! Weâll be in touch about your prize via PM soon 
Thank you everyone who entered, and of course @vmbrasseur for taking part in our Spotlight - thank you! 
Congratulations @thoh! Iâll be contacting you via PM
