 Good afternoon, all. So let me give you some background behind the topic. So the topic, original topic was organization culture, catalyst for open stack community. And I think I generalized it for the open source community because the overall culture and open source are correlated. So before I start, let me introduce myself. So myself Deepak Gupta, and I am working as an open source software leader at NEC. And I'm basically from India about me. So I'm having about 17 plus years experience. And that experience is mostly around open source software. So I started my career as a Linux kernel developer in year 2000. And mostly the area where I worked for were Linux kernel cache dump, memory managers, and file systems that are my expertise areas. And after that, I worked in virtualization. That is Zen and KBM. And after that, I worked in mostly storage product development, file block and object storage. And I associated with open stack since 2012. And I'm presently working as the head of NEC open source software technology center in India. So that is my background. So with this background, let me quickly recap the organization and culture. And that the topic I chose because what I felt in my experience that open source movement starts in an organization, then it dies. Then it starts again, then it dies. So overall, in my experience, organization and culture can be a motivator for open source community. And that's what the topic of today's discussion. So before I go, let's start with some of the definitions. And definition of organization. Organization is a collection of people working together in a coordinated manner for a cause. So that's standard definition we found in Wikipedia. And the culture, culture is a way of life. Especially the custom beliefs of a group of people. It calls culture. And organization culture is a system of shared assumptions, values, beliefs, which govern how people behave in the organization. So that is the background of organization culture. And the shared values have a strong influence on the people in the organization and dictate how they dress, act, and perform their jobs. So that's quite a complicated definition of culture. But essentially, the organization culture derives the behavior. And that behavior is responsible for overall achievement of the organization. So let's look at the attributes. What all attributes are there in an organization? Oops. So organization culture consists of the vision. So given a vision, vision defines the background for the organization. Values. Values denotes what organization stands for. Then the practices. Practices are the particular behaviors or behaviors with people depict when they came across some situation. And next is people. Of course, the team are people who are part of the organization. Then the narratives and history. So the narrative and history denotes the history of the organization and the background of the organization. So it also has an impact on organization culture. And finally, the location that is placed. So in US, Europe, or Japan, or India, this also plays a critical role in organization culture. So we'll open the talk with open source versus closed source. And it's a cultural contradiction. So especially this talk is useful for the organizations who are working in closed source and have aspiration to go for the open source. So that's the background. So to start with, let's have a basic fundamental difference between closed source versus open source. So closed source, all confidential. It cannot be shared with anyone. And in open source, there's no secret. There is a fundamental contradiction. Closed source typically believes on the defined methodology, good documentation. And in the open source, the methodology is quite open. And maybe documentation is something which takes the last seat. Closed source, I mean, there's a culture of assigning the tasks and asking the status. Open source, mostly the members choose their job by themselves. And then the copyright and copy left. So copyright is a closed source stuff where people prohibit other to not to copy their stuff. And in open source, they left the copy behind. So in open source, there's no copyright. It's copy left. So let's go for the motivation for open source. So sometimes you go looking for motivation, and sometimes motivation finds you. So that is the code for the open source. Let's look at the business motivations for the open source. And I think in the keynote, it was quite apparent that open source is the only way going forward. So in the business motivator site, we have quite a few. So first is interoperability. Most of the companies who are working in the closed source are going for the open source because they would like their solution to interoperable with others. So interoperability essentially means collaboration. And the collaboration is one of the motivation for the organization to go for open source. Second is market demand. So market demand has changed now, a 10 year back. And now, there is a huge difference. People are going more and more towards the closed systems. And vendor locking is no more an option. So that market dynamics or market demand changed the psychology. And this is becoming one of the motivation for our nation to go for open source. Next is reduced total cost of ownership. So whenever you go for the open source, the total cost of ownership, as in the organization, reduces because you can use the work done by other organizations. Next is customer connect. So customer connect is one of the fundamental reasons why people are going for the open source because even in this summit, you see we have a user group also available at the same time group is also available. We can listen the voice of customer in the same forum. Next is the quality. Of course, you have a base mineswork together. So the base quality is delivered and rapid development. So speed of development is quite fast when you go for open source. Next is the motivation for an individual to go for open source. So fundamental name and fame. So many of us is having aspiration to get a good name and fame on internet. So that is the biggest motivator for individual to go for open source. Next one is the fund network. So since open source does not believe in the boundary, so individual is motivated towards open source. Next is freedom to choose. Of course, open source does not have any obligation. So you are free to choose. You are free to select and free to live. So that freedom motivates many people to join the open source movement. Next is personal age. So personal age indicates a symptom where people would like to work with like-minded people and a base of the mind in the world. So that is another motivation. And of course, financial gains. Most of the open source guys are well-paid. So now we'll be covering a framework which is used for nurturing the culture of open source in the closed source organization. So this framework we used in NEC to cultivate the culture of open source. So the framework is having fundamentally four stages. And the first stage is leadership buying. So before we start for any open source movement, we must be having a buy-in from management. Unless we have buy-in, I think at organization level, open source movement will die. Next, once we have a buy-in and management decision, the most important step is forming the team. So team formation for the open source contribution, especially in the closed source organization, is quite difficult. And that's the next step what we should be having. Fundamental stuff, third stuff. Those who work in large organizations can understand that policies are quite different. And maybe they can become blocker for the open source contributors. So we need to tune the policies in such a way that we can create a conducive culture for open source development. And next is, of course, continuous improvement or what we call kaizen in Japanese. So that is again required to review the framework what we created. Finally, the closer. Closer depicts the exit path. So most of the organization fail to handle this closer phase. But I think in the framework, the closer phase is having its own importance. So we'll be covering one of each block in detail. So leadership buy-in. Leadership buy-in starts with a business plan. So while an organization commits for open source, there has to be a business case. Unless there is a business case, it's quite difficult to sustain that initiative. So the fundamental step is to create a business plan around open source. And that business plan should be able to eventually generate money for the organization also. That's where we get the funding. Next, get the stakeholders commitment for OSAs. So when you go for OSAs in close source organization, there are a lot of blockers and a lot of people who are against the open source movement. So while we create leadership buy-in, we have to have stack holder commitment that as an organization, we are committed towards the open source. And this commitment makes a lot of difference for the future of the OSAs survival in the organization. Next, the fundamental question, I think. This is the tough question to answer. Decide what to open source and whatnot. I think there are a lot of talks going on around this topic. Even in the summit, I think there's a lightning talk on decision of what part should be open source and what part should not be open source. So it all depends on the organization policy. But fundamentally, if you can dissolve this contradiction, it, let's say, leadership level or the strategy level, then your life will become easy. You have to have a clear distinction that this path goes to open source, this path does not go to open source. So then communication of the strategy. So once you define the strategy, a communication is very, very important to internal members as well as external world. And then set up the review process. Because when you are moving our organization towards open source, it's quite difficult to take decision in one go. So there has to be a review process. That after every month or maybe a quarter, there should be a leadership review on the strategy level. Second is the team formation. So team formation starts with identification of the team members with the right mindset. In close source organization, the mindset of the people is quite different. They tend to work in silos. And for them, going to the open world is a shock. So the fundamental curve is to identify the right individuals who are having a mindset which is quite open. And they are open to work beyond the boundaries. So while for some of the OSS developer, it's quite natural. But in the close source organization, when people work years in the silos, it's very difficult for them to accept this fact that they have to work along with the external world. Second, providing a training for the open source software and defining the rules. Because the developer who is working in the organization is having access to the close source as well as open source responsibilities. So this training trains person for organization culture that what part has to be in open source and what part cannot be in open source. That's fundamental training. It has to be given to each developer to create the mindset. Quite important step is the career path. So most of the organizations which are close source, they got a standard career path. A developer can become a technical leader or maybe a technical architect, solution architect. So all these parts are defined. And since as an organization, these parts are so much in vibe that they sometimes do not have a space for any new ingredients. So rules are well set. If you do this, then you become this. You do this, then you become this. Once a person moves to the open source, in this system, a person's career looks amvious. So when you create a culture, you have to ensure that a person should be having a defined career in open source. So we are trying to create a culture inside an organization where individual will be having one, two, three visibility that once a person goes to open source, nothing to fear. The career progression will be as it is as he was having the career in the close source apart development. So career path definition is very, very important for individual, right? Because I think in the close source organization, very small part of the organization is focusing on the OSS. They feel isolated. Next is tune the performance management system for the OSS members. So performance management systems are tuned for regular users and not for the open source developer. So we have to tune them in such a way that people can perform, and their performance can also be accessed. Defining rewards and recognition. So rewards and recognition for the OSS developer are must. So in terms of rewards, there can be some declarations and rewards. But in terms of recognition, the most important recognition would be personal attribution to the work what the person is doing. It has to be attributed to the person, OK? Now tuning policies. So we'll be touching upon some of the policies which must be tuned. So to start with the IT policy, OK? So IT policy, I think in some of the organizations, there is a policy that pictures cannot be downloaded. So that's why pictures is blocked. So in IT, when you work in an organization, there are a lot of restrictions. So IT policy must be changed in such a way that there should be a dedicated development environment which is there for the OSS developers. And this environment is having special firewall rules which will allow individual to interact with the outer world. Otherwise, it's quite difficult to interact within the organization, from the organization to outside world. It's mostly restricted. You cannot do much. So IT policy must be tuned in such a way that this access is given. HR policy. So in HR policy, I think there are a lot of policies which are binding people towards the culture that is more disciplined. For example, working hours. Working hours are more or less defined that a person has to come by this time and go by this time. But when you go for open source, you are working in different time zones. So policies must be modified in such a way that your time zones can be respected. Next is email policy. So I think many of you might have seen the emails coming from people having a disclaimer, a large disclaimer. And in the open source world, I think we do not like the kind of disclaimers. So that policy of email must be modified in such a way that whenever a person is using email from the organization, it has to have no disclaimer at all. Very important is compliance. So those who are running the compliance is like ISO 200001, that is information security. These kind of compliances are biggest hurdle because it contradicts with the open source philosophy. And open source philosophy says that there's nothing confidential. Information security is not meant for open source developer. But we must comply with the compliance and have to find out how these open source developer can deliver the source code to the outside world, still comply with the compliance. Next is communication policy. So as open source, we know that a lot of emails are having jargons. They use a lot of different language. And communication policy within our organization restricts individual to not to use such kind of words for public communication. So communication policy must be tuned in such a way that people are free to communicate with the outer world using the language which is accepted by the open source. Next is the improvement. So continuous improvement, I think, the fundamental stuff is management review. Reviewing the overall situation by management. And at a periodic basis, we have to have some mechanism to giving that feedback back to the system. So management review consists of a strategy review. What strategy organization is created for the OSS? That strategy has to be reviewed periodically. And if there are certain improvements required, those improvements must be incorporated. Team review. So this is what happens in close source organization when we have people working in silos they're exposed to work in the open environment. So there's a periodic review required for the team members. Sometimes the members are not comfortable. So it's important to review the situation and maybe remove those members from the community and put the new members. Or if there's a need, then maybe hiring from the outside can be another option. Next is policy review. So as we go in our journey, the policy becomes more and more important. So periodic review of policy will help removing the hurdles which are there for the open source community or open source development. So policy review is a process where a lot of stakeholders are involved and this policy review must be conducted with management team. Last is the closer phase. And closer phase is the phase where organization decide or declare that they are no more contributing with the open source. And I think this is the phase which posts of the organization do not handle properly. So managing closer is a graceful exit plan. So I think we have, we heard a lot of news that XYZ organization decided to call off for the OSS, but is that exit is graceful? So while as an organization when we declared or we announced that we are committed towards open source, we cannot run away as it is. We have to have a graceful exit. So as an organization, the graceful exit plan must be there and that is most difficult part to design. And again, the communication of this plan. So while we started our journey with internal and external communication, so communication closer is the important step which has to be there at the closer stage. So if you have done Excel communication for opening that OSS, we should be having an Excel communication for closing that OSS moment. Finally, there should be a plan B. So plan B indicates there should be a plan for the team member who are part of this team, what will happen to those guys. Again, it depends on the culture. So maybe I think in some of the companies or some of the location geographies, they do not take care of the people, but in some geographies, people are quite important. So we have to have plan for each team member, what that person will do once we close this OSS. Or we can have plan for the next OSS. For example, maybe right now OpenStack is at hype. We may have a lot of team members working in OpenStack, but maybe after two or three years when this OSS moment saturates, then we can go for the next OSS. So all this stuff must be very, very clear. Okay, so this is a fundamental framework, what we applied at our organization, and we are sharing some of the case studies as a result of this framework, what we achieved. So we have created OpenSource Technology Center, especially in NEC. And what we have done, we divided the team into three parts. One is the community connecting team, which is interacting with the outside world and doing community contributions. Next is the global support team. So global support team is essentially a team which is providing support to the internal or external customer around that OpenSource software. And third is the system integration solutions. So this team creates new solutions using the property in OpenSource combination. So this framework creates a business model, wherein we have a community connect is going, giving back to the community. And global support and SIS solutions are typically the business motivators, right? This is where we earn money. Now, if you go to the community connect, there are three responsibilities of this team. Number one is upstream development. So of course, everybody likes that upstream development to be there. And research and development. So this team collaborated with the outside world and do a lot of research in new technology areas. And one of the most important stuff, what this team does is pushing the real customer problem from the community, from customers to the community. So global support team and SIS solution team, they keep on communicating the troubles they face with the OpenSource software. And this team pushes the real problems to the community back. And that's where the community gets a lot of inputs to improve and move, right? So global support team is responsible for supporting internal products which are consuming the OpenSource software, right? Because in the close source organization, we are having property as well as open source. And of course, the global support team is responsible for supporting our customers worldwide, right? Which are using our solutions which consumes OSS as well. SIS solution team, this is another fundamental team which is there in product organizations. So this team creates solution to solve the business problem. So this team can use some OpenSource, some of the close source, some of the appliances, and then solve the business problem. Next, this team also creates integration of products with OpenSource software. For example, if you are having a storage product, how to integrate that storage with the Swift, that can be the job of this team. So they make our product compliant with the OpenSource. And next is SIS with OSS and property software or property appliances, right? So we have one part which is property one, another one is OpenSource, combining them and then creating a solution. So this is the framework what we have created in NEC for giving boost to the OpenSource as well as having some business out of it, okay? So this is the example yesterday what we followed and these are the results what we achieved in OpenStack committee. So in OpenSource, Tegave Center, we focus not only on the OpenStack, but also in the other OpenSource software. So in today's talk, I'm giving a brief summary of contribution what we have made in OpenStack. So approximately, maybe 0.8 million line of code, what that's what we achieved with a more than maybe, okay, more than 150 blueprints which are completed and transactions are more than 30,000 then we'll be having, we are having page sets on 25,000 plus page sets what we contributed, right? So this is a summary of contribution in OpenStack and the next slide shows the journey. So importance of this slide, this slide shows the movement across villages, right? So as I said, you know, when you create the culture, so I have taken the step shot of two years, right? From Kilo to Newton. So if you look at this culture of OpenSource, it's generating result release by release. So you can see from Kilo, Liberty, Mitaka and Newton, we have a contribution all across. So beat lines of code, beat reviews, beat blueprints, beat commits. So the team is working hard and for a long run in a long-running way and producing the results, right? So this is the summary of Mitaka where we demonstrated the framework, its application and the results achieved by this framework, okay? So that's where I think I'll be having a more subverted slide as next slide and I'll be opening forum for the questions. Thanks.