This session will show how the OAAF, the Open Agile Architecture Framework can help architect the change journey of enterprise transformation and will throw some light on the next OAAF development iteration. So a warm welcome please for our three speakers. Thank you. Ron just talked about autonomous things and robots. During this session today, we'll talk about autonomous human beings and teams. So it will be complementary because we think that human beings and teams are also central to digital and social summation. Since the OAAF snapshot was published last July, we have collected feedbacks, identified improvement opportunities and gauged in conversation with actual forum officers. And since the OAAF contents a lot of new material, some of it being a real binding shift compared to traditional action method, we acknowledge the need to have meaningful conversation with the enterprise architect community. And we thank the executive and the staff of the Open Group to give us the opportunity to share our view on the next iteration of the OAAF. The Open Group is not alone in that broad agility market and especially an event occur on October the 2nd. So very recently, SAF, the Scale Agile Incorporated Organization, announced the new version of SAF.5.0. Though this version has not been published yet, the preview start by acknowledging that agile product delivery is not enough. You need business agility and here I am quoting the SAF preview. Since the beginning, the OAAF took enterprise agility and business agility as one of its core, let's say objective and scope. So from this standpoint, we think that there is convergence on the market. And since also SAF is starting to talk about business agility, which is quite new, we think that we will start this morning presentation also talking about business agility and sharing some thoughts with you about business agility. The second major change that SAF did was to add customer focus or centricity to their big picture. You know the SAF big picture with a lot of things, not very readable, but now you've got customer centricity at the middle of it. VF snapshot has also put customer at the center, but we talk about customer experience. And we think that it's another indication of the convergence of direction here. I will not continue to do that comparison point to point, but just say that though the SAF moves into a direction that is very aligned with the AF, it's still weak on the actual side. And we believe that it's really the sweet spot of AF to actually provide the architecture knowledge, know-how and methods to enterprise that move toward agility at scale. We will start the presentation by talking about the case study, because we realize that in order to present this new concept, you need to illustrate them with concrete examples so that case study will be in the banking domain. And we will present first how that bank operates before the agile transformation, and we will show how the bank is transforming toward business agility and agile operating models. So let's go to slide two. Yes. So the siloed organization that we present here is very similar to many of the banks' organizations with variations that we can't find. That organization does not facilitate outside in thinking, because it's really siloed oriented, and it does not also facilitate cross-functional collaboration. Therefore, the bank is slow to collect weak signals, give meaning to them, and respond rapidly to those weak signals. And the bank, when it has to change, changes through waterfall programs that focus on the run side of the bank, and those programs take a lot of time to deliver. On slide three, it's a simplified view of an information system that many banks share in terms of variation of it. In those types of systems, one change in one application impacts many more applications. It creates many dependencies, and the result is that it takes a lot of time to implement new products, new requirements, because of those dependencies. And the monolithic nature of those types of systems end up costing a lot and slow innovation a lot. So in contrast, we will define business agility, and for us, and we were inspired by a book published recently, which title is See Sooner, Faster from the MIT Press, where business agility is the ability for the enterprise, for that bank, to see sooner, so to sense what's going on in the market, what do the competitors, what client wants, and act faster. And in the example that we presented before the agile transformation, the headquarter identifies potential threats and opportunities, and it takes a lot of time to go through the other silos, because in general it's marketing that sense and to result into giving meaning to those signals, and it takes a lot of time to actually respond to those signals. In contrast, we think that agile teams that are teams of teams sometimes which are closer to the field can see earlier than others, and because they are autonomous, they can respond more rapidly. And we'll see in more detail how that agile transformation really improves the speed of sensing and the speed of acting to respond to those changing in the environment. This model requires, as we said, autonomous teams that are cross-functional, and this is what Jean-Pierre is going to present in the next slide. Yes, thank you for that. So as you can see in this slide, the business is now organized to meet the needs of market segments. You have to example the consumer market and the SME market, not this one. Tribes which regroup small teams named squad own a product family, for example consumer credit, or part of customer experience. Tribes and squads are aligned to streams of work that develop and deliver products and customer experience. These agile teams are cross-functionals to reduce friction between the traditional functional silos of the organization. All relevant competencies and skills are represented, included, of course, Haiti. Agile teams have business KPI, such as revenue growth or profitability. These teams have the freedom to make business decisions and are accountable for business results, of course. Cross-functionality is facilitated, at least by the reorganization of working space. Building floors are no longer dedicated to a function, such as marketing or Haiti. Building floors regroup all the people who are working on the same product or customer journey. Both old teams mix business and Haiti competencies. So an agile organization, reshaped teams, reshaped offices, needs collaboration tools and, of course, new ways of working. Agile ceremonies are part of this new ways of working. So an agile organization, localization and composition of teams are different, but what is the main difference is the governance. The way these autonomous teams are governed is quite different. The strategy is deployed through assigning objectives and KPIs to tribes. Tribes have the freedom and resources to be able to decide how they are going to meet their objectives. Business objectives and budgets, including Haiti budgets, are reviewed together every quarter. Unlike managing yearly budget cycles, the agile organization is able to manage quarterly budget cycles. The tribe sponsors assign objectives and target KPIs. Objectives and KPIs are covering both the change the bank and the run the bank. Agile ceremonies are used to decompose objectives, manage backlogs, assign work and allocate resources, both on the change the bank and both on the run the bank. At the end of each quarter, agile teams conduct retrospectives about sales, about projects, but more times are conducted and analyzed to improve ways of working and optimize resources allocations. The biggest shift is to combine business objectives and IT objectives, business KPIs and IT KPIs, for the same tribes and the same teams, and assign them to the tribe leaders. This slide summarizes the current situation that the semi-tribe has to improve and the objective it has been assigned. The three major problems in this example the semi-tribes need to address are improved the competitivity of its suffering and to boost sales, of course, to reduce economic and regulatory capital consumption and to fix legacy system, information system, which gets into the way of a good client experience and costs too much to run and to maintain. So in this organization cross-functional teams are accountable for both business and IT outcomes. An example of this is the objective to reduce the capital consumption. This reduction needs both a business objective, which is improving the loan product and to increase sales and an IT objective, which is to improve calculation engine about the reduction. So Fred Eric now will summarize the lessons learned from this new organization. Thank you Jean-Pierre and just for those who are not in the banking industry, SME stands for Small and Medium Enterprise. So it's a market segment within the banking industry. So now we'll talk about these attention points when the bank has deployed that model. What you are showing is a situation where the bank has only deployed a giant scale that way at the headquarter, excluding the branches and the middle offices. The attention point on the left reflects the shortcoming of these dual models and also that dissociation of design and execution, so to speak. There are some tensions on budget, commercial priorities, and also the interlock with other initiatives is less easy. For instance, leveraging loans to Small and Medium Enterprise to cross-sell cash management services to that same market segment. The key success factor on the right applied to most of the tribe we reviewed. Freedom needs to be balanced by accountability. Teams need to be small and stable. We need to have enough experience, expertise in those teams so that they can be autonomous. I will not quote all the success factor, but just to give you a sense of what good looks like. Greater agility can be achieved by extending the agile organization to the branches and the middle offices. We think that the current state is not yet ideal and though the headquarter is now agile, the field is still organized on a geographical basis. People work for branches and branches are located in various geographies. The bank is considering extending the scope of tribes and branches to branches and middle offices. So it's on the left here, instead of being separate, it would be included in the tribes. That means that in that model, geography is less important. You can have someone who is selling or supporting SMEs. It happens that they are located in one branch, but they no longer really report to the branch manager, but they report to the tribe leader. Antoine will now describe the consequences of that new organization on the operating model. Thank you, Frédéric. In the example that has been achieved in the bank project currently in progress, Jean-Pierre, you said that's not only happening to your environment, but you see this happening in many banks all over the place. It means there are some patterns of architecture which underpin this approach, which basically are the various aspects that we are trying to cover within the AAF. So at every core of it is the notion of this product intentional architecture. It adopts, you know, we have all this term customer experience. This is really adopting this outside view for building the architecture. And it's going to drive the selected business outcome that do matters for the customers and the criteria we're going to use to measure them. And this outside architecture, it shape the way the enterprise is going to be organized. This is a team-based approach. And the way it shape it is that we're going to mirror the product architecture with the notion of streamed aligned team, which is going to take into account from to back the way to deliver those business outcomes in a proper manner. So this mirroring approach is really how the intentional and operational architecture are going to be fit together. The streamed aligned team, because they cover the anti-value stream, by nature they are cross-functional. This is not a layer approach to it. If you want those product architecture, which match the customer experience to be effective, you need these streamed aligned teams. But if you only have those streamed aligned teams, you're going to lose the value of the entire enterprise and the common assets. So you must be organized to nurture the common value of the enterprise, the risk being that the streamed aligned team becomes against silos. And this is done basically in two ways. The first one is to having a notion of competencies and supporting teams. Those competencies teams, they brought the know-how of the enterprise and the various disciplines, including legal, security, and, you know what, the architecture, which is a key asset of the enterprise. It is not something that you're going to delegate at outsource. It is something you're going to nurture so that those streamed aligned teams are able to do their business properly. The other part of it is the platform teams. So if you don't want each team to reinvent the wheel, you need to factorize, you need to mutualize and help the team doing their core business while providing services that are enablers and preferably self-services so that you minimize the dependencies on the thing you rely on. The same thing if you're using the architecture team as a team where you delegate the architecture. In fact, you have dependency on that team. You don't have the knowledge within the tribe. And you wait for architects to be available to do your work. The same way the platform needs to provide services that you can use not being too much dependent on it, but leverage on it. Of course, when you have all this operating model working, you still have independent autonomous teams. And for them to make up an enterprise as a whole, you need some common way to align them towards the common goals. Jean-Pierre already mentioned the way agile governance needs to be set up, which is tribe-based with autonomy with common ways of going in the same direction, with three main items that we'll develop later, which is a common purpose, shared consensus, we'll talk about it, and as a notion of guardrail, a way to control things with overseeing without being too much prescriptive. Of course, with all this, it doesn't make architecture static. So it's going to be a continuous architecture activity that move from that intentional architecture to operation on the grounds, getting the feedbacks. But because you're tribe-oriented or stream-aligned team, the signal from the market, the connection to customer experience is going to be better. So lower signal are going to be heard earlier. The way to react is going to be done easily because you have the shared understanding on how to react and you have the direct connection to the solution you're going to provide with continuous delivery. This means that the role of architecture is key in maintaining those various aspects. So if you have team leaders in charge of both the design of the run and the running itself, architects need to be close to this new leadership. They need to be friends of the team leaders so that this design and running can go smoothly within the organization. So where does it come from, all this? This kind of breakthrough of the way we were doing traditional architecture. And I think most of you are aware of the thing called the Conway's Law, aren't you? Let me study it again. Any organization that designs a system will produce a design whose structure is a copy of the organization communication structure. So there is a very tight connection between the thing, the design, and the architecture of this thing being produced. This is the idea of connecting together the design of the run and the run. And Mark Cormac has demonstrated that loosely coupled organization developed much more modular design than tightly coupled organization. If you have a global team that work together, the tendency is to say, we share. So we don't API's ourselves, I would say, in a kind of brutal manner. So if you want autonomy, you need that kind of communication that will need to formalize the relationship between the teams and between the systems they conduct. So this is why this is what they call a team-first architecture. And to do it, they apply what they call the Reverse Conway Manoeuvre, where instead of thinking of the architecture in isolation, you go in to first shape the enterprise organization in a way that mirror, as we said, the product intention of architecture and the organization of the company. Is it moving? So of course, the key aspect, this is kind of my mantra, I would say, or preferred topic. The trick of architecture is to create boundaries. Life is a continuum. You wake in the morning, you do things, at the end, you've done some work, but what is the aim of it? In processes, you have the notion of operation, action, and you need to put boundaries between processes. The trouble is all those boundaries are somewhat artificial. It's because you need to decompose things. You can't handle the whole world at once. And the more systems become complex, the more you need to decompose. And modularity is here to help us create those autonomous paths that we can manage. So in a way that we minimize dependencies, it is if I change something, I don't want everything to be changed, because I was working at the search life scale that I don't have created those boundaries. Life is like this. Sales create boundaries. Then you have organism, then you have society. So we all work in architecture by doing modules. Now we need some criteria how to do this modularization. And we've seen three of them. I'm going to three more than three of them. The one is the journey, the sub-journey, the business outcomes that we got from the product architecture instead of the beginning. Another criteria, as we've seen, is the value stream, which is going to provide us the scope, the front-to-back scope that make up the boundary of the team. And the third one, which is another topic we have in the agile architecture framework, is a single domain-driven design. The domain of activities, in terms of resource being managed, activities being performed in a manner that you can split them and provide those results with some kind of, again, some kind of interaction API that provides the proper dependence between the module. When you've got that split, of course, you minimize the dependencies, but you can't help having dependencies otherwise, again, you recreate silos. The goal is to manage those dependencies in such a way that they become non-blocking. So what do we mean by non-blocking? We mean that they don't go out of the scope of the team which has the dependencies. So first they need to be identified, then they need to be owned, and then, of course, if you don't have control over them, like you have some resource of some architects you rely on, but they're not available. You don't have the skill of architecture, you have no autonomy, so what do you do? Wait, this is a blocking dependency. So you must organize the dependencies so that they are non-blocking, and one clear way to do it is to provide self-servicing. I can't provision the resource myself. I know it, I've been taught how to do it. It's provided by another team, but I can't exercise it myself. So as we've seen, now we need the alignment part. You know how to run, you know how to decompose, you know how to manage dependencies. How can we do to become together? So Jean-Pierre mentioned some mechanism to do the agile governance, and I want to note three other items here. The first one is a shared purpose. Of course, you need a shared vision. You know where to go. This notion of purpose, the reason that of your organization, the reason that of the system, is what makes you happy and what makes you understand what you're doing. Of course, to do this, you need some kind of awareness. If the understanding of where you want to go is only split by team, there's no way you're going to come together. So as General Mac Stanley said, this global awareness is having a global, the holistic viewpoint of your organization. It's not something you need to hide. You're not going to hide information for power. You're going to share it for the global understanding. It doesn't mean you need to be a generous team. You need to know everything. You need to know where you go together. This is a mantra, think globally, act locally. And the last thing you need to have is that kind of how you make things happen in a kind of rigorous manner that you go all together in the same direction. Do you do control, procedure, going in each room and checking that the work is done? That's a traditional command and control. You provide those notions of guardrail, force function, which provide you guidance, which empower people by providing rules, guidance. You know that well, architecture principles, this is beyond architecture principles. All the things that rule the way you're going to go together. So now that we've summarized the various pieces of architecture landscape, Frederic is going to tell us how it applies to the IT departments. Do we still have IT departments? Just because Antoine talked about platform in one of the previous slides, I'd just like to share with the group that Christophe Klein from BNPP and myself will do a presentation tomorrow afternoon that will focus on that aspect, platform and especially renewable digital platforms. But coming back to, which is part of information technology, coming back to information technology, you remember we said tribes own variety. Does it mean that the central IT department disappears? No. It's only the capability that are critical to the success of the tribes that move under the control of the tribes. There is still room for a central IT organization for, for instance, operating the infrastructure for also legal and investor obligations and also shared capabilities. The other aspect will be that refactoring, that modernization that Antoine presented as so important. So we'll move now quickly. I just want to introduce an approach that actually you can read in the EF snapshot around how to handle the legacy system. But the idea is that in the head of SOA people believe that just creating APIs on top of legacy monotech system was going to make the system agile. And actually that's all true because those APIs do not shield from knowing the internals, which means that you've got abstraction leak meaning that the consumer of the API need to understand too much of the implementation behind the API which creates further coupling. So that's why SOA actually resulted in higher coupling as before, though it was not the OCEAN intention. So what is important is the number three is to start modularizing the system. So you start to do it at cost-grain level. You create a separate sub-system. You connect them through APIs or events. And then you can start implementing yet finer-grained services called microservices that will redevelop the functionality of a sub-system. And that's number four in a way that will be much more moderate in agility. And at the end of the day when you've done that for a sub-system you can decommission that part of the sub-system and that's called the stronger pattern and at the end of the day you get rid of the old system described in the AF snapshot. Second thing, in terms of changing the way you look at the world instead of looking at architecture as layered business information system technology, you take the business domain and you start modularizing the system based on the business domain. I will not go for the sake of time in more detail in presenting the concept that helped do that. It's the strategic pattern of domain-driven design. For those who are interested you can find that material in the AF snapshot. Let's say that the ideas that you directly implement your business ideas in your software systems. So there is a much direct connection between business to speak and software. So as we've seen during all the presentation all that requires a lot of change and succeeding that change is really a profession Yes, thank you for effectively transforming an organization, a neutral organization is a change management stake. So it's not big bang, it's in three stages. Successful seeders follow three stages. The first stage is to build a strong coalition assembling an executive team and this team must collaborate effectively. It's not a question of a sponsor, it's a matter of a coalition of sponsors and this sponsor must create a real team. This coalition needs to have a non-preneurship mindset and to have some architecture skills of course you see to design the rights, the rights drives with the right ITM. The second stage is this coalition has to identify and to mobilize the right middle management pioneers. These pioneers will be the first tribe leaders about the most important business goals and the most important IT pain points. The third stage is to create, to shape squad agile teams and to provide support when needed by these teams. In this organization agile teams are free to engage honest conversation with executive sponsor with the coalition and can share with them issues and particularly innovation ideas. So agile transformation truly requires a change in management style moving to from command and control to a servant leadership with architecture skills. It's the beginning of the conclusion. In terms of conclusion we created that slide with free key messages and we think that those messages you can read them understand them easily because it really summarizes the idea that we have developed but please take a few minutes reading them to think about the questions that you'd like to ask so we can move directly to the question part because I see the time is running fast and thank you very much for listening to us. Thank you gentlemen. Let's we've had some questions coming in but it's not too late. You're going to need you're going to need this I'll go over here probably the best way probably the best way of doing this so anyway we do have some questions come in do you see the role of solution architects becoming more engineering focused working closely with DevOps delivering within the boundaries provided by enterprise architects so will solution architects become more engineering focused? I think one of the difficulties transitioning toward that new way of architecting is that the same words may have different meanings. When I hear solution architect I hear an architect that creates a sort of IT solution that embeds processes and business but mostly an IT solution during our all presentation we didn't talk about IT solutions we talked about architecting the agile enterprise so I'm not sure what the solution architect will do in the future but I think we have clarity about what architect needs to do to really help the enterprise become agile and digital but solution engineering as a cross architecture is absolutely key for those teams to be from to end they really need to have solution engineering and architects are the vector of it so of course they need to know the technologies they do said base engineering they know concurrent engineering that kind of skill is absolutely key for architecture to be a powerful discipline here. Thank you, we'll move to the next question probably one mostly for Jean Pierre what is the time scale that you had or expect on your journey and where are you at this point? It begins two years ago it's from my experience in a very long way what is important is in two years to to onboard the most important business tribe about the most important objectives and most pain points IT states and I think that between four or five years you will be able to transform a traditional bank legacy system to a new one and to a new organization Thank you Do you have something to add, Frédéric? or next question Just to say that what Jean Pierre is presenting when we look at other banks that are doing the same thing we are about the same type of time frames Thank you Is the fully agile operating model the death of intentional architecture emerging architecture seems to be becoming more and more common I would not say that remember the diagram that Antoine presented the first input was that intentional architecture because if you don't have an intentional architecture there is no way you can define the boundaries of your agile teams especially the teams of teams that are the tribes but that intentional architecture is there to be challenge and is evolving so it evolves through those iterations to an imagined architecture but both are necessary I could add, I wish I missed the fact that those teams they also start from small teams like the squad and they can move to teams of teams which is provided by the open group they explain how this emergence happening when you move from squad to team of teams and the relationship between the intentional and emergent architecture and you move from team where you hold everything to distributed teams and the emergence is going to roll out in different manner so yes look at the DP book for that also Thank you Antoine, you beat me to it I was going to say that it took my line, thank you How do you manage the life cycle management of the platform or architecture across the various silos and how does this work for a domain driven, model driven approach Actually, we will cover tomorrow afternoon with Christophe Claire from BNPP that topic but let's say that the key is to create non-blocking relationship between the platform teams being infrastructure platform and the consumer of those platforms and one example of non-blocking is the development of self-service If you provide self-service to development teams they don't have to wait anymore for the infrastructure and upstream to get the resources they need to deliver the product and therefore you've got a loose coupling between the platform team and the consumer of those platforms and DDD can be applied both on the business domain to create loosely coupled applications but it can be also applied to the infrastructure domains to architect the platforms themselves in a modular manner The key difference is that for the platform the domain concept will be more technology concepts as in the application it will be business concepts We're running out of time but I'll try this one quickly Is there a danger that decentralized tribal IT gets too big or it doesn't have enough competence due to its size We had a seminar also in France about what was not working in Agile and it was exactly the problem that was faced the lack of common assets managed by architects and nurtured by architects which led to poor efficiency finally So of course if you dust all the tribes in isolation they will become silo again and of course an organization is beyond those streamlined teams all the culture and you must have it running so you must allocate part of your budget to nurture those common culture for sure and this is why we mention about safe and so on they have a lot of things about it but a good understanding on how to nurture this is a key role of us architects and safe if you look at it and maybe they will fix fact in the new version 5.0 but they don't talk about the platform they don't explain how to articulate platform teams versus streamlined teams So that's just an example of the actual weaknesses of safe and that's exactly where we think that there is a sweet spot for the year Gentlemen in the interest of letting people go to the break we'll leave it there but thank you Jean-Pierre Le Cam, Antoine Longin and Frédéric Lee Thank you very much, gents


Hi everyone, my name is Victor Stiner and I'm going to present you Python 3 10 years later. So I'm a C Python core developer for eight years, but I'm contributing to Python for 10 years. Currently I'm working on C Python on OpenStack for Red Hat, but I moved to a new team recently, so today I do maintain Python for Red Hat, and I'm a very happy user of Fedora on them. I decided to organize my talk in four parts, the four seasons, so let's start with Outone. So the start of Python 3 was a project called Python 3000, and everything started with a PEP written in 2006, the Python 3000, and the thing is that at this time more and more people started to complain about things called Python warts, which are design issue of Python 2, and some people started to write a list of all the warts, so the plan was to fix all of them, or most of them. To give you some example, in Python 2 you have two different types for integers, you have the long integer and small integer, and depending on the operation, depending on the input type, you may get a small or large or long integer, so if you would like to test the type for variable to check if it's an integer, you have to check for both types, and if you're new in Python, it could be very surprising to have two different types for the same thing. And something else is that we added a new class in Python 2 during the development on Python 2, so for example, add properties, and the issue with the new class is that if you use new features like properties on all class, it doesn't work as expected. And again, it's a little bit confusing, that's depending if you inherit from object or not, you get an old or new class. So the idea was to move to the new class and just remove the old one. For example, when you divide two integers in Python, you get an integer in Python 2, and when you are new to Python or when you use a calculator, you expect that you get a floating point number. For example, divide 1 by 2, you get 0 in Python 2, and it's maybe not the expected results. So we wanted to change that to always return a float, especially because in Python 2 you already have a dedicated operator, which is the integer division. Instead of a single slash, it's a double slash to always get an integer. For Unicode, I would say that if your application is using Unicode everywhere, like for inputs, for outputs, if all the text is on proceed as Unicode, everything is fine. If all your inputs are bytes, all the outputs are bytes, you get bytes everywhere, everything is fine. But if you have both Unicode and bytes, you will get a hard time because it works in most cases, but as soon as you write a name with a non-asky character, like a letter with a diacritic in French, you get a Unicode error, and it can be very painful to fix all your application to make sure that you are using Unicode everywhere. So we also wanted to change that in Python 3. For the comparison in Python 2, the idea is that the comparison never fails. So if you compare two numbers, if you compare two objects, but your Python is not able to compare the two objects, what Python does is to get the type, the name of the type of the object. For example, you compare the number 3 to the string hello, you get the string int for integer and the string s tier for the name of the type, and Python decides to order this object depending on the two strings. It's a little bit surprising, and maybe not the behavior that you expected, so again, we wanted to change that. And last but not least, in Python 2, all imports are relative by default. So if you use the same name that the module in the Stornart library, like the CIS module or the OS module, you may get your own code instead of the module from the Stornart library. So it can be very surprising, and you can get a lot of issues depending on how you run your application. So again, we wanted to change that to use the imports absolute by default. To limit the risk, to not break everything, from the very beginning of Python 3, the idea was to only fix acknowledged watts, to not fix everything, but a short list of things. We also had a community process to decide what to change, which means that we have a list of peps with numbers starting with 3,000. And we did not want to re-implement the interpreter from scratch. The interpreter is a C Python, which is written in the C language. And if you write a new implementation, maybe what you can get is to get a very subtle behavior changes between Python 2 and Python 3. And the idea was to limit the number of changes, to really make sure that we get the best backward compatibility. And from the very beginning of Python 2, Python 3, sorry, we already had a deadline for the end of life for Python 2 to warn all of your users to make sure that everybody is aware that we are moving on, and it's time to move to the new Python. And finally, in 2008, the Holy Grail, Python 3, we got it. And the first migration plan was very, very simple. Python 3 comes with an application called 2-3 to port your whole code base that wants to Python 2, from Python 2 to Python 3. And by doing that, it's very easy because it's a single step and you're done. Maybe if I'm still here to discuss about the migration from Python 2 to Python 3, maybe it didn't go as expected because there are many reasons why it doesn't work as smooth as expected. And one of the issues is that when Python 3 was being released on Linux, you didn't get Python 3 from the first day. We had to wait one up to two years to get Python 3 in Linux. So if you remove the Python 2 supports, you drop all your user base. If your user base is in Linux. So for the maintenance of modules, using 2 to 3 was a no-go because we just don't want to lose our users. Another issue with this migration plan is that when you have 10 dependencies, if you have a single dependency which is not compatible with Python 3, you are stuck because just, for example, import the module, raise the syntax error, and you cannot continue to port the rest of the code because you are blocked very early in the migration. And the last point is that we didn't expect that. In fact, many people were using Python 2 and we were not aware that so many people depend on the Python 2 and use it in production. And something else is that is a thing called technical depth.  And the developer says, for all these new cool Python 3 feeders, obviously. Okay, but can we use all these new feeders and the developer? Well, since we still have to support Python 2, nope. Because the thing is that when you still support Python 2, if you use a new feature of Python 3, you get an import error or you get a syntax error or whatever else. So it means that even if technically you support Python 3, you cannot use new features. So the migration as a cost, because you have to spend time on the migration, but there is no direct benefits. So when you discuss with a manager to explain the technical depth, it's very hard to convince your manager. So to support your code, what you can do is to divide your code in two different branches in Git or Merkle or whatever you want, to have one branch for Python 2 and one branch for Python 3. And some project decided to be forked to not have two different branch but two different repositories. In some cases, the fork was made upstream, like the DNS Python project has been forked as DNS Python 3. Sometimes the company behind the project, like PIL, didn't care about Python 3 because of the technical depth and because of the cost of the migration. So in that case, the community decided to fork the project and to actually do the migration. So the PIL project has been forked under a new name, which is PILO. And not only you get the Python 3 support but also new features. And suddenly, in some cases, the project, like, for example, MySQL Python was no longer maintained. And when I was working on OpenStack to port OpenStack to Python 3, it was a blocker issue because MySQL is very popular in OpenStack. And this was the only driver to connect to the database. And since the project was no longer maintained, it was very difficult to get any change merge in the official project. So one guy decided to fork the project under a new name, MySQL clients, to port to Python 3 and again to add new features to fix bugs. But you got a new issue is that you don't know what is official upstream because the old one is official one but it's no longer maintained. And if you move to the new one, you don't know if the old maintainer will maybe wake up one day and say, oh, this is my project.  It was a little bit difficult in some cases. And when Python 3 has been released, the stable version of Python 2 was still Python 2.6. And the issue with Python 2.6 is that it has a lot of troubles to write a single code base for Python 2 and Python 3 in the same file because of the syntax, it didn't help to write a single code base. For example, about the Unicode string in Python 2 to get a Unicode string, you have the U prefix. But if you use this U prefix in Python 3.0, you get a syntax error because we decided that it doesn't make sense in Python 3 to have a prefix because by default everything is Unicode. So you don't have to add any prefix. It's obvious. This was not a good choice because people really wanted to keep Python 2 support. So it was very painful. And one solution was the 6th module, which has a U function. And when you call this function, depending if it is Python 2 or Python 3, you get a conversion, like you decode the string to get Unicode on Python 3. And then in Python 2, if you really wanted to get Python 3 features like the new Unitest, which has new methods to write Unitest, you can use a backported version of the module. But then it's a pain because you have to pull a dependency and it's more complicated than using something for the standard library. So after the autumn comes the cold time of the winter time. And to start the winter, there is a website which has been created in 2011 which is called Python 3 Wall of Shame. And the purpose of the website was not really to blame maintainer. The intent was to motivate package maintainer to move on to Python 3. But when the website has been created, only 9% of the top 200 projects on PyPI were compatible with Python 3. And to give you an idea of the status of the migration at the beginning, I identified three big players in the Python community which are Twisted, Mercurial and Django. Twisted is a very powerful framework to write network applications, not only clients but also servers. Mercurial is something similar to Git. It's a source control management and it's written fully in Python. The last one, Django, maybe you already heard about it. It's a very popular framework to write web application, to have the database using an ORAM, to have templating, to manage users, to generate the admin interface. So it's a very complete framework and it's very popular. But when Python 3 has been released, there were some troubles to bought all these applications to Python 3. The issue with Twisted on Mercurial is that Twisted is working on the network layer. On the network, you cannot speak Unicode because you only have wires, you have bytes, and to get Unicode there, I would say it's not the appropriate type to manage network. So the native type for Twisted is not Unicode but bytes. And Python 3 makes it more difficult to use bytes. And for Mercurial, it's the same thing because not only for the file contents but also for the file name, they really wanted to use bytes to get the best compatibility with all operating systems. And because of that, it was a very long journey to them to be ported to Python 3. For example, Twisted today is ported but Mercurial is still a work in progress, 10 years later. And Django, at the beginning, it supported Unicode but it was not perfect. There were many, many issues. So it took time to port Django to Python 3. And because of all this issue that I started to describe, because of the very slow migration, because of all these problems, we started to see the French guy, the Python 3 trolls. We considered that maybe Python 3 doesn't bring anything because as I explained, when you use Python 3, you cannot use new features because you still have to support Python 2. So you have to spend a lot of time for the migration but you don't get anything. So what's the point of Python 3? It's useless. And according to the trolls, the migration to Unicode is just a pain point. It doesn't bring anything because if you use bytes in Python 2, you never get any kind of error because of Unicode error or Unicode encoder error because bytes just works. Maybe if you use two different documents in two different encodings, your maids get an error but not an error but mojibake, which means that you get strange letters in your text, but they say that, oh, who cares? We all speak English. So slowly the trolls come up with a new idea. They say, hmm, maybe people are still using Python 2. Maybe we should just continue the development on Python 2 and let the core developers do the same thing on Python 3. And so they decided to create Python 2.8, which is a Python 2.7 with new features. And the problem was that even if some people were like the idea, nobody was volunteer to do the actual work. And to give you an idea of this issue is that in 2014, so it's only four years ago, there was still a debate about the transitional Python 2.8. And what was written in this article is that they are still concerned about Python 3, which may never take off. And Python 3 only represents under 2% of packages according to the trolls. But what we did in 2011 is to write a PEP, the PEP 4.0, the PEP not found, which is the Python 2.8 on release scale. It's a document to explain that, no, we are not going to continue the development in Python 2. We have very good reason to move on. And it's a document to make it very obvious for everyone. And if you look at the numbers differently, in 2013, in fact, 80% of the most of the 50 top projects on PyPI were already compatible with Python 3. So it was not 2%, but 80, it's different. And in 2014, at the PyCon US, Willow Van Rossum gave a keynote, and he took a very, very good, wise decision. We decided to extend the support of Python 2 by 5 years. It means that instead of having a usual support of 5 years, we get a very long support of 10 years. And the idea was to send a message to all our Python 2 users to say that, okay, we know that you have good reason to not migrate right now. I took time to migrate the dependency, took time to write new tools. We know that it's very painful. We will not break Python 2. For your information today, Python 2 still gets security fixes. It still gets bug fixes. You still get new release at least once a year. So we still support Python 2. We don't force you to move right now. There is no intent to break Python 2 on purpose. So the deadline is now in 2 years. So after the cold winter comes the fresh air of the spring with flowers, new plants, some new starts. The good news is that we fixed our first issue in Python. Do you know what is the first issue in Python? The first issue was that when you are to install a dependency, the newcomer came on IRC on a main line and asked, how can I install a dependency? And the answer was, oh, just install setup tools. Okay, but how can I install setup tools? So you had to go to a specific website, download a Python script, install the Python script, and maybe you need a system administrator permission to install the script. So it was very painful to explain how to install your first dependency. And the good news is that in 2011, PIP 1.0 has been released. And in Python 3.7.9 and Python 3.4, we added something called Ensure PIP. So it's not PIP itself, but it is the thing to bootstrap PIP. It's an installer of PIP. So thanks to that now, you don't have to worry about how to install PIP because it's already part of the language. You already have something to install PIP for you. You don't have to take care of that. And because of Ensure PIP has been added to the standard library, quickly PIP became the de facto installer for Python. So because of that, today you don't have to ask how to install something. Everybody knows that it's PIP. And thanks to that, it's much more easier to install dependency and it's also much more easier to have dependencies because previously some people just didn't want to have dependency as they decided to vendor some libraries to avoid any kind of dependency. And out of that, you get some security issues, for example. And the last point is that today, Linux distribution also comes with PIP. Okay, so previously I said that maybe two to three was not as a good approach for the migration because you just lose all your Python 2 users. So maybe we can do something differently that instead of removing Python 2 support, is to add the Python 3 support. And said like that, it seems very obvious because people know today how to do that. But you have to understand that it took a lot of time to came up to this new approach because it took a lot of time to understand that the old approach was wrong. It also took time to write the new tools to do actually the migration. And there are very important modules like 6, for example. 6 is very useful to write a single code base for Python 2 and Python 3. And one example of this new approach is a modernized tool which takes your Python 2 code base and adds Python 3 support. And I also wrote a different tool which is called 6r. This tool is written for my very own usage which is to port OpenStack to Python 3 because in OpenStack it's a giant project with 2,000 developers, a lot of companies, many, many things, many changes are merged every day.  So I wrote a new tool to be able to modify only a few files by doing a few specific operations. For example, using my tool, you can only add parentheses to the print statement to convert the statement to a function call because the function calls works on Python 2 and Python 3. And by doing that, the main benefit is that instead of porting your code base at once, in fact, you can do it step by step. And by doing that, you can validate that at each step everything is fine. You can run tests to check that there is no relation. And it's much easier to review these changes because they are much shorter. So thanks to this approach, it was much more easier to port big applications. If you are a very big company, maybe you get other issues because your code base is really large. In this case, maybe you need a different approach. For example, for very old legacy code, what you can do is to first add new tests because nobody wants to get regression just because of Python 3. So the idea is that first you write tests to make sure that you don't regress. And another approach tested by Dropbox is that they are working on type hinting, type annotation. And using the typing module, which is new in Python 3.5, I think, you can standardize the way to annotate the type for function parameters and for the residual type. And by doing that, you can use a tool called MyPy, which is a static analyzer to make sure that you pass the correct type to a function. And by doing that, they expect that the migration to Python 3 would be much, much more easier. And to make the transition easier, we have also made changes in both sides of Python. For example, in Python 3.3, we reintroduced the Euro prefix for string. And thanks to that, you can use the prefix in Python 2 and Python 3 to get a single code base with unique code strings. In 3.5, we added the bytes formatting operator, bytes percent args. This is very useful for Mercurial and Twisted because they manipulate a lot of bytes. And the bytes operator is more efficient than taking bytes, conversing with unique code and encode bytes back to bytes. And on the Python 2 sides, what we did is also to add new warnings. The idea of warning is that you take your application, you enable the warning, and once you get a warning, you know that, oh, maybe you should have a look at this part of the code, and you can start to fix some issues which are warnings about future backward-uncompatible changes. And again, to build bridges between the two versions, more and more people back-ported Python 3 features from Python 3 to Python 2, which means that, actually, you can use Python 3 features. So, for example, there is a unit test tool, but also Enum 3.4, which is a new Enum module of Python 3.4. And after spring comes the summertime. If you recall, the website called Python 3 Wall of Shame, the author of the website changed the title to Wall of Superpower. Yeah! I removed from 9% to 95%. So, it's almost 100%. But in practice, you have to know that we don't need 100% for the top 200 packages, because this list is very long, and in the list, you have some packages which have been deprecated and replaced by better solutions. And another very good news is that, finally, Python 3 is faster than Python 2. On this picture, you can see that on a specific list of benchmarks, the list of benchmarks where Python 3 is the difference with Python 3 is the most significant. So, all results are normalized to Python 2, and if a line is smaller, it means that it's way faster. So, you can see that in some cases, it's up to two times faster or even faster. So, there are just two cases where Python 3 is still slower. It's a start-up time. So, there are two benchmarks for the time-to-start-up Python. This is an issue when you have a very short command-line interface. Just run a command and get a result immediately. But we are working on these issues. To explain it differently, you have to know that the Instagram company is fully based on Python, because Instagram is using Django. And because of the time-to-market, it's not possible for them to rewrite everything in a different language or just to rewrite everything from scratch because there are too many competitors on this market. So, what they did is to post their code days from Python 2 to Python 3. And just by doing that, now they saved 12% of the CPU and 30% of memory. And if you think about a very, very large company with Instagram with 700 million users, it costs a lot for the server because they need a lot of servers. So, any kind of optimization means a lot of money for them. If you did not look at Python 3 changes and you are still not convinced to move to Python 3, maybe you have to know that we have a list of bugs that cannot be fixed in Python 2. Because Python 2 is very old and because it's very old, we know more and more bugs. But we cannot fix these bugs because of the backward compatibility because people consider that Python 2.7 will never change and they have expectations on that. We will not break the change of behavior. But sometimes to fix bugs, you really have to break the backward compatibility. For example, if you think about Unicode, technically we can do a lot of things in Python 2. We can break the backward compatibility to make sure that when you compare bytes to a Unicode, you get an error. But if you do that, you can be sure that many users will complain because it will just break all applications written in Python 2. Another issue is that for the dictionary type in Python 2, we are using an hash function because it's an array with an hash function to implement the dictionary. And if you inject specific strings, you get the worst case complexity, which means that Python becomes very, very slow. And this is a security issue if you have a web application because an attacker is able to crash your server to abuse your CPU. And we fix the issue in Python 2, but the fix cannot be enabled by default because it changes the order of elements in a dictionary. So if you really want to make sure that you are secure, you have to opt in for the new fix. To give you another example, the sub-process module to spawn sub-process, it is not thread safe. So maybe you did not notice because everything is fine, but maybe one day during the night you will get this bug and you will add a bad time because it's very difficult to work around this issue. You need to put a lock on the function and if you have a big code base, it can take a lot of time to fix the issue everywhere. And there are even more complex issues like the recursive lock in Python 2 is not signal safe. So imagine that you spawn a child process. When the child process completes, you get a signal to notify that the child process completes. And this signal, if it comes at the wrong time, can make your recursive lock inconsistent. So that thing will happen. And you cannot control when it happens. It's very difficult to reproduce this kind of bug because you don't control the execution time of the child process. So you may get the signal early or late. And last but not least, as the clocks in Python 2 are not monotonic. If you see the previous talk about the time zone, you also see that you have the winter time and a summer time in many countries. And even in some countries, you get four changes per year. And because of the change, the clock moves in one direction or another by one hour. And in some cases, it can crash your application because the application doesn't understand why the clock is moving backward or forward. And to fix this issue, you need a monotonic lock, but we were not able to fix that issue in Python 2. But the good news is that we fixed everything. So just use the Python 3 on your goods. For example, I added a monotonic lock in 3.3. And one more complex change is that file descriptor. It's a file descriptor. You can imagine it's a file. By default, in Python 2, when you spawn a child process, you will inherit all open files. It means that if you open a list of passwords in the master process and you spawn a new application, you will be able to access the password files and you may not expect this behavior. And it was very difficult to convince other core developers that it's not a good idea because this change breaks the backward compatibility and you may know that we care a lot about the backward compatibility. In Python 3.7, I made a different change is that when you get a signal, for example, when a child process completes, when you get a signal, Python is currently blocked in a blocking C-scroll. So for example, you read data on the disk, and the disk doesn't have the data in cache, so you have to wait for the hardware. In this case, if you get a signal, the C-scroll is interrupted. You get an interrupted error. And in this case, you may get an error and you have to handle it in your application. And it's very annoying because you have to be prepared for signal at any kind of C-scroll and there are many, many blocking C-scrolls. So the change is that Python will now retry the C-scroll for you. So if you are blocking C-scroll and you get this error, Python will just do the same C-scroll one more time. And so to explain you the advantage of Python 3 is that this is a quote from Widow Van Rossoom on my pep about the file descriptors. He wrote that we are aware of the code breakage. This is likely to cross, but doing it anyway for the good of mankind. And if you're still stuck at Python 2 and you still need reason to move to Python 3, you have to know that in the standard library we got not less than 21 new modules. And just to name a few, there is a asyncio, enum, passlib, unites.mock and many, many others. So it means that you don't have to install them. They are already part of Python. And it's very useful to develop new application. It will use a number of dependencies and there are some tools, for example, to debug Python, which are very useful. So not only is the Python has new features in the standard library, but the Python language itself also evolved. For example, one popular features of Python 3.6 is called fString. It's a new way to format string. And in my opinion, it's just the best way to format string because it's very short, it's very obvious, and it's very difficult to make mistakes. For example, you can just name a variable and the variable is replaced by its value, but you can also call a method on an object, like call the title method to convert the first letter to an uppercase. You can even do any kind of Python expression. So you can do a lot of things and not only you can use it for prints, but also for any kind of string. For asynchronous programming, we added a lot of things for Python 3 coroutines. The first challenge was to add a yield from, which is something to delegate generator. This means that you have one generator and you pass through all values to a different generator. And the first version of, I think, I used yield from, but it was a little bit surprising to use it. So in Python 3.5, we added two new keywords. I think to mark that one function is asynchronous and await is a keyword to say that, oh, I am waiting for something. And by doing that, it's much more obvious when you read the sentence in English that it makes sense. Not only you are about to, I think you also have something called asynchronous generators. So you can now use the yield keywords inside AsyncDef. So this is, for example, very useful if you think about a database. You would like to provide a generator to iterate on each line of a database, but you don't know if the color is going to use all lines because, for example, if you have one million of rows, you don't want to send it as a list because it will use too much memory. But using the yield, you are able to, for example, fetch 10 values and iterate on these values, and after that, fetch 10 or more values. So you can implement very efficient strategies for a database. And the Async4 can be used for an asynchronous list comprehension. Or you can also use Async inside these comprehensions. It's not only about AsyncIos, there are other very useful Python 3 features in the learn syntax. I really like the first one, which is the keyword only. So imagine that you have an existing module, it's very stable, but you need to add something to pass a new argument, but if you add a positional argument, maybe a user of your library on the old version will pass the argument and get an error. So the idea is that using a keyword only, you have to specify the name of the parameter to write keyword only equal the value. And the print statement becomes a function. So here is an example where you can use keywords, but they are not keyword only, but you give you an idea of the syntax. And I also like the print function, because today you can use it in a lambda function, for example. And I really prefer the new syntax. For the star previously, you was able to use the star when you define a function to write star arguments to get an arbitrary number of arguments. But now you can also use when you assign a variable to say, for example, one star tail, and the tail gets the rest of the list, the tail of the list. And another thing is that now you can use the star inside a list, but also a double star inside a dictionary to say that you update the dictionary with another dictionary, like you concatenate two different dictionaries. And something very trivial but very, very useful for the readability of your application is that today you can add an underscore in your literal numbers. This is very useful for the readability because if you get nine zeros or six zeros, it's very difficult to read this number to see quickly if it's one million, ten million, or one billion. You can also annotate the type of a variable using colon and the name of the type, like x colon int. For the context manager, you can specify multiple context managers on a single line. This is very useful. As I said previously, there is a byte formatter to format a byte string. And something very useful if you use the numpy, it's dot operator, the at operator. It's used for matrix and multiplication. In numpy, currently the name is numpy.dot, but the issue with numpy.dot is the way that you pass arguments. It's more difficult to read the expression. Using an if fix operator, it's much more obvious how you write your formula. Okay, so we saw that the Python 3 is much more powerful. We saw that we have tooling to migrate your code very easily to Python 3. So now the question becomes, is it time to bury Python 2 to just delete it? The good news is that we already started to remove Python 2 For example, if you install a recent version of Fedora, Fedora since three years, or if you install the latest version of Ubuntu, like Ubuntu since last year, there is no Python 2 in the base system. This means that you install the full system. There is no Python binary. There is no Python 2 binary. But obviously, if you install an old application which depends on Python 2, for example, Mercurial or GIMP, the plugins written in Python, you pull the Python 2 dependency. But at least you are able to get a base system with everything in pure Python 2. About the timeline for the removal of Python 2 in projects, there is a website called Python 3 Statements. It's a timeline of 20 or more projects with the first support of Python 3 in the project, the deprecation of Python 2 and the removal of Python 2 support. And you already have Python 3 only applications, which are Django 2 and IPython 6, which are Python 3 only. And I think that Python 2 was a big achievement for the Python community because Django is a very popular module. It's very complete. It's a lot of features. And if something like Django is able to move on to Python 3, it means that any of you is able to move to Python 3. And there is also a pythonclog.org, which is a countdown until 2020, the 1st of July, which is the end of life for Python 2. So I'm working for Red Hat. So the question is also about Red Hat Enterprise Linux. You have to know that even if you use Red Hat 6 or Red Hat 7, you can already get Python 3 using something called Software Collections. It's a new repository and you can easily install, I think, Python 3.6 for Red Hat 7 and Python 3.5 for Red Hat 6. So it's already in the available and you also get supports. The support is a little bit shorter than the operating system, but it's between three years and five years. And the very good news is also that in the latest version of Red Hat Enterprise Linux, so the version 3.7, we announced that Python 2 is now deprecated. So if you need a reason to motivate your manager, you can say that even Red Hat started to deprecate Python 2. And the very good news is that the next version of Red Hat Enterprise Linux will be Python 3 only, no Python 2. And one open question to finish is that we saw that we spent a lot of time on porting all the application. It was very painful for the community. It took a lot of time and energy to write single code base for both versions. So maybe we can imagine a new approach to add new features to Python. For example, if you look at the JavaScript approach, what they did is that there are two projects called Babel on Polyfill. And using this project, you are able to use the new version of JavaScript, even on very old browsers. And by doing that, JavaScript is able to evolve very quickly, much more faster than Python. By evolving, I mean that you can use the new features. You don't have to wait until all browsers around the world move to the latest version of JavaScript. And I suggest you to see the talk of Daniel Espotti at PyCon Italy. He describes the evolution or stagnation of programming languages, and he compared Python to JavaScript. Mm-hmm. Okay. Okay, seriously, about Python 4. I know that many, many of you are joking about Python 4 and expect that Python 4 would be the new Python 3 to break the world again. I think that everybody understood that Python 3 was not well-prepared, and maybe for the next version of Python 4 we will do it very, very differently. I mean that my expectation for the Python 4 is that it will be as any release of Python 3, which means that we follow the same deprecation process.  We will not break the compatibility for free. We will just follow the usual process, which is that at least you have one version with a deprecation warning, and sometimes you even have a pending deprecation warning, another version with a deprecation warning, until at the third version you start to remove the function. So my expectation is that it will be just as any other release. Okay, thank you. So we can do maybe one quick question. There is a question there. Thank you for your talk. I was going to ask a boring question about process IDs and process modules, but I'll switch to a more interesting one. How do you yourself and the rest of the core team along with the PSF kind of work to get this kind of through, because you're all not in the same place, this is not in the same company? How do you decide these maybe contentious type decisions to go a certain way or do a certain thing? I'd be interested to know what's the process for getting Python out there, the thing that we all use every day. So your question is about how we take decision in Python to accept a feature or not. So I've noticed the ES6 is starting to look a lot like Python with the imports, and Python now with the f-string looks like ES6. So how has that process kind of started to work? What I like in Python is that compared to Java, the Java world, for example, everything is open to everyone. There is a Python ID's mailing list when you can propose IDs to get a first feedback. And once the ID is mature enough, it moves to Python Dev where we get a second discussion. And it seems like anyone is able to propose IDs, and if the ID is good enough, you may decide to implement it yourself or find someone else. And I don't think that Python is owned by any companies. I think that it's more a community process, and I don't recall that one company forced to get one specific issue. And as I said, it's really, for me, it's a power of the Python community to be open and not to restrict. You don't have to subscribe or pay money to propose new IDs. And for the decision itself, again, it's driven by the community. Maybe some of you have heard about a new operator, which is called Equal, the PEP 7572. It's a new assignment operator. I think that we got something like 800 emails about stats. So we got a lot, a lot of discussion. And this is an example where the community stand up to say that I don't like this feature and we don't want to get it. So I think that the process works pretty well. And another aspect of the decision is also that we have the BDFR in Python with Guido van Wassen. And we also have very strict rules about the consistency of the language. And I think that one of the key responsibility of Guido is to make sure that the world language remains consistent. So if it's not Pythonic, it will not go into Python. Okay, thank you everyone. Just a round of applause for Victor.


10 and I just wanted to go over this in conjunction with the last video I did on the Lordstown CEO talk during Q3 call and this is kind of the equivalent of the Foxconn CEO. I'm going to skip through a lot of this. This is November 10 so it's current so we can start Foxconn purchase 50 million of stock directly from Lordstown for $6.89 a share. That's kind of a good good faith money up front. They're going to sell the Lordstown facility the total with the hub motor and battery line separate $230 million. A down payment of $100 million by November 18th that's a capital infusion and subsequent down payments and this I don't think made very clear. There's $250 million subsequent payments so they're going to have $100 more in OPEX in November 18 this month February 1st next year they're going to have $50 million and no later than April 15th in 2022 they're going to have another $50 million. So $100 million this year and then basically in Q1 2022 they're going to have another $100 million so that's $200 million and then the balance of the purchase price will be paid at closing and the closing is targeted for April 30th 2022 now that's going to be another infusion in April so in April we already have 50 million and then we have coming in on the 30th we have the final payment okay which is $30 million but in addition they're going to get a first payment for the OPEX of the plant from September 121 to this date which could be as much as $230 million in my estimation have to see but you know so you're looking $100 million this year another $100 million in April Q1 of next year and then again at the beginning of Q2 next year possibly $230 million cash infusion so I don't know it depends how this accounting is worked out maybe Lordstown won't need to raise capital it'll be close but I think that was unclear and I don't think I did a very good job of stating it here but you can pause this and read this yourself and come to your own conclusion there but that's that's it's this kicker reimbursement of the of the OPEX that is the kicker and depending on how much they attribute to this and I don't know how they're going to do that accounting plus this 30 million I have an estimate down here of a 230 million so next year in 2022 they're going to get 50 million 50 million 100 million right and then maybe 230 million more so that would be 330 million possibly cash infusion from this deal next year and 100 million this year so this may finance the internally finance the production of the endurance in addition to the 50 million shares they bought they're going to get 1.7 million warrants exosizable for three years just three years that's a short time at 1050 strike price okay so they're going to be under pressure to get this stock price up the higher it's up the more they make this gives them and this is just really back in the napkin this gives them an approximately 70 million share interest in lords town the same as general motors has now this is something else that I think is important here uh young lou lou lung we young we chairman on chairman of haun high tech has stated he's talking about the partnership the lords time mortars purchase is going to turn Ohio into haun highs that's fox con technology haun highs most important electric vehicle manufacturing and r&d hub in north america so this is a big deal and i just want to show you why this is a big deal it is fox cons biggest manufacturing r&d hub in north america for evs okay and haun high fox con is the world's largest electronics manufacturer and evs are basically electronics but being the world's largest electronics manufacturer and this is going to be their most their main most important manufacturing and r&d hub in america so this is the world's largest manufacturer of electronics in north town it's going to be their main pressure point in north america anyway guys i just wanted to go over this real quick i'm going to pause this here in case you guys want to see any of this other information you can pause the uh video but i thought that was an interesting take and i wanted to include this with the other information from the previous parsing of the new ceo's lordstand ceo's statements so i think uh there's a lot that people are missing from the feedback i see on the internet on this and uh you guys can pause this and look at these payments i do it it looks like maybe they are internally financing the uh production of the endurance are pretty close to it with this deal we'll have to see what the what uh what the details work out with as far as the manufacturing agreement on the endurance you know will fox con agree to you know take a commission on each sale rather than take the commission up front for the manufacturing that could also happen that would free up more capital anyway this is mxux signing off guys comment like and uh subscribe anybody out there that's a new viewer if you go to my youtube channel you can look at the most recent videos i've done very complete coverage on lordstand motors if you own this stock or want to own ride you should subscribe to my channel and take a look at the catalog of my past videos you'll be able to find anything you want to know about lordstand motors there and ride stock all right this is mxux signing off thanks a lot uh catch you guys later so this is lordstand motors and i'm gonna pass by the supply chain area so you'll see i'm gonna go as slow as i can lot of merchandise and containers that used to not be here i've been here before and all this is new so one can presume these are parts for building these look at that these are all stacks and stacks of something okay and that is lordstand there so


Okay, hi everyone. Thank you so much for joining me in this section. I hope we are having a sighting time at the Singapore National Library. We are quickly going to look at connecting library metadata to WikiData, a semantic web approach to information discovery. My name is Omar Odeon, Okuangai. I'm currently the head of eLibrary Services at Glorious Visual University in Nigeria, West Africa. It's my honour to be doing this short, to give this short talk, which will be followed by a practice section, which will be handled by, like, my links to other librarians on ground, through. And I'm sure we're going to have an exciting time together. So, we're talking about connecting library metadata to WikiData. But why do we need to start thinking about this? Now, this topic was born out of the current problems that are associated with library metadata in our current dispensation. We know that technology has helped improve library metadata, and we now have different cataloging systems and different OPAC system, online public access catalog, that allows for the sharing of library graphic records, otherwise known as library metadata. Now, what the challenge with existing technologies is that these technologies are oftentimes domiciled in each institution. So what it does is that it makes each institution having their own records. There is no aspect of interconnectedness among different records, different knowledge. And also, not to mention the fact that there is limited visibility to these records. And oftentimes, you find that these records are only domiciled within the institutions and linked to the institution website. So it creates a kind of unlimited visibility, which in turn also affects accessibility to these graphic records that could impact the use of information resources in the library. And that's why this session is, it was conceived to discuss wiki data as a technology that could be leveraged on by libraries to help improve the discoverability of library materials, and also the interconnection of libraries and institutions together. And it's important we have a brief understanding of what exactly is wiki data and how does it fit in library into the dispensation wiki data as as commonly defined is a free multilingual knowledge base of linked open data that can be edited by new months or machines alike. The, the technology is, is seen as a knowledge base of linked data. It contains treasured data with entities and with entities about people, places, institutions, organizations and so on and so forth. So it's a powerful tool for improving accessibility to information. And it was also conceived, it was launched in 2012. It's because of the linked nature of wiki data, it is considered a semantic web technology, and it allows for use of structural data in a linked environment. So what exactly does wiki data fit into libraries in, in our current discussion, how does it fit wiki data as a technology often time can be used as a hub for library data. And we found that libraries can actually contribute to their own graphic data onto wiki data as a way of creating access to this to their records. And this often time will be more will be very useful to libraries with less technological infrastructure and less technical support to create their own. Open catalog system to enhance and discover. I think libraries, especially in different regions from developing regions to develop regions, we find this technology very useful as a whole. Then there's also the advantage of linking of collections together, as well as demographic records in an ever expanding world with wiki data libraries and librarians can help link their collections together. And by sharing relationships between one collection and the other, for example, collections by the same auto resources published or also by particular auto can be linked together. Then also, it can be linked with other institutions, other libraries using a center identifiers. Then there's also the, the fact that wiki data curriculum for enriched demographic data. And this could be taken, for example, in our regular catalog system, we create information for, let's say, the name of an author, the title of a walk, the place of publication, the year of publication, and so on and so forth. Let's see, what if instead of just having the name of an author, we can have more information about the author, for example, like where the author schools, other publications that he has, and other libraries, for example, that has content about an author and things like that. And this can be made possible with the use of wiki data because you can help to show this link, this relationship and connect one entity with another entity. So this is a huge advantage that wiki data have, and it has the capability and potential to create a giant open knowledge ecosystem that could help improve scholarship and research across the world. And that's why libraries must begin to embrace wiki data, not as a replacement to existing cataloging systems or information retrieval systems, but as an addition to it as a way of creating a new level of openness to its collections. And then there's also the advantage of using the query service in wiki data, such as the wiki data spark query service, to help analyze library graphic data and create visual image that could be used to make informed decision. So these are other advantages that libraries could gain by using wiki data and connecting their meta data into wiki data, so as to help improve overall service delivery in the libraries. And there's also the issue of linked access to edited the graphic data of people involved in the work, which is what I've explained has continued more information about the authors of a work. So but when we talk about wiki data, and the question that often comes to mind is what makes wiki data stable for library metadata. We've already highlighted the importance of wiki data being the fact that it creates a better visibility for library graphic records such that instead of the graphic record being domiciled in only one cataloging system, it can be visible, it can be seen from people from different parts of the world. And let's say, for example, my library, Glorious Vision Investing Library, we have our own cataloging, our online management systems that allows us to, to catalog and share our graphic records with our users. But what if we can add our cataloging information to wiki data? It means that people beyond our immediate environment can have access to it. So it means for people in Singapore, for example, can access the records, people in the United States in Europe can access the records and so on and so forth. So this ultimately helps to improve the discoverability of library resources and creates a better learning environment for not only readers but also researchers and information seekers in general. And then there is also the ultimate advantage of interoperability between libraries, especially by libraries can actually foster collaboration and cooperation by collectively contributing graphic records to wiki data. Now there's a project we are currently working on in Nigeria, which is a recording pilot in wiki based in wiki based in Nigeria libraries. And we are currently exploring how we can actually use wiki based technology, which is a software that powers wiki data, where exploring how we can use it to create a unique catalog for different libraries in Nigeria. We will talk more on that later on because of this presentation. But the goal is that with wiki data technology, we can actually foster cooperative cataloging among libraries and libraries could engage in cooperation and updates their records together. What this can do is that it will help improve the standardization of bibliographic materials and help create better more quality metadata for libraries and also help libraries that are not having enough skilled mapper to create their own bibliographic records or metadata by themselves. So we can actually work with existing metadata. So all this helps to make the library create a better learning environment for not just the libraries but also for the librarians themselves. And there's also the advantage the fact that wiki data is highly visible, is highly visible, very visible, and it's connected to Google and other AI agents that help in the area of search and retrieval of information from the library. Not to mention the aspect of querying and analyzing data from the library. So this is an image that was uploaded by GCNLWU. It's a pennant manuscript. It's a visualization of the pennant manuscript that has been uploaded into wiki data by the National Library of Wales. And that is a notable example of a library that has actually contributed thousands of material and graphic records to wiki data. And these records includes books, manuscripts, maps, and other kinds of information resources. And it shows the interconnection, the links between different resources. So what this can do is that with wiki data we can create visual images of library collections. We can create timelines, create different, we can work around our data and play around it to create different, different image or different data that could help make informed decision. So the advantages of wiki data are enormous, but having known this, how can we now contribute our contents to wiki data. Now we're going to have a short practical session after this brief talk, which is going to be handled by librarians on ground to be led by Peru. So, but it's important to know that part of the ways we can actually contribute our, connect our library metadata to wiki data is by, we can do that by manually adding wiki data items, creating wiki data items for our library collections. And there we can add different statements. For example, you want to create a wiki data item for a book titled things fall apart by Chinua Achibi. You, you can get to write the name of the author, the title of the work, the place of publication, the year of publication, then this can also be linked to Chinua Achibi as a person. So you can see that the link, it brings, it links different entities together, both persons and organizations and things like that. Then there's also the option of batch uploading of batch uploading of records, graphic records, using quick statements, which is actually allowed within the wiki data environment. So one can actually upload large amounts of the graphic record at once after the records are being cleaned and ensure that they follow the same data type and consistency. One can upload it, but it is advantage this has over the manually created wiki data item is that the librarian may not have so much 100% control over the data that has been uploaded. There may be some inconsistency among the records, but with the manual style you get, you have ultimate control over what you want to add, the kind of statements you want to add. So, we're not just speaking jargon, we're not just speaking abstract things. Different libraries across the world have actually embraced wiki data and have actually contributed their library demographic data to wiki data in order to create and improve global knowledge base. And the goal is that after this presentation, more libraries will embrace wiki data and actually contribute their demographic records to wiki data in order to create a more improved scholarly ecosystem. So there are multiple examples of libraries all over the world that are that have embraced wiki data, and I've contributed parts of their records of mapping data to wiki data. Of course, one of them is the Library of Congress, which has actually led the way in contributing. There's also metadata to wiki data and that they've done for since 2015. And there's also the Tether States universities. These are just few examples of course many other institutions, libraries, other GLAM institutions have also contributed, library methods have also contributed their own demographic records to wiki data. And these are just few examples. So in the course of this presentation, we're going to look at three case studies of three case study of libraries that are actually contributed parts of their demographic records or metadata to wiki data. We have one of the case study I noted here is the London School of Economics Library, which has actually connected over 2,000 records of their library metadata to wiki data. And the goal of this is to improve the discoverability of their materials. And they have also linked these records to other standard identifiers to help improve the visibility of the records. One case study here is that of the University of Texas Libraries. The University of Texas Libraries have created over 1,000 items for each person Latin American collection on wiki data using a tool called the Mix and Mash. And that matches Estana catalogs with wiki data. So ultimately, seven libraries have contributed demographic records to wiki data and more are still encouraged to do so. The third case study here is that of the National Library of Wales that has linked over 100,000 items to wiki data so as to help in not just creating visibility but also in the aspect of querying the data to create a visual images that could be used for planning and decision making. Ultimately, part of the collections that have been added by the National Library of Wales to wiki data includes information about books, newspapers, journals, maps, manuscripts, amongst others. Well, aside from wiki data, they are also the similar technology which is wiki based with multiple examples being the German National Library and the French National Library. They are also exploring wiki based as a linked data tool to help improve visibility and interconnectivity of library collisions. So coming back to Africa, there's also the example of the BAM library from the University of Ghana where they've also contributed parts of their library records to wiki data. So aside from connecting records to wiki data, I also want to just quickly bring to our attention the news of the pilot project on wiki based that is currently being piloted in Nigerian libraries. So we have a team of librarians in Nigeria be supported by the wiki media Dutch land. So pilot wiki based, which is a software that powers wiki data in Nigerian libraries and the goal of this is to help create a union catalog or an interconnected catalog for Nigerian libraries whereby we can actually link the records from one Nigerian library to another Nigerian libraries. So part of the goal for the pilot wiki based project in Nigerian libraries is to support Nigerian librarians to create their own wiki based or cloud user accounts. And you know that wiki based or cloud is a software as a service platform that is allows users to have to set up their own wiki based instances. So the goal is for librarians to set up different wiki based instances for their libraries and or populates those wiki based instances with their graphic records and connect them with other levels for improved discovery ability and visibility. Then there's also, of course, linking of the graphic records among the selected libraries that have been piloted, then also training of at least 13 Nigerian librarians to work in the linked data in a wiki data and wiki based environments. So using wiki data or wiki based is not just all simple. There are also challenges that we have to consider if we are to fully adopt wiki based in libraries, if we have to fully connect our resources to libraries. But there are not, there are certain challenges that we have to look at, look, watch out for before we engage in connecting our metadata to wiki data. And part of it is top on that list is the issue of sustainability. How sustainable is the practice beyond just connecting a batch records or a current records. So we hope to sustain the issue and this can be very challenging, especially since connecting library metadata to wiki data is more usually part of the workflow in many libraries. So this can become very problematic when there is no continuity or sustainability of the practice. And it can be difficult to update the records if this is not part of the library workflow. Then there's also the fact that it can be time consuming, working in wiki data environment can be time consuming, especially when, especially when one is not already familiar with the wiki data environment. That means one has to start learning new set of skills, how to use the wiki data query service amongst others. And of course, this knowledge are not taught in library schools so it requires more learning and more training on the part of the librarians. Then also, other multiple challenge is the fact that libraries may not really have total control over the knowledge that are shared, over the data that are shared on wiki data. And this is because wiki data is a collaborative platform that is being edited by people from different parts of the world. And it can cause a sense of concern to librarians when you may not have absolute control. So I think overall that the advantages of wiki data, advantages of wiki data, it supersets the challenges and one can always work around the challenges. So to conclude, wiki data is a powerful tool and all librarians, we encourage librarians, wiki medias and other open knowledge advocates to help connect libraries together by contributing more library data, library data to wiki data. As this will help to create more connectivity among libraries among institutions and also create more a rich, a rich knowledge base of linked data, which ultimately will help improve scholarship and improve an open knowledge ecosystem for an open scholarly ecosystem for society. So we know that the future is foundation is to bring, the future goal is to bring libraries together, bring a knowledge house together and wiki data can help achieve that. So the call for action for all of us is to sit back and think, just give yourself some time to think, what can I do to improve accessibility to library records? And how can I as an individual as a librarian help my library to be more visible? And what actions do I need to take? Those are questions I want us to ponder on even as we go into the practical session with my colleagues on ground. So I'm going to stop here. And I want to thank you all for listening to this talk. Yeah, also some useful link. I'll drop the link to these slides so you can also have access to it. If you have any question, please do not hesitate to write to me. I'll be more than happy to respond. So I'm open to, of course, more interactions about this more engagement about this and of course more collaboration. Thank you so much. And do have a lovely time. Thank you.