 Well, that's a good way to start. Wake everybody up. Hola! Welcome to Barcelona. So we're going to take a somewhat tongue-in-cheek approach to relating our experiences with OpenStack and dealing with enterprise customers, as well as our own organization. My name is John Arway. I'm a senior technical staff member with IBM. I've primarily been working on our internal CI system for the ZVM hypervisor. So it's an over plug-in. We also have neutron plugins coming along. And I have some mates here. Hi, I'm Emily Hoganbrook. As you've probably guessed, I also work for the ZVM hypervisor for IBM. And I primarily work on the testing side of it. So you can ask me afterwards about testing RepStack because I just want her getting our RepStack compliance for our appliance that we have included in ZVM. So I'm active in the Tempest project, also active in Women of OpenStack with the speed mentoring, if any of you guys went to the speed mentoring breakfast. And this is my fifth summit, which is crazy to say. Thanks. Hello, my name is Xi-Chan. And I'm mainly developing OpenStack NOVA plug-in for our ZVM driver. And also I contribute to the OpenStack NOVA project. So mainly in some review of our commit. So thank you. All right. As you're going to see, we've broken down the presentation fundamentally into three parts. And one is the more enterprise-y stuff, right? The stuff that our clients and what we found interacting with them around OpenStack. The second is the organizational changes that it's driven on our own development team. Which is a substantive different issue. And the third is a variation on the organizational pieces, teaching our own developers how to play nice with the community. Because of course, most of them came from a proprietary background. Big shock. So into the minds of Moria, we go. I did have to take a timeline here. And I was really glad in the keynote yesterday to see Annie point out that, you know, VMware has actually been around for a little bit longer than OpenStack's been around. And this just gives you kind of a sense for the timeline. All right, so if VMware has been a thing for, let's say, twice or three times as long as OpenStack, ZVM has been around a little bit longer. Right, by a decade or two. So it shouldn't be a big surprise if you find out in the course of doing something like a plug-in that the abstraction layers don't quite match and you have to do some creative papering over the differences. This is a very high-level architectural diagram of what we've got going on when it comes to running OpenStack on ZVM, right? I took the architecture by analogy approach here. So this we've got a hypervisor at the bottom. It's actually in two pieces for historical reasons not to worry about. Pretend they say KVM. Right, if you understand KVM, you'll get the right idea to first and even to second order. It's a thing that run guests underneath it. There's some of these guests in particular are fundamentally systems management stack for the operating for the hypervisor. That's the smapping open cloud pieces. Good here, Pico. Okay. The smappy layer is what you would think of conceptually as Limfer. All right, it's an API that the OpenStack plug-in pushes down onto. It's remoteable. It manages guests through the hypervisor, that kind of thing. So it's not radically different than anything you've seen. It's just the names are spelled differently. Right, and that hides a certain layer of abstractional differences, but still to first order the animals in the zoo are fundamentally the same. And the OpenStack piece is just like, you know, anywhere else. The plugins are written in Python. So you can run them on this hypervisor. You can run them on x86 if you like. Wherever you choose to. And we've got different products running in each of those situations. In fact, right now. So one of the first problems we had was our own clients are being told by their CIOs, you guys got to go do the cloud. Right, you mainframe guys go do the cloud. And sometimes the CIO kind of knows what that means and just as often not really. Let alone is their definition of the cloud the same as the OpenStack definition of the cloud. Right, that's obviously been a topic of some discussion on its own recently. What is the OpenStack definition of a cloud? So one of the first things we've ran into was you know, our own technical leaders in some cases sales people and other telling organizations that have remember some of them that are doing virtualization since the 70s. Right, so we're talking 30, 40 years. They've got a whole bunch of homegrown processes built around managing these pets or cattle whatever you want to call them. And you know, you get people walking and saying sure you can do cloud and you don't have to change any of that other stuff. Don't worry about it. Right, it's if you know OpenStack as you people do, you know, that's not really true, right? OpenStack has its ideas, you know, this is my playground and everybody else kind of get off. So you have to be careful about that and there's various ways you can deal with it. As with a lot of these things, the biggest issue usually is understanding you need to ask the question and probe a little bit and see what they mean. If they come to you and say, well, we need to do cloud, what does that mean to them? Right, we've had some of them come to us and when we probe a little what we get is we want to manage things exactly the way we're doing it today, which means we have our own custom scripts. We want to use those to create our guests to manage the CPUs and the storage on them, but we want a self-service portal in front of it for our developers to use. Right, you don't need OpenStack for that. If you're willing to give up some of those scripts that you know and love so well, you can use OpenStack, right, but it's not a zero change kind of an adoption. The second thing we have is sort of a larger variation on that same team to some degree, right? We've had clients come to us and say, okay, we've been told to do OpenStack and the CIO, I'm sorry, we've been told to do cloud and the CIO says we absolutely must use the OpenStack APIs to do it because our organizational orchestration standard product is thus and such and it talks OpenStack. Right, okay. So, you know, good, well-meaning people, not probing any further, it's always a debatable thing in 2020 hindsight, say, ah, okay, you must do OpenStack, we have things that do OpenStack, you want to run them on the mainframe, we have things that let you run on the mainframe, matchmate in heaven. Right. What the questions they didn't know they needed to ask at that point was, are you willing to give up those custom scripts and things that you've used to build and manage these guests for years that are hooked into your backup systems, that are hooked into your compliance systems, that are hooked into your license management systems? Well, and the answer of course was no, we don't want to give those things up. So there was a little bit of an organizational debate to go on. All right. You have to figure out how in this world do you do compliance. You don't have to do it through OpenStack. Right. But you have to be careful to articulate when something is possible to do and manage through OpenStack and when it has to be done from the outside. Right. You can't expect the kinds of enterprise clients you're going to get, especially when you're coming from executives or managers of IT infrastructure groups, to understand all the technical details of OpenStack that people in this room just understand. Right. Because you've sort of assimilated over time. They don't have that technical background and you need to help them figure out what the boundaries are because they still care about running their businesses. Right. Their compliance issues don't go away. Their license issues don't go away. They have to figure out how to make it work together. So you have to have some idea when you're walking in, at least of which of those questions you know how to answer and which of those you have to say, well, we need to sit down and figure that out, right, and do an architecture that works for your enterprise. Because of course they'll have different products they want to use. Sometimes they have homegrown kit, all kinds of things. You see the gamut if you talk to even a few customers. Third or fourth thing we've run into is the assumption that public and private have the same needs. And another way to think about this is are you trying to be a service provider or are you just trying to sort of run your own dev-op stuff in the cloud? Because they have very different business models and that forces different effects on you. You care about different metrics. When we did the Linux one community cloud as an example, which is a cloud running on ZVM, the first thing those people wanted to know was how many instances can I deploy in parallel in 10 minutes? Which is not something that in 25 years people had really cared much about on ZVM because it was always the system's administrators doing it. It wasn't end users. And the system administrators weren't going to conferences and on every chair in a keynote putting a little flyer that says, hey, go try out this cloud. And expecting a spike to come in in the next hour. So you get very different usage models that come out of that and you have to have different metrics sometimes for your own development group. We'll find, and Emily will touch on this again later, this is going to stress different parts of the stack potentially. With something like ZVM where that management stack had primarily been operated by humans in some cases by scripts, but still the scripts were directly being run by humans. It wasn't quite as automated as we're doing. New problems are going to fall out of that. Whether they're problems in the homegrown stuff or problems in the base, it doesn't matter in the end. Somebody's got to go figure it out and deal with it. One of my favorites being somewhat of a security weenie on the side was we went to one of our first major customers who's a large U.S. company. They do a substantial number of all the paychecks in the U.S. as an example. Every month they print paychecks. They do healthcare sign-ups as an outsourcing sort of business. Very large company, running on the mainframe. Walked in and we happened to be, just from a timing standpoint, we're dealing with Juno. So we got Juno in there and they said, okay, we want to hook this up to our enterprise LDAP system. And that's when we discovered, oh, there are some fixes that we need from Kilo back ported. Because otherwise the queries don't work. So you run into things like this. Obviously that specific example is fixed now, but the lesson is you have to understand how you're going to fit into these things they care about. Because they were actually fairly sophisticated. They knew they were going to have multiple clouds internally more because they're a service provider and they have certain different compliance regimes they have to deal with. And they wanted to allow the humans, their own employees, to work off the enterprise LDAP. But the service IDs like the Nova and the Neutron and your friends to have different credentials in each cloud. So that if one cloud gets hacked, it's not all of them. Very sensible security. That's the model they have in their head. We couldn't deal with that out of the box because of the Juno-Kilo back porting and fixes sort of issue. Another thing that can go wrong and certainly have to probe for is why are they doing this? What do they really need out of it? One of the criteria that kind of blindsided some people in the development organization was they came in and said, all right, we've been working on this for two months and it's just about there. We're ready to demo it to the executives. Oh my God. This other group inside did a demo with another cloud provider and they can provision, I don't know what it was, 20 and 10 minutes or something. You have to be able to do that by this week. The moral is you have to understand your competition is even within the company and what other groups are engaging because it's like any other change. Change is hard. People resist change naturally. It's cognitively loaded. So if you can provide something to them in a way that makes their lives easier, your conversations are going to be so much better. And it's not just you as an open stack district provider with the IT people running it, the operators. It's the end users. If you can keep the end users happy, the operators are happy, their managers are happy, they'll buy your stuff, oddly enough. Keep in mind that second level effect and not get wrapped up in the first level and just making the operators happy. It's also the people the operators are dealing with. Another thing you can do is make it as complex as possible. We made some mistakes in our first pass. We had some ideas about let's make this perfectly encapsulated appliance. They'll not have root access for lots of good reasons. And then, of course, as soon as you find things, they're all like, oh, this file isn't getting log rotated. And therefore, after a month of uptime, it fills the file system and you have to go in and do odd things. And you can't do them because you're not able to pseudo on this particular command. You can't edit this file. You're pseudo. Obviously, you have to fix those over time. But the point is you may actually need to be able to break that encapsulation sometimes. And you should be prepared for that. One of the first things I did after joining this group kind of midstream was force that issue of now we need to be able to pseudo as root, even if it's just for service purposes. We don't have to document it. We have to tell them that in advance. But we need a way to tell someone, yes, we've diagnosed what's wrong. Here's what you go do as a command and it will fix it until we can get you a proper service fix. Another bugaboo is the upgrade pace. Enterprises, because they have to deal with these auxiliary processes, the license management, the backups, the disaster recovery, the compliance. In the U.S. there's healthcare rules. In Europe here, there's rules about where your data lives. All these things matter, more or less, depending on which government you have to be dealing with at the time or which industry. Well, if it takes them three or four months to get through their internal certification process to make a new VM basically go online, which is not uncommon in the enterprise space, and you tell them every six months you're going to do a complete upgrade of the whole thing, they kind of toss a hairball on that very often. And it depends on their own maturity level. It gets into the organizational aspects as well. If they as an organization are also trying to do a lot more of the agile and the DevOps kinds of things, they may be more willing to accept frequent upgrades. But if they're gated by processes that are outside their control, like some of these compliance and certification tests, that's not only going to matter so much. In the end you're going to be gated by what they can successfully adopt and put into production because they've got the same problems we all do. They have to keep their bosses happy. The bosses have to keep the shareholders happy. They have to keep their clients that are paying the bills happy. This all rolls downhill, none of it's an isolation. So the upgrade pace and how smooth each one of those upgrades goes can make or break what you're doing. We happen to skip releases. We're going to do it once a year because for our customer set that seems to be the sweet spot. We know there are some holdouts that will go all the way out to 18 months. Okay, they're more risk averse than the others. That's allowed. But we at least give them a range of choice and we try to be upfront about this is your range of choice because it's more frequent than they're used to with some of these other products. Some of the other components in these systems, they only get a new version every four or five years. They'll get smaller bits of function in between there, but they won't get something called a new version with a whole upgrade path and scenario more often than every couple of years. So I think you had the message at this point, right? You can deal with these things. None of this is insoluble. It shouldn't cause you to go running scary into the bay and go, that's not the answer. The answer is to think about some of it before you walk in there. So you're not that dear in the headlights. You say, okay, what are your issues here? Do you have to deal with compliance? What are your processes today? So you can help assess which ones OpenStack is going to fit into and which ones it's going to fit less well with. So with that, Ms. Emily is going to talk to us about organizational issues. Cool. Thanks, John. So starting to talk about organizational issues, I want to tell you a little bit about our team to begin with. So our team is split between the US and China. Our US team comes from the ZBM hypervisor, so people who have worked on very proprietary technology, lots of emphasis on IP, on keeping things secret, on maybe a model of software development that would be the opposite of Agile. Wonderful. So working with that team had its challenges. Working then with the China team was completely a new team for this project, so bringing them into the ZBM org and getting them trained into our organization, as well as working on OpenStack and our drivers. So first big mistake we made, I'm sure probably a lot of us have made this mistake at some point, getting your own private copy of an open source code and making lots and lots of changes and only periodically pushing it back out. Because it's not perfect yet, it's kind of a lot of work to push it back out there. We started that probably with the China team, they were having some issues getting through the firewall to GitHub, and of course our US team was totally used to working with private repositories. So they said, yeah, of course we'll make a private copy of our working code and then like every six months we'll push it back out to GitHub. You guys can laugh at that. It was a really bad idea. So we have fixed that now, obviously, but not after a lot of pain and a lot of going through and then you wind up with a whole bunch of conflicts as you're trying to merge it in, and I don't recommend that. Going half in on open source. So John showed you the picture of our stack and we have our open stack drivers that talk to xcat, which is the extreme cloud administration toolkit. So that's another open source project that we support in zbm. And again with xcat, we had come from a place of the xcat community is a lot smaller than the open stack community. It was perfectly fine with xcat. It didn't change that often, so we were okay with doing this private copy of our driver and pushing it back up every once in a while. And so even when we started developing our open stack drivers in the open and doing all of our commits directly to the GitHub rather than to our own private drivers, we were still doing that with the xcat drivers. So now we have two different build processes. And so when you're trying to put things together, it's just a nightmare because you remember, oh, things go this way and part of it and this way and this way and part of it. And better just to do everything out in the open, bite the bullet, make the change. So lesson learned there too. John touched on this. We have a lot of existing components in our stack. And we had been using them in certain ways for many years in some cases. And then all of a sudden we were using them in totally new ways. Open stack was maybe pushing down on things a lot more often than previous solutions had been. And we found new stress points very quickly, especially with that Linux one community cloud. And yeah, it was a real shock to us. And so we had to put a lot of new test environments in. And it taught us a lot about how to test our stack better about the different stress points that we need to look at and how to really look at things differently there. This is probably the biggest one. Ignoring the organizational and cultural change. So not sitting down with the team before we started this and going through, OK, well, when you want to develop something, you're going to put a blueprint out in the open. When you want to work on something, it's OK to put small changes out there even if they don't have the whole function. People were used to this environment where it's a lot of intellectual property. And so they're like, well, I don't want to tell too many people about my design because it might get stolen. It's open source. Of course it's going to get stolen. That's the point of it. You put it out there to be stolen, right? And so not just addressing that change up front, not addressing the difference to management of how this team would need to be managed differently than the traditional team. So our manager has the open source team under him. He also has a traditional development team under him. And so we're competing with them for resources in a nice way because we all work for the same department. But when it comes to things like sending us to open stack summits, the question I get all the time is, which customers are you going to meet with? Because the budget for open stack summit travel comes out of the same bucket as the budget for customer travel. Well, that's not the point of the open stack summit. They say, well, you can't go to mid-cycles. There won't be any customers there. Well, that's not the point of a mid-cycle. And so not addressing this with management right up front, that these things need to come from different buckets. It's a new way of developing, and we need to accept that there are new ways then of collaborating and designing. And we need to do lots of education with the team too. And we need to do lots of education with the team to make sure that they understand that. In cases you can't tell, I'm the one who put the rainbow in the presentation. So how did we solve these issues? Well, it was a lot of scraped knees and pain. But we are working through it. We're learning to do a lot more education with the team. One thing we did was appoint kind of community liaisons both for our US team and our China team. So people who were working mostly facing in the community that they could come back and then educate their team members about how to work better in the community. With management, we actually started meetings with our manager, with managers of other groups that were wholly open source. And that has helped some. One thing that just came up the other week is my manager was saying to me, oh, I'm not sure this CI system that we have. Would that have caught some of the problems in the public cloud before they caught it? If we had had the CI system up and running two years ago? I said, yeah, yeah, it definitely would. It would have driven that level of load on the system and we would have found these different stress points. And he said, oh, I didn't realize that the CI system had that benefit. The CI system is not just a little change-by-change test system that it can also drive these big stressful tests and things like that. So doing this kind of education about why the open source community does things the way it does, why these things are important, and talking with our team about why it's important. We're also now reaching out with our business partners. So we work with SUSE, who includes our plugins in their SUSE Open Cloud Project, Open Cloud Product. Tongue twister there. And so we're working with SUSE and they're looking at our drivers and talking to us about our drivers, but there are other business partners that maybe are not as familiar with working in the open source community. So we're starting to reach out to them. We're starting to work with the Open Mainframe Project, which is an outreach of the Linux Foundation. So we're starting a cloud stack consortium with the Open Mainframe Project. And so we're hoping there to bring in some of our clients to talk about some of the things like John talked about, and also to bring in some of our business partners to talk about how they can develop more in the open too and how we can work together to develop our plugins in the open. So with that lead into working with the community, I'm going to turn it over to Ji Chen. Take this. First of all, I hate my CI because sometimes they give me some trouble to let me fix the problems. Someone tell me, you need to fix this. It's a blocker, you need to fix this. But CI is very important for us to development. So back to, as Emily said, back to 2013 or 2012, we are starting to work with the community. And at that time we thought we are very experienced people. We are new hiring IBM, but we have a lot of experience in other companies. So we thought we are experts. We are where you need, you guys are community guys. You guys need to listen to our suggestions otherwise. But it's not true because we are working not for open source project. We are not very familiar with open source culture. And there are some, for example, some concept gaps between our solutions and OpenStack. For example, Noir Resize. Noir Resize is kind of, you can resize the instance and you can log on to the instance and see whether it satisfies you or you don't want it. You can revert. So this is totally different to our ZBM concept. We just resized this instance and nothing else. So from cooperation with the community, we learned that we need to be familiar with community first. So you need to listen to community suggestion or concept first. And after that, you can bring your suggestions to the pinpoints or to the staff that you think you need to change. So this is what we learned. And as you know, we are a pretty small team. We don't have that resource as a bigger team. So all of us not only need to develop our staffs but also need to contribute to the community. So let's bring a question. So when you arrived at office at 9 o'clock, we were very happy mode. And suddenly you found, open your computer, you want to subscribe the mail of community and see what happened there. But you got a phone call from your few team and they said our customer has a problem or they want some this, this and this. So what you do? You need to think about which one is bad, which one is more proud to you. Either cooperate with your customer or work with community. So we have this kind of problem because of limited resource. We need to focus on the customer case first. And when you solve a customer problem, you will find, oh, I don't have time. I need to play with my son. I need to teach my son mathematics or whatever. So you don't have time or don't have enough time to work with community. That's being a problem to us. But we need to find to know how to solve this problem. So back to 2013, we started to think about that all our team members need to contribute to the community. Maybe part of them need to involve. And I, for example, we got some mentors in same time zone. That's very important because as Emily said, a lot of our team members are in U.S. And, for example, a lot of our core contributors of OpenStack are also in U.S. So it's two hours difference. You cannot catch any people in your normal work time. So what we have done is we reached some core people in Australia or some other place near our Asia Pacific. So we tried to reach them and set some phone call. As you know, phone call is much easier than same time or some put text in a screen. So it's much easier for us. And also we are trying to use some, let's say, weekly share or monthly share. So all the people in a team can know what's going on there. And so you don't need to be fully involved, but part of the team will share the information. And if you have really interest, then you can continue to work on that. And so one problem of us is we are not X86 system. So our reported bugs sometimes are not considered as a, you need to reproduce this in X86 because you are not working for a DB stack. So you need to show the logs and you need to show the proof. But we tried to manage that. And we give some help of the community. So we sold up some bugs. And yeah, so this is what we have done in the previous five or four years. And we have learned something as June and Emily said through the process of our enterprise support. So that's all. And do we have any open for questions? Oh, come on. Someone must be wondering something. Yeah. Playing with this switch from proprietary to open source in their organizations. No, you all got hired right out of college into open source. Not all of like me. I'm a journalist. So my job is to try and understand this stuff and write about it. So not smart as you guys told. But I'd like to hear a little bit more about the cultural problems and how you tackle them if you go into a bit more detail on that. You're just trying to get us on stage for the video. Sorry about that. Yeah. I think that one thing that I've had to kind of say to the team multiple times is, you know, it's okay to admit our mistakes in the open. It's okay to, you know, let people see the process. And so the feeling sometimes with the team like, oh, well, we don't want a bug opened out launch pad. We'd rather have an internal repository for bugs so that people don't have to see the mistakes we've made. Obviously with this presentation, we're working toward being very much more open about the mistakes we've made because that's not a bad thing in open source, right? We work through our mistakes. We learn through our mistakes. And getting the design doc out in the open, too, I think has been a big thing. I don't know how many times I have to say to people like it's really okay to put it out there, put it in a wiki, put it somewhere where people can see, give all of the doc behind it. You know, if somebody else takes it and downloads it on their own machine and puts it into a proprietary product, that's going to cause them legal issues. Like people are still very much in the mode of like, oh no, they're going to steal our IP and put it into their product. And just getting people to understand that's not a concern at all. So there must be considerable internal resistance inside IBM given what happened with Oracle and Open Solaris and so on. There are other examples, but that would be very clear in everyone's minds in the senior management of IBM. So could you maybe discuss how you tackled that one? I don't know that we tackled it so much. I think it's really been a sea change in the industry because certainly when I started, yes, there were examples, there were long-running multi-year things, we had things drilled into our heads, but really it's come from the top. I mean, we have an internal GitHub enterprise now, for example, is one of the things that's come up in the last couple of years. And the different units, it varies by which part of IBM. I mean, it's the same thing that happens in a large enough company. I don't think that's a shock, but it really is coming from the highest levels of, you know, get out there and be open. I personally maybe was inoculated a little bit earlier because about 10 years ago I changed over to the, what was the Tivoli unit and did a whole bunch of standards work. So it was in the W3C, it was in DMTF, places like that, where a lot of it wasn't open source, it was more about specifications, but aside from that, you know, the deliverables are all open, you're doing everything in the open. I mean, I was a W3C work group chair for about four years. The process has really drilled into you. Where you have to work on, I think, our own management a little bit, was actually the middle and lower layers, because that hadn't percolated all the way down into the systems unit yet. It was up at the top and certainly the cloud people understood it and the IOT people understood it because those are much more, you know, we're part of this ecosystem and there's a whole bunch of other stuff we've got to fit into, sort of mindset, which is not where the hardware division typically came from historically. But those people are at least educable, right? They are people that you can work with and you can say, you know, here are the business reasons for doing this, you know, by the way, you're hearing this from our senior VP and whatever, this is actually what it means. This is an example and they can respond to that over time. It's no different from other humans. Some are faster than others, some are more resistant than others, but in the end they get it. Some support within the ZVM organization, too, because they actually went through a fight back in the 80s about whether or not to release all of their code out in the open. It wasn't quite the same as open source then. So there are still some older developers who might still have badges and pins from that fight who feel badly that there were the things that went more proprietary, you know, 30 years ago. So this isn't a discussion about training and skills, but you kind of went there. So do you have any guidance for the people in the room of people who, as you say, are educatable, like smart people, but they need to change their ways of working to be more collaborative and using the modern, not waterfall anymore process. Do you have any advice for self-paced learning, boot camp, what is the best approach? I'm a big opportunist, right? So I just sort of talk to people and find out who's the most receptive. Find one or two or three of them. Careful, that thing's loaded. Find one or two or three of them. You know, give them a bite-sized project they can work on and really encourage them to try the new stuff, try the different tool, whether it's Slack or GitHub or whatever. Let them show that it's possible because a whole lot of the doubters start from the oh, that'll never work mindset, right? And you put a big pin in that balloon. You say, well, these guys did it and they're the junior developers in the group. What's the problem? Explain it to me. Really changes the conversation. And, you know, I mean, some people, even if they're in the resistant patch at the beginning, they're self-reflective enough that when they see that success, they'll start to say, all right, maybe I do need to learn something new here. You know, there's always going to be the trailing edge. You know, one of the Clayton Christensen adoption curve. There's always the stragglers. Accept that. You won't win every battle. Another question? Yeah, just lob the mic. Are there any particular points or friction points, perhaps, with the community that you can talk about that you had to work through and how you did that? How you helped change their minds, perhaps, in order to help them accept the kinds of changes that you wanted to make in the open stack? So, recently, we are trying to make our drivers for NOAA, for Neutron, and others to be accepted by the community. But we got some trouble there, because we were requested not only for CI, but also for diversity, because we are IBM-er, we offer for the system, and we need to attract more people to work for the driver in order to grow and to convince the community that we have diversity, we have health. We are healthy, because if our IBM is not going to play the game, then the whole project or the whole driver is gone, so the community don't want to see that. So we are trying to convince the community to accept our driver, but at the same time, we are trying to fulfill the requirements for the community, because we need to run under the SRA of our CI system in four hours to submit a vote for the patches, and we need to attract more people to work for that. Such kind of a thing will be the top challenge or top risk for us in the short term or midterm. I'll just put in another plug for the open mainframe project, because the Linux foundation, talking to the Linux foundation about what we can do and also about how we can talk better with the community and how we can bring more of our business partners in to help us talk with the community, so again, our drivers don't look so much like they're just IBM working on them. So that we're out of time. If people want to ask us more questions, we'll just go out in the hall after the session so that way the people can get in for the next presentation. Okay? Thanks, everyone. We are signing autographs.