 Hi, welcome everybody. Thank you for staying even around dinner time. So our next speaker is Mr. Cedric Thomas. The floor is yours. Give a big hand to him, please. Good afternoon. My name is Cedric Thomas. I'm the executive director of the open-source organization, the OW2 open-source organizations. We are celebrating our 10th year this year in 2017. We are an open-source organization. We host projects. Our mission is to develop a codebase of open-source projects. These projects are developed essentially by a different type of communities, mainly from Europe. We run them. We're not a repository. We are a community. So it's all run with governance. And we have members that pay the fees. That keeps us independent. Of course, we come from free software. We make ours the four freedoms that were designed, defined like 30 years ago. And that makes the foundations of what we do. But we also realize that free software, through some dubious ways, became commercial. And free software became commercial open-source. That's the reason why I want to cover this about the value chain. That's what brought our interest for the value chain. And how we can support our project, become better projects out there in the market. So what I'm going to cover this afternoon, right now, very quickly, is what is the value chain, how we understand it. What is evaluating readiness for market readiness? What is that kind of evaluation, how it works? Then what happens in the open-source world? The technologies and where we come from, how we've been doing this. And then I'll show you exactly a little bit of where we are. So really take it as sharing a work in progress. I'm happy to discuss this with you. The job is far from being finished. So open-source project and the value chain, these projects come all in different flavors. We have what we call community projects that are more or less loosely coupled projects with sometimes uncertain sustainability. We have enterprise projects that are really supported by commercial companies behind and our real market product. And increasingly we have what we call collaborative projects that are R&D projects, many of which are supported and funded by the European Commission. So most of them, they want to address a customer. They all have a mission to be used on the market and to address some users or some customers. But software is only code, and code is just text, and what you do with text, you don't do much. The minute you want to do business with software, this software becomes a product. The minute you want to have a customer with this software or with the services that come with software, we're talking about a product. But what makes a product? A product is not just the code. It's the code plus everything that makes it usable for the end user. Roadmap, documentation, training, support, expertise, etc. And that's where we see the value chain. That's what creates value. What creates value? It's all this. It's not just the code, but it's the code plus what you put around that makes it actually usable by an average customer. Not another developer like you, but somebody who's an average decision maker who has to buy a product to run a business. And what happens when you look at the most projects, the many open source projects, many of those you see rough codes on GitHub, they are stuck upstream. They miss all this, what is downstream, what is between them and the customer. And that's what we call the delivery challenge. This is what we want to address by evaluating the market readiness of our projects. We also have something a bit special about open source is that the average decision maker, they want to trust open source software, they want to make sure that they are predictable, they're not just like there or something developed by hobby developers. And who creates this value? What is the ecosystem? The ecosystem is made of the contributors first, those who write the code, of course, but we also have systems integrators that make the code and the software actually fit for specific business purposes. We also have what we call fiduciary services, which are specific organizations that provide administrative and fiscal or financial services to this project. We have those, this bit nervous, those that sell distribution, think of OpenStack distributions, Doop distributions, Linux distributions. Of course, we also have the users that are part of this ecosystem. They also contribute back to the project and we have the open source organizations. And that's where we fit and that's our perspective. And this is why we think we can bring something to our project. And we bring something in three layers, a technical infrastructure. We are focused on infrastructure software, so we invest a lot in cloud computing and that's where we want to take our project. We also invest in governance and in quality and part of the governance is the quality. We have this quality program that we call OSCAR. This is where market readiness evaluation fits. And we also have a marketplace and this is why we want to have market ready projects that we can provide to the marketplace. So evaluating market readiness and maturity is something that comes from a long time. The model of all evaluations is what we call the technology readiness level. That's something that was developed by the NASA, then reused by the Department of Defense and Department of Energy. And that scales technologies from the bottom where it's useless to the top where it's very useful. It's been exploited in day-to-day mainstream operations. When I was looking at that and thinking what we could do for our project, I came across an investment readiness level scale from an investment company that applied the same approach. Another one in terms of market evaluation is that one where they put the scale flat and from left to right, you have a more business or market perspective. When you see the different kind of stakeholders from the left to the right, you start with basic research with government labs and academia and towards the left and to the right, you have the large businesses and the product. And the red line here illustrates the amount of funding that is often available for some of the projects. So that's a perspective from evaluation. But there is another thing that we come from which is evaluating open source projects. The evaluation of open source projects comes from a long time, long perspective. There are dozens of tools available, typically because the open source projects run on open platforms that generate scores of data and there are lots of tools and companies to analyze this data. We worked with one of them who's been there, I can mention them, I don't know if they are in the room, but some of them are doing very, very good jobs. So for us it started in 2007 with an European project called Colipso that was more mainly academic that delivered something like that which was a huge spreadsheet with hundreds of questions to evaluate the project. So in 2010 we took Colipso and other projects and other tools like Sonar, like Phosology and we decided not to reinvent the wheel, not to create an assessment methodology, but only to make available those tools to our project so that the users can look at the data and have information about the project. So the project was not anonymous, we want to share and make them transparent and share data with the users. And we also reused what we had from the Colipso open source maturity model. We made it a little bit more user friendly. In 2012 we got involved into a research project called RISCOS which had another interesting perspective which was to analyze open source project in terms of RISC analysis and RISC management. What's interesting about that is that it really comes from the fact that open source is becoming mainstream. We had to deal more and more with mainstream conventional managers for whom open source was something a little bit evil, was a little bit dangerous. So the perspective in terms of RISC was something that was interesting from then. The good thing here is that talking about RISC takes the information one step level, one step higher. It's not just about data or just information but it's more about perspective understanding, bringing meaning to the data. In 2015 we came across the Nindex Foundation and the core infrastructure initiative that was launched after the heartbeat failure. And we got involved with David Wheeler and we realized that we're doing pretty much the same agenda. I said that we're much more pragmatic. If you look at the first list of things that we're checking, we're checking whether the project had a website, which is something we're totally overlooked. So having done that, here is our approach. We have a whole platform which is called OSCARNA for open source capability assessment radar that covers many different aspects of projects. It's already in production, so these are screenshots from our website. For a given project we have the result from the OMM, the assessment. This is what you can see from the project. We have the phosology data, we have the SonarCube analysis, we have RISC analysis, our RISC models are public. You can change them, you can adapt them to your business needs. And we publish, we end up with a market readiness scorecard. But it's just a scorecard and it's not the technology readiness level thing we wanted to have. So the work in progress in the presentation, no, no, this is the most important one. The work in progress is that we have lots of data out there produced by many different tools and we need to put them in a one-dimension scale. That's what we're working on at the moment. The one-dimension scale is a series of different scenarios and each stage of that scale represents a different situation, a different scenario. It's a synthesis work that we're doing with our project managers and that we're planning to really announce at our annual conference in June. That's all. Thank you. So I'm sorry to do what the second mic isn't working, but we can still take some questions. I'll just run the mic up and down. Anybody have? I see a question up there. Yeah, we're talking about the CII and the CII is mainly about evaluating security in the software. It's not only security. When we discussed with them, we realized that the scope was broader than security. So we're also trying to add to that actually merge all the different criteria we analyzed so that we have a common standard and had security. Maybe security we will not cover. We leave that as an option for them. Anyone else want to shout out a question? No, I don't have that feedback of whether companies have actually used them to make decisions or whether that has influenced decisions. What I know is that users are looking at those because we see the way the pages are consulted. What we do, we kind of reserve this for our project. So in order to project gets into the code base and has access to all these facilities. And again, I have to say it's a co-production. It's something that we do for them, but we expect the project leaders to also do and contribute because we understand that helps them improve their project. So we work together on that. So if there's no more questions, then I would like to wrap up and give a big hand to Cedric for his talk.