 There we are. So good morning everyone. Welcome to Flog. This is the first talk after the big one, so hey. What I would like to talk to you about today is a little bit of, so it's a problem which we may not have entirely in the Federal community because we are pretty much, we are quite open source oriented. We like making our projects open source and our contributor I use to this period on how do we make project open source, how do we run project open source, but even within communities or companies that are open source friendly, there are always people or situations where people are not feeling like not ready of making the project open source. So one of the questions which I've been wondering is in such an environment which is so friendly to open source project, why are people actually not willing to make the project open source? What are the reasons that they give, that they say well, I can't release this now because of these and these reasons. So I've come up with a list of about 10 reasons. I'm not going to go through them right now because I'm coming back to this, but these are basically a little bit about the main 10 reasons that have come up, that came back the most often. And then there is one more reason. That's the 11's and that's one is the I do not own the code. Well that's one we're gonna very quickly talk about it because basically there's not much things we can do about it. If you don't own the code, if you don't own the project that you want to make open source, well then, I'm sorry but there's not much I can tell you on how to make it open source. Talk to your manager, to the person who actually have the code and see with them if you can work something out or just be more careful the next time you start the project that you want to make open source. So back on our 10 reasons, there are things like I do not know how, there are reasons like it's not worth it, it's a small project, it's a small idea, it's not worth publishing, it's people don't care about it, anybody can do it in half an hour. There is no point, so this is similar to the it's not worth it but this is more like there's no point of making it open source because nobody can run it. You need such a specific infrastructure that nobody's gonna be able to replicate, nobody's gonna be able to work on that so there's no point of making it open source. It's too much work, I don't want to know it's too much work, then you have to do things and yeah, there is no documentation, there is no test, there is the most famous reasons. I want to clean the code first or the other one, which is great. I want to do this one more things and then I release it. It's good enough for production but not enough to actually look at the code. Pretty much. Then there is also all the question about making a business out of it so someone with still my ID, there is, what is my business model if I make my project open source or there is the question of it's business critical so if I release it then people will again steal my ID or work on it so if we work through them a little bit closer, the first one is I don't know how. So while there are a number of resources available, there are books, there are websites, you can go to conferences. In conferences you can make people that are already contributors to open source projects, you can see community managers and you can meet people from different teams so like Red Hat has a team dedicated to helping projects make it being open source and how to build a community around them. So that's the OSAS team within Red Hat and if you have questions, I'm pretty sure you can contact any of them. We have Remy in the room here and I'm pretty sure it would be more than happy to answer any questions you could have or any problems you're facing by making your project open source. But you know, making a project open source preferably free and open source starts from the start. Your project is using, you know, it's an application so there is the sources. It might be a design project, it might be a book, it might be any project starts from start, make it public, make the source met what you use to build this project public. It can be as simple as a table on an STP server. It can be an HTML page on your personal page. It can be a blog post. Just, you know, start from the start, make the code open source and that's your first step about making a project actually open source. So one of the reasons that I was wanting to is the producing OSAS.com website. It's a book as well. It's a book which is free in all the meaning of the term. So it's a free book that you can download for free and it's a free book in the free and open source meaning so that you can actually improve and work on it. So quickly to mention, to visit the page and see if you like it or if you like it. There are these things you like, you know. The second category of points that we got was the it's not worth it. It's too specific, nobody will run it or it's too much work. Well, these are what I called fake reasons. So these are not valid. These are not correct arguments. You can't refuse to make a project with these reasons and it's very simple. It's not worth it. Well, the first question is how do you know? You know, it maybe took you half an hour to work on that but maybe somebody was struggling on this idea for a couple of days and was trying for the angle to approach that problem. And I have a friend of mine that was like writing a prototype on something and I was like, you should blog about it. He was like, no, it's not worth it. And I'm like, dude, it's maybe not worth it for you. It's maybe just a prototype. It's maybe just something that you worked on quickly one evening. But I like the idea. I like what you did. And if I had the time and if I was willing to, I might just take on your idea and do something with it. So, and you know, it's just the first step for me to get starting in pushing that idea further. But no, he still hasn't published it. So I'm still angry about him. So yeah, it's not worth it. You do not know. It may be not worth it for you, but it might be worth for someone else. And if you just, you know, publish your idea, make a blog post about it, put a simple HTML page somewhere. People might actually find it. Put a very permissive license on it if you don't care about it. But put it out there. I mean, it won't cost you anything and it might actually help someone. The second point is, there is no point from an infrastructure point of view. Well, we have a couple of projects in there which are a good example, something like Copper. So to run Copper, you need to have a complete cloud infrastructure because Copper spends a cloud instance when you want to build something. And then we have a bad example which is TransEffects. TransEffects used to be open source and then they moved to a completely closed and proprietary model. And one of the reasons why they moved to open source to a closed model was like, nobody is running TransEffects. So why do we care about making it open source because nobody is running it? So what's the point? Well, was the fact that they were making it open source preventing contribution? No, they're still a contributor even though nobody, people were not running TransEffects. I've been contributing to Copper and I do not run a cloud instance in my laptop. So the fact that it needs a very specific infrastructure does not mean that people will not contribute to it. And if you're actually investing things like unit tests, this is actually even easier because then people can contribute to your project when the unit tests and if your unit tests are built in such a way that you don't need actually the infrastructure to test the code, then you actually are enabling people to help you to work on your project, provide features, provide bug reports or bug fixes and that without actually having this infrastructure problem. So there is no point from infrastructure to point of view that's up to you on how you build your project but you can make an open source project with a very specific infrastructure required. Then the other point is too much work. Well, this is actually not true. This is exactly depending on what you want to do with it. You can make a project open source free and open source by just releasing a travel on an FTP and just leaving it there. You can make a project open source by making a blog post about it with the source code attached to your blog and leaving it there. How far you want to take your project is up to you. It's if you want to build a community around it, if you want to support, to have tickets, to have a mailing list, to report these issues, this is up to you. You can just make your project there, leave it there, people can find it, can contribute or just fork it and then someone else might step up to actually lead this project instead of you. Which is great, I love when I don't have to work on a project that I started at home. This is the best sign of health for your project. Somebody else, the idea was good enough that somebody else stepped up and took over the project for me. And then we have the second categories of reasons. These are, there is no documentation, there is no tests. I want to do this one more thing or I just, I want to rewrite it first. And these are specific to one thing which I would call the hubris. And this is something which in IT world, we have a thrilling background at that. And that's something which we might want to work on to improve things. So the hubris aspect, I think, comes from one of the old, comes from a whole idea. So this is Larry Wall, Larry Wall who is the person who created Pearl and he wrote a blog post saying that there are three virtues that every developer should have, laziness, impatience, and hubris. Laziness because you make the computer do something for you, impatience, you make it so that it's fast, and hubris, so we have the complete definition of the next slide. And it's basically the quality that makes your right and maintain programs that other people won't say anything about. Well, this is one way to look at it and I would like to propose an alternative way, which is the quality that makes your right or create and maintain a welcoming community around your project. So that means that it's not about the project itself, it's not about the code, but it's about the possibility of the project to evolve. It's about the possibility of your project to become better, to have people that contribute to it and improve it. And there is something about this, which is the way that we are perceiving ITM project in general. So there is this well-known saying that says kohito ergo sum, so that's Latin and that translates to I think therefore I am. But in the actual world, it's not the way we're seeing it. We're seeing I do therefore I am. So we are actually, people are the perception that they are being judged not by what they are or who they are, but what they do. So you're a great programmer not because of the way you attacked and then you took an angle on the project on how you thought about this is a great idea, this is a way of solving a problem. But you're judged as a developer by how you wrote how the code looks like. But the code is the technique, what's important is the idea. So and that relates to a thought that was even by Kaplan Moss at PyCon this year. The URL at the bottom is the YouTube for his talk, which is available online. If you haven't seen it, it's great talk. I really encourage you to go see it. And what Kaplan was saying is that in the IT world, I don't know if you noticed, but there are only two kind of programmers. They are the very, very bad programmers and the very, very good programmers. So the IT programmers looks a little bit like this. You have the average programmer in the middle here and then you have the very, very bad programmer on one side and a very, very good programmer on the other side. And there is no average programmer. It's just your eyes are good or bad. And actually, this is not even realistic. I mean, this is more what it should look like. You have a bunch of very, very bad programmer and then you have a few very, very good programmer. But you still don't have any average programmer. But we know when you do statistics and when you look into a population of Pearson, we know that talent or skills are actually following what we call the normal distribution. And the normal distribution looks like this. You know, it's a bell curve. And that means that most people actually here, actually 95% of the population is between the two red lines here. So if we are, I think we are 200, about 200 people in the conference, that means that there are 20 people in the conference that are of which 10 are very, very good. 10 are very, very bad. And the rest of us are just average. Yeah, so we have one identified, we have another nine to five to find. But most of us are just average. And this is a perception of what we are and how we do things that we need to change in the IT world. We need to stop thinking that what we do defines us. It's the way we are thinking about it that's important. So we have to realize that we are just as good as the next guy and as bad as the previous one. And one of the ideas that I don't want to publish my code because it's not good enough, because I want to rewrite it, this is a wrong way of doing it. You need to just open source it and then rewrote it. Then build a community about it. And people are afraid that if I publish bad code and then a recruiter from Google, who read out comes in there and sees the code and he's like, this is terrible. I don't want to hire that person. But if you're able to tell the recruiter, like, yeah, this code is bad for these and these reasons because I took this and this shortcut because I didn't know that then, then you actually are able to explain the recruiter that you have a self-critical look about your work, that you're able to tell this is bad, this is how we improve it, and this is what I want to do with it. Then you actually are able to prove that you can think about your work, that you know how to solve a problem, and what's missing is basically the technique. And the technique is the programming part is just technical. You can learn that, writing good code, something you can learn. Having a critical look about your work is the important thing. So it's actually maybe a good thing of publishing bad code and having a good open source and LC relation with the community to improve your project. That's actually a better point than directly publishing an amazing code that nobody want to touch because nobody knows how it works or to improve it. So this is a little bit of all the points which I want. We have to, in the actual world, change the way of perceiving what we do and start thinking about who we are as how we approach something and not about how we are doing things. And then we have all the reasons which are basically running around the business side of things. So I don't want to publish my code for all the business reasons. We can go through them. So the first one is someone steal my ID. Well, that's what licenses is so important in an open source project. You can choose license. There are a large number of licenses which are allowing you to just pick the right one. There is the website, tldrlegal.com, where for each open source license and they are I think most of them or all of them are in there. For each of them you have the can, cannot and must of the license. So what you can do with this license, what you cannot do, so most license you cannot be made reliable for the program. And then you have the must of things like you must include a copy of the license with the source code, these kind of things. And using this website, you can actually find the exact license that you need for your project to make sure that people might actually reuse your ID but they cannot steal it to make business out of it if you don't want to. Then we have the question of what is my business model? Well, we need to remember that free open source software, free open source projects does not mean free beer. It means free source code. It's mean access to the code. So there are a number of projects that are using open source plus, using open source software, open source tools and that are just being sold. I mean, Android is open source based. Real, as we say in open source projects, Emax was sold at the beginning. Transifx, before it became proprietary, also at the business model based on an open source project. So don't forget that the expertise is in your house and you can actually use source, you don't sell the support, sell the teaching. There are a number of business model around the open source software, which, so this is an article from John King, which is called Seven Open Source Business Strategies or Competitive Advantages. And it just goes through all the difference, all the seven business model and how you can build using open source projects or with an open source project, how you can actually build your business model. The link of the article points to the actual article. The link at the bottom points to the article. And so we have something like the Red Hat, where we sell support. You have something like Geo Licenses, that's the MySQL model. You have something like advertisements, eventually. Sorry? So versions, you have the community option. Yeah, you can also have this. You can have like a proprietary version, which is version N plus one and then version N with open source and then when you release N plus two and plus one becomes the open source version. So you have a number of different business model and this article goes through them all. Then we have the, is it business, it is business critical? And then the question is, is all of it business critical? Or can you not open source the parts which are not business critical? If you're really saying that something must remain preparatory, well, can you actually keep these ones and then contribute the rest of it? And that will already help to get contribution. Eventually this might even lower your maintenance burden. If you contribute your changes upstream to open source libraries, then you actually are going to have more people eventually helping you and therefore you have eventually less work for your developers. So it might actually be a good thing at the end. So this was the 10 reasons that I found and this was the thought about which I was having about all of them and basically if you have questions, I'd be happy to answer them. It was worth. So the question is, is the license, is the license actually preventing you from doing business? It is true, but you have something like the HGPL license for which any modification to the source code must be made public as well. So it means that someone can make business out of your code but they must make their change to your code public as well. And therefore you can take their, you can also take their change back to your business. What were the last things that? HGPL. The license has to be made public. Yeah. This is a campaign. Yeah. Remain here? Yeah, which is actually not the case with copyright or permissive license. This is where anyone can, you can't stop anyone from making a business out of your code. The only way to make sure that they can be a partner and not a competitor is to use copyright. I'm not aware of this. Thank you for speaking. You can't stop anyone from making a business out of your copyright software. No. Right? There are all kinds of consulting companies that use this installation. So it's not stopping the business as much as putting one of the same competitive platform, right? So that you have the same software. I'm sorry, you have to divide between code and that idea. That's the first point. Code is not the idea. The idea is something else. Making business out of an idea, that's not a copyright thing. It's always prevented, it depends a little bit where you live in the world. In Europe, it's always prevented because we don't have public domain. As you asked, so Beethoven's fifth will always be better with that. So that's the idea. You can't steal an idea. You can't steal it. It's not possible. It's always your idea. I had a question. Is secret sauce a myth? Because that's one thing. It's kind of related to the business reason. As I said, people will say, well, we don't want to open source this because it's our secret sauce. That's something we don't talk about. The question is a secret sauce a myth. We don't want to open source it because this is our very specific business model. I think this relates to the last point. This is very critical to our business and we really don't want to open source. Well, what about everything else? Can you make everything else open source? And then, you know, this is the least, I would prefer everything to be open source, of course, but if you really want that part to be, well, then maybe there's other things that can be open source. What is the takeaway on this secret sauce that we don't have to get? If you actually want to open source, I've seen projects literally putting a table on a website. All that the upstream developer was doing was uploading the table of the release. There was no source control. There was one, but only for himself. So people, that was a little bit, making contribution will make it a little bit harder because you would send a patch and it would have really changed some things and your patch would, of course, not apply. So you can make it open source by just putting a table somewhere. It works, I mean, this is, technically, it's valid. Yeah, if you want to make it open source, you can make it as simple or as complex as you want. The question is, do you actually want to build a community around it? Then the question is no more about, do I want to make more project open source, but do I want to make a community around it? Do I want to get contribution? Do I want to get bug fixes and reuse, this kind of thing. Does that answer anything? One other comment I'd add to that is that no matter how many smart people you have working inside your organization, there's always lots more smart people outside if you don't have them to help you build a community. Even if it is your secret sauce, why not use the smart people on the outside of your organization and tell them about it? The point is you have all people all small in one area and you just have to put the person to the right area. That's the point. You might be a bad programmer, but he's definitely better in writing documentation or something like that. It's all people are small in their own way and you just have to put them to the right stuff. Yeah, but there might be smarter people in that same area outside your company. And you need... And if you can get them to contribute, it's even better. Every person. So I just wanted to ask, why don't you work with the government and enterprise in managing their way through open source licensing and also sit on the open source industry association for Australia? The main question that always comes up a lot and the question that I kind of want to shove with you in there is, you mentioned a few thoughts and codes put out there. And of course, there is a valid question that goes, okay, well I've written this piece code, I've written something, I can just put it out there, but at the same time, that can also add to the frustration and fragmentation of the end user that comes along and finds a project that they really want to adopt that hasn't been updated in the last five or six years and that can also have a negative impact on our industry as a whole for people outside of that kind of going, well, it's open source projects and just things that are sitting there and no one's coming in to you. What would you say to combat that? I think this is one of the places where as much as I kind of don't like them, platform like GitHub are actually providing an answer because the Google code used to do that a little bit as well. They provide you a way of seeing how LC the project is. They give you a graphical representation what were the last commits, how many people contributed, are there tickets, how many tickets are laying around, how many requests are still open and not being reviewed or worked on. So the fact that GitHub make this contribution model completely open actually helps to determine the health of the project and as a developer I've been running in too many projects that are like, yeah, this looks interesting and then you look, you have 20 requests that none of them have merged, you have 400 tickets and the last commit is five years ago and you're like, yeah, I might not use that one finally. There are also a number of different kind of things trying to help solve this problem, right? Like for example, Skolo, and all the, I think they changed names there's also something else to talk about. Open Hub, what's it, Open Hub? Open Hub, right, by Blackhug, but there's other ones as well and personally I would actually, I'm surprised that we have to see a really big rise of consulting organizations that help you navigate open source projects. There used to be some like 10 years ago, they all kind of died, but it kind of seems like that would be a really useful thing. I actually think it's something that Red Hat should offer as one of our products. Now we should develop a world of coffee. Yeah, yeah, I agree with you, Nino. Yeah, I'll be first. Something I've noticed is that depending on the environment you're working in, an idea, I'm not judging it as an idea or an idea to tell it too closely actually becomes a roadblock or the mindset becomes overprotecting to some idea and the next good idea just doesn't even enter into the thinking process because you're only this side of it. You get an air out and it gives room for other ideas into the pipeline. Yeah, that's right. Actually, there's been a bunch of writing about this self startup problems and that basically if you have an idea for a startup, you are about a thousand times better off if you tell everyone you know. And the reason is because no one, kind of said at this point about that, no one can really steal your idea, but more importantly, no one actually cares. You think that you have the best idea in the entire world and it's gonna make a billion dollars and everything else and for you, it might, but for almost everyone else in the world, it won't. So it's kind of like, you're much better off talking about the self startup, there's been a bunch of work going around, in fact, that self startup concept. Yeah, some things. It's good. I'm just gonna say, this is great, I think we talk about, yes, these are a lot of technical reasons, but I think one of the things they don't see enough about the Sasanians, the importance of community in this process, that you see a lot of, and with this open study, open SSL, project access issue, where they've said everything's involved, or people, of course, the statistics, a lot of other products, Bash, Gits, are very similar, one or two people doing it, and even other projects where you do have multiple contributors all the time, who smoke, because they're primarily from one company, so I think the big thing that has to be overcome with this is ensuring that you have a healthy community around your project, otherwise, yes, you publish it, and I know there are a few companies that, there will be a few projects that publish their things, but primarily, if it's all one company running the show, and you may have maybe a handful of contributors outside of it. Most projects are going to be this way, anyway. You have the main contributors, the people that created the project, and then you have a few contributors coming, most open source projects are going to work this way. There are very, very few projects, like the Link's Journal, where, and even then, Red Hat is the one that dominates the number of commits somewhere on the Link's Journal, but there are very few projects, like the Link's Journal, where you have a bunch of companies that are actually invested, developed by time, into that project. You also think that, I think it's a large part of the project, we go back 10 years, 15 years ago, now we're in the point where open source is not, there is actually a industry, and it is, so therefore, we've got a lot more companies that are driving these projects, et cetera, but there is a very big difference between a company-driven project and a community project, and you notice the difference in the projects, for the companies that drive it, something that actually adopts and take on, the community approaches, share that community roadmap, and get people to contribute back to that roadmap, not as opposed to ones that keep it more closed. And I mean, I just feel that we're in this interesting point where within our industry, because we've hit such a good group roadmap, but that's just something I noticed. My tuppence. So I had an actual question, too. Do you know any examples of companies that are successfully doing the N plus one kind of release model? I don't remember the exact company name, but Virtuoso, so Virtuoso is a triple store for the semantic web technologies, and they do have an proprietary and an open source project, and basically the proprietary project has more features, so it supports a larger dataset, and it's also normally basically one version above. The... Do you have a license that you used to have? Probably a dual license. Yeah, so it's like, when it does make a custom, there's not an industry standard driving a lot of it. To be honest, I don't know if it was recently allowed to have a latest version of what it's called, but several have been able to do it in that way. Manga, and it's available. What do you have on this one? You get contribution by the source code is open, and then part of it, so some of the optimizations will be not part of the main repository, just in a sense. Yeah, it's version was one thing. Yeah. It was, for example, a GPL. Yeah. And if people were actually sending the project to you, it would have to be a proprietary version of it. But it doesn't have your M.I.T. or... Yeah, I don't get it either. So I'm not sure exactly which license I use. I have a friend's company who like... It's been a long time since I've been on the source of your stuff, and I think that's a lot of ways to go with Manga, but I didn't know many examples of any of the questions you were just, there's a fear kind of a way to do that. Thank you. It comes to versioning. There's also the possibility to get the source code later to the project, which was used by Red Hat. Long time ago. Which Android is using? And also suitably used it, sir. They are successful companies, you know, using this model. Yeah, it's not much to prove in the success as much as showing them a model that works. They don't want to figure it out. Oh, we'll use it this moment. Oh, we'll talk about it. You know, there's other sources to get there. Well, no, they have some close ones. Any other question left? Well, then, thank you everyone for coming.