One year of open governance for OTB: thoughts and context
Grizonnet, Manuel
One year ago, in the frame of the OSGeo incubation process, OTB team decides to initiate a Project Steering Committee to formalize the way that decisions are taken. It was largely inspired by existing governance in other OSGeo projects related to OTB like GDAL, Quantum GIS or GRASS. This initiative aims in encouraging people and organization to join the effort and participate more actively in the evolution and the decision process of the library. Most people well understand this approach and join the effort to provide high level guidance and coordination for the ORFEO ToolBox to guarantee that OTB remains open and company neutral. This presentation will come back on the set up of this open governance, how it improves the way that the project progress, how it could evolve in the future. It will be also the occasion to interact more largely about open governance and decision making processes in free and open source projects. Manuel Grizonnet
 It's also not another technical presentation. So I'm working to lose at the French Space Agency. I'm working mostly on the development of an open source library called Orpheo Toolbox. And the goal of my presentation is not to present a TB. I've got only one slide. I've got a presentation Friday morning about the TB. But about the status of the incubation process for OTB in OSU. And Orpheo allows us to make some improvements in the way that the governance and the project is working globally. So Orpheo Toolbox is an image processing library. It is, how can I say it, it's a library using all the other library libraries like Goodall, Osim and it was funded in development. As a byproduct of the development of a satellite called PlayAD, which is an optical satellite, which is able to produce submetric images. It was launched in 2010 now. So since 2006, CNES is developing the software which aims at giving tools, algorithms to help people extract useful information from images. It's used at CNES, of course, but also now in other agencies like the European Space Agency, which uses OTB as one of the libraries in the ground segment to produce the Sentinel-2 image we saw this morning. And it's written in C++ on top of the inside toolkit library, which is also an image processing library, but dedicated to medical images. It's using lots of other libraries, Goodall, Osim, OpenCV, and to give you an overview, we saw this morning that all those raw data is now available with the Landsat, HATES, Sentinel-2. The goal of OTB is being able for users to go from this raw data to a classification map, combining algorithms, external data, etc. So the topic of my presentation is to give you an overview of the OTB-OSGO incubation process and to describe how it allows us to change the way we worked and how decisions are taken now in the project. Explain how the project steering committee is working now that we have set up one year ago, and to sketch the possibilities offered by these more open governs. So the OSGO incubation, OTB is not a really famous project in OSGO because it's quite specific in terms of data we are working on. It's a library, you need to combine algorithms, it's also quite specific as the guy from the Open Commission said this morning, the users are public scientists or public administrations, so it's quite far now niche, I would say. But we've got users and we applied for the OSGO incubation in 2011, we start again in fact the incubation process in 2013, we find a mentor, I want to thank him, London Lake, and we start to complete the checklist. It's a long process, which is sometimes too long discussions, but as you will see it's a hello us to really improve the way we structure the project. So here's the checklist, OTB has always been an open source project since the beginning of 2006. Everything was public, there was a mailing list, etc. etc. So the first point was the infrastructure transitions, the source access was okay since the initial of the project. The way that the community was functioning, it was not existing, it was mostly managed by people like Ness. Ness was funding the library and there were people like Ness like me, which were driving the library and the decisions and I will focus on this point, but now we've got this PSC. And we are now at the last point of the OSGO incubation checklist, which concerns the code copyright review, but you will see that OTB also since the beginning follow, I wouldn't say, good habits regarding the way we are. Keeping track of copyrights, we are keeping headers on our files, etc. etc. We don't have for now a Committer Responsibilities Guidelines, such things, it's something which is in progress, I will come back to this. And after this we will be good, I think, to become a member, I hope of OSGO. So how was the decision making process before we create the PSC? As I said, it was the benevolent dictatorship dynasty who made future requests. Everything was decided, in fact, at the French Space Agency, Ness. Everything was open, of course, everything was open source, but the future requests were made by persons involved in Ophio projects, so colleagues at Ness, or users we are working with in France. It was people inside the Ness, and also users from the main Ness, of course, but who decides at the end, at the beginning, it was the Ness team. With the support also of a company, CS Communication and System, which is a developer, a contractor of the Ness, which is developing OTB since the beginning, and also developing activities around OTB. And who actually racked the code, it was CS developers, but also people at Ness, which are involved also in the development and are not only making contracts to make the development. So why we decided to change? It was not only because of the OSGO occupation, it was really a matter of transparency, because users were, of course, are often informed afterwards of major changes. We tried to get people involved, but there was no some kind of rules to follow to add new features, big or small features in OTB. There was no insight or motivations of what we are doing this or that. It was, of course, difficult to participate in decision making because there was not really process. And OTB become a big project, so with lots of algorithms, lots of applications, and there are lots of ways to contribute to the project. And it was, there was more and more people who want to get involved, but it was more and more complicated to follow what's going on in the projects. So we want to do his contributions at that time. There was no procedure. We've got external contributors at that time, but we don't have really a process to get this contribution. And of course, there was also, as we discussed in other presentation, a question of sustainability, because CNES is funding most part of the development of OTB. But what if one day CNES stops funding it? And we wanted to get new actors more involved in the project. So it's like two years ago. So we create this PSC. This project steering committee is mostly, we take the experience of existing PSC. We've got in quantum GIS in Goodall and other OSGO project. And we didn't reinvent the wheel. It's the same with the code. We don't want to do this. And we didn't do this also for the project steering committee. So we have now this structure. And what is cool now is that more one year and a half at the beginning, there was only people from CNES in this PSC because we bootstrapped the steering committee. But people outside CNES from CSB, which is a laboratory scientist, which is doing research using OTB. He's now a member of the PSC. There are some people from IHRSTA, which is a public administration, and also people from CS, which is the contractor, which is making development of OTB and CNES and for other companies. So how this PSC is working, the PSC is the workflow is highly coupled with the way we are now doing and making decisions and adding new features in the library. OK, people in this PSC are developers or people who know where the library and follow the process on how we can have the new features in the library. So they are deciding the workflow, the testing procedure, how we will package, which, when we are going to do the release, etc. We took also the experience of Goudal, I think, is using this kind of request for changes procedure. When you first describe, it's called a request for comments to start, so you've got an ID. You go to the OTB Wiki and you don't have code yet, but you've got an ID, you describe it and you can have some comments and start a discussion about a new feature you want to add to OTB on the main list. Then happen the development. OK, and you will propose a request for changes for OTB, so it's another description with another template and we start a procedure, a process of review of these features, a public review and a vote. OK, and then it's merged in the library. And we've got also now the fact that we've got a release manager, which is managing the way that we are introducing new features in the library and when we need to do this. And it requires the approval of one person, which is nominate for every release. So that is a short reminder of what is the process now of our decisions and how development are done now in OTB. So of course it has been some impact on the way we were developing new features. So we moved to Git. We were using Mercurial since the beginning of OTB, a subversion at the initial start of the project, then Mercurial. And we moved to a Git workflow to be able to transfer this ID of requests for comments and requests for changes in a notion of branches. So it's a little bit complicated, but it's working like this in lots of projects. You start for the developing branch, which will start at the initial of the release. You are doing some feature branches, those feature branches which correspond to a request for changes. And it will be approved and then merged. And then we'll start a new branch to do the official release and etc. etc. etc. So it does not exist before in OTB. And the way that we are declaring this new process makes us change the way we are also developing and managing the code in OTB. So the release manager accepts requests for merges and then corresponds to a PSC which approved this request. So every release is now planned every three months. That's something also we changed because before for users they didn't have a clear idea of when will be the next OTB version. Now it's every three months and they've got a clear idea of what they will find in the new release. And after one to two weeks we will release one of the releases. And it's working pretty well. That's also something I want to point out now. The way that we have set up this description of new features. So it seems for developers a little bit at the beginning it's a little bit complicated. You need to go to the wiki describe that you want to do exactly. You need to follow some procedures and template. But it really helps us to to constraint and allow users to have a clear idea of what's going on and why we are doing such things. So we've got request for changes not only for CNES now. That's also a point I will come back to this. We've got new contributors. We follow now this procedure to be able to get some new features merge in the library. For users so every significance as I said ongoing or past changes is not public and visible. Users have the opportunity to comment pending request for changes. So everything is it was always public but also those discussions happened on the OTB mailing list. What I want to say also is that users can also file new requests, comment them and for them releases are more frequent. And it's a really a good thing for them. For contributors so there is a clear and detailed process as I said how to get the code in OTB. Contributors are guaranteed to be treated with equity. I think it was the case before but now it's stated we've got some rules were following those rules and everybody knows about them. And they know the deadline when they want to get a feature inside OTB. For developers of course following the procedure there are some pro and cons but there are no more silent code of hundreds of modifications of files that could happen in OTB. It's not possible anymore. It's impossible to do this now. Of course there are some adjustments needed. We accept comments from review. We're getting the code merge. It takes more time of course to be able to develop a feature. For small features you can ask do we really need to make a request for changes and follow this procedure which is quite light. But for really tiny modifications it's a little bit complicated. And I will go a little bit faster. So pros on the overall I think that we would that that's really good. What we have done here where we have more code reviews we have more contributors. The changes we made are more consistent because we are making one feature then everything goes to one branch and is described. Everyone can get some give his opinion even people which are not on the PSC. OK. And new features are more visible I think. OK. The project steering committee for OTB is still small. OK. There was initially lots of people of CNES which was not a good thing. We want to get people involved but it's working. We've got now more and more people from from other organizations in it. Of course it does not. It does not solve the point we were discussing before about funding. OK. It does not make possible if the funding is still mostly are mostly still coming from CNES. But we hope that making this organization will will make it possible to to get new organization. Make some funding and do request on their own without without having to to to get some help from from the CNES. OK. We are we can improve the way we are reviewing code is not so important. I will skip this and we still have technical problems with with those procedure. It does not solve bugs and etc. I will skip this voting part and this also. We are doing PSC meetings. OK. Also through IRC after after each release. And we are also publishing the log in the minutes of the of those meetings. And and it's the place where really important questions are discussed. It's still a young organization. It's of course a tool that we can adapt. And and also the process can be can be can be discussed and can be changed. So I will go to the code review. But I don't think I've got a lot of time. But the last point of the OSU incubation process for OTB concern the the code review. Also for OTB the the way what we we've got contributions and we were using external libraries was done I think it's a pretty good way and right way since the beginning. All the dependencies are licensed in Apache or MIT's license. The the contributions are licensed in the CC license. It's a French translation of the GPL license. OK. It's compatible with GPL and also license which is I don't know. I would say this the open to the open the OZ organization. I've put a stamp of this license saying that it's open and open source license. We don't have yet what's called a contributor agreement. But we want to do this. We have I think a good good management of the copyrights etc. Also with the help of the packages like Debian as OTB is now official package of the Debian GIS repository. It helps us a lot to correct small and make some improvements on this part. And we've got also in the frame of this code provenance review a discussion initiated at the CNES to move also the OTB license which is a GPL like license to an Apache license. That's something which is ongoing and that's why we didn't finish the OSU incubation for now. I would like to finish and to decide on the OTB side if we move to an Apache before completing the incubation because it would be a big change. So I will skip the this code review. So in the frame of the Azure incubation and also in the frame of this discussion to move for to GPL to Apache we have done a code review of OTB which is now completed. And we have started the process to contact the contributors of OTB to make them sign and give and get them get their agreement to change the license. And I've got considerations about changing and relicensing the project and it's not an easy part. It's a big decision and I think we will be able to complete this this year. And that's my conclusion. Thank you. So we've got time for questions. You have one minute to finish your last slide. Yes I can finish. So what I said okay I want what I want to say is that I'm not sure that being an official project for OTB and an official Azure software will change a lot of things especially for CNES. But I think that the process and the incubation even if it's a long process, long discussion really help us to make the project more open and the community more involved. Even if the project was open since the beginning everything was open the mailing list etc. And I think we were doing this in a pretty good way. The setting this PSC and following all those rules that have been set up in another project and try to adapt to the context of OTB really help us to make a more open project. That's it and I hope to be able to to complete the change of license and then being able to be an Azure software hopefully this year. You can ask me questions. We've got different type of users for OTB. You've got users on okay agencies which are on the ground segment using libraries as one of the components of a big project for them. I'm not sure they will see the difference. I hope it will help them to take the time to make contributions, more contributions to the library. At the complete opposite we've got end user, okay, thematic user, scientists which use graphical interface based on OTB and also they saw new features. But for them there are still the websites, the mailing list. I don't think they follow all those discussions but I don't think it's changed. But in the middle you've got contributors, scientists also but doing image processing or organization like IRSTA which are not a member of the PSC which are using OTB as one of their components which is spreading their organization. So it's one of the key components for them. I think it has changed the way and it's helped them to say okay we can be more involved in this project. We can participate to the discussion and perhaps it has changed perhaps the decision choosing between one tool to another one to make some developments. I hope it helps them to make the decision to take OTB. So for public administration, some administration in France, I see the difference. So to for instance remove proprietary software and move parts of their process with OTB. It was the same timing as I said as we changed the policy on the on the governance. Yes. Okay I didn't get it. It's a good question. First the license was chosen in 2006. The CNES was not really used to do open source at that time. So they choose GPL considering I don't know really. It's perhaps also with the ID perhaps to do dual licensing. We have discussed this I think in the first presentation. So they are different way to to make to valorize your open source project. CNES does not want to to sell software. It does not matter for them but they want to to create an ecosystem where other companies in France or in other country use some satellite images but also some software and develop some business or activities around OTB. There are some companies which use OTB and develop activities at the Upran Space Agency for instance but they they have since the beginning said that a less permissive license less Apache will allow them to to to do some proprietary software of course with OTB and it will facilitate in their perspective the development of of activities and business with OTB. So it's more a consideration of how CNES can help companies in the in around them around CNES to develop activities with OTB. I don't think that it will change also a lot things for CNES for lots of users. They don't really care about the license for most of them. Thank you.
 It's also not another technical presentation.  So I'm working to lose at the French Space Agency.  I'm working mostly on the development of an open source library called Orpheo Toolbox.  And the goal of my presentation is not to present a TB.  I've got only one slide. I've got a presentation Friday morning about the TB.  But about the status of the incubation process for OTB in OSU.  And Orpheo allows us to make some improvements in the way that the governance and the project is working globally.  So Orpheo Toolbox is an image processing library.  It is, how can I say it, it's a library using all the other library libraries like Goodall, Osim and it was funded in development.  As a byproduct of the development of a satellite called PlayAD, which is an optical satellite,  which is able to produce submetric images. It was launched in 2010 now.  So since 2006, CNES is developing the software which aims at giving tools, algorithms to help people extract useful information from images.  It's used at CNES, of course, but also now in other agencies like the European Space Agency, which uses OTB as one of the libraries in the ground segment to produce the Sentinel-2 image we saw this morning.  And it's written in C++ on top of the inside toolkit library, which is also an image processing library, but dedicated to medical images.  It's using lots of other libraries, Goodall, Osim, OpenCV, and to give you an overview, we saw this morning that all those raw data is now available with the Landsat, HATES, Sentinel-2.  The goal of OTB is being able for users to go from this raw data to a classification map, combining algorithms, external data, etc.  So the topic of my presentation is to give you an overview of the OTB-OSGO incubation process and to describe how it allows us to change the way we worked and how decisions are taken now in the project.  Explain how the project steering committee is working now that we have set up one year ago, and to sketch the possibilities offered by these more open governs.  So the OSGO incubation, OTB is not a really famous project in OSGO because it's quite specific in terms of data we are working on.  It's a library, you need to combine algorithms, it's also quite specific as the guy from the Open Commission said this morning, the users are public scientists or public administrations, so it's quite far now niche, I would say.  But we've got users and we applied for the OSGO incubation in 2011, we start again in fact the incubation process in 2013, we find a mentor, I want to thank him, London Lake, and we start to complete the checklist.  It's a long process, which is sometimes too long discussions, but as you will see it's a hello us to really improve the way we structure the project.  So here's the checklist, OTB has always been an open source project since the beginning of 2006.  Everything was public, there was a mailing list, etc. etc. So the first point was the infrastructure transitions, the source access was okay since the initial of the project.  The way that the community was functioning, it was not existing, it was mostly managed by people like Ness.  Ness was funding the library and there were people like Ness like me, which were driving the library and the decisions and I will focus on this point, but now we've got this PSC.  And we are now at the last point of the OSGO incubation checklist, which concerns the code copyright review, but you will see that OTB also since the beginning follow, I wouldn't say, good habits regarding the way we are.  Keeping track of copyrights, we are keeping headers on our files, etc. etc.  We don't have for now a Committer Responsibilities Guidelines, such things, it's something which is in progress, I will come back to this.  And after this we will be good, I think, to become a member, I hope of OSGO.  So how was the decision making process before we create the PSC?  As I said, it was the benevolent dictatorship dynasty who made future requests.  Everything was decided, in fact, at the French Space Agency, Ness.  Everything was open, of course, everything was open source, but the future requests were made by persons involved in Ophio projects, so colleagues at Ness, or users we are working with in France.  It was people inside the Ness, and also users from the main Ness, of course, but who decides at the end, at the beginning, it was the Ness team.  With the support also of a company, CS Communication and System, which is a developer, a contractor of the Ness, which is developing OTB since the beginning, and also developing activities around OTB.  And who actually racked the code, it was CS developers, but also people at Ness, which are involved also in the development and are not only making contracts to make the development.  So why we decided to change?  It was not only because of the OSGO occupation, it was really a matter of transparency, because users were, of course, are often informed afterwards of major changes.  We tried to get people involved, but there was no some kind of rules to follow to add new features, big or small features in OTB.  There was no insight or motivations of what we are doing this or that.  It was, of course, difficult to participate in decision making because there was not really process.  And OTB become a big project, so with lots of algorithms, lots of applications, and there are lots of ways to contribute to the project.  And it was, there was more and more people who want to get involved, but it was more and more complicated to follow what's going on in the projects.  So we want to do his contributions at that time.  There was no procedure. We've got external contributors at that time, but we don't have really a process to get this contribution.  And of course, there was also, as we discussed in other presentation, a question of sustainability, because CNES is funding most part of the development of OTB.  But what if one day CNES stops funding it?  And we wanted to get new actors more involved in the project.  So it's like two years ago.  So we create this PSC.  This project steering committee is mostly, we take the experience of existing PSC.  We've got in quantum GIS in Goodall and other OSGO project.  And we didn't reinvent the wheel. It's the same with the code. We don't want to do this.  And we didn't do this also for the project steering committee.  So we have now this structure.  And what is cool now is that more one year and a half at the beginning, there was only people from CNES in this PSC because we bootstrapped the steering committee.  But people outside CNES from CSB, which is a laboratory scientist, which is doing research using OTB.  He's now a member of the PSC.  There are some people from IHRSTA, which is a public administration, and also people from CS, which is the contractor, which is making development of OTB and CNES and for other companies.  So how this PSC is working, the PSC is the workflow is highly coupled with the way we are now doing and making decisions and adding new features in the library.  OK, people in this PSC are developers or people who know where the library and follow the process on how we can have the new features in the library.  So they are deciding the workflow, the testing procedure, how we will package, which, when we are going to do the release, etc.  We took also the experience of Goudal, I think, is using this kind of request for changes procedure.  When you first describe, it's called a request for comments to start, so you've got an ID.  You go to the OTB Wiki and you don't have code yet, but you've got an ID, you describe it and you can have some comments and start a discussion about a new feature you want to add to OTB on the main list.  Then happen the development.  OK, and you will propose a request for changes for OTB, so it's another description with another template and we start a procedure, a process of review of these features, a public review and a vote.  OK, and then it's merged in the library.  And we've got also now the fact that we've got a release manager, which is managing the way that we are introducing new features in the library and when we need to do this.  And it requires the approval of one person, which is nominate for every release.  So that is a short reminder of what is the process now of our decisions and how development are done now in OTB.  So of course it has been some impact on the way we were developing new features.  So we moved to Git.  We were using Mercurial since the beginning of OTB, a subversion at the initial start of the project, then Mercurial.  And we moved to a Git workflow to be able to transfer this ID of requests for comments and requests for changes in a notion of branches.  So it's a little bit complicated, but it's working like this in lots of projects.  You start for the developing branch, which will start at the initial of the release.  You are doing some feature branches, those feature branches which correspond to a request for changes.  And it will be approved and then merged.  And then we'll start a new branch to do the official release and etc. etc. etc.  So it does not exist before in OTB.  And the way that we are declaring this new process makes us change the way we are also developing and managing the code in OTB.  So the release manager accepts requests for merges and then corresponds to a PSC which approved this request.  So every release is now planned every three months.  That's something also we changed because before for users they didn't have a clear idea of when will be the next OTB version.  Now it's every three months and they've got a clear idea of what they will find in the new release.  And after one to two weeks we will release one of the releases.  And it's working pretty well. That's also something I want to point out now.  The way that we have set up this description of new features.  So it seems for developers a little bit at the beginning it's a little bit complicated.  You need to go to the wiki describe that you want to do exactly.  You need to follow some procedures and template.  But it really helps us to to constraint and allow users to have a clear idea of what's going on and why we are doing such things.  So we've got request for changes not only for CNES now.  That's also a point I will come back to this.  We've got new contributors.  We follow now this procedure to be able to get some new features merge in the library.  For users so every significance as I said ongoing or past changes is not public and visible.  Users have the opportunity to comment pending request for changes.  So everything is it was always public but also those discussions happened on the OTB mailing list.  What I want to say also is that users can also file new requests, comment them and for them releases are more frequent.  And it's a really a good thing for them.  For contributors so there is a clear and detailed process as I said how to get the code in OTB.  Contributors are guaranteed to be treated with equity.  I think it was the case before but now it's stated we've got some rules were following those rules and everybody knows about them.  And they know the deadline when they want to get a feature inside OTB.  For developers of course following the procedure there are some pro and cons but there are no more silent code of hundreds of modifications of files that could happen in OTB.  It's not possible anymore. It's impossible to do this now.  Of course there are some adjustments needed. We accept comments from review.  We're getting the code merge. It takes more time of course to be able to develop a feature.  For small features you can ask do we really need to make a request for changes and follow this procedure which is quite light.  But for really tiny modifications it's a little bit complicated.  And I will go a little bit faster. So pros on the overall I think that we would that that's really good.  What we have done here where we have more code reviews we have more contributors.  The changes we made are more consistent because we are making one feature then everything goes to one branch and is  described. Everyone can get some give his opinion even people which are not on the PSC.  OK. And new features are more visible I think.  OK. The project steering committee for OTB is still small. OK.  There was initially lots of people of CNES which was not a good thing.  We want to get people involved but it's working. We've got now more and more people from from other organizations in it.  Of course it does not. It does not solve the point we were discussing before about funding.  OK. It does not make possible if the funding is still mostly are mostly still coming from CNES.  But we hope that making this organization will will make it possible to to get new organization.  Make some funding and do request on their own without without having to to to get some help from from the CNES.  OK. We are we can improve the way we are reviewing code is not so important.  I will skip this and we still have technical problems with with those procedure.  It does not solve bugs and etc. I will skip this voting part and this also.  We are doing PSC meetings. OK. Also through IRC after after each release.  And we are also publishing the log in the minutes of the of those meetings.  And and it's the place where really important questions are discussed.  It's still a young organization. It's of course a tool that we can adapt.  And and also the process can be can be can be discussed and can be changed.  So I will go to the code review. But I don't think I've got a lot of time.  But the last point of the OSU incubation process for OTB concern the the code review.  Also for OTB the the way what we we've got contributions and we were using external libraries  was done I think it's a pretty good way and right way since the beginning.  All the dependencies are licensed in Apache or MIT's license.  The the contributions are licensed in the CC license. It's a French translation of the GPL license.  OK. It's compatible with GPL and also license which is I don't know.  I would say this the open to the open the OZ organization.  I've put a stamp of this license saying that it's open and open source license.  We don't have yet what's called a contributor agreement.  But we want to do this. We have I think a good good management of the  copyrights etc. Also with the help of the packages like Debian as OTB is now  official package of the Debian GIS repository.  It helps us a lot to correct small and make some improvements on this part.  And we've got also in the frame of this code provenance review a discussion  initiated at the CNES to move also the OTB license which is a GPL like license to an Apache license.  That's something which is ongoing and that's why we didn't finish the OSU incubation for now.  I would like to finish and to decide on the OTB side if we move to an Apache before completing  the incubation because it would be a big change. So I will skip the this code review.  So in the frame of the Azure incubation and also in the frame of this discussion to move  for to GPL to Apache we have done a code review of OTB which is now completed.  And we have started the process to contact the contributors of OTB to make them sign and  give and get them get their agreement to change the license.  And I've got considerations about changing and relicensing the project and  it's not an easy part. It's a big decision and I think we will be able to complete this  this year. And that's my conclusion. Thank you.  So we've got time for questions.  You have one minute to finish your last slide. Yes I can finish. So what I said okay I want what I  want to say is that I'm not sure that being an official project for OTB and an official  Azure software will change a lot of things especially for CNES. But I think that the process  and the incubation even if it's a long process, long discussion really help us to make  the project more open and the community more involved. Even if the project was open since  the beginning everything was open the mailing list etc. And I think we were doing this in a  pretty good way. The setting this PSC and following all those rules that have been set up in another  project and try to adapt to the context of OTB really help us to make a more open project.  That's it and I hope to be able to to complete the change of license and  then being able to be an Azure software hopefully this year.  You can ask me questions.  We've got different type of users for OTB. You've got users on okay agencies which are on the ground  segment using libraries as one of the components of a big project for them. I'm not sure they will  see the difference. I hope it will help them to take the time to make contributions, more  contributions to the library. At the complete opposite we've got end user, okay, thematic user,  scientists which use graphical interface based on OTB and also they saw new features.  But for them there are still the websites, the mailing list. I don't think they follow all those  discussions but I don't think it's changed. But in the middle you've got contributors,  scientists also but doing image processing or organization like IRSTA which are not  a member of the PSC which are using OTB as one of their components which is spreading their  organization. So it's one of the key components for them. I think it has changed the way and  it's helped them to say okay we can be more involved in this project. We can participate to the  discussion and perhaps it has changed perhaps the decision choosing between one tool to another  one to make some developments. I hope it helps them to make the decision to take OTB. So for  public administration, some administration in France, I see the difference. So to for instance  remove proprietary software and move parts of their process with OTB. It was the same timing as I  said as we changed the policy on the on the governance. Yes.  Okay I didn't get it. It's a good question. First the license was chosen in 2006.  The CNES was not really used to do open source at that time. So they choose GPL  considering I don't know really. It's perhaps also with the ID perhaps to do  dual licensing. We have discussed this I think in the first presentation. So they are different  way to to make to valorize your open source project. CNES does not want to to sell software.  It does not matter for them but they want to to create an ecosystem where other companies  in France or in other country use some satellite images but also some software and develop some  business or activities around OTB. There are some companies which use OTB and develop activities  at the Upran Space Agency for instance but they they have since the beginning said that  a less permissive license less Apache will allow them to to to do some proprietary software of  course with OTB and it will facilitate in their perspective the development of of activities  and business with OTB. So it's more a consideration of how CNES can help companies in the in around  them around CNES to develop activities with OTB. I don't think that it will change also a lot  things for CNES for lots of users. They don't really care about the license for most of them.  Thank you.
foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_0_239.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_240_299.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_300_347.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_348_5903.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_5904_9491.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_9492_9695.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_9696_16871.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_16872_19559.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_19560_20951.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_20952_26159.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_26160_29735.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_29736_30467.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_30468_30791.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_30792_32939.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_32940_33143.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_33144_33515.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_33516_33743.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_33744_34103.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_34104_34163.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_34164_34295.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_34296_34895.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_34896_35075.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_35076_35159.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_35160_35759.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_35760_36503.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_36504_36695.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_36696_36971.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_36972_37019.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_37020_37079.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_37080_37127.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_37128_37235.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_37236_37523.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_37524_37571.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_37572_37811.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_37812_37859.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_37860_38471.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_38472_38555.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_38556_39383.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_39384_39431.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_39432_39479.png foss4g-2016-1043-one_year_of_open_governance_for_otb_thoughts_and_context-hd_39480_39613.png
It's also not another technical presentation. So I'm working to lose at the French Space Agency. I'm working mostly on the development of an open source library called Orpheo Toolbox. And the goal of my presentation is not to present a TB. I've got only one slide. I've got a presentation Friday morning about the TB. But about the status of the incubation process for OTB in OSU. And Orpheo allows us to make some improvements in the way that the governance and the project is working globally. So Orpheo Toolbox is an image processing library. It is, how can I say it, it's a library using all the other library libraries like Goodall, Osim and it was funded in development. As a byproduct of the development of a satellite called PlayAD, which is an optical satellite, which is able to produce submetric images. It was launched in 2010 now. So since 2006, CNES is developing the software which aims at giving tools, algorithms to help people extract useful information from images. It's used at CNES, of course, but also now in other agencies like the European Space Agency, which uses OTB as one of the libraries in the ground segment to produce the Sentinel-2 image we saw this morning. And it's written in C++ on top of the inside toolkit library, which is also an image processing library, but dedicated to medical images. It's using lots of other libraries, Goodall, Osim, OpenCV, and to give you an overview, we saw this morning that all those raw data is now available with the Landsat, HATES, Sentinel-2. The goal of OTB is being able for users to go from this raw data to a classification map, combining algorithms, external data, etc. So the topic of my presentation is to give you an overview of the OTB-OSGO incubation process and to describe how it allows us to change the way we worked and how decisions are taken now in the project. Explain how the project steering committee is working now that we have set up one year ago, and to sketch the possibilities offered by these more open governs. So the OSGO incubation, OTB is not a really famous project in OSGO because it's quite specific in terms of data we are working on. It's a library, you need to combine algorithms, it's also quite specific as the guy from the Open Commission said this morning, the users are public scientists or public administrations, so it's quite far now niche, I would say. But we've got users and we applied for the OSGO incubation in 2011, we start again in fact the incubation process in 2013, we find a mentor, I want to thank him, London Lake, and we start to complete the checklist. It's a long process, which is sometimes too long discussions, but as you will see it's a hello us to really improve the way we structure the project. So here's the checklist, OTB has always been an open source project since the beginning of 2006. Everything was public, there was a mailing list, etc. etc. So the first point was the infrastructure transitions, the source access was okay since the initial of the project. The way that the community was functioning, it was not existing, it was mostly managed by people like Ness. Ness was funding the library and there were people like Ness like me, which were driving the library and the decisions and I will focus on this point, but now we've got this PSC. And we are now at the last point of the OSGO incubation checklist, which concerns the code copyright review, but you will see that OTB also since the beginning follow, I wouldn't say, good habits regarding the way we are. Keeping track of copyrights, we are keeping headers on our files, etc. etc. We don't have for now a Committer Responsibilities Guidelines, such things, it's something which is in progress, I will come back to this. And after this we will be good, I think, to become a member, I hope of OSGO. So how was the decision making process before we create the PSC? As I said, it was the benevolent dictatorship dynasty who made future requests. Everything was decided, in fact, at the French Space Agency, Ness. Everything was open, of course, everything was open source, but the future requests were made by persons involved in Ophio projects, so colleagues at Ness, or users we are working with in France. It was people inside the Ness, and also users from the main Ness, of course, but who decides at the end, at the beginning, it was the Ness team. With the support also of a company, CS Communication and System, which is a developer, a contractor of the Ness, which is developing OTB since the beginning, and also developing activities around OTB. And who actually racked the code, it was CS developers, but also people at Ness, which are involved also in the development and are not only making contracts to make the development. So why we decided to change? It was not only because of the OSGO occupation, it was really a matter of transparency, because users were, of course, are often informed afterwards of major changes. We tried to get people involved, but there was no some kind of rules to follow to add new features, big or small features in OTB. There was no insight or motivations of what we are doing this or that. It was, of course, difficult to participate in decision making because there was not really process. And OTB become a big project, so with lots of algorithms, lots of applications, and there are lots of ways to contribute to the project. And it was, there was more and more people who want to get involved, but it was more and more complicated to follow what's going on in the projects. So we want to do his contributions at that time. There was no procedure. We've got external contributors at that time, but we don't have really a process to get this contribution. And of course, there was also, as we discussed in other presentation, a question of sustainability, because CNES is funding most part of the development of OTB. But what if one day CNES stops funding it? And we wanted to get new actors more involved in the project. So it's like two years ago. So we create this PSC. This project steering committee is mostly, we take the experience of existing PSC. We've got in quantum GIS in Goodall and other OSGO project. And we didn't reinvent the wheel. It's the same with the code. We don't want to do this. And we didn't do this also for the project steering committee. So we have now this structure. And what is cool now is that more one year and a half at the beginning, there was only people from CNES in this PSC because we bootstrapped the steering committee. But people outside CNES from CSB, which is a laboratory scientist, which is doing research using OTB. He's now a member of the PSC. There are some people from IHRSTA, which is a public administration, and also people from CS, which is the contractor, which is making development of OTB and CNES and for other companies. So how this PSC is working, the PSC is the workflow is highly coupled with the way we are now doing and making decisions and adding new features in the library. OK, people in this PSC are developers or people who know where the library and follow the process on how we can have the new features in the library. So they are deciding the workflow, the testing procedure, how we will package, which, when we are going to do the release, etc. We took also the experience of Goudal, I think, is using this kind of request for changes procedure. When you first describe, it's called a request for comments to start, so you've got an ID. You go to the OTB Wiki and you don't have code yet, but you've got an ID, you describe it and you can have some comments and start a discussion about a new feature you want to add to OTB on the main list. Then happen the development. OK, and you will propose a request for changes for OTB, so it's another description with another template and we start a procedure, a process of review of these features, a public review and a vote. OK, and then it's merged in the library. And we've got also now the fact that we've got a release manager, which is managing the way that we are introducing new features in the library and when we need to do this. And it requires the approval of one person, which is nominate for every release. So that is a short reminder of what is the process now of our decisions and how development are done now in OTB. So of course it has been some impact on the way we were developing new features. So we moved to Git. We were using Mercurial since the beginning of OTB, a subversion at the initial start of the project, then Mercurial. And we moved to a Git workflow to be able to transfer this ID of requests for comments and requests for changes in a notion of branches. So it's a little bit complicated, but it's working like this in lots of projects. You start for the developing branch, which will start at the initial of the release. You are doing some feature branches, those feature branches which correspond to a request for changes. And it will be approved and then merged. And then we'll start a new branch to do the official release and etc. etc. etc. So it does not exist before in OTB. And the way that we are declaring this new process makes us change the way we are also developing and managing the code in OTB. So the release manager accepts requests for merges and then corresponds to a PSC which approved this request. So every release is now planned every three months. That's something also we changed because before for users they didn't have a clear idea of when will be the next OTB version. Now it's every three months and they've got a clear idea of what they will find in the new release. And after one to two weeks we will release one of the releases. And it's working pretty well. That's also something I want to point out now. The way that we have set up this description of new features. So it seems for developers a little bit at the beginning it's a little bit complicated. You need to go to the wiki describe that you want to do exactly. You need to follow some procedures and template. But it really helps us to to constraint and allow users to have a clear idea of what's going on and why we are doing such things. So we've got request for changes not only for CNES now. That's also a point I will come back to this. We've got new contributors. We follow now this procedure to be able to get some new features merge in the library. For users so every significance as I said ongoing or past changes is not public and visible. Users have the opportunity to comment pending request for changes. So everything is it was always public but also those discussions happened on the OTB mailing list. What I want to say also is that users can also file new requests, comment them and for them releases are more frequent. And it's a really a good thing for them. For contributors so there is a clear and detailed process as I said how to get the code in OTB. Contributors are guaranteed to be treated with equity. I think it was the case before but now it's stated we've got some rules were following those rules and everybody knows about them. And they know the deadline when they want to get a feature inside OTB. For developers of course following the procedure there are some pro and cons but there are no more silent code of hundreds of modifications of files that could happen in OTB. It's not possible anymore. It's impossible to do this now. Of course there are some adjustments needed. We accept comments from review. We're getting the code merge. It takes more time of course to be able to develop a feature. For small features you can ask do we really need to make a request for changes and follow this procedure which is quite light. But for really tiny modifications it's a little bit complicated. And I will go a little bit faster. So pros on the overall I think that we would that that's really good. What we have done here where we have more code reviews we have more contributors. The changes we made are more consistent because we are making one feature then everything goes to one branch and is described. Everyone can get some give his opinion even people which are not on the PSC. OK. And new features are more visible I think. OK. The project steering committee for OTB is still small. OK. There was initially lots of people of CNES which was not a good thing. We want to get people involved but it's working. We've got now more and more people from from other organizations in it. Of course it does not. It does not solve the point we were discussing before about funding. OK. It does not make possible if the funding is still mostly are mostly still coming from CNES. But we hope that making this organization will will make it possible to to get new organization. Make some funding and do request on their own without without having to to to get some help from from the CNES. OK. We are we can improve the way we are reviewing code is not so important. I will skip this and we still have technical problems with with those procedure. It does not solve bugs and etc. I will skip this voting part and this also. We are doing PSC meetings. OK. Also through IRC after after each release. And we are also publishing the log in the minutes of the of those meetings. And and it's the place where really important questions are discussed. It's still a young organization. It's of course a tool that we can adapt. And and also the process can be can be can be discussed and can be changed. So I will go to the code review. But I don't think I've got a lot of time. But the last point of the OSU incubation process for OTB concern the the code review. Also for OTB the the way what we we've got contributions and we were using external libraries was done I think it's a pretty good way and right way since the beginning. All the dependencies are licensed in Apache or MIT's license. The the contributions are licensed in the CC license. It's a French translation of the GPL license. OK. It's compatible with GPL and also license which is I don't know. I would say this the open to the open the OZ organization. I've put a stamp of this license saying that it's open and open source license. We don't have yet what's called a contributor agreement. But we want to do this. We have I think a good good management of the copyrights etc. Also with the help of the packages like Debian as OTB is now official package of the Debian GIS repository. It helps us a lot to correct small and make some improvements on this part. And we've got also in the frame of this code provenance review a discussion initiated at the CNES to move also the OTB license which is a GPL like license to an Apache license. That's something which is ongoing and that's why we didn't finish the OSU incubation for now. I would like to finish and to decide on the OTB side if we move to an Apache before completing the incubation because it would be a big change. So I will skip the this code review. So in the frame of the Azure incubation and also in the frame of this discussion to move for to GPL to Apache we have done a code review of OTB which is now completed. And we have started the process to contact the contributors of OTB to make them sign and give and get them get their agreement to change the license. And I've got considerations about changing and relicensing the project and it's not an easy part. It's a big decision and I think we will be able to complete this this year. And that's my conclusion. Thank you. So we've got time for questions. You have one minute to finish your last slide. Yes I can finish. So what I said okay I want what I want to say is that I'm not sure that being an official project for OTB and an official Azure software will change a lot of things especially for CNES. But I think that the process and the incubation even if it's a long process, long discussion really help us to make the project more open and the community more involved. Even if the project was open since the beginning everything was open the mailing list etc. And I think we were doing this in a pretty good way. The setting this PSC and following all those rules that have been set up in another project and try to adapt to the context of OTB really help us to make a more open project. That's it and I hope to be able to to complete the change of license and then being able to be an Azure software hopefully this year. You can ask me questions. We've got different type of users for OTB. You've got users on okay agencies which are on the ground segment using libraries as one of the components of a big project for them. I'm not sure they will see the difference. I hope it will help them to take the time to make contributions, more contributions to the library. At the complete opposite we've got end user, okay, thematic user, scientists which use graphical interface based on OTB and also they saw new features. But for them there are still the websites, the mailing list. I don't think they follow all those discussions but I don't think it's changed. But in the middle you've got contributors, scientists also but doing image processing or organization like IRSTA which are not a member of the PSC which are using OTB as one of their components which is spreading their organization. So it's one of the key components for them. I think it has changed the way and it's helped them to say okay we can be more involved in this project. We can participate to the discussion and perhaps it has changed perhaps the decision choosing between one tool to another one to make some developments. I hope it helps them to make the decision to take OTB. So for public administration, some administration in France, I see the difference. So to for instance remove proprietary software and move parts of their process with OTB. It was the same timing as I said as we changed the policy on the on the governance. Yes. Okay I didn't get it. It's a good question. First the license was chosen in 2006. The CNES was not really used to do open source at that time. So they choose GPL considering I don't know really. It's perhaps also with the ID perhaps to do dual licensing. We have discussed this I think in the first presentation. So they are different way to to make to valorize your open source project. CNES does not want to to sell software. It does not matter for them but they want to to create an ecosystem where other companies in France or in other country use some satellite images but also some software and develop some business or activities around OTB. There are some companies which use OTB and develop activities at the Upran Space Agency for instance but they they have since the beginning said that a less permissive license less Apache will allow them to to to do some proprietary software of course with OTB and it will facilitate in their perspective the development of of activities and business with OTB. So it's more a consideration of how CNES can help companies in the in around them around CNES to develop activities with OTB. I don't think that it will change also a lot things for CNES for lots of users. They don't really care about the license for most of them. Thank you.
of the incubation process for OTB in OSU. And way that the governance and the project is decisions are taken now in the project. Explain that we have set up one year ago, and to sketch managed by people like Ness. Ness was funding the will come back to this. And after this we will be OSGO. So how was the decision making process or that. It was, of course, difficult to other presentation, a question of sustainability, to add to OTB on the main list. Then happen the making this organization will will make it open and open source license. We don't have yet and also in the frame of this discussion to move contributions, more contributions to the library. in this project. We can participate to the