Transcript
Bergeron: I'm Robyn [Bergeron], I'm the Community Architect for Ansible, Red Hat, IBM, whatever nebulous thing's going on. I used to work previously at a company called Elasticsearch, which then changed its name to Elastic, I did community stuff there. Before that, I worked at a company called Red Hat, and I was the Fedora project leader there for a number of years before moving on. After I went to Elasticsearch, I then went to Ansible and then we got bought, and me and half of the company all got to go back to Red Hat, yay for that. Yes, I do work on Ansible, we've got 4,000 contributors, GitHub said we were 1 of the top 10 most active open source projects last year, on GitHub is the addendum I will add there because GitHub may be large, but it is not the only place in the universe where people can contribute, and I would be remiss if I did not remind people of that, particularly while giving a talk like this.
Yes, my job title is community architect, which sometimes people are, "Eh?" especially if they're an actual architect of houses. They're, "That's not being an architect. I'm an architect, why not community manager? Why are you not a developer advocate?" etc. Well, this is basically what I do, my job is to build frameworks in which the community can actually succeed and build stuff and do great things together.
It's empowering people, getting roadblocks out of the way that they can do whatever they need to get done. It's not always a role that is necessary, especially if you're thinking about it at the beginning of an open source project, but when you get to 4,000 contributors, making sure the bar is still reasonably low, but having enough process to help people move along is pretty important. It's a balancing act, and that's what I do, I really my job, which I haven't always said about every job I've ever had. I'm sure all of us have had a job that we ran away screaming from at some point or another, and, thankfully, I'm not at that point.
Why do I my job? Well, number one, I've been to a lot of conferences, and it drives me nuts when speakers or take 15 minutes to do the who am I and then 5 minutes of actual content, but, in the context of this talk, I thought laying out "Here are some of my beliefs," because it's important to the rest of the talk and knowing my frame of mind would be, useful. I believe in the power of humans to do awesome things. I believe that collaboration helps us, whether it's software or, general things in society, people working together. You can do more together than you can do alone, you cannot reinvent wheels, all sorts of amazing things. I believe open source is a development model, not really a business model, some people disagree with me, or they just haven't watched a long enough time to actually have seen that. I'm a crazy libertarian, I'm from America, I do believe that free software and capitalism and making money can actually live together harmoniously. I'm not just saying that because I'm at Red Hat and we're the one people that ever, made a crap ton of money off open source.
I keep waiting and hoping, I saw Elasticsearch or Elastic went public recently, and I said, "Wow, I am glad that they actually got to that point," because, once you have more examples, then it's a lot easier to say, "No, I don't really think that this is a tiny bubble vacuum of special ..." especially when your company espouses open source software, transparency in open source way, it shouldn't just be, "We're the only ones that have figured out how to do this," because that's conflicting. This is my frame of mind as I go about my daily life and my job, a lot of this is why I care about what I actually do and why I care about having healthy communities.
Why am I here? Well, because Gareth, Gareth is awesome, he just mentioned all the reasons why he invited me and I'm still flattered. Thank you, and it's exciting to be here, but al it's not that I just care about my job, or that I just care about open source. It's we have this whole ecosystem of people who are building stuff together, and improving their lives, and improving the lives of others, and we can't really just say it's a bunch of people scratching their own itches anymore because, wow, there's a lot of money involved, whether it's in the production of open source software, or it's in the consumption of it, you can say whatever you want about whether or not it's good, or bad, or evil to sell open source software, but pretty much everyone uses it. If the ecosystem goes to hell in a handbasket, it's very difficult to imagine a world where suddenly all of our employers are, "Well, actually, maybe that open source stuff, I don't know. It's shady, it's when Microsoft said it was a cancer 20 years ago” or whenever that was we've come a long ways. I'm happy with the progress we're making, and I'd for it to continue in that way. We've built up a lot of knowledge across a lot of communities, and a lot of experiences across, an enormous amount of communities from early open source software to the project number 100 million and 1 on GitHub that just started, 30 seconds ago.
We all need to learn from each other, I've had the fortune to work with really smart people and learn a lot from them. When I started contributing to Fedora, I was at home taking a break, raising kids and decided that the best way to nurture my spare time where I needed to talk to adults was to contribute to an open source software project. We can debate whether or not those things are always different, or the same, or not, and I would also argue, I've learned a lot from my kids that I've been able to apply towards open source software and community building.
Ethos
I've learned a lot, I've gotten to learn from others, and I would be dumb if I didn't also share what I knew here with you, and with anybody who is willing to listen to me, that's why I'm here. You may have seen the title of my talk, "Ethos(s) is a Word." I added the little S in parentheses to, bring the open source software ha-ha. I'm assuming most of you, or some of you, at least caught that. I believe it's more than just a development model, at Red Hat - I hate to be pushing towing the company line. J, just remember, I quit once, when I say stuff it's from my heart - we talked about a thing called Open Source Way.
Folks actually wrote a whole book that you can look at on the Internet at opensourceway.org, or something that, but it's all of the things and the practices that, we can do that are not just for building open source software communities, but are really the practices that you can apply to communities of any type anywhere that help them to be able to succeed, because most communities are actually about collaborating together. While we can say, "Oh, we need this and that," and we need to have these ways for us to talk to each other, every community needs to have norms and ways to talk to each other, and that's what Open Source Way is all about.
Really the openness, and the transparency, and all of the things that go way back in the roots of open source, all those lessons behind them, part of that is what gives us this spirit of a culture. We're not all just, "Yes, we're all here to throw some code over the fence." We want people to work together, we want people to contribute, we want people to have great experiences with our software and take our software forth and save the world or launch rockets into space or go to Mars, whatever it is, but all those lessons, all of that is if we don't share them, I said, lots of this would be lost. I don't know that open source would be the same if we don't at least try to maintain some of that culture.
Why does that matter? Most of our livelihoods depend on it, whether or not you're making the software or not. If you're here, I'm assuming you make software, you use software, you have a computer or a telephone, or you've been on the internet, or you vote, or you drive down the street and there are traffic lights. Open source software is all over the place and without that, not good. We all have a vested interest in it whether from a, "I to make money, I'm a fan of money," level, or, just a basic humanitarian cause type of level.
Ethics and Constraints
Gareth asked me to give this talk, that sounds super awesome, and it looks such a great conference. Then we get closer to the thing, and I'm, "Oh, right ethics, I took that one course in college. Oh my god, that book was like this, and there are words, and people who study that for years and have doctorates and things," and like many of us, I have a sense of imposter syndrome that is probably not as big as yours because, you know, imposter syndrome, but, yes, I have it.
I started going, "Oh, my God, am I actually up to the bar here, or am I going to stand on stage and make a butt out of myself?" because big subject area, words, very academic, and filled with rabbit holes all over the place. When I say rabbit holes, it can be deeply philosophical, and from certain points of view, and there's many different types of ethics and perspectives on ethics, and how you should live your life, and if that relates to morals or not, or whatever.
There are some things, when I'm talking about ethics here I'm just not going to go here. Since we talked about freedom and free software a lot, I'm not going to talk about are we as individuals truly free or not? If we can't agree on, yes, that's a basic premise, then the rest of this is probably a moot point. Is it unethical to profit from free software? Is this license good, or bad, or, terrible and mostly think if it's an OSI approved license, it's free enough.
If it's something else you invented last week, then, that's another topic, but actually approved acknowledged licenses, ethical, yes, probably. Isn't this whole talk just, me standing on a stage and, explaining how much I know? For the sake of discussion here, let's not veer off course into the squirrel hole. I mean, I'm perfectly capable, as you can tell, of doing that all on my own, thanks to the little squirrels that live in my brain.
Why Are You Here?
The big question is why are you here? Because there's lots of different points of view about what should I do? How should I do it? What's good? What's bad? What's terrible? The focus here is when it comes to building healthy communities, because communities build software, you can enable them, and you can empower them, or you can just scratch your own itch and throw it over a fence and that's perfectly fine, but if you are in the opposite seat and you want to enable a community, or you work at a company and they want you to enable community, or you're consuming something and you'd to make sure that it continues to exist, then this is about some of the practices and the things you should do, probably shouldn't do, really shouldn't do, and I do have a special place in my heart for this one.
Does anybody here work for a venture capital firm? It's totally fine if you do, I'm not actually going to throw anything at you. I'm not going to talk smack about your firm, I'm not going to talk smack about, a company that you guys have invested in, I'm not going to talk smack about the recent wave of anti-Amazon licenses that everybody is coming out with, I'm not really available for employment, I mean, unless you have a lot of money and it's something very interesting that I might actually care about, but it would be very hard to peel me away, especially if you've invested $300 million in a company, anyway, not that I have opinions.
Practical Wisdom
This has been one of the more interesting developments that has related to this talk that has emerged in the past few months, and, yes, I might have opinions. What I mostly have is practical wisdom, there are lots of rules and practices. I encourage people to learn from the past. Ethics can be blurry lines, there's not always, "Here's this rule and you're either black, or your white, or you're zero or you're one, or you're left or you're right." Sometimes we have some good feelings in our guts, sometimes we need to merge that a little bit with some of the creativity that we have and some of the lessons we've learned and be practical about stuff. Open source software has a long history of people referring to others as zealots, I'm not going to say that those people don't exist, but there's a lot of other people that are practical.
Some communities take a more seriously holistic approach, I've worked in the Fedora project, all of our infrastructure ran on free and open source software partially because we believe in free and open source software, but also because if we relied on something that was proprietary and went away, then our community would be absolutely screwed back to life.
Now I work on Ansible, we're an open source software project, we're ok with using GitHub. That's just a facet of our community, communities are different, and what is practical for some may be impractical for others, as long as people actually accept the tradeoffs, you don't want to be on GitHub, that's fine, understand that that's where a bunch of people are actually at, and if you're somewhere else, there was a time in Fedora where you actually had to sign a CLA and fax it in, talk about barriers to entry. Making trade-offs is a thing you have to do, and I recommend to people at this point, be practical about it, but also I say, I dispense practical wisdom, it's going to depend on case to case, some of this talk is giving you some of those practical points that you can decide, in certain cases, there's definitely things that are bad, don't do some of these things. Sometimes it's probably not the greatest thing, but if it makes sense, when you understand the ramifications of what's going to happen, then, take the other path.
Open Source
I do want to say a few words about open source, I'm going to get to the meat here, I promise, but background is useful. Open source is a development methodology, I know lots of people think it's a business model, it's not. There's plenty of other business stuff that is actually business models. In open source land, we say lots of stuff transparency, and release early, release often, with all eyes more bugs are shallow, all of that stuff. It's part of the culture that we built an open source.
Those cultural practices are not just hippie things that we are, "This sounds cool, and I bet will make people really believe that we believe in freedom if we say this stuff." It's actually stuff that makes it an effective development model, the feedback loops that get created when you actually put stuff out in front of users, we talked about this in Agile Land, and, general business today is, the things that allow us to build the right thing, or we want to get customer feedback, well, if you get it out to them sooner, they can tell you if you're going in the right direction, or the wrong direction.
In open source, it used to be, if you want other people to participate in the project, what you don't want to do is sit in a corner hiding, and then eventually be, "Here's the direction that we're going," and, "Whoa, we're all shocked, and none of us knew, and you're telling this is open source. If you had told us six months ago, we would have gone and done something else, or you would have done something else, and now we are at a point of friction."
In any case, giving feedback loops is one of the things that helps open source software to actually build good things and allows people to say, "Yes, I want to continue participating in this community because I can see the direction that it's going in, and I want to invest my time this way, rather than in one of the 999 million other places on GitHub and elsewhere, etc." I know sometimes in legal land, people talk about following the letter versus the spirit. I think there's a decent corollary here in open source land where, yes, you can as an individual or as a, large company, release something into open source software land. You can throw it over the fence, and you can say, "Yes, we're an open source software project." I think for an individual, that's perfectly fine, this is how Linux started, so eventually some great things can happen.
As a company saying, "We're going to throw it over the fence, and we're going to call ourselves an open source software company, but we're not going to do the community thing" sure, you can do that. I don't know that that's a very effective practice, that's asking for your company to go down the drain and have all your employees not have jobs. It's also wasting a bunch of time, some people will argue about is open source software development slower or faster? It depends on many factors, but there are benefits to practicing in that way. There are drawbacks to making it available and then basically shutting off the community, number one being sometimes they can be very outspoken, and they get mad at you, and in those cases that can be actually detrimental to your business. If you're going to be an open source do it right, be good about it, don't ignore people, at least be honest with them.
A thing that I always remind people of is that users are potential contributors, people do not come and contribute to your project, by and large, 99% of the time, probably 99.999% of the time. They do not just come to contribute to something that they aren't using or don't care about, you have to take care of your users and listen to them, and if you're lucky, some of them might turn into contributors. They're your force multiplier, or they can be the end of use, choose wisely.
The Separation of Church and State
We also can't talk about open source and vacuum, I believe my abstract said something about the legitimacy of open source can't be denied, and I think everybody is probably on board with that. You can see me afterwards, and I can convince you if you believe otherwise. Lots of people to talk about the freedom vacuum, and that's talking about any philosophy in a vacuum like Republicans, or Democrats, whatever country you live in has political parties and, yes, I'm sure that in a vacuum, that way of life would be amazing, but we don't ever live in vacuums, there's always competing forces and things that are set in place that we can't ever change them.
One of the things in open source now is money, talking about one without the other and whether or not you're doing the right thing or the wrong thing is very hard to balance because sometimes our principles are at risk. On the flip side, sometimes it's people's jobs and livelihoods that are at risk, so it would be unethical for me to pretend money wasn't part of open source land.
Some Universal Rules
You noticed earlier that I had a couple of breakout things for different, I guess we would call them, personas or something if I was making user stories for community. There's some universal rules I think that apply no matter what you're doing, I think if you're starting a project, being clear about where you're headed, what your ground rules are, even if you're a project of one, it's perfectly ok to say, "I'm sharing this with the world, and I don't intend to ever look at any of your PRs, but I thought somebody else might think this was useful, and you are welcome to take that and go ahead," provided you understand what might happen because sometimes, majority of the time, nothing is going to happen.
I want to be frank with people here, I get asked a lot "How can I make it in Ansible?" not everybody is going to be a gazillion person software project. Most things will be small and useful to you and may be useful to some other people who have been settled into a similar role that you have in your career, but, as long as you understand I'm just putting this on the internet, I have no intent of taking care of it, don't get sad later, if somebody makes a bazillion dollars off of your thing, that's not how that works.
Making your software easy to use and easy to contribute to in the ladder is particularly important. It's easy to have really great aspirations, "I know this project's going to be super huge, and I'm going to build in a bunch of process immediately." Keep the bar low, keep the feedback loops often, people have choices about what they can contribute to and they will go and contribute to something else if you get in their way. Ten years ago, 15 years ago in open source, that wasn't much the case, people were, I don't want to say more hardheaded, but they were more hardheaded about getting something in and doing something right now. There's options, you can go anywhere, and people will go to someone who is treating them better. Treating people right, whether that's in kindness, or listening, or just simply making life easier for them as a contributor is probably the good thing to do and getting in the way of that is probably detrimental to their soul, "Why can't I do this? I'm failing." They could walk away from open source software, I've seen that before "I'm a first time person." "Well, we're going to jump down your throat." Yes, well, that person is probably never ever, ever coming back to this again, not just our project, but frankly, sometimes any project and that's probably not something we should want, just as a general cause, but, yes, hurdle jumping.
If you have rules, if you have process, if you are beyond a community of you and the one other person, if you start getting to three, four people, if you get hired by a company to work on open source software, whatever it is, your process and rules, please apply them equally to everyone, I know that it's really fun to be, "Well, everybody else has been waiting in line, but I'm going to, force, push this whole thing that I have because I have the employee driver's license. Isn't this cool?" and break everybody else's stuff in the meantime, just because you're employee does not mean that you're not part of the community and the rules apply to everyone. It's ok to have rules that, be blunt about what your intent is, what your company's intent is, but at least keep the level, the playing field level.
Don't be evil. You thought I'd never get here, this is the ethics draft, I remember. Gareth reading my abstract and saying, "Could you put some more evil good versus evil wrong versus right in there?" I'm, "Yes, I guess." I guess I always just try to do what's right, and I never really consider doing the wrong, sometimes people are "You should do this," and I'm, "Let me tell you why that's wrong," . I can't remember, was that Google's slogan? Ok, well, good on them.
If you’re A Creator of Open Source Software
If you're a creator of open source software, by that I mean one person, you've got a little project, be honest about your intent, if it's a science project, that's fine, just know when to live with it. If you get users and contributors, you need to learn how to delegate, you should do that. It's very easy to be micro-managerial, until the end of time, you will disincentives demotivate, make sad the people who are trying to contribute to your projects, possibly the users who are trying to contribute to your project. Even worse, they could get mad and have an uprising, and that would be terrible.
We talk in open source about this thing called the bus factor. I don't know if any of you have seen what the bus factor is, I to call it the bus raptor factor because I don't really to think about what happens when someone gets hit by a bus because people in open source have been hit by vehicles and died. I to think about it more as if you get eaten by a raptor, don't be a single point of failure in your community. You could get eaten by a raptor, you want to delegate the ability for others to actually get stuff done and make decisions without you being the thing that's blocking their wheel from going around, not on the bus, on the raptor bike. Just delegate, it is hard, I have worked with some people who are very hard to get them to delegate, and sometimes you have to do interesting things to change their minds or the scopes of their jobs.
If you want to build a community in the event that you're not building a science project, you should really consider, well, A, if somebody else already has a project, you should consider contributing to that because it's really cool to start a new project, but there's a lot of them and if somebody else already is doing stuff, it's ok to not be the person who started it and to be the second person that helped along the project. It's fine, you should think about how your code is actually architected, and what you envision the relationship between that, and how you're building the community, or how a potential community could be built is going to be.
My fine example of this is Ansible. There was a fabulous paper out of HBR about architectures and participation and modularity, which showed, aside from a whole bunch of game theory, math, it was Page 2 through 20, the rest of the paper, which I actually was able to understand, talked about the advantages of, if it's the right type of project, having an architecture where, you have an engine, and then you have things that plug into it, we've just seen this in open source monolithic projects. A good example here is Eucalyptus or CloudStack versus OpenStack. I'm not going to debate whether anything is successful at this point, that is a conversation that other people can troll each other on the internet about, but the downfall of people trying to contribute to some of the more monolithic projects was they had to understand everything that was going on, rather than how their one piece they're an expert and actually worked, and having well-defined rules for how it works together with all the other pieces.
That's the thing that actually enabled lots more people to actually contribute and get stuff done. Also they had an overlapping language use of Python, which fit well with their user base and other things. It also fit well with how they delegated control and, empowered people to contribute in the community. If you're really serious it's worth reading, there are lots of sources on the internet about different types of ways to actually build, and it's not all HBR, it's not stuff out of Harvard all the time. There's plenty of real-world examples, in our case, we just happened to take some cues from some research, and as it turns out, I guess it was a good idea because we've done ok as a project and then small company that got bought by a larger company that is now getting chomped by a huge company.
Help your potential contributors to be successful. I guess this is the opposite of don't be terrible and ignore them or tell them to go away, or that they suck. That's bad, it's bad for them, it's bad for you, it's bad for your project. It's hard sometimes because you can help people and they will disappear. I have this 1 out of 20 rule, for every 20 people you talk to maybe one of them will become a long-term contributor. Sometimes they'll be a one-time I'm just stopping by, and hopefully, you can help them be successful and have a successful open source experience just for the sake of everything else at large. Sometimes when that number 2 person is after 60 people, and then you just have a rush of them all at once, it's easy to get frustrated, don't have faith, or have a beer and call me and we'll have faith together with beer, or a tasty non-alcoholic beverage for you, if that is your choice. Mine would be beer or whiskey.
Also remember that any significant amount of success can lead to employment. Negotiate wisely if you embark on this with your community in mind because sometimes people want to buy you they can take your community over and then stamp it out or reassign a bunch of cops all sorts of stuff. If you are in the situation, this is not a ton of people, but if you were ever in that situation, make sure that the person who was approaching you is being clear with you about what's going to happen because it's not just all these people in the project, it's also potentially your future trustworthiness.
People have built up trust in you, and if you sell them out, unless it's for several billion dollars and you're just going to be on an island and, "Bring me with you," and then you'll have to live with it is the thing, it’s "Yes, I'm living with it, and it can't be too bad if you have several billion dollars," and you're living on an island, but it's still going to eat away your soul if you have one, most of us do, almost all of us do. That is a philosophical rabbit hole, not doing that whole.
If You’re a Participant of Open Source Project
If you're a participant in open source project, be honest about your intent. If you're contributing to a project on behalf of another employer, that's fine. I mean, you don't even have to necessarily advertise it because, most people either belong to some organization or, they're participating on the mailing list. If your employer's, "Please go into this project and influence it," or wants something to change for it to continue to be useful at least say that because the product is filled with people who want the project to continue to be successful. If your employer is hoping something will change, it's either because that's a bad idea of your employers, and your employer needs to get that feedback, and they're great people to tell them that as the users of the stuff, or the community needs to sit down and have the soul-sucking session of what are we all really doing here together, and what do we actually want to achieve together? Those conversations do not get initiated at all if you are not honest about who you are and where you're coming from.
Speak up, if you have concerns about what's going on, you don't have to speak up in a, "I'm just going to throw a flame mail," but it's worthwhile to go around and talk with other members of the community, double check that what you're thinking "Am I just crazy or is this happening?" Sometimes it's maybe not that, there's something else, maybe you've missed the mail on the mailing list, but ignoring it and just hoping that things will get better, bad for you, bad for community, bad for your employer, potentially other person's employer, perhaps all of society. Say something, I don't want to do the "If you see something, say something," but I just did, sorry.
If You’re a Cat Herder in an Open Source Project
If you're a cat herder, by cat herder, I mean, community architect, or community manager, or developer advocate, or whatever other, myriad titles, project leader, etc., I can't say this enough, be honest about your intent and the project's intent, and if you have an employer, what your employer's intent is. I was the Fedora project leader, the job is literally described aside from smart enough to do the job and dumb enough to take it. The other way that it was described is over here you have the community, over here you have Daddy Shadow Man, that's this guy. His name is Shadow Man, I call him Daddy Shadow Man because he buys beer. Daddy Shadow Man sometimes has other, not other interests, but sometimes people inside Daddy Shadow Man aren't always looking at what's going on the community. If you're the cat herder, the tightrope walker, you got to be saying, "What's going on in community land to them?" and you're if people over here are being shady, you need to chat with the community or be honest about what's going on. We have a saying "It's ok to be disappointed, but it's never ok to be surprised." That's for a good reason.
There are plenty of times over the life of Fedora where, "Surprise, you guys didn't realize this, but, XYZ is happening." and it took years, years being 5 years, 10 years before I was even involved to fix some of that stuff because it was the very early days of open source. It's probably one of the most important lessons that we've learned it's good to keep everybody in balance on both sides, that's how you stay in business, that's how you have a healthy community, that's how you have people still coming together to make free software that we stuck on OLPCs that went to kids in other countries that never ever have had any technology at all because we were being honest with each other. It’s your number one job, if you are in that position is aside from all the other things, you probably have to organizing events, and, paying for pizza and all the other things. If you can't do this, there's not going to be any events organized or people to buy pizza for, bear that in mind. Lots of people to assume bad intent all the time on the sides of companies, but I think most people are also willing to if you actually explain things to them.
Sometimes there are business decisions, sometimes there are smart ones, frequently there are dumb ones. The dumb ones can be rectified, the smart ones are the ones that determine whether or not we're going to continue to have funding. Those are conversations you have with your community, and you take that information back and say, "Here's what they said," or maybe even, "It would be cool if you, business people, came over here and sat next to the people that are working on the stuff you can get their point of view and not just rely on me being the back and forth."
If Your Company Is A Creator/ Provider/ Consumer
If your company makes open source software, hey, it's a repeating thing, be honest about your intent, please be willing to listen, healthy communities much more likely to be financially viable, they could turn into you having a product that makes money in open source land, “ooh” and then you too, could be like other companies. If you're not wanting to make money, and you still want to have a successful community because you are sharing software with the world that your company itself relies on, you still probably want to have a healthy community because if that looks bad, then it reflects poorly on your company, and if you have investors of any type, then they see that and they're, "Is things bad over here in your company land?" None of that's good, that winds up being bad for people in the community, people participating, and your employees and your shareholders, I guess, in some cases.
Understanding the risks of not doing that, anytime something goes wrong in an open source community/company, it gets a mind-boggling amount of attention. If you want to have a healthy community, be committed to it and do the right things. If you don't, everyone on earth is going to hear about it, and you have to be willing to live with that or hopefully just not do that by being honest up front. Also understand your dependencies, and I mean that in a literally in a software building kind of way, but also in a "If I depend on this project, is it healthy? Does that guy have a job? Is this guy overwhelmed? Is this..." I'm sorry, I shouldn't say guy, is this is man or woman, happy or, do they have time to work on this? If they're completely overwhelmed, and they're about to just be, "Screw it, I'm out, I'm done, mic drop. You guys all do your own thing." We have seen this in open source, even in recent months and years, where people were just, "I'm done with the harassment, I can't keep up, no one else is helping me."
There's a company called Tidelift, where I'm still grasping the business model here, but trying to take money and give it to the people who are making the large chunks of open source components of the internet. There are gazillions of open source conferences that are basically free to go to. There are millions of Python software foundation, there is a list of foundations, I'm surprised there isn't a foundation yet. Somewhere in between the maximized commercialization types of foundations and the license foundations are a whole bunch of the backbone of the internet building blocks type places, they have a handful of employees, they're cranking stuff out, and it takes one donor to be, "Yes, actually …"
In my case, right now, I worry about, now that Red Hat is getting bought by IBM, are a bunch of these foundations that employ people with the money we give them suddenly going to be losing out on some money, are we going to pull our money together and make sure that we're giving them the bigger same amount that we're not shorting the open source universe by accidentally buying an open source software company called Red Hat? IBM already gives them money, we don't need to give them twice as much now because we're all one place, there are certain number of people, and if we depend on it, making sure that they're healthy is part of your folks staying healthy.
If you are able to influence that, if you're able to explain that to your boss, or coworkers, or if you have an open source programs office, imploring them about, "This is the stuff that is vital to us being able to make the things that we make, and if this goes bad, here's what could happen." That is usually a quick way into sponsoring the right things, and doing the right stuff, and making sure that those people have jobs, that you can still build software, everybody stays employed, world happiness.
If You Are From A VC Firm That Invests In FOSS Companies
If you're from a VC firm that invests in FOSS companies, I'm not going to say this has given me heartburn recently, be honest about your intent, "Oh, my God," and actually stand by it. Don't be, "This is what we're going to do," and then later be, "But actually now that we sunk $300 million in and we haven't figured out what the business model is going to be." That's not going to result in, "Well, now we feel secure about that company and their ability to deliver."
No, don't make community-obliterating decisions just because we're really sad that, you haven't gotten that 20x return yet. Please stop blaming Amazon, this is one of those give and take things. Yes, Amazon does frequently take things and turns them into services, Amazon has also given the whole planet access to a crap ton of computers that otherwise we would all still be sitting around waiting for someone in purchasing to fill out that piece of paper, and then we have to wait for the server to arrive, and then the software to arrive.
Like it or not, it has done wonders for us, and they do contribute to open source all over the place. It's just not in the "We have a giant foundation and everybody can see it," types of ways, or in the "We bought GitHub," types of ways. If you're a software company, if you're an open source software company, the same rule applies to you as what Marc Andreessen says is happening, "Every company must be a software company," you can be agile, that you can pivot, and change your business model. That also applies if you're an open source software company.
I have fields here, I worked at a little startup that took in $7 million and did ok. Seeing the things that other people have done and I'm, "if you have a shovel, you keep digging, it's not you're going to come out on the other side of the planet and suddenly be fine, maybe reassess together because if you go out of business all those things are going to get sold off and your community is going to be sad, and someone's going to fork it, there's going to be chaos. That's not good, that's bad." The big thing is it's bad for the whole ecosystem, I see this going on and I'm, "We have spent all of these years building trust in open source software, building trusting communities, convincing employers that it's ok for people to contribute open source software, it's not terrible, it's not awful." It takes stuff this for people be, "Oh, maybe it is terrible after all," and, "Oh, good. Well, I'm glad that we came all this way and now we're back here in the trough of disillusionment. Thanks, Gartner." Not cool, this is the future that I really want to avoid, is people losing faith in the model, but in order to keep faith in the model, we have to do the good things that the model requires to keep the good model going.
Conclusions
That's the end of my rant. Conveniently, that's the end of my talk, especially since I got the five-minute warning. I know that that was a lot of stuff, some of it may be super obvious. Sometimes things always strike me as, "That's super obvious," but it never really struck me until somebody actually bluntly pointed it out and typed it on a screen to me, "Oh, you're right. I knew that," but now I know it, or it's more obvious to me about how doing that thing actually matters.
I hope that you all got something out of this, or something you can take back to your employer, something that you can take home and care about and put in your happy little heart, and if not, I'm sorry.
Questions and Answers
Participant 1: The way you talk about open source projects in one hand sounds brilliant, and on the other hand sounds really terrible, and awful in some ways. Tell me, there's something you said about strategic, in being strategic about doing open source.
Bergeron: I believe that if you think ahead, not every project can be strategic. Sometimes things are just glue, and that is perfectly fine, one of the biggest questions I get all the time is, "How come this project just doesn't have as many contributors as wide projects?" You're making a device driver, you're making some algorithm that is for marine biologists who only live in a certain part of the world that, the audience is only big. If those people are a happy community and they're getting stuff done together, then hooray for the power of open source. If someone's getting mad at them saying, "Well, why aren't we turning this into a company, I bet we could make a zillion dollars," that's when you need to set expectations, I just want to make sure that my boss understands that this is as far as things can go.
If you do have something that could go crazy, or a really good idea, or it's very obvious early on that "Wow, I'm solving a bunch of people's problems," you should take a step back, you should call one of the zillion nice people in open source software who are out there, or take cues from other communities to be, "Ok. I am about to be on this precipice of how do I not turn that into ow" and I feel especially if it's something that's cool, and it can change people's lives, one of the things that I always get about Ancible, Ancible is such a cool tool. I actually, automated myself into having weekends and seeing my kids again, and that's the gratifying thing about my job currently is, "I'm making your life better and not just because you can write some stuff." it's you're feeling you're doing better at work. Being strategic when you can, good idea, be willing to accept that not everything is strategic, it's up to you. If it's helping you, then that's good and hurray.
See more presentations with transcripts
