 So today, I'm going to talk about contributors, colleagues, customers, and clients to keep it up front. So there's not going to be a marketing talk for an ad, though it's a sponsored talk. But we'll look into some of the aspects that we have learned over a period of time working on the open source and some of the things that people who are in the business are doing. So we'll look into some of the lessons learned and some of the takeaways probably. And we'll also look at what could be the possibly next for open source. So it all started 30 years back. And I think it's appropriate to say 30 years because in 1985, the Freed Software Foundation was started. And I think it was yesterday, the FSF had the 30-year celebrations. If you're following, you'll probably know. So 30 years back, Richard Stallman, he wanted to work on a piece of software that would improve the performance of computer that he's using. So when he wanted to get access to that code, he couldn't access that. So he tried contacting the people who gave the software. But they told him that they can give the access, but he has to do a lot of paperwork and stuff. And also importantly, they also said that he wouldn't be allowed to share. So that's something that really got Richard Stallman thinking. And from there, they started to work on something like a UNIX imitation. So the GNU was started. And the bunch of people, they started to take this path of liberating software. So because back then, if you wanted to use a computer, you had no other means of using it other than having a proprietary software. So many did not like it, but there was no alternative. They were on their path to liberate software. So they continued on the path. And after a certain time, when the word got out, when people got to know that there's something like GNU that is happening in the industry, when they look back, so now they had a lot of people who were ready to contribute to the free software. So this was like a change, a shift in the way the traditional software used to work and the software being controlled. But suddenly, there were people who now had some tools to work on a free software. So it was amazing. It was an amazing feeling. And a few years after the free software foundation, there was some smart people, extremely smart people, who thought that free software is really, really great. And they thought that there is definitely some business opportunity in the free software. So when these extremely smart people, they took this free software and then went to people saying that, hey, you know what? We have a Unix-like system, which is less expensive and runs faster, but the industry really did not accept it that well. They said, oh, what does free mean here? So even though RMS famously said it's free as in freedom and not free as in free beer, but it was difficult to explain people. So these business folks, so the folks who wanted to make business out of free software, they are the ones who coined the term open source. Now this was different. It was easier to explain. And it also open source, also test upon some of the practicality of developing a software in a more collaborative and sharing manner. And that was open and that was freely shareable. So they test upon this. So they coined this term open source. And then the industry started accepting. So what exactly was open source? So open source is a way of collaborating with other people, having a free distributed software without having to worry about the intellectual property and without having to go through a lot of legal papers or anything of that sort. So this was a great shift. And we started now seeing a lot of contributions coming from a lot of people. So there were contributions from individuals, there were contributions from organizations, and there was contributions from people who were in the academics. So there was a huge amount of contributions coming up. Now there were like an army of people who had this GPL and everything with them equipped to take on the world. So what exactly was going on in the open source? So what was going on inside the open source? It's interesting. So there were some rules that were given which said that free distribution of software and the source code should be made available with the software. And if anybody wants to improvise this code, he should have the ability to work on the software freely and distributed freely, but keeping the original author intact. So there were some golden rules that were laid out. So what exactly went on in open source was completely opposite to what a traditional software development system would look like. In traditional way, you learn that you need to manage complexity. You need to have a small group of people. And then you need to have a plan and stuff like that. So in the open source, it was completely opposite. There were like hundreds of people across globe debating, defending their ideas, and being very critical about the peer review code. I mean, if somebody looks from an outside world, it looked complete chaotic. But then what was happening was there were people who were organically coming together to solve a common problem. And when people do that in a community to come together and organically solve a problem, there is this incredible amount of cross-pollination of ideas that happen between people. And they start producing at a pace that was unprecedented. And it just took off. So there were like a lot of people contributing. And industry had never seen the pace at which the innovation was happening. So it was no longer the person who was sitting next to you was your colleague. But the person who was, say, working somewhere else and remotely was your colleague. And they helped each other to solve this common problem. So it was a completely different perspective. So what's next for open source? So I think it is not something new. This happened earlier. And I'll take you back to the initial Linux days. So I think we are at a stage now where we can look at the cross-pollination between the communities rather than the people within the community and with the people. So let me tell you about the Linux and Apache. So when Linux came, it was definitely less expensive, faster, and everything. But the adoption rate was not as much as you would expect it to be in industry until Apache happened. So what Apache did was Apache suddenly gave a business case to Linux. So Apache worked best on Linux. And it was faster. And ISPs loved it because Apache could do something like it allowed you to host multiple websites on a single machine that then proprietary web servers did not allow them to do. So this was completely something new. So if you look into it, why did Apache work best on Linux? So it was the community members who were contributing to Linux, where the community members who were contributing to Apache. So they were exchanging ideas. And there was this incredible ideas that were exchanged. And the real-time solutions were solved right on the fly and in open. So look at your colleagues as in a much broader perspective. I think that's one of the major shift that we would want to see in industry is working between communities. So when you guys think of opening or, say, working on a new project, right? So the framework allows you to just start a new project and work on it. But I think it's always good to look into what the other projects are there and try to contribute, probably work together rather than working as individuals. So that's one of the message. I think that is important that we learn as we move forward. So let me ask you this. How many of you are entrepreneurs here? Any entrepreneurs? And anybody who is aspiring to be entrepreneurs? OK. Good. So when it's a platform for entrepreneurs to work on because open source world is a place where you can freely exchange ideas and thoughts and everything, when you start a project or when you start something, it's the originality that counts. So people who have started organizations or, say, startups, you would think that, OK, I have some original idea and let me start something. But is that enough? Is that enough? That's the question. So interestingly, Oltair, who is a French Enlightenment writer, he has said that originality is nothing but judicious imitation. So the word judicious is important here. Now, if you look at how Linux and GNU came to this world, there were nothing but an imitation of what UNIX was doing at that time. But so it's really not making it the way to work in a new manner. But it is important that you have to make it work with a new vision. So that's the key. So think about originality as something that when you start something, look at it with a new vision, that it solves some problem. But that's not entirely enough. So what is important is your idea should be enterprise. When I say enterprise, it should have the capability to take complex things and solve complex problems and also earn money for you guys. So the earning money is an important thing because that kind of leads into what we're going to talk next because that gives a customer perspective or client perspective for your product. So think about enterprise. It has a lot of the business and everything. But if you look at it, there is a community and there is also environment. So when we look at enterprise, the choice that you make or set up your project for is important. So when you start a project, don't think of starting a project with just originality in mind. But start a project which can be an enterprise-ready project. So when I say enterprise-ready, you have to make right choices. Now you guys select Python because Python is something that we know that there are enterprise products that are already in use or rather using Python. So similarly Fedora. So Fedora is future for rel. And rel, we have numerous examples that rel has enterprise products running on it. So the choice is really important here. So client. So when you set up this, the client, there is a very blurry definition of who is a client and who is a customer. But a client, you can think of someone with whom there is a regular engagement and for a short duration of time. A customer or someone with whom you would have engagements or say whenever the issue comes up or there's a value, then you talk to the customer than engaging them on a continuous basis. So clients are important. Clients are really important because they really work with you to develop that particular project of yours and make it enterprise ready. It is important that any startups who want to make a product, if you want to say that, oh, we have customers, in the initial days, it's always clients for you guys because you need to engage with them a little bit more and then let them help you to develop a product that is enterprise ready. So that's what Red Hat does. I don't want to take more time here, but that's what Red Hat does. So Red Hat initiates the projects which are enterprise ready. So when you see a Red Hat-initiated project in any of the open source world like Fedora or there are numerous others, they make it enterprise ready projects, but it's not a product. So an enterprise ready project is different from an enterprise product. So the choices that we make for a project is really crucial for us. So there's a lot of brainstorming that happens within the community, and I think which is really important. And we make the right choices. And once that project is matured enough in community, then we take it back to the Red Hat, and then we do a lot of hardening of what we call it as, hardening of the product. And then we release it as an enterprise product. So I think that's for any of you guys who want to start a new project. Think on those lines. I think that's what I wanted to share today from the Red Hat perspective as to how you can develop an enterprise product. That's all I had. Any questions? At the time of building the community, as you said. So what are the challenges with the major ones which were Red Hat looked as a hurdle towards it? So building community is really crucial, that how to be very transparent. You cannot have discussions which are in closed loop mailing lists or say with a small set of people. So when we have decisions that are made in public and taking everybody's considerations, it is bound to happen that there will be a lot of objections, debate, and everything. But if there are logical ways of explaining as to what is correct, then it is very fruitful. Because you would have ruled out many of the problems that might come later at a very early stage. And another thing is it is always good to see collaborating with community that is already doing something rather than starting something on just because we are Red Hat or something. So we always look at, if you see, we work with OpenStack community. There's a lot of contributions from OpenStack. Even though we can just go ahead and start another OpenStack kind of community. But I try we don't do that. We really see that collaborating with other communities is the best way to go forward, which is mutually beneficial. I have one question here. So I need an advice. Like if I wish to be a contributor for OpenStack in the next two years, I'm going to start on it. Where should I start and how should I start? I think the best way to look at it is there are many ways to contribute to Open Source. You can be an evangelist versus you can be a hardcore developer to somebody who can test and report some of the issues. And you can be an architect. But many of the things would require you to build credibility over a period of time so that the community accepts. So to start off, I would say, know what your aptitude is and align any of the skills that are in line with your aptitude. So it is very important that your aptitude is aligned with the skills that you would want to contribute. You might have interest to contribute. But if you don't have the aptitude, then it might not take you longer. So I think it is important that you get that relation right. And once you get the relation right, there are many ways, as I said, from evangelists to whatever, start understanding the product is good. Building credibility that is being on the mailing list, being on the IRC channels, and then trying to talk to people and ask questions. In the open world, people might criticize you that it's not this list, you just go ahead. But they're actually correcting your course. So don't take it in a negative way. There won't be all that nice all the time. But they're always there to take you up to that next level. So did I answer that? Also I would like to add to that question. David, for yesterday, we had a dev sprint. So yeah, if there is any. Also, you can talk to the people at the Red Hat booth. They can help you. One of the things, when he asked about communities, the thing about communities is I've been with Red Hat for more than 10 years. And when I started off with Red Hat, we were just an enterprise Linux company. Now we can't call ourselves an enterprise Linux company anymore, because we are in the cloud, we are into storage, and we are into many things. So one of the lucky things which Red Hat had was, it was earlier on, it was one of the only free and open source companies which was making money. And most of our products are free. In fact, 99% of our products are free. The only products which are not free are the companies which we just acquire and we try to see how we can open source those things for the mutual benefit of. And the second thing why Red Hat has been successful, even from a business perspective is, one of the core DNAs of the companies, we have an upstream first policy. Upstream first policy is basically whatever code we contribute, we send it upstream first to upstream products like the Linux product or the tag community and all. So like most of us are software engineers for the first major thing about any software, proprietary or open source, software is always a liability. Even if it's a proprietary software or open source software, both software ship without warranty. As in it fails in your customer premises, it fails in productions, none of these companies will provide a warranty of your software being run. So one of the things which we do in that way is, we try to not maintain many, for example, many of you, I mean, in your Python projects, you have this requirements.txt file, which you pull into your projects. Although your application requires only a few of it, you're not maintaining all those 30 dependencies, 40 dependencies in your project. Who maintains those dependencies? If any of those dependencies fail, your project also fails. When I mean a liability, these are the liabilities. So, I mean, a general perspective is there are about three million open source projects right now, of which only 20,000 make it to upstream distributions like a Debian or Fedora, of which only like 5,000 make it to a enterprise distribution like Red Hat Enterprise Linux. So why do you think there are three million softwares? And I mean, can't we ship all of this? Only the most stable ones do get shipped as an enterprise product because as Red Hat, we support these things for seven years. So if you take a look at what's a successful software project or what's an unsuccessful software project, these are a few things which you need to keep in mind. And irrespective of its property or open source, few things are pretty common for a successful software. And one of the things is the stability of your code. You don't go on changing the interfaces in your code because there are many other people without your knowledge are using your software, providing stable interfaces, providing stable binaries. Like most of you know about what are application programming interfaces, API. How many of you know what an ABI is? Application Binary Interface. So application binary interfaces, for example, if you're writing a product, you won't go ahead and define what a printf and a scanf is. You accept that the operating system does the printf and a scanf for you. You trust the operating system for it. Imagine the developer, say the G-Lipsy developer decides to change printf from foo is equal to A plus B is equal to foo is equal to B plus A as a definition of printer. Although your programs will behave the same, there's a breakage in your code which is being consumed by your applications. So these are the kind of things which you need to keep in mind when you're building stable softwares around communities, stable communities also. For example, a small example is NumPy. How many of you have used NumPy? Not many of you know that there have been, NumPy is one of the popular Python scientific application software. But not many people know, the ABI of NumPy hasn't changed in 10 years. What is the outcome of this? Now there are three big companies which have built around, who have built softwares around NumPy, like Enthought, Enthought has built software, Continuum IO has built software, and there are many popular projects like Pandas and all, who have just used the NumPy array to build a lot of softwares. And there are communities around it, and there are conferences like PyData, the SciPy conferences around this. Why do you think? This is just one small library with a very stable interface. So if your projects have that stable interface in that, then you can build stronger communities, stronger people come and contribute to these projects, and even companies will start using this. So this is one of the things about contributions and how to make stronger communities from the software perspective. We are a Python development firm based out of Kuchin, Kerala. And just wanted to know if there are avenues for us to partner with Red Hat's products to take to our customers, is there any way in which we can add value? Yeah, definitely. I think if you go to redhat.com slash partners, there are ways of associating, attaching your company with Red Hat. And what you can do is if you know people who, if you know customers whose strength and weaknesses, then probably you will be able to pitch your product with Red Hat products. And whenever Red Hat understands your business, right? So whenever there is a solution, we have solution architects who go and create solutions to the customers. So if they see that your product is in line with somewhere who is already a partner of Red Hat, then there are definitely avenues that you can work with them and take it forward. How's the capacity to build our teams using the B-Dist and the S-Dist output? So one of the things say, if you want Red Hat customers to use your product, it's a simple way when you build your software using the python setup.py tools along with Distutals and other things, you can build out RPMs. So once you build out RPMs, you're not only testing it with the Python ecosystem, you're also testing it with, say, RPM distribution, the same thing with Debian-based distributions. What happens is instead of you trying to solve problems on every distro, the Python's build ecosystem builds it for every distro. So that way you get access to the whole community of users which test this. And if it's better, it's open source. For example, each bug Red Hat solves in Fedora or upstream, like say Fedora or upstream openstat.org or Fedora, Red Hat saves a lot of money. As you're engaging the upstream open source community to leverage to find bugs and to fix bugs upstream itself before you support those softwares. So that's one way you can start engaging. And if it's an enterprise product, yeah, most of the enterprise industry doesn't move as fast as your typical software stacks because in a startup, the software stacks change very fast because they're re-architecturing every eight months, 10 months. But in an enterprise stack, it moves very slow because the kind of customers who use these softwares are banks, governments, stock exchanges where they don't want change. They think there's more of stability than innovation. Yeah, there is a lot of innovation which happens, but it's not their higher priority. It's like, okay, let's try a re-writer application in Scala. No, it doesn't. Because they're happy with C and they get performance and results. Yeah, that's why it's important that, you know, the right kind of choices that you make, the platforms that you work on in the initial time where your software is gonna sit on top of that particular platform and the language of choice and everything, right? So that is really important because you set yourself for a more stable and a more enterprise kind of a project which has the potential to become an enterprise product. So whatever the changes that you see, there's a lot of innovation that happens at the very initial stages of the company. But as you move forward, you know, it definitely will have a slack in terms of innovation but you'd rather want to make it more stable and everything, right? So that's where you shouldn't be struggling with, oh, okay, we chose something when we started, now we have to see, do something else, right? So that's why that thought process of thinking from an enterprise perspective is really important. It's not just the ideas. And also if you're starting a new project or something, one of the mistakes which I did earlier on being an open source contributor, I never thought about deployments to be frank, okay? Thinking about deployments from day one of your project who, like for example, right now Python, okay? And just look at the way people are deploying Python software right now. They deploy it in a traditional way on bare metal. They deploy it on VMs. They deploy it on containerized applications. It's very heterogeneous. As in one company, I mean, those days are gone where one company says use our own programming languages, use our own compilers, deploy it on our own servers. Right now the customers can have everything. They can have a Microsoft kind of thing. They can have VMware and also they'll have Linux, okay? It's, the customers have a choice of choosing how they want to deploy your software. So if you write a, if you write your application and open at that, you can deploy it by containers. You can deploy it via, as a VM images, everything. You need to, the more ways you can get customers to install your software is one of the faster ways you can get adoption of your practices. And the second thing is, yeah, I mean, when he asked about how many entrepreneurs there are and how many want to be entrepreneurs. See, each of us are always learners and we are always entrepreneurs in some other way. Either you're trying to hype up yourself within your company, showing your technologies or something. So these are the changes which you need to be aware of. What's going on in the industry? What are the better practices? This one happens when you come to meetups, read the Python planets and also read the popular open-stock aggregators. So you get to know how it's evolving. Like, for example, the containers. Everybody knows, everybody wants to be in the container space but nobody, there's no clear idea. I can make a container image but how am I going to have it in my data center? Are there clustering things available? Does one company provide it? Does many companies provide it? So those are the kind of decisions which you need to take earlier on in your project. As in thinking about deployment from day one of your project, use your better leverage over other software which, who don't think about their deployments. So they'll just have an EXE file or an EMG file or something like that and say, okay, we can deploy it anywhere. Like those ones. Okay, thanks guys. Yeah. Thanks for this.