 This morning, in my keynote, I talked about how there are people who are not just sort of part of the art of open source, but really the business of open source. Folks whose professional careers are working within organizations to enable large scale collaboration, whether it's to their employer's end or to a collective of employers. And I thought it would be interesting this afternoon to talk with these folks about what they do, why they do it, and so forth. Why don't I just quickly let each of you give a brief introduction on sort of, after I've already introduced your title, sort of what you do for your organization and sort of in a day-to-day basis. So what more I want to start with you. So my name is Maury Whalen and I manage a team within in and tell that's part of the open source technology center. The team that I manage, we do virtualization, so KVMs and enabling. We do data center, so making sure that, you know, Linux based operating systems are invest on Intel platforms, Intel architecture. We do things with data center with open stack. I also have a team that works with the Linux kernel and some com software, like Bluetooth, con man. So it's all about making sure that Linux based operating systems run best on Intel architecture. Great. Mark? As Jim said, I'm Mark Henkel. I run Citrix's open source business office. And we develop ecosystems around open source projects that benefit our commercial interests, primarily collaborative projects and Linux foundations and project, Open Daylight, and in the Apache software foundation, we work with the Apache Cloud Stack project. We also do a lot of user enablement and developer relations to try and create those ecosystems and work with partners to educate them on how to work with open source. Great. And Neil? Right. My name is Neil Jacques. I am the executive director of the Open Daylight project, and I would say the primary function of my job is really to do two things. On one hand, it's trying to get an industry that is bitterly competitive to act in a way that is completely different from the way that they've been acting for the last 10, 15, 20 years, to set aside some of the resources to working together, to working together on something where there isn't necessarily a direct ROI from that individual, that effort, but to work on a greater core, on a greater project. The second piece beyond getting folks to actually invest in the project is making sure that we take that investment as a group and that we get the most out of it, and so working very closely with a fantastic community of developers to tackle what the biggest problems are in the industry, to work with each other, to make sure that we continue to come back to the core principles of operating with each other, and to finally release great code. Great. So one of the questions that I get asked often from companies who are wanting to invest more in open source is how do I go out and hire developers who play key roles in communities that I want to influence, that are going to not only help make that project better, but hopefully help make my company's goals relative to that project better. And I got to say Intel is one of the top companies in the world of attracting and employing folks who have key roles in the Linux kernel and a variety of open source projects. But the question I get the most is, and this is for Maury, how do you manage these people? Is that an Intel employee laughing out there? It might be. Perhaps not at all. But A, how do you decide how those folks spend their time? What's the boundary between the company and the project? Who identifies with what? What's your sense of how do you do that? I think I always start by saying it's the business first and from a probably a 30,000 foot view, what I tell people my group does is I look at Intel's roadmap about 12 to 18 months out and I make sure that Linux runs best on it. So that's business first, right? We do have a job to do. The bills have to be paid. But past that, you need to make sure that open source developers do have a lot of flexibility for creative freedom. You don't really want to stifle people. You know, there are times when I have to have conversations with people that I also manage that when are you an Intel employee versus when are you just your internet presence? There's always a balance there. A lot of times some of these developers, their passion is working in open source development, but you have to balance it when when are you an employee, when are you not? I think a lot of times we do have processes for people to keep their own time projects. So if somebody does have a project that they don't want to have to give up just because they become an employee, we do offer that kind of flexibility. You know, we have to respect when somebody's a key maintainer that there are times when things that are going on in the business, what's going to trump it, right? When there's a like a kernel merge cycle, these can be really intensive times for a lot of people. And you have to be, you know, people are not robots. You have to be very respectful that somebody needs to go heads down in a merge cycle opposed to getting some project done internally. So you have to try to balance that between their schedules. It's just a lot of open communication, just like working in open source, right? Well, let me flip this question then over to Neela because Neela runs the open daylight project. And there are over 100 participants committing code in the project itself. Yet none of them work for you, right? So you have sort of the opposite issue where, you know, you're saying company first and respect the boundaries of how folks are working within these projects. You have the reverse issue, which is, you know, they're working within these projects, but they also work for companies. So how do you sort of get the project itself to a point where, you know, engineers are committed to it and, you know, working in harmony together? What's the role of the project, I guess, in that? Right. I mean, I think the first one, and it's funny, I wrote a blog post about this, I think, yesterday. In an open source project, regardless of where you are in the project, whether you're the executive director or, you know, you're a developer, there's a different kind of leadership that you need to have. It doesn't work to be a boss. It doesn't work to tell other people what to do. So continually what I found is it is about being able to enroll people into a vision. And so from my end, it's about really listening to the community. It begins not by me saying this is my vision for the project, but listening to the community and trying to tease out the common visions, the common views, and then play that back to the community. Because I think the first thing that I find in managing these folks is you don't manage these folks. What you do, simply, is that you show the challenges that exist in the industry. You show the possible solutions that are coming and you help facilitate people working with each other. I think on the other side, in terms of the corporations, it's important, and I think I want to build on something that you said, it's important to show corporations how you can influence and how you don't influence an open source project. You influence by what you choose to invest in. If there's something that you care a lot about for your organization, you fund developers and effort follows interest in an open source project. What you cannot do, and this will bite you really, really fast, is try to influence how people do their job. Because the moment that you start seeing developers acting by their corporation's interest, rather than the bigger interests of the project, then no longer collaborating, and it immediately creates a rift within the project. And everybody has to be vigilant of that. And when there is an attempt to do that, we need to nip it in the bud, because that will kill your project. Well, you know, Mark, to expand on that, you've been involved in a lot of open source projects, both in participating in it from a corporate perspective through Citrix, but also actually creating whole scale open source projects and setting up a structure, a model within which people can collaborate together from a broad set of companies, even if they don't particularly work for that project. What do you find are some of the best practices around setting up projects? You know, what are some of the ingredients that you look for in a successful open source collaboration? Well, I think the understanding your end game is one thing that is just critically important, and it shapes what happens in the setup. So sometimes your end game may be to facilitate shared collaboration across companies. In that case, governance and bylaws is very critical so that there can't be any overt moves by the vendors and it is vendor neutral and they can collaborate through some kind of democratic process. Other times you see open source projects that are aimed at user adoption. In that case, you want to enable a collaboration through at the user level and allow people with a single voice to make a difference and enable the idea of collective intelligence, so all these discrete elements within the project can come together to make something really neat. Like plug-ins in a Firefox or Chrome browser is an example of allowing all these discrete elements collectively to make the browser really powerful. Yeah. I have a question for the whole panel that I get asked a lot that I want to pick your brain on, which is, you know, we're talking about mass collaboration, right? Big industrial scale market changing collaboration. And, you know, we're seeing sort of, as of late in particular, the rise of these foundations, right? You know, it seems like every other day I see a new and obviously the Linux Foundation helps out a lot of these foundations, so that's great for us. But what I get asked about, and frankly this question is posed as a criticism sometimes, which is, well, you know, these foundations, it's just a big corporate-led thing, and that's, you don't know anything about open source, because open source is really about a groundswell that sort of happens organically, and it comes from the bottom up. And the answer is sort of, which is it? Is it sort of the plan, large-scale mass collaboration that gets industry together to do it? Or does it have to be, does it always have to start in a dorm room? Does it always have to, you know, be, does it always have to come from Finland? But no, I get this question a lot. How do you guys respond to that? Does it have to start in the dorm room, or does it matter that it starts through a collection of large organizations doing it? Why don't I start with Mark and then we'll go to Maury and then Nila? So I do think there is this rise of the vanity foundation, it's starting, you know, but the, and I think the reason it happens is because when you want to tell people what you're doing, it helps to have name recognition, so the great foundation that is the Linux Foundation for Open Source Development has a strong success rate in Linux, but when you talk about open daylight, that makes it tough to people to, as you explain it in first glance, that there's a relationship between the methodologies and the foundation that we all know and respect and this new and up-and-coming SDN controller that's going to be awesome. So I think that the, that is, that is a problem for awareness, like just to explain user awareness, and that's why the vanity foundation is appealing. Other than that, I don't think, I think there are plenty of foundations out there that give us the governance and the collaboration framework that we need, but awareness, if a developer drops code in the woods and nobody's there to see it fall, does it make a difference? I mean, that's the quintessential question, so you have this great, great piece of code, this widget, this program, and you want to share it, and that's why I think it occurs, but I don't think that other than that singular reason, it's necessary. But Maury, Intel participates in a lot of open source projects, but you also started large open source projects, the Yachto project, Tizen, a bunch of others. What's your answer to that? Does it, does it have to? I think it kind of goes both ways, you know, you could have, you also have to take advantage of when developers have great ideas to keep creativity and innovation going and kind of brew that, right? And you have to, I mean, you know, I get a lot of developers that come to me with, you know, great new ideas, and you have to try to figure out if you want to make a business out of them, right? Do you want to put Intel's name behind them? Because if they do grow up and be something bigger, you would have Intel attached to it. So we definitely have to ask those questions, but I definitely think there's, you know, having foundations, having specifications, standard APIs, those type of things, we don't need more power supplies, right? Right. It has its place and time, but I still want to say that, you know, having the great ideas, the creative minds still come out and be able to put something behind them is definitely still worthwhile. Yeah. Why didn't the folks from Open Daylight just throw the controller code up on GitHub and call it good? Why Open Daylight? Why did all these big organizations invest a lot of resources, both financially and, you know, over 100 engineers into this thing? You know, actually, before I answer that, I want to say one thing. I think that at the heart of your question is, can you boyband an open source project? Can you boyband an open source project? Right, I mean, I think that's the question on everybody's mind is, hey, can a bunch of corporations sit in a boardroom thinking about, go, ooh, we're going to create an open source project. We'll pay him to do this and him to do that and it'll come together. And I think the first answer is no, you can't. I don't believe you can boyband an open source project. You can have as many corporations wanting and ordering people to work on something, it won't work. So at the heart, I think, of every open source project is a singer-songwriter. And what you can do as a corporation or as a foundation is support and help the singer-songwriters to get together. If you try to create it, you know, for a while it may work, but it's going to fall on its own weight. Now, I think that becomes the other side of it, which is however good a singer-songwriter is, there is a support system that is required to get the world to know it, to be able to do the mixing and to select what are the right parts. Making an album isn't something that one individual does. And so I think in this case, what you have, you have a set of smart executives certainly seeing a major trend in the industry and recognizing that if people continue to do it in their own siloed way, we're not going to do anything. But, and I think this is the wisdom of people like Indergopal at IBM, they recognize that for something like Open Daylight to work, it can't be controlled. It can only be supported. And so this is why I think these corporations turned it to you, frankly, and to the Linux Foundation to say, how can we get people who understand what it takes to build the frameworks and to build the structures to enable these grassroots efforts to thrive? And to gently guide rather than simply point at a problem. Somehow I feel like I ended up being a roadie in this entire picture here. But Mark, is that from Citrix perspective, is that what you're really looking for when you come into these projects is a facilitation vehicle like that? Yes and no, depending on the situation. So, you know, sometimes you are looking to facilitate collaboration across partners. Sometimes you are looking to facilitate lower operation and research and development costs. So Zen Project is a good example. We want to share that burden on non-differentiating features across like-minded companies. It's just a matter of, there's a different design point for and reason why you would do it. Sometimes you do it just because you want to drive massive adoption and create an opportunity to support them in some commercial way, whether it's a service or an add-on or complementary features. It's just my point of what's your end game for each one and it may be different. Yeah, yeah. What do you guys think is the most important element in enabling this kind of mass collaboration around these, you're all participating in these big projects. Is it a by-laws, is it a tech development structure? You know, what are some of the key elements in your minds that really enable this? I'll start with Mark and then we'll go Maury and Neela. So I think that it's all about the ability for distributed contribution to the project. So if you look at the Linux kernel, the actual kernel development relative to the hundreds or millions or billions of users happens among a very, very small percentage of those users, hundreds in a substantial way versus other, and I used the browser example earlier. Core development requires a high degree of coordination, so that doesn't scale for mass collaboration. That's, there's overhead, but where you can take all the discrete development and put it together into something cool, like, you know, OpenStack has their ecosystem they mentioned earlier or Nagios monitoring or browsers or et cetera, where all that work from development to testing to user input into documentation collectively becomes collective intelligence and that's powerful. So that's by-laws and other things are facilitative. The real thing for mass collaboration, that's the key to this discussion is mass collaboration allows collective intelligence to reign. Well, what do you, at Intel, do you guys have a set of criteria you look for in these projects? Whereas, you know, it has to have a transparent development process or a certain kind of license or a certain tech infrastructure. Is there, what do you guys look for in these projects? They're different. You know, like through the Linux Foundation where you have hosted what, Tizen, Yachto, and there's a different levels of documentation and by-laws that go with all those. I think if anything, you know, it fills the need that you're, you know, like take Tizen, for example, they're Samsung's, you know, that's who we're primarily collaborating with. They're both a competitor and a partner in this instance, right? So we definitely just need a neutral space to do these things. But, you know, past that, it's programmatically, you know, the same as most projects that you do internally. You need a high degree of declarity, transparency. You need to know who's working on what. You need definitely openness. So, you know, when your partner goes off and does something and you can actually see it, right? So it's those type of things. Yeah, yeah. Nila, how about you? What do you think are some of the key fundamentals that make them a daylight work that are fostering this collaboration? I think really three things. Governance on one hand. The second one is culture and the third one is sweat equity. Governance in terms of there's always questions with competitors. People are always going to ask, what is this other person's motive? So you want to make sure it begins with that, with a firm structure where you can get past that question of why is he saying that? I think culture is the trust that builds up among individuals where you don't even ask the question anymore. You just, you feel in a sense, many of the individuals feel close, more of a tie to the project than they do to their corporation at times. And then the final one is it takes sweat equity. People have to be willing to, you know, there's a difficult decision that happens at 9 p.m. at midnight, sometimes three o'clock in the morning where somebody else needs help. Do I offer it or do I go, you know what, he works for a different company, I don't care, or she works for a different company. Yeah, yeah. So Mark, you've talked about who the next leanest twirl bulbs could be and what kind of problems that person can solve. I wanna ask this question in two parts. You know, as we're seeing at the foundation, really in every key section of technology, whether it's IoT with all scene or you know, SDN with open daylight, you know, you got cloud stack, open stack, you know, these big foundations coming together and investing industrial scale resources and growing a huge technology project. And I will argue, I would argue that there's some boy band aspect to that in that this is being manufactured to solve a meaningful joint development goal. I always get asked this question and I wanna ask it to you because you talk about who the next leanest twirl bulbs could be. The first question is, who's the leanest, it's the same question every time. Who's gonna be our leanest twirl bulbs, right? And the question is, which is better? Sort of the technical steering committee decision making structure or just the benevolent dictator of leanest twirl bulbs? Like, which is better and then who's gonna be the next leanest twirl bulbs? Well, will we be booted? Do we have enough? Wrong question. Yeah. Leanest. Leanest just turned off the lights. There can only be one. Well, I definitely think it needs to be someone who's loving and touchy-feely and soft-spoken. Like, leanest. Yeah. I mean, that is a key, you know, point. I think it has to be someone who is solving a problem that is very personal to them and has massive impact in their life. So I think it just, I think it has to be someone with passion leading it and I don't think that these, and I do think there are boyband open source projects that would point out which ones, but I think that's happening very prominently these days. I think that it has to be driven by people who have a personal skin in the game reason to do it. Like, Leanest wanted to have his POSIX operating system run on his computer and be as tenacious as a rabid penguin to do it. I mean, that has to be the driving force. But if you can't, I would argue, and I happen to know him quite well, Leanest is a unique guy. Yeah. And what if you can't find these people? Or what if in order for the thing to get started, you have to have a group, you know, you look at the ASF or OpenSEC or Open Daylight, you have essentially a technical steering committee that ties in another, you know, the technical steering committee. And I think you can have that, but I still think that to the question, there has to be maybe a group of people that have some personal passion around that. There has to be the guy who's, or a gal who says, I really, really want to have an awesome SDN controller because I geek out on networking. And there are people in the Open Daylight guy, I can't think of that. Daylight project? Daylight project that a guy from Tennessee is... Oh, Brent? Brent. Brent Salisbury. Brent Salisbury. Brent Salisbury is one of the reasons why I think Open Daylight will be successful because he is tenacious and passionate about networking, even though there is a foundation, like you don't need the foundation, but you need those people, is my opinion. Maury, I'm going to put you on the spot by asking, I get asked people, many, many companies are looking to hire these types of people. And Intel has done a decent, how do you find these folks who can participate in these projects and be passionate and technically smart and diplomatic and sort of work in that? Do you guys have some special formula or? Secret sauce. No, we go to a lot of conferences. That is something that we definitely want to make sure that we invest leadership into going to a lot of different Linux-based conferences, Linux Foundation conferences, those type of things. And so a lot of the social, the networking that happens there definitely puts a lot of presence out there. So we find a lot of people, just from who people know, talking to people, that type of thing. I've asked developers in the past, why do you keep working here? And it's because they get new toys at their desk, right? How many times in your life do you actually get to influence what the hardware does with the software, right? And so I think that's actually attractive to a lot of developers that, at least work in the Intel Open Source Technology Center. You know, it's networking, it's word of mouth, it's keeping things challenging and interesting to people. It's not putting people in a box, to go back to the next Linux thing, the same thing, right? You need people that, strong visionaries, right? People that just are kind of in the wild west, cowboy, I've got my vision, I'm gonna go forward. And once you, going back to your point about culture, right? Once you start building that type of culture, people are kind of gravitate to it. They, I like to work in that environment. Yeah. So for lack of a Linux Torval, it's an open daylight. You have, let me just say, it's a technical steering committee, right? Made up of a little more than a half a dozen folks. So how is it going without a Linux? Is the world coming to an end, or how is the development process happening? And how does it work? Right, I mean, I think it works just like many organizations in our world, right? Every once in a while, you have a visionary leader that seems perfect for the task. And it's a mix of the individual and luck and timing. And if you have that individual, it's awesome and everybody likes to follow them. That's pretty unique. So what happens when you don't have that individual? You get multiple individuals who step up. And even within a technical steering committee, obviously you have a set of bylaws and people go through votes. But what you find is individuals put their own, they grow, they step up. We have a gentleman named Dave Meyer, who is a CTO at Brocade. And he is tremendously respected in the community. He's a very soft-spoken leader. A lot of the way he leads is by asking questions and allowing discussions and knowing when to end the discussion, but also knowing when to step back and allow the discussion to happen. We've got individuals like Chris Wright, who is speaking this morning, who is also often able to come in and share an opinion, but also listen to others. And then we've got developers like Ed Warnacky from Cisco who are incredibly passionate. Some days I definitely think he has an opinion about everything. Probably has an opinion about why it's raining right now. And he's very generous in sharing that opinion with the group. Is Ed in this room? And the thing is, how does it work? I think it's a group of folks who truly believe in the vision. They truly believe that we can and will change the way networking happens. And we will accommodate different styles, different people's gifts. And Open Daylight will be different in a year. It will be different in three years. It has to be, because nine months ago, we didn't exist. We've seen 150 people contribute. By the end of this year, will it be 200, 250, 300, 400? Who knows? And so we're gonna have to adapt our models of working. And I think as long as there are passionate people with great skills, with great experience who are honest with themselves and with each other, I think the project will be fine. Okay. Last question. Since we don't know who the next Linus Torvalds may be, can we name what the next big mass collaboration will be? What do you guys have a set? What project do you think is the next big one to go crazy, to really explode from maybe a small project into a big, large-scale development? Do you guys have any guesses? I'll start with you, Mark, go ahead. I think it's the class of projects. And I'm really fascinated by 3D printing and prosthetics because it's a, there's a big return on those investments. And if you readopensource.com, there's a really good article about this progression of prosthetic hands and the whole thing universe. So I think the idea that you can democratize a low-risk medical device that has a huge return on quality of life is really where I think the next non-traditional, non-IT-related boom is gonna be. Interesting. Maury Intel's got its eyes on any up-and-coming projects that you can talk about. You know, if I had to, I go back and forth here because the wearables is out there, right? And kind of the internet of things. And I think there's a bof tomorrow on this. I think that's gonna take off. But I still wonder, going back to the cloud side, the data center side, I still think there's tons of room for innovation. I kinda wonder, how has cloud been operating in your household? Because it got private clouds and public clouds and kind of a hybrid, but it's personally operable in your household. I kinda wonder how it's gonna come into the house, into the home. We use it every day, right, on our handholds. But I think from a tool that we could actually use in our home, I think there's a lot more innovative opportunity there. So I would probably pick those two. Kind of go for it. So you teased us though, tomorrow there's a bof that Intel is hosting on the internet of things. So if you want a little preview on what some of the open source projects might be. You can attend the bof. Attend the bof tomorrow night. All right. And Neela, I'll leave the last word to you on what's the next big project. All right. First I wanna hit two small projects. I'm really bullish on both OVS and Docker. I think they're both really neat. But in terms of a big project, to me I'm really intrigued by Cloud Foundry. I believe that we need right now the intersection of AWS, Eclipse, Borland. And I think that Cloud Foundry has the chance. If it's not Cloud Foundry, it'll be something like it. That a pass that developers can get on, it saves them 50, 60, 70, 80% of the development time. I think Cloud Foundry has a good chance of getting there. All right. Well, you've given us a broad breadth of things to cover from prosthetics to platform as a service. So stay tuned. We're gonna come back in just a bit here to have our most popular kernel panel. So let's take a half hour break and come on back in here and hear from the kernel community. Thank you. Thank you.