 Hi, if you're here to hear about Interstress Commons and building a community that you're in the right place, and if not, or if I'm boring you, feel free to get up and leave as you feel you need to. If you come up with questions as we're going through this, there is a question slide at the end, so just remember what it was and we'll get to it. Okay, and in the interest of time, here we go. So Interstress Commons is a project that I started eight years ago, because, sorry I should take this off, because as a consultant doing open source, I realized that the number of customers that we had that could actually get there, with just a little help from a consultant, was starting to be smaller and smaller. We were running out of people that were going to be able to get there. And when I looked at why, it was mostly cultural issues. And so I had a consulting gig with PayPal. I got them to do an Edge open source project, which is where the engineers involved have special powers and most of the rest of the engineers don't get to work that way. And they had a pretty good outcome from their launch of a framework for Node. And they decided that they had other stuff they wanted to open source and wouldn't it be cool if I came and worked for them? And they kind of made it so I couldn't say no. They basically let me keep my consultancy open while I was working for them. So it was like, I really had to do it. And so I got in there and I realized that they did not know how to do open source, except at the Edge. And most of the projects that they were giving me to do were not going to fly. And I started thinking about how can I help them and have it take long enough that my stock will be worth something. And I thought, well, what if we resurrected the idea of inner source? So I didn't invent inner source. Inner source was invented by Tim O'Reilly. The term was invented by Tim O'Reilly in 2000. He had just started a company with Brian Bellendorf, who was here a little bit earlier this week, who founded Apache. And Brian thought that companies needed to learn the methods that Apache uses because then they would get better code reuse and they'd have better engineering. And he correctly thought that this would be a real boon, except he missed the fact that middle management could push effectively against the idea of yet another initiative to fix things because open source hadn't won in the marketplace yet. So it was really easy for them to say, this isn't going to happen. I'm not going to bother. And when I was thinking about resurrecting it, it was 2014, Satya Nadella had just said, Microsoft is now friends with open source. And that was kind of the moment that most journalists thought, oh my God, we actually won, which I'm here to tell you, as somebody who started in 1999 as the first corporate open source officer, that was a big deal. But so this is this, I'm telling you that the first lesson I learned was, it is possible to resurrect an old idea when it's time for it to really happen. Sometimes you see people with really good ideas and you get on that train and then it falters and it falters because it's the wrong time. That doesn't mean the idea is bad. So you have to hold on to those ideas until it's the right time. And then sometimes you can really, really take off. And that's kind of what happened with inner source. If you think that eight years is really taking off quickly, which in my opinion it is because it took 20 years to do open source, I looked at it because I was 55 the year that I joined PayPal and I said to myself, I don't have another 20 years, but I probably have 10. So I'm going to throw away everything that I think is going to get in the way of fast adoption. I'm going to work really hard to make sure that this lands as quickly as it can. Okay, this is the leading issue in both open source and inner source implementations and also in every foundation that anyone has ever started to support open source. Everybody thinks it's going to happen faster than it will. And they think that it is going, they budget based on that. They commit resources based on that. And as they near whatever threshold they've given themselves, which is usually unrealistic, they lose heart. Right, again, I gave myself 10 years. I figured if we couldn't get it done in 10 years, then it probably really didn't need to happen. And I'm at year eight now. And so I wasn't kidding, it really does take 10. By the way, my pictures always mean something related to the point. And this is in Jaipur, but there are five of these in India. This is an astronomical instrument thing that was built around 1724. And the guy who built them, he built all of them, because he thought that this was really cool. But it took him almost 15 years to build all the ones he wanted to build. And it all still works. And this thing here, that's actually a sundial that is accurate to within two minutes if you know what you're looking at. Isn't that wild? So anyway, stuff takes time. And cultural change really takes time. And you have to give it the full measure of time. So when I consult on Inner Source, because now I get asked to consult on Inner Source, it's the first thing I ask. How long do you think this is going to take? How much time have you budgeted for this to be good? And it's always ridiculously short. And then I have the long conversation about how that is not going to fly. And you're going to have to revise your ideas in order to make it work. If I think that the customer is not going to get there, I'm pretty sure I can get them through the first experiment. If you guys have looked at the books that we wrote for Inner Source, there's a book about the first experiment and some case studies. And we can usually do that in a short period of time. So at least they get a taste of what could happen if they were willing to allow that it's going to take longer. And then I also shorten my contract because I don't want to be around. Right? OK, that's number two. Number three is, and this is true in open source and Inner Source as well, you are what you measure. So that means if you're really obsessed with metrics and a lot of companies are OKRs or whatever they're calling them this week, I am not a person who loves to dive deep in the metrics. But it can be helpful to have a little data to throw around generally for senior management you have to in order to give them the 20 second up or down that they're looking for. But what I think is interesting and what I learned on Inner Source Commons really validated on Inner Source Commons is that I can use metrics to drive behavior. Because Inner Source is at the end of the day a cultural change engine. And if people knew how to do open source already, they wouldn't need Inner Source. So you need to realize that you can use metrics as weapons. And I don't mean like blend instruments. You can control people to do the right thing by picking the right metrics. So for instance, everybody has a problem with release early release often. So number one problem setting up open source projects with people who've never worked in open source. It's really a problem in Inner Source because real code review basically doesn't exist in engineering right now. It's kind of one of the holy grails that Inner Source is trying to fix. Because it does exist in open source. And that's part of why we have higher quality code. And there's a bunch of other stuff that falls out from that. So if you are having that trouble, you can tell because if you're counting lines of code, you will see a sawtooth pattern where there'll be like a little code, a little more code, all the code, a little code. And it'll be defined by sprints, right? So that tells you that people are holding under their code too tight. It's never going to happen that 30,000 lines of code drop the day before it's supposed to be merged. It's going to get a decent code review. And a good reviewer or a trusted committer is what we call them, won't let it merge. They'll sit down and understand it first. If you really want to get it done, you want to encourage people to give away the code every night. However, before they got that day, give it away so that the person can read it. And in order to get them to do that, you can never be known that you've changed the metric to number of pull requests. And believe me, they will get smaller. It's like magic. But you don't want to do that forever. It's a totally bullshit metric. You just want to do it until they cotton on. So metrics can be your friends, even if you don't really love them, which I really don't. But because I think they're overused, over relied upon. The other metric I do really like is net promoter score for Inner Source, because it almost always makes engineers happier campers, almost always. And if you work for a company that is reasonably humane in their management practices, then that is a significant thing. So consider getting them to do net promoter if they don't already. OK, number four. And this is during the last Chinese Olympics. You have to think ahead about scaling, because this is what happens in Inner Source. You do the experiment. You get good outcomes. At least one senior person goes, this is cool. We want to do more of this. Pretty soon, they're telling you that you have to do it for the whole company. They put it in their goals, so it's going to cascade through all the goal crap. Everybody's going to put it on their goals, but they won't even know what it means yet. And then before the year is out, they will tell you it doesn't work, even though they haven't actually practiced it yet. So you have to work harder to prepare. And there's a few pieces of advice that we give at Inner Source Commons about preparation. I find that those things, even though we've written them down and we talk about them all the time, they are the number one thing that people gloss when I'm consulting. So you have to really hammer on them. One of them is hire a communicator before you need them, ideally during the first experiment. Hire a communicator and have them help explain what you're doing, both inside the company, so they have to be able to market inside, in addition to marketing, eventually outside. You would market your Inner Source outside once it's working well, because you might want to recruit people who want to work that way. That is becoming more and more of a thing. And even if they don't know it yet, the youngest people you can hire, fresh out of college people, want more agency than traditional engineering gives them. So it's a good thing to be able to say, we are moving in that direction and you have a chance to work that way in this company. But initially, they're going to be marketing mostly inside. Because they're going to be dealing with engineers, they need to not be bullshit marketers. That means they need to know they can't shape the message. They have to be honest people. And they have to be willing to be honest. They have to be able to say things like, I'm a marketer and I don't really know for sure, but I think you probably worry about this. Is that true? Get people to talk about themselves and then use that information to actually make this more palatable to more people. Trust your communicator to know how to talk up to senior management. You probably have to go with them, because they always want to see you. But this is a really important thing. And then the other thing about it is you can't scale intersource without having all the code be visible. And people like to put walls around their code. And so you have to make sure, as a condition of scaling, that all those walls come down, or as many as humanly possible. And as the person trying to figure out how to do this, you will find that if you go look at the code that is claiming that it's the family jewels, so it can't be open to the rest of the employees, you will usually find crap code. And the people who built it know that. And that's why they're pushing back. So maybe you don't be the person who tells them that, get the senior architect or somebody to do that. But that's a really common thing. Now, there are, of course, real trade secrets. There are things so sensitive that you can't give them to everybody in the company. But one of the things about this is trusting your employees more than you're comfortable with trusting them now. I find that most of the places where people treat engineers as fungible tools, they are cogs in a wheel, which we're not. We're artists, right? So people aren't happy when they're treated that way. Those places also don't trust their employees at all. And that's not a nice way to work, in my opinion. I worked for Intel during the Andy Grove years. They used to strip searches between two buildings on the same campus. And it creeped me out every time it happened. So this is partly about agency for all engineers. This is a better way to work. How would you like to work, right? OK, next thing I learned. Oh, my goodness. Change agents are not made. You can find people who want to be a change agent. You get to where you can tell if they're going to be able to do it without hurting themselves. I used to teach a class for the first four years of intersource. I didn't talk about intersource so much as I talked about change agency and who you have to be to do that. And Solona, who's in the back, helped us with that. We all took turns teaching that class. We called it intersource 101 and later intersource 102. It was a three hour class. And this is how it went. We explained what you have to do to pull off intersource as a change agent. You're going to need to do a cultural inventory. Well, what are the parts of that? OK, we'll tell you what the parts are. What are the common problems you're looking for? Here are the common problems you're looking for. Now, in your workbook, you're going to spend the next 15 minutes writing out longhand your own cultural inventory of the company you work for, because you've been there a while, so you probably already have an idea. And then without telling them that the next stage is, OK, 15 minutes is up. Now we're setting a five minute timer. Find somebody you don't know. Sit next to them. Tell them your stuff. And then they're going to tell you theirs. And what they learn from a whole three hours of moving around the room, comparing notes as we take them through these exercises that examine their appetite for change agency, they are going to find out that everybody has the same issues. All the companies have the same issues. So who succeeds and who fails? Well, it turns out you succeed if you have a certain kind of alchemical ability to mold yourself to be the ginsu tool that that culture needs, whatever that culture needs. And not everybody can make that shift. Some people are perfect for one culture, and then they can't do it for the next. There are people who can do it all the time, but they're also always monitoring where they're at. And this is going to become a specialty, I predict. So it's worth thinking it through. And I think all that stuff is online. I'm pretty sure it is, because we published it through O'Reilly. So it's probably on SafariU, that workbook. OK, you have to run as lean as you can. There are a lot of reasons for doing this. And my apologies to our hosts this week, but they're kind of the exception that proves the rule. It's important in open source and in inner source, in my opinion, to not suck up resources for its own sake, to not hoard money, to not tie participation to paying. You need people, first of all, to be able to use the thing whether or not they can pay. Often, they'll be more generous and more grateful than you expected them to be when it helps them, rather than before it helps them, which is what the sponsorship thing does. But also, you don't want to have to deal with the vicissitudes of the market. Apache, which we have modeled ourselves after, because at the end of the day, inner source is just the Apache way, fundamentally. That's what Brian saw it as, and that's what I see it as. Because we're modeling ourselves on them, we're also modeling how we run the organization from them, and they run as lean as they can. They don't actually engage in excessive fundraising for the size of the community that they have. For a long time, they didn't do it at all. Everybody was a volunteer. And so we are also striving to be as lean as we can. It keeps you from being a target. One of the things that happens, unfortunately, in the open source world is some of the larger aggregate foundations will notice a trend and decide that they want a piece of that. So the first thing they'll do is try to buy your foundation or your project. And if they can't do that, then they'll spin one up that's going to compete with you for fundraising. So once again, running as lean as you can means that you have more resistance to that strategy. And I am of the opinion that there need to be fewer monolithic foundations and more broad horizontally arranged foundations, because I don't see any upside in it. Part of what we were trying to fix with open source was that companies tend to grow like mushrooms and they get really big at the top. And in ugly, their stock barely holds them up. And then there's downturn and everything falls apart. Open source does really well in down times because we don't live that way, at least not historically. So Saline, there is a temptation to take more than you need. Now in Europe, it's helpful that nonprofits can't really hold over money as easily. But in the US, you can build a huge stockpile, as we see from some of our famous open source projects that have done that. Some of them have a lot of money in their foundation pocket. And curiously enough, they're not that relevant anymore, which I think is kind of interesting. OK, you do, however, within the idea of being lean, hire for gaps. That's things that you're not going to naturally get around to doing, that your volunteers are not going to be consistent with. And it's a problem, like bookkeeping. Frankly, marketing, because most of the people that turn up at intersource commons are engineers or engineering focused. So we pay for marketing. We don't pay much for marketing. It's an experiential hire for a lot of the people that work on it. We pay for, let's see, party planning, event planning. Because we used to do it ourselves, and we found that we were all exhausted at the end of every event cycle and ready to die. So now we have a staff that does a lot of that work for us, which is super helpful. They do the social media thing for us. Now, we all repeat everything that they do to get more reach, because we have more followers than most. I mean, when I say we, I mean, there's a few of us that have a lot of followers. And we just retweet everything they say. But it's better if you write something, you get higher ratings. I'm just saying you have to do this, even though you're living as leanly as possible. But there's ways to do this where you are giving someone an experience that they wouldn't otherwise have in their employment career that's going to help them in the long run so they're willing to do it for less money or part time. We have a lot of part time people that help us, and they get little, you know, pittances of money. But it's not like hiring a full time person. Is that everybody got that? OK. You've got to create the biggest tent you can. And that's because if you're successful, people will try to take your tent away from you. And one of the strategies that you can do to keep that from happening is make it really easy to work with you. So we have language versions happening now. We've got a lot of material in the source comments that we produced. Some of the early stuff was produced with O'Reilly, so it's pretty high quality. PayPal paid for it. Other stuff later is community built, but it's still pretty high quality. And we're starting to get people doing donation translation, which is great. It means they're really enthusiastic, and they want people to learn about it in their own language. There's two problems with it. One is, we're not exactly sure what they say. Some of the romance languages, we have people around who can read it. But Chinese, I'm never going to know what it says. But we have a sponsor who has deep experience with NLP, and they're reading through them for us with the machines. So if they've snuck in the Molotov cocktail recipe or something, we'll know about it. So far, everybody's been really above board, so that's good. So there's that. There's a liability in versions that you don't know about. But the other liability of it is, and again, I'm saying I want a big challenge. So I want all these language communities. But if you don't think through how those language communities are going to interact with each other and with you, if you think you're a mothership, you get a problem. This happened in Wikipedia. I used to be the CTO of Wikipedia. And one of the big problems we were trying to solve was that all of those language versions, some of them had really big communities behind them. Like after the English Wikipedia, German Wikipedia is the next most important one. As Wikipedia was delivering new features that were useful for English Wikipedia, sometimes German Wikipedia would say, yeah, we're not going to install that one. And that was an interesting problem. The other thing that happened, they figured out how to fundraise while I was there. So they went from making $8 million a year, went from their direct appeal to over $60 million a year. Now, that has achieved $20 at a time, average size. So it really is a community outpouring of support for a resource that everybody thinks is really important. And they use the money to the best effect that they can. They're pretty careful about it. And they're carefully scrutinized as well. They produce an annual plan, annual reports so you can see what they're doing with the money. But there was a movement from the regional Wikipedias to get a proportional share of the fundraising sent to their versions. And they all wanted to start self-hosting. And there's a reason that everything's hosted in America. It has the most liberal free speech laws still today. And it also gets you out of the problem of a country that doesn't like the way that the border is drawn on the Wikipedia article, even though that's maybe the accurate drawing of the border, but they've got a fairytale they want to tell. We sometimes got people that were kidnapping the country guys for that country and forcing them to change it to the official story. And they do it. And then they go like this. And then it would change itself back because the community chooses. And they get the message that that individual person was not actually responsible for the content. And that was always weird for them because they always want to throw it to choke. But because it's under US law, they can't do anything about it. So that's why all the editable content in Wikipedia lives in the US. So when you're settling a bar bill, or bar bet, I should say, and you're just trying to get the information up so you can see, that happens really fast because stuff is cashed everywhere. But if you're going to actually edit, you have to hit the US. So if you're from India, that means you've got 13 and 1 half hours of latency that you're dealing with in signals. It's not amplified anywhere. So stuff like that, the big tent of fact can have unintended consequences. But the reason you want it is because you want a group of people who will be upset if somebody tries to co-opt you, which will happen if you're successful. So you want loyalty to the fact that you're providing high quality content, you're doing it generously, and you're enabling people's changes. So we don't mind when people pick up our code and do stuff with it because it's licensed under Creative Commons, share alike, be why share alike, which means it's really clear what you can do with it and what you can't. You have to attribute to us. If you modify and make interesting changes, we encourage you to give them back to us because we're trying to create a center of resources that then everybody can take and localize if they want to. But we'd really like a two-way street where people give back. So we don't really police for companies that are setting up and stealing our stuff because we don't see it as stealing. We see it as spreading the word. And right now, we're getting into a list of consultants that you might want to hire because people are starting to want that. Now, I am a consultant for Inner Source. I don't depend on that work. I do it mostly to understand what's out there. But I want the people that have really gotten good at it to have that avenue because they love it. They like making the change. So I do want to say, these are people that we know are doing a good job of consulting to you. They're an awful lot of people out there that will tell you that they know how to do this. And some of them are pretty famous. There's one person in particular who periodically tweets at sort of short or blogs, a short version of how to do Inner Source. Inner Source is easy. You do this, and then you do this, and you do this. Item number two is develop a maturity model. So there's a lot of stuff in there that is going to require some of these help. Anyway, that's fine as long as they're really doing Inner Source. I don't care. Not everything you try is going to work. You just got to resign yourself to that. And when that happens, you have to be honest about it. The latest one of those is I'm famous for putting term limits into every open source foundation that I work on. So starting with the OSI, which I ran for 10 years, the last thing I did was put in term limits so that nobody ever did that again because I was really pissed off by the end of it. I didn't want anything to do with it anymore because I had burnt out. So we kind of agreed amongst ourselves that six years was a good amount. So I almost always put in language that says that board members will serve for not more than two consecutive three-year terms. And then they must take at least a year off before they come back for more punishment. I think this is really healthy. It's really healthy for the organization. It's really healthy for the individuals. My friends in the back row who work in open source are like, yeah, that's really healthy. Well, guess what? If you graph that onto a brand new organization, you create the situation where all the people have to leave the same year that you need to keep. And so we had to back out of that. We had to come up with another answer. Some of the people that are really helpful to us got pushed out of their board seats because of the rule, because we have people that really want to stick to the rules and you've got to honor that. It was written down. It was a rule. That was my bad. You have to say, oh, God, unintended consequences. Can we figure out a way out of this? And be honest, you know? This is human endeavor. All right. And then the last thing and kind of the most important thing, how am I doing for time? Oh, pretty good. The most important thing is it's about people, just like open sources people. These are intentional communities. They're not easy. Intentional communities are never easy. And this is no exception. So I'm going to give you, this is such an important one that I'm going to give you three exercise that just talk about this inner sources people idea. But this is a picture from one of the recent summits that we did, virtual summits that we did. We now have to do virtual summits forever, which is why I'm going to linger on this picture, because we were getting an average of 300 to 500 people at our in-person summits, which a lot of throughput, a lot of good information. But we're getting 10,000 people at a time at this. You can't see it, but there are pages and pages and the Chinese people aren't even represented because they're doing their own mirror and doing it all in Chinese. It has hugely increased our reach. And because we're in the business of educating, we're an educational non-profit 501c3, we have to educate, so we have to keep doing this forever. And we've just opened a CFP for this if anybody's interested or listening to this makes you think that you might be able to bring something to the community from your open source practice, we'd love to hear from you. And that CFP is open now. And it really is a very, very nice community. Okay, these are my notes for how to do that. First of all, if you are a person like me, you have to really work hard to not dominate. And let me explain why I tend to dominate. It's not actually my normal nature. I came up through tech at a time when there were very few women. And in order to succeed, I had to be a ball buster. I had to. I had to be able to talk over the guy that was mansplaining and missing my point on the phone call or in the room. I had to not care what people said about me. There were a lot of things I had to get used to, right? That are not conducive to helping people who don't have that set of skills or afflictions get there, be nice to each other, right? So I have to step back and think about another way to talk about it and feel about it. I have to take feedback that I would normally defend myself against, but that's not how we run in our first comments, right? I have to draw out people that are not speaking in meetings because they don't feel empowered to do that. I have to make them feel that way and model that as a behavior. We say hello when people join our general channel. If it's not me saying hello, somebody does it. It's not a bot, it's people saying hello, tell us about yourself. Or if you don't want to, that's okay. We don't care if you tell us your cultural, or your affiliation. We run under Chatham House rules. And when I did that, when I made that choice eight years ago, I wasn't hearing about people using Chatham House rules for this purpose, but I hear about it a lot now, but I'm gonna explain it real fast in case you don't know. Chatham House rules developed by the Chatham House, which is a think tank in England. They decided that better quality conversations would ensue if people felt safe, like they weren't gonna be outed for not knowing the answer to a question. So you are not allowed in our community to use what you heard to talk about another individual, the individual who said it, anybody who commented on it, or the companies any of them work for it. We will boot you if you do that, unless it's a publicly known thing. I do it sometimes because the companies that I'm talking about have told me it's okay to say what they're saying, or they've spoken publicly, because all of our sessions for Inner Source Commons and all of our community calls, the original presentation gets put up in our YouTube channel and we've got hours and hours of those now, and we count that as it's okay to talk about this, because we give them the opportunity when they're submitting the talk to tell us if it has to be embargoed under Chatham House. And if they say yes, then we don't post it. So that's a real thing. All right, a lot of the people that are sticky in your community want to be you. God help them. They want to do what you do, right? And I don't even know how to tell somebody how to do what I do, really. Yeah, and so, but I want to help them in that aspiration because they are your stickiest proponents. They're the people who keep your community together. And as it scales out, they're the ones that, I don't have to answer things authoritatively very often anymore because my board and the people that have served on the board know those answers pretty well and they're pretty good about answering, so I don't have to, which is great because this year, this next year, 2023, I am going to step back from being the chair of this organization for one year because I've been there since the beginning and I'm already two years over, although we only incorporated recently, so technically I'm doing it early, but because I'm on year eight, I can spend year nine, right, out, and not really out, because I've got a bunch of stuff in my head that I have to externalize and I don't have time to do it now. So I'm planning to take that time to write down all the stuff that I keep forgetting to write down, to give to the community. And then at the end of that year, I'll come back and offer to serve again and they may not want me by then, but if they do, that'll be an example of how you do that as a board member, so that's why I'm doing it. Helping people step into this life, we all have to do that. There are not enough people that know how to build community in these communities. There are a lot of people that are in them, but they aren't intentional about their involvement in them and they're not necessarily learning very quickly. So I feel like it's all of our jobs to do this, both to model the right behaviors, but also to take on mentees, teach them, and I do a lot of it, I do a lot of it. And I also disclaim like crazy, like you may have to throw out most of what I'm saying because I'm kind of a unicorn, but this is how I do it kind of thing, right? So if you start seeing a lot of people that play it like I do, that's probably my fault, but I don't know how else to help them. So anyway, you gotta do it. And you gotta come up with structures that help you do it. And then if you are not praising every contribution, you are so screwing up, especially somewhere like intersource commons, you need to model that behavior and also pound it into people how important that is. People are volunteering, except for the very few people who get paid, but even they have to be praised for everything they do. It makes the community so much nicer. And I'm not talking about that weird thing that happens in America with little kids who play soccer and everybody gets a trophy. No, you had genuine praise. You need to not give the same praise to everybody all the time because then it's not real. Find ways to highlight people's excellent work, especially risks they take that pan out that you help them with because being a cultural change agent is a risk-taking endeavor. It just is. And sometimes you win and sometimes you lose. It's your community that holds you together. When you get fired because you overstepped it, it's your community that's gonna find you your next job. Like we're in it together, so you have to do this. And I think that might be the last of those. Intersource Commons is doing really well. We have sponsors. I decided not to put any of the pictures up of who sponsors us and all that because you can find all that on the website. The people that work with us change from time to time because, again, most of them are part-time, the ones that are paid. And they check in and out when their forever job turns up or whatever. But the woman that is our executive director does a great job of running all of that. She's also a part-timer, but she's pretty stuck to us for at least the foreseeable future, I think. And there's some really big companies are using this to fix their engineering. And that is very exciting. To me, the best thing I can tell you is we have a 600-pound, 6,000-pound gorilla now in our room, which I can tell you about because it's public. IBM is using Intersource, and they're going to try to do it across all of their engineering. Microsoft has said the same thing, but I'm going to talk about IBM because of the way they're a center of gravity. They started with a different name than Intersource. They were aware that Intersource was a name, but they told themselves they needed to change it for cultural reasons. In general, I'm in favor of people coming up with their own name for their own culture, but I'm not at IBM because when they publish the case study and they give it another name, everyone will start using that name. Except for fixed disk, which was a bad mistake on their part, everything that they do, it becomes a thing. So we basically made the case for them not to do that, and they listened to us, and that was great. So that tells me we're doing really well. All right, so now is the Q&A. Did I say anything that made people unhappy or does anybody have something to comment, Ben? Yeah, having been involved in some small communities, if you don't document what people are doing, is it difficult when you try to hand over or when you try to be transparent about the process? Yeah, you're right, I should have added that. Happily, because we're using Apache methods, they already have documentation, and we have people who turn up, and as soon as we give them agency, they say, what can I do to help? And we say, you're new, document what you're seeing, what you're experiencing, and that will be helpful for everybody that comes after you. So we have a pretty good set of documents about how we run things, but we are basically using the Apache model. So for instance, our board meetings. Everybody has read everything before the board meeting starts because it's in GitHub and you have to approve it, right? Which shows that you at least open the file. And then they get automatically merged into the eventual minutes and it's all, it's as easy as it can be because of the work that Apache did before us. Anybody else? That's a good one though. Yeah, oh, that was a stop. She says I have to stop now. I apologize, but I'll go out in the hallway if anybody wants to have more conversation. I'm happy to do that. And if you've not checked out in a source commons, by all means come and look at it. If even if you're just trying to see if what I'm talking about is true, and if you run into something that isn't true about what I just said, please let me know because I'm telling you what I believe. So thank you.