 You haven't heard it yet. Settle down. So, hi. As mentioned, my name is Brian Prophet. I am a community architect with the Red Hat Open Source Program Office, and our team's responsibility there is to maintain the health and good standing of many of the upstream projects with which Red Hat works in the open source ecosystem that eventually will become our product. And as part of that job, one of the things that a lot of us and our team does on a daily basis is try to determine exactly what determines community health in the past. This has always been a process where we've gone by our gut feelings or our past managerial experience. We've come through and we've said, you know, well, based on my prior experience, I believe that this is what, you know, a healthy community should look like. For the most part, that is an effective strategy. However, to standardize that and quantify that and get actual numbers behind it, then it becomes a much more interesting challenge. And that's basically the subject of our discussion today. So data is one of those things that can fake you out very quickly. Like any kind of visual image, if you stare at that, I think long enough it'll freak you out a little bit. I don't know if it's working. Okay. So visual, like human beings are basically, we are designed to be visual creatures. Because everything we do as a reaction is based on our sense of sight. We recognize patterns because if we didn't, we get eaten by a tiger in the jungle. We recognize movement because, again, we would get eaten by a tiger in the jungle. Or to flip it around, we need to find food that moves, so we need to figure out quickly what is happening. So our brains are very much wired towards visual input. Because of that, when we quantify things by data in a visual form, sometimes it can kind of throw you off. So to give you an example in nature of things that might look really pretty but would also throw you off, let me introduce you to the blue dragon. And this is a wonderful looking creature. It is a three centimeter long sea slug, also known as a sea angel. So right away, it's giving you a pretty good vibe. This is really pretty and everything, except for the fact that it eats Portuguese metaphor jellyfish, which sounds like a good thing for those of us who have problems with jellyfish. However, if that means it keeps the venom from the jellyfish inside its own body, so if you touch this thing, welcomed in your paralysis. It won't kill a human, but it won't really feel well, and this is pretty much how it eats. Again, beautiful but harmful. And then we can, of course, forget the mantis shrimp of song and story. This is a basically 15 to 30 centimeter long crustacean, which has the ability to see more colors than any other animal. The human eye, which I've mentioned before, has three color sensors within the human eye. These guys have 16. They can actually see colors that we can't even imagine, let alone visualize. And based on its coloring, you can see it pretty much takes advantage of that. What it can also do, and this is the dirty part, is those front appendages there, they can accelerate them to the velocity of a rifle gunshot, which will end up delivering 1,500 newtons of force. And that's basically so fast that there's actually a light reaction in the water called cavitation, which generates a burst of light when they do their appendages like that. Interesting side note, you can't keep these things in aquariums because they will either kill everything in the tank with them, or they will break the glass on the tank. So, you know, pretty, but again, deadly. But getting that back to how data is managed and how it works. We have a problem as human beings of being faked out by what we see. We all come into a conversation or a situation with our own preconceptions. That is normal. That is how we operate as human beings. We come in and my experience is different from yours and yours and so forth and so on. We carry these predetermined thoughts and reactions to what we see and hear. And the common cliche for this in the English language is we see, you know, not seeing the forest for the trees. We can either get too focused on the minutiae and not see the big picture or we see the big picture and we don't realize that there's something going on with the individual trees. Okay? This is a common problem that we have as human beings. This translates over to data interpretation very quickly because that is basically a visual medium. We don't usually hear data. We certainly don't smell data. We see it either as charts of numbers or actual visual graphs or something like that. So to give you an idea of how that works, let's take a look at this. This is actually a couple of years old. This is the world's biggest data breaches and hacks from 2017. So it's a couple of years old. And you look at this and each circle represents, you know, whether or not it was a breach or an actual malicious hack based on the color. And then, you know, you have the different organizations and the number of accounts that were compromised by these individual incidents. And this picture tells you quite a bit. If you're a security expert, it tells you that, yeah, I think I could get a job at Marriott Hotels, you know, because they, well, at least a couple of years ago, they clearly need some help getting their systems locked out. If I look at this as like the average consumer who's out on the internet every day, I may never want to leave my house again or use any kind of online account, okay? So, you know, these kind of old stories are valid for how you're looking at this and what preconceptions or motives you have for looking at this kind of data. This is a little bit closer to home. Now, this is unfortunately a little bit hard to see on this particular slide, but what we're looking at here, this is a collection of data from a community in Red Hat around the OpenShift platform. And if you're not familiar with OpenShift, it is a Kubernetes distribution that manages the orchestration of Docker containers and other OCI compliant containers. And this data is just one piece of a much larger dashboard that shows the level of get commits and get authors and there's mailing list traffic over there. There's usually IRC data in the middle, though this particular data, the link wasn't working very well, but generally what we're doing here is we're looking at a cross-section of activity within a very active open source community. And this is actually a tool that we in our open source program office used around OpenShift and other upstream communities like RDO and Overt and Gluster and Seth. And we had this data for about two years. And we had a problem with this data because the problem was it was basically like a fire hose of information. We were under the misapprehension and I will say that I was a big proponent of this, where if we had a way of seeing all the data coming in and seeing the traffic and we would be able to determine trends in our community health based on what we were seeing on dashboards like this. And again, this is a static picture, but I can tell you that you can drill down at each one of these tiles and get very detailed information. So problem solved, right? Well, no. Our community people and myself included were having trouble sort of determining what was going on in our communities as a general trend. We were getting a fire hose of information in and not really being able to process it and do anything with it. I would say that the bailing was pretty much on our side of the equation. I'm not here to tell you that what Viterchia does, and it's a company based out of Barcelona, Spain, they do a great job with this kind of thing and it might be useful for your community. But I think for our part it was a not because we weren't ready with the right frame of mind to process this data. And what do I mean by that? So we determined very quickly that just having a big picture is not necessarily your best option. We determined that we didn't really know what questions we needed to ask about what was going on with our communities. We just thought that if we saw this data and it was coming in that it would magically, a light bulb would go off and everything would just make perfect sense to us. And that was really not the case because what we quickly learned is that we didn't even know what questions to ask. We hadn't taken a step back and prepared ourselves to understand what makes a community healthy. So if I throw this out, and maybe my teammates refrain from answering because you already know where this is going, let me ask you, just throw this out there and just jump in with an answer. What do you think makes a community healthy? Trust. What? Trust. Trust? Among the community. OK, how do you measure trust? You seem like a nice guy. I could probably go into five bucks and give it back to me. But how do I measure that? So let's think about, let's narrow it down a little bit more. Measurably, what would you take with the aside of community health? Ashley, can I share? Yeah, so one person as opposed to being the one who commits for one. Right, yes, so commit diversity. Yeah, so, right, exactly, that's a great one. Anybody else? I'll tell you one that usually comes up. And a lot of people fall for this is downloads, right? I know. Yeah, some of you already know the answer to this, settle down. Downloads are not necessarily going to be a good thing because Mozilla, and I always pick on them, and I always have to put it in the caveat, Mozilla is fine. What I'm about to say is not true in any way, shape, or form. But Mozilla has hundreds of thousands of downloads every month or even every week of their software. So it would be a relatively straightforward assumption to say, well, they are a very healthy community. That is not the case. For all we know, and there's not, but for all we know, there could be this massive infighting going on within one of the Mozilla communities. And they've been having this argument, and there's about to be a huge fork, OK? We as consumers of the software who are downloading the software over and over again, we would not understand. We would not even know that. We would just assume, falsely, that the community was healthy, just by number of downloads. So downloads is not really an accurate measure of community health, but that was one of the things that people were using. And we, even as our team, we were having discussions about this and moving forward. And we had to drill down into other questions, like what Ash had mentioned, and Carson. So how often does it, some of us have to do with completing health? Right. Yeah. Exactly. And that is also an easy trap to fall into. I've fallen into that trap a million times. Because, yeah, I would say, yeah, if you asked me to list a number of the healthy, non-Red Hat communities out there, I would probably put a little up the top of the list. And I'm just guessing that based on the fact that they seem to be relatively successful in their releases and things like that. But again, that's anecdotal. That's not measuring. So questions are critical. And we needed to figure out what those questions were going to be. Because once you have the good questions, then the answers in the data become more apparent. And then they tell the story that you want to tell. So basically, this is a very long way of saying that we needed to have more of a scientific, experimental method with approaching how we look at communities. We needed to have a hypothesis. And then we needed to have a test of that hypothesis, ideally repeatable. And then over time, we would be able to test what our hypothesis was based on what we were seeing. And then if it was repeatable, we would have fairly conclusive results. And then we would get a narrative that would talk about the health of our community. So that was step one. Step two, that became, okay, so what questions do we ask? What do we, you know, let's get down to it. We can all be high-minded and things like that and figure out, okay, we gotta ask questions. Well, what are those questions going to be? Because if I'm working on, say, a five-person development team and we're building a really cool little security package that fits inside of a larger project, then that's my community. Versus a community like, say, OpenStack, which is multiple organizations and many hundreds of developers working on different modules within OpenStack, okay? It seems like, on the surface, there are questions that would apply to a five-person team versus questions that would apply to a five-thousand-person development community with documentation and QA and everything else thrown in the midst. That would be really hard. And that was one of the challenges that community managers were facing over time because there was this notion that, well, what applies to my community does not apply to this one over here. We can't ask the same questions. Turns out that's not exactly true. And the way to think about this as we approach the idea of standardized, quantifiable questions to ask is think about where you live. And you may live in a large city like Boston. Or you may live in a tiny hamlet at the top of the mountain in Switzerland. Or where, you know, in every place I'll spend in between. They're all, they're both communities. But obviously they have, you know, obviously different sizes, different demographics, things like that. How do you measure the same things? Well, even though they are vastly different looking, these communities share a lot. They all have to have some form of transportation. And the village in the mountain in Switzerland, it might be a couple of dirt roads going in between the houses. In Boston, we've got thoroughfares and streets and expressways and subways and mass transit. But we still, they're things that get us around in each city. They both have to have a water supply. And the village, it might be a single well or multiple wells or whatever you've got. In the city like Boston, it's coming from a reservoir system, massive infrastructure coming in. You name it, we've got it. But the questions are still the same. How are you getting water? Are you getting water efficiently? Is that water clean and drinkable? The basic questions are the same for the small community in Switzerland on the mountain and the big giant city in the US. And again, everywhere else in between. That's how you approach looking at these questions around community and community health. You don't really care about the size. You don't really even care about how it gets done. You care about is it getting done and is it getting done consistently and efficiently? I don't care if the water's coming from a well or 500 reservoirs out in Western Massachusetts. As long as water is coming to me so I can get to it as needed, I have a helping hand. And that's how we sort of approach these. And this is where we come into just the conversation about talking about community health. And as I mentioned before, until we started really looking at data and starting to really ask the right questions, community health was really sort of a role in the dice. I feel like my community is healthy because I haven't had anybody trolling on my mailing list in the last three months. Right, maybe that was a problem before. And you feel like okay, that got solved, so I'm okay. Well, okay, but maybe you have a problem with people coming into your community. Maybe you have a diversity problem where you don't have enough people, a certain gender or race or whatever, coming into your community and staying in your community. Maybe people feel like they're not welcome. There are hundreds and hundreds of different things that can throw off a community very quickly. So we started asking, what does it take to make the community healthy? And there are a few core ideas here that I want to examine with you and talk about as a big picture, these are the areas that make communities healthy and that we are trying to examine both within Red Hat and within the project I'll tell you about and a little bit within the Linux Foundation. So the first one is evolution. Now evolution is actually a clever relabeling of what you might be familiar with as a business term, the growth maturity and the climb model, okay? So you're looking at each project, what stage is that project in? Because that stage or state, if you want to talk about developer speak, is actually important to the rest of the questions that you ask. If I have say a brand new project that has a governance structure of a single benevolent dictator and a few other people working on the project, well, if it's brand new, that makes sense. You just got started, it's just a bunch of people getting together and working on something cool and new and they said one person's gonna be in charge. So that makes sense. If that the same thing you've got five years later, when you've got hundreds of developers and still that one person in charge doing all the oversight and decision-making, that would be a mature project and maybe not really so much a very healthy thing. Same governance, different states, there's a problem. Okay, and that's just one example. So we look at evolution in terms of how is code developed? It's not just like the governance structure or the size or even the age of the project, although those certainly come into play. So we're looking at things like code development. So aspects of how the source code changes over time. If more and more developers are coming in, have you adjusted your workflow to accommodate more developers? Or have you built bottlenecks into the system that really should be gone because you're not scaling up properly? The growth of the community, as I mentioned, is a big thing. Are you growing? That's always good. And then are you growing efficiently and adapting your processes to that growth? How do you resolve issues? Have you, again, that gets into that governance model. Is it just one person doing all the deciding? Or is it, have you accommodated and built like governance boards or more maintainers or whatever governance you decide to do? These are things that we talk about in evolution. The second area is diversity. Now, diversity is actually a few things. One is the standard way that we think about diversity in the technology industry today, when we're applying it to race and gender and religion and sexual orientation and so forth and so forth. These are all human-based diversity things and they are all very important. The more diverse a community is, the more we get back to what I was talking about earlier where we all have these subjective experiences that we're bringing to the table. And the more we have differences in those experiences, there's a pretty solid argument that says the more creative your solutions are going to be. But diversity also goes a little bit beyond that into things like corporate diversity. If we have a project at Red Hat that, say, has 88% of people involved in the upstream project work for Red Hat, is that a good thing or a bad thing? I mean, yeah. Well, for Red Hat, it's great because I just basically say, oh, we're gonna put in these features and that's what's gonna happen and that's gonna show up in our downstream, right? So for us, it sounds like a pretty good deal, but here's the problem. The other 12%, they're gonna feel marginalized and left out. They're probably gonna leave eventually. And the other thing is, who knew it's gonna come in? If somebody new comes into my project and says, why would I wanna contribute to this project because Red Hat doesn't like it, they're just gonna turn it down. Not that we do that, but that is an assumption that somebody would make. So that's a problem. And we are actually, beyond that pragmatism, I should emphasize, we are big believers in having a lot of diversity. Some of our most successful projects are projects that have a vast amount of organizations and volunteers involved, Fedora, which I don't know if everyone's familiar with it, Fedora is the upstream project for Red Hat Enterprise Linux, which is probably one of our most key products that we have. It's the platform from which most of our other products are built from. Fedora, the last time we did a survey, is somewhere around 30% of Fedora active Fedora contributors work for Red Hat, which surprises people. Because again, I just said, it was one of the key projects that we have. I mean, that thing's gotta be healthy because almost everything else we do ties back into that. Only 30% of the people actually work for Red Hat. And that's great because the other 70% are in there working on the same kinds of code and they're getting what they need and putting in what they need and then taking out what they need for their own projects outside of Fedora. So Fedora is a classically great example of how corporate diversity should work. Sorry, I lost my mouse here a little bit. Other things that we talk about when we talk about diversity. Not just the bodies that are inside the community, but we're also talking about what is the leadership diversity? Is it always the same people in charge and not just the same people working for the same company, but is it like this click of people? Because this happens a lot. Human beings are habit-forming. We love to have the same people around us all the time. If we work well with a certain group of people, we want to continue to work well with a certain group of people. That's great, but sometimes you've not included other people inside that to get new ideas and new leadership. So what is your leadership diversity? What is your governance diversity? Do we recognize good work? These are all diversity questions. How, if a new person comes into your community, what's the path for that person to become a maintainer? Or a member of the technical action committee or whatever your governance model is. Is there a promotion path? And is that promotion path the same for everybody? And that's some of the questions we ask around diversity. The next one is value. Now value, this one's a little tricky because I've actually had, I've done a presentation like this for an academic conference actually here in Boston earlier this year. And academics look at this and they're like, yeah, but we're not trying to make money with our open source projects. We're doing things for scientific value and scientific research and things like that. That is absolutely true. But the value of questions still remains because whether I'm getting my value from how much money am I putting in a project and how efficiently am I getting a good code out of it, that is certainly a value question. You can take that to an academic point of view and say how much money am I getting from my grant and am I getting the right kind of code and the right cadence even on an academic schedule out of the software project or am I seeing results? So value, it's a little bit different with academia, but it's not really a straight up profit and loss spreadsheet, but there is still valid value questions to ask. What is the value of the project itself, which I mentioned earlier? What is the project? What is the value of how much of the work do I do out in the community? And it's done by volunteers away from my company? That's worth something. That's the last time that I, when I take that and make a downstream product, that I have to worry about Q and A and things like that. So there's value there. There's ecosystem value. If my project died tomorrow, what would happen to the rest of the open source ecosystem? The classic example of that was SSL, because it had a major vulnerability a few years back and a lot of software uses SSL to, I'm sorry, open SSH, I said the wrong thing. Uses that software as part of their security package. If that one project failed, then a lot of other ones would suffer because of it. So there's value in the software itself beyond just monetary value. And then we have risk. Risk is probably by far a bit of the nebulous area, and there's some overlap. I just mentioned the value proposition of a project. If that project dies or is injured, it has value because suddenly its failure becomes a problem for other projects. That is very much tied into risk as well. So those two overlap at that point. What is the risk of this project? One of the classic examples of this, and you probably have heard a variation of this scene before, is called the bus factor. And this came up back in, I don't know, 2005 or six or something, when the Linux kernel was really, really taking off. And suddenly, you know, businesses were adopted, Linux left and right, and people kind of looked around and they were like, hey, what happens to Linux that means torbols get hits by a bus? Okay, and at the time, people were like, oh my gosh, this is, that would be the most terrible thing ever, and millions of dollars would be lost. That was never true because we must learn pretty early on that even though he maintains that benevolent container model for the Linux kernel, he has enough maintainers, they could basically pick up the slack, so if he were hit by a bus. The aforementioned OpenSSL, which only had, I think at the time of its vulnerability, there was only one person working on it, that was a terrible bus factor. If he got hit by a bus, then, you know, that would be catastrophic for that project. So when we say projects have a bus factor of one or a low number, that is another example of risk. And by the way, the nonviolent version of this bus factor is the lottery factor. We always like to throw that out for, you know, those of us who are pacifists because it's like, that's basically, if somebody wins the lottery, they're like, see ya, and we're out the door. You know, not that I would ever do that, but exactly, you know, Tahiti is wonderful. So, but that is a risk. What happens if somebody leaves? Somebody has to change jobs, they move to another city, their spouse moves and they can't do what they're doing. These are things that involve risk. Other kinds of risk entail code quality. If you don't have a good code checking infrastructure and you don't have a good QA in testing process in place, more bugs get into the equation, you have risk of software failure and also, you know, a public distrust of your product and possibly your community as well. Transparency is another thing. Transparency and not doing things out in the open is a risk. If you keep things closed and decisions are made behind closed doors, then you run the risk of alienating the rest of your community. And to give you an example of like, how easy these things are to fall into the trap. The transparency one is always a great one for me to do because I've done this a hundred times where I've seen a problem in a document somewhere or a code somewhere. And you've probably all done a variation of this. And maybe you're working in a physical office or maybe you're working in a virtual office, but you turn to your neighbor whether they're right there next to you or you know, on the other side of a video call how are we to communicate with them? And you say, hey, I've got this problem. Can you take a look at this and see what's going on? And they look at it and they're like, oh yeah, I know how to fix this. And they give you the answer, you fixed it, you submit the patch always well. What's wrong with that picture in terms of transparency? Well, I mean, nine times out of 10 really nothing because it's usually a pretty small fix and it's in there. That was not a transparent thing. Two people had a side communication, probably not on the public mailing list or public IRC channel or wherever the community is working. They had a side conversation, took two seconds. What's wrong with this? Oh, this is wrong, fix done fine. But that's not transparent. And over time, that kind of habit that we've all done can trip you up. So this is why we, even within Red Hat, we have to constantly remind ourselves, do things as much as you can out in the open, right? That is a really key message. And it gets into the value of, or the proposition of risk. And then finally, everything else. So I didn't just pick these five areas of community health, the top of my shining head. There is actually a method to this organization. These are all the five different organizational groups that we have in a project known as Project Chaos, C-H-A-O-S-S, which is community health open source software. I can always strip up on the A, thank you. And that is a sub-project of the Linux Foundation. And what Project Chaos does is we are building metrics around those five areas. So before I get into that a little bit, let me talk to you about what common means. And this is actually an area I get really, and one of the things that I work on is the organizational affiliation metric, which I mentioned to you early before. It came up in the evolution group. And it's one of those that actually sort of applies to all the four other groups, which was why we sort of put it out in common, because it bridged a lot of the different groups. Organizational affiliation, as I mentioned, is basically around the question of how many organizations are working in any given open source project at any given time? What's the percentage? How many are actually committing? How many are actually approving commits? How many people are on the governance boards? And from how many different companies? And the belief is the more diverse those elements are, the stronger and healthier the community is. So this is where we get into. We also talk about geography, which sort of bridges over to diversity, but where are our contributors located? That's a big kind of big deal. If a lot of your contributors are in Europe, they've got certain work patterns that they're gonna follow. They get bigger vacations, way more than Americans do. But those are key differences in culture and work ethic that are gonna show up and are important to any open source project. And then response of this. How quickly does a project respond to problems and situations? Again, that one sort of bridges a lot of different areas. So we've thrown it out into the commons group, sort of the catch-all, so to speak. And what project chaos has done? And the website is chaos, again, C-H-A-O-S-S, chaos.community. And I invite you to go out there because what chaos is doing is we're actually releasing metrics in all five of these groups. We just released our first series of metrics, got my days wrong, three weeks ago, and we actually have released a series of metrics around organizational affiliation. So it now will become a standard, we hope, for anyone who wants to figure out what are the questions to ask around organizational affiliation or any of the other metrics in any of those other groups that were released. The idea here is not only, it's not just a theoretical discussion. By standardizing these metrics, part two of this is going to be on the software side. Software companies like Beturgia, and there's Apache, Kibble, thank you, thank you. So Apache Kibble. Those are two projects that I can name off the top of my head, although apparently not very well. So that do metrics analysis of communities. So Beturgia and Kibble can use these metrics and integrate them within their software. And now as community managers and community leaders or people who are interested in community health, we can analyze different communities based on these standard metrics with these tools and get a fairly consistent set of answers. So that becomes an important part of what Project Chaos is doing. So with that, I think I did okay on time, I believe I am finished, so I'd like to thank you that I can open it up for questions. Thank you. Yeah, I believe we have five minutes left in the session for questions. If you could try to stay behind the podium so that we can record them and I can bring the microphone around to anyone who raises their hand. I think it's gonna sound like a funny question, but. No, I'm sorry. So you did, thank you, I'll be here all day. So you did mention as part of community health and a diversity that you do look at the amount of, say, Red Hatters in the community of the people that make up the contributions here, how many are employed by us. Does that factor in the risk? Yeah, I mean, it could factor in the risk. I mean, for a company like Red Hat, we're not gonna probably disappear overnight. But if you were a smaller company and you were, like, say, a startup somewhere and you had, like, maybe 10 active contributors to a project of 40 people, if that startup were to fail, suddenly that's 25% of the active contributors who are now under some kind of stress. I mean, they're probably not going to disappear but they may have to change jobs and their priorities may change and suddenly they may not be as active as before. So yes, organizational diversity can run in the risk in that respect. I think for Red Hat specifically to answer your question, I think it becomes a risk factor in terms of, like, being, it gets into that whole value question and this is where it gets a little overlapping but people sometimes don't see value in open source projects that are dominated by single vendors. They tend to be wary of them. Not always, I mean, Google launched Kubernetes and all hands are jumping in on that. It's crazy town over there, you know? And RaxFace did OpenStack and that took off and went very well. But sometimes that doesn't work so it is kind of a risk factor because now you've got risk involved in how will my communities growth be limited by the fact that I'm dominated by a single vendor because that does happen and which is why we try to encourage diversity as much as we can. Any two minute question? So and because I recall in your talk you also mentioned the risk to the communities of like if Red Hat or a dominant company came in and made a decision that was domineering basically. So those kinds of things not being healthy to the community. Can you speak of some of the ways like why it's important to write out that the community is healthy in and of itself regardless of, does that make sense? Well, I mean, obviously when our community is healthy because we want, I mean, from a business side obviously the healthier community is more efficient it is the less money we have to put into it and it's better for our bottom line. So that's the strictly mercantile mercenary part of it but also like as a culture within our company and a lot of other companies that are invested in open source having a healthy community just makes life better for everybody. I mean, so that's, I, I, you know, it is you can have a vendor dominated project and still have a healthy community but I do think that it is important that you be cognizant of it and try to be working towards more diversity as you move through it. Because we have a lot of projects in Red Hat that I would call healthy even though we are dominating them as a vendor but if they stay that way, like if they were that way in two years or three years down the line then I would start having problems and that's what we're doing in our, in the open source program office we look at these projects, we audit them for these things and as we build the metrics and apply more standards and we start building a data set over time I think we're gonna be able to come up with definitive answers to the questions that we're now asking. Right, I think we're at time. Brian, are you open to more questions outside the room afterward? If you can catch me I actually have to head for the airport but I do have a few minutes for questions outside so that would be great. Thank you.