Okay, so we may move to another point of view, and Narendra Taneja, with the Chairman and Independent Energy Policy Institute, which is a new daily think tank. So I leave you the floor to discuss about the governance, please. Well, thank you very much. The last, almost a couple of hours has been very different color and mood in the room, so I don't know. You see, the global energy gravity center is no longer in Europe or Atlantic. It's in Asia, and the 405 billion energy consumers in Asia, they are consuming, you know, maximum energy, and that's where the future lies, whether you're a Western company or Eastern company, you're from Europe or Russia or America. If you want to secure your future, you have to look at Asia. That's the reality. However, when I travel to conferences like this, it's a conference actually in global south, in Abu Dhabi, in Asia. But since yesterday morning, I've been feeling I'm in Europe somewhere, and 70 percent of the time I feel is an echo chamber, you're talking to each other, then why did I travel from Delhi? Or why did, for instance, people travel from Africa? So you have got this habit.  And you see, in global north, there are only 1.4 billion people. In global south, there are 6.7 billion people, including people in Abu Dhabi. This is global south. We've got to understand and acknowledge it. You see, I travel to Europe almost every month, and it's so suffocating to go to conferences.  Today, BRICS, somebody mentioned today, BRICS total GDP on PPP basis, actually, BRICS is today bigger. From the first of January, BRICS is bigger than G7. Why do people realize that in Europe, investment part of the world? Why there is no realization that, look, it's a one small planet, and the world has changed? Energy, in this room, we're discussing energy. And going by the question answer, it seems that only region that matters is Europe and maybe the United States. That's the end of the world or the beginning of the world. My friends, the world has changed. You've already spoken for two hours, so allow me 10, 12 minutes now, because this is where the heart of the global energy is. So I'm representing the heart. I'm going to focus on energy governance and global energy order, and therefore, of course, the security.  You don't deserve to be in the high turbo. Somebody mentioned yesterday the richest continent on the planet is Africa. So we got to understand that whether it's energy or it's climate, we need to engage the whole world. Unless the discussion or the conversation is truly global, we will actually end up reaching to the wrong conclusions. And when the conclusions are wrong, solutions that we propose to the world, or for that matter, the people of Europe would not really produce any results. And look at, for instance, climate. Climate for us in India, we have 1.4 billion people, densely populated country. Climate for us is science. How do we go forward? On the one hand, we have to eradicate energy poverty. And at the same time, we have to mobilize sufficient energy for our people. How do we do that? So it's science. But for many in the global north, I'm not targeting anybody. You know, I love Europe. I spent nine years of my life in Europe. I went to universities in Europe. But for many, climate has become a religion. You just can't have conversation on this matter. If you say, look, I mean, there are 3 billion people, energy poor on the planet. We need to engage with them. We need to do what? No. Is it a religion? How can you question it? I'm not saying everybody, but there are many. And that has become a problem. And at the same time, when you look at the global narratives, whether global narratives on energy or global narratives on climate, because the West has the experience, you have a good think tank, you have diplomats, you know how to articulate his English language or the French language and all that, all these narratives are dominated by the West. I'm sorry to use the expression, but that's the reality. So the result is, what we have seen in this room, for instance, and we have seen in the conference also since yesterday, that has become a challenge. The result is, until very recently, energy and climate were always talked in the same breath. Now, the global North, or if I may use the expression, the West, has decoupled it. Now say, energy is different, is sovereign, different world, and climate is, if you're talking climate, you can't talk energy. Energy, then basically you can talk only about renewables. This climate extremism is actually bad for climate security. Because if you can't have conversation, how can we find a solution? Is bad for climate security, is bad for energy security also? No, this climate radicalization that we see in quarters in the global North is today the biggest threat to energy transition. Because unless we go about for honest conversation where the interest of everyone is taken care of, how do we move forward? How do we move forward? And I give you an example. In my city, I live in New Delhi, we recently hosted G20 Summit. And you know one thing, in G20, we have tracks on everything. We have tracks, tracks means this conversation on agriculture, on medical sciences, on damn everything you name it, and it was there. But not a single track on traditional energy, fossil fuels. They were kept out of the room, completely, energy, a green energy, many tracks. In the final declaration, no mention. And this is G20. I asked some people, because we hosted it, but host does mean that you control the narrative. Because narrative is still controlled by the West. And they say, oh, they don't want it. Now imagine, you are talking, you are G20, you are talking of securing future, but you have no discussion on that. Now the biggest challenge is, the biggest challenge today basically is that the way I see it, that no conversation is allowed on this, that we need to kind of recouple energy and climate. There is no other way, there is absolutely no other way. Number two, this tendency on the part of the global north to have conversation on the energy transition, roadmap energy transition, which is basically the way they wanted. If realizing energy and climate, go to any village in Africa, go to any village in Asia, go to any village in Latin America, these are highly emotional issues and local issues. People worship trees, people worship local sources of energy. For many energy and climate are very deeply integrated the way they live, the way they breathe. But if you think the West has got the solution and they have the template, you either accept it or we are going to make your life difficult. If you are a smaller developing country, we will punish you one way or another.  That's not how we work. Energy transition, different countries, different characteristics. Third point I want to make here is, look Ukraine happened.  I'm just quoting her, she said yesterday. Now the point is that the result was that energy has been weaponized. And you know who has suffered the most? Yes, in Europe you built fortress, you got from the, you replaced your Russian energy with American energy and Australian and so forth. But do you realize that there are three billion energy poor in the rest of the world? Do you realize they are the one who paid the price? Do you realize that you know how many children might have died because of that? How many family budgets might have been disrupted and actually killed? How many people realize that? Can you have discussion on this in Europe? I have tried, trust me. It does work. They don't want to listen to you because they love most as a echo chamber, they love to talk with each other. Now the point here is that, you know, when it comes to, when it comes to priorities, you see, I mean, they can have, they have the right because they have money, they have technology, they have everything. But the point is if we really are looking for solution, that's not the way to do it. Now question is, you know, on a positive note, now what do we do? What to do? I think we need to, when it comes to climate conversations, you know, Abu Dhabi is going to host the next COP summit. I'm not too optimistic, I'm very blunt. We need to basically reset the button on climate. Climate energy transition used to be the very top of the agenda, global agenda, until two years ago, three years ago, honestly, tell me, is climate now on the top of the global agenda? It's not. It's Ukraine. It's crisis in the Middle East. It's Taiwan. Tomorrow is going to be something else. But when it comes to climate, if you want to have results, if you are really worried about, you know, the global climate, you have to reset the button. We need to go back to the table. We need to really rework. Now, second thing is, we need to democratize all these discussions and conversation on climate and energy transition. Obviously, I mean that the process is not democratic. It's not democratic. It's mostly top-down, top-down from the global north to the global south. Yes, countries like India and China, we assert ourselves because we can. But what about these 54 countries in Africa? How many countries in Africa can actually assert? We can be sanctions against them without calling them sanctions. Now, at the same time, I mean, there are many other things to do. De-weaponize oil, de-weaponize it. Gas. You're playing with the lives of the people, the future of the children, the future of, you know, the economies of smaller countries and more vulnerable economies, 80 percent countries in the world, they are energy deficit, 80 percent, they import energy. The biggest trade in the world is actually oil. Oil is number one. Roughly accounts per 60 percent of the total global trade. Now, the point here is that, you know, at the same time, when it comes to issues like, you know, technology, green finance and all that, again, we need to reset the button there. And we re-coupled, again, as I said earlier, you know, energy and climate. And at the same time, is there any global energy order in the world? Where is the order? The world is all united. We are basically, is the polarization that's happening. If Russian oil and gas is banned, if it's sanctioned, Russians will have to find a way to sell it to whosoever can buy it. That means you actually are creating a parallel order. And in India, there was a question this, to us, I mean, if Russians offer us a better discount, you know, we will buy it from Russia. If the U.S. offers, we'll buy it from the U.S. If it's offered by Rwanda, we'll buy it from Rwanda. Oil has no nationality. Molecule has no nationality. We'll just buy it from there. What's wrong with it? You see, that's how it works. And then the important point is everybody is now saying that, you know, rule-based international order, rule-based international energy order, who makes the rules? Who has made these rules? The West. And if you don't follow, then you are questioned. And if you follow, then you have to become a subservient. So what kind of world we are talking about?  So you'll say, who is this man? Where does he come from? We were so easy. So we were enjoying, you know, this echo chamber. But this echo chamber has been punctured. So sorry for that, if you think that's the way you feel. But the fact is we need a new international energy order. Number two, we need a new international energy governance. And number three, we ideally need a new global organization, which is basically can play some role in situations like this, circumstances like this, can step in and play some role. And my final point is that for God's sake, de-weaponize oil, gas, and energy. It's important. There are many other things you can play with. Weaponize them if that's important. But this is something 3 billion energy poor on the planet, they need it. So for their sake, if you have any love for humanity, any love, and West talks about humanity and whatnot, I think de-weaponize it. Let oil and gas and these or all these commodities flow so that people can at least survive. Unless and until they survive, how can they really worry about things like climate? Thank you very much. Thanks for your patience. Thank you.


How was your meeting with Prime Minister Narendra Modi as of now? It was an outstanding meeting. I couldn't have asked for anything more. First, I was an honor to have a chance to speak with him, clearly with his leadership and what he's done to create a really strong balance between industrial policy as well as trade policy. It makes it an ideal opportunity for companies like First Solar to establish manufacturing in India, and his commitment to ensuring domestic capabilities and ensuring his long-term climate goals and objectives with focus on energy independence and security. I think the alignment of what he's trying to accomplish couldn't be better for companies that are looking to manufacture in India. And I think the enablement of an environment that is pro-business is just more opportunity for us to be successful to help India achieve its climate goals. India is taking a leadership role on a global stage as far as renewable sources of energy is concerned. How do you look at the policies of India's press climate change renewable sources of energy is concerned? I think if every country could embrace and emulate what India has done, our ability to hit the long-term climate objectives that are established in the Paris Accord won't be a problem. I think India's leadership as it relates to being very aggressive and his commitment towards 150 gigawatts by the end of this decade and enabling policies and support of that and enabling domestic capability to ensure the most competitively advantaged and lowest cost way to deliver renewable energy into the market or should be replicated across all major markets around the globe. And we've also seen that various measures have been announced in India to boost the renewable sources of energy the solar equipments primarily. Do you think this will help attract investment specifically from your side as far as manufacturing capacities are concerned in India? Absolutely. So I think like for example the production linked incentive that has been put in place is ideal and it's you've seen even just with the recent announcements with the number of companies that have applied for that the response has been overwhelming and so I think that type of program is ideal to help US manufacturers to come to India in particular and we're hopeful that we'll be successful in receiving an award or a grant through the PLI. But as I told the Prime Minister is that our commitment to India and wanting to be part of the journey and the vision that he set out while the PLI is important it's not one that we would forgo. We want to be part of this opportunity and be part of this journey. Also India has started this initiative called the International Solar Alliance. We have big countries becoming a part of this Solar Alliance. Do you think this International Solar Alliance will complement your investment plans in not only India but various other countries as well? Absolutely so yes and it will help us think through opportunities. One of the things we want to do in India is not only to be there to support the domestic market but we want to be a technology leader in leveraging capabilities that India can provide and then also compete on a global platform and to participate and export into international markets. That type of alliance and opportunity further enhances that potential. Thank you so much for talking to us. Alright thank you very much.


I'm John Furrier, the founder of SiliconANGLE, and I'd like to introduce Amar Kapadia from Evolt to kick it off, and we're going to start the debate right after this. Good evening. Welcome to Evolt. We are your hosts for tonight. And my name is Amar Kapadia. Before we get started on today's exciting topic, I know Randy has kicked off the storm with the open letter. I've never actually seen press at a meet-up before. So it should be exciting. Just some quick logistics. Restrooms are out that way, and they should be open if they aren't, you know, let one of us know. There's Wi-Fi instructions and food and drinks. Please enjoy. A quick brief, 30 seconds on Evolt. Evolt is a Seagate subsidiary, and we are in the cloud storage business. We have several software as a service and offerings. And if you think about an enterprise, and you see any on-premise storage software or infrastructure, that's on our target. Those are the things we are looking at in terms of adding a dash as a service. We are also active in OpenStack. We have contributed to Swift 3. Randy, please take note. It's a S3 API on top of Swift, and we are also involved with other projects in OpenStack. So without further ado, I'm going to hand it back to John, and John can introduce the panel. Okay, thank you, Mark. Appreciate it. SiliconANGLE's dedicated coverage to going out to the action is really what it's all about tonight. When we cover the OpenStack summit in Portland, one of the things we mentioned on the Cube is the new standards process about the community and documenting it all, and Randy Baez kicked off the great conversation at USCON and we want to continue that coverage. We want to pass it off to Randy Baez of Cloud Scaling, Mattis, and Joe Arnold, our host here. Guys, take it away for the great API debate. It's an open discussion, right? I think Randy kicked off this discussion in a way that only Randy Baez could do in the community, I think. So I think we owe him a debt of gratitude for being able to create so much momentum and dialogue around this issue. And the issue is how important is it to be compatible with another set of industry APIs that are in broad adoption? And so the format of tonight's discussion will be to talk about this issue, ask a lot of the important questions, and the format will be, we're going to kick this off, introduce each other or do introductions of ourselves, and then I have a couple of questions that we'll kick off with, but then I'd really like to ask the audience to participate and ask the questions that you have burning desire to ask from between Boris and Randy on the topic. And we'll go for about an hour here, and we'll see where the sparks start to fly. So briefly, so my name is Joe Arnold, and I'm the CEO of Swift Stack, and what we do is we focus on the object side of OpenStack, a project in OpenStack called Swift, and we built product and services around that. Before I was doing that, actually I had the privilege to work with Randy to get inducted into OpenStack, but before that I was building out platform services on top of Amazon, one of their early customers. So that's kind of the background I'll hopefully lend to the questions as they come up. Boris, can you care to introduce yourself? Yes, my name is Boris, I am co-founder and chief marketing officer at Mirantis. I would imagine that a lot of you folks have heard of Mirantis, if you've heard of OpenStack, hopefully you have, that means I'm doing my job. We are probably today the largest systems integrator around OpenStack, and we're also a technology company. And I guess to kick it off, opening remarks I wanted to also thank Randy, he's kind of been historically the biggest visionary behind Cloud and one of the first people to kind of hop on to the OpenStack bandwagon. Some of you may not know this, but this guy was actually the guy that to a large extent influenced our existing company direction. So a lot of the things that we're doing in OpenStack today is because of him, and probably now he's like, damn, why did I do that? So, you know, just, you know, two years ago nobody knew about Mirantis and OpenStack. The other father of the OpenStack is Randy. I couldn't have envisioned, you know, sitting myself next to this guru. But yeah, thank you. So now please introduce yourself. Okay. Slightly embarrassed. I'm probably fleshing red, but that's all good. I'm Randy Baez. I'm the CEO of Cloud Scaling. I'm a longtime infrastructure guy, which I think is a little bit different in a lot of this particular ecosystem. I grew up on infrastructure. I've been doing it for 22 plus years. Got a lot of experience on systems, network storage, like the whole stack, building data centers, really all those aspects. So building infrastructure clouds has hit my sweet spot. Really where that started to become something I focused on was when I was VP of Technology Strategy at GoGrid, kind of in a CTO style role. They're kind of leading the direction of the architecture and the platform. And then that really morphed into cloud scaling, which in our early days was a professional services business like Morantis, where we were focused on helping people with strategy and architecture and then eventually large scale cloud deployments, two of which are very relatively famous. One was Korea Telecom, which was one of the top three cloud stack deployments and also one of the first Swift deployments, certainly the first Swift public cloud deployment in Korea. And then the second of which was a company called Internet where we built the first compute cloud and Swift cloud. Actually, all three of us were involved with that. So we're a very early proponent of open stack. We are part of the launch. Cloud scaling was part of the launch in summer of 2010. And we're really the only one of our competitors out there today who was part of that initial launch and has been deeply committed to open stack since the very beginning. So sometimes I find it a little funny and then people will easily misinterpret my intentions and sort of seem to feel that I am not, that I don't love open stack and nothing can be further from the truth. My entire business is built around open stack. We've pivoted over to become a product company that offers a product based on open stack. I am deeply in love with open stack and I want it to succeed and that's why I have an opinion and that's why I share it. So let me start by asking, I think one of the first questions when it comes to API standardization and adopting somebody else's standards. And Amar Kapadia, the guy who just introduced the meetup from Evil, wrote a blog post yesterday talking about some of the trade-offs where when you begin to standardize on a set of APIs, particularly one that you may not necessarily control, that stifles innovation where you can't make changes to the services or the product offerings that you want to offer. Working on erasure coding in Swift, for example. And we may expose new API elements in order to add that functionality. Networking with Quantum, or I guess not Quantum anymore. Neutron. What do you have to say to that argument where choosing another API standard limits your ability to add functionality into products? I'll start with Randy first on this one. So there's absolutely a trade-off between standardizing and innovation. I think we all know that to claim there isn't is kind of nonsensical. But I think what gets missed a lot of the time is that those things kind of follow each other.  HTTP follows TCP. So it's not the zero-sum game where I'm either all innovating or I'm all standardizing. It's a much more nuanced kind of situation. And I think when we look at something like the AWS APIs just to make this more concrete, it's a little ridiculous to say that they stifle innovation for a couple of reasons. One, they're only one of the APIs in OpenStack. Two, they've been extremely stable. So we're not talking about APIs that supposedly Amazon controls them, but they very, very rarely break backwards compatibility. And so we're just talking about them adding new feature functionality in the APIs that aren't exposed in ours so we would lag them. Big deal. Who cares, right? It's a fast-fall strategy anyway. Embrace and extend. No big deal. So, you know, I think it's a valid argument. I just think it sort of misses the mark, which is that in many ways we can do innovation and standardize simultaneously. Of course. Yeah, so, you know, my take on it is that it's definitely noble cause to support cross-platform API compatibility. And I don't think when we're talking about the API compatibility necessarily has to be Amazon, although Amazon is definitely the most dominant mover there. But it's... How do I say that? I'd like to level-set, I guess, on the argument a little bit first, because there is a big difference between taking somebody else's API and adopting it as your native API. Any system, in my opinion, always has to have its own native API. And having a native API does not necessarily preclude you from actually, you know, going ahead and making some sort of effort to be cross-compatible with other platforms. So, in the original kind of a manifesto that Randy has produced, I think, it wasn't exactly clear what we're talking about. I was talking about just throwing away the native API behind the stack. No, it was absolutely completely crystal clear. I've had to go back and read it multiple times now because people made those kinds of claims. And in my bullet list, I very clearly did not say that. Moreover, you even put in a follow-on letter, which I think is... Which was even more clear. I think it's an indication that it's only okay of me to misinterpret it because everybody misinterpreted it to the point where you had to put a follow-on letter afterwards. So, let's be specific about a couple of things here. So, there is a statement in the project technical board. Sorry, what's the name of the technical project committee? TCL. Technical Committee. Technical Committee, right? That said, we're going to support the one set of APIs, the OpenStack APIs, and everything else is going to be outside of that. So, question for you. Is the statement that the AWS APIs need to be an official thing as approved by the technical committee to be officially supported and maintained? And is that really what the crux of the debate is here? Well, there's two elements. I mean, I'm okay if they're outside of the core. Like, I don't actually have a problem with that. But the first thing I asked is for the community to stop sort of saying like it's us against Amazon, which I think is just a totally ludicrous type of attitude. I mean, it's like saying it's OpenStack versus VMware. I mean, we need to go co-opt these systems. OpenStack is going to win by beating VMware and Amazon at their game, which means co-opting them. I mean, that's my belief. And so, I think we should support the vCloud Director API in the same way we support the AWS API in the ecosystem, whether it's in core or not, I don't really care. But the second thing that I think is more important in a way is that there's sort of this attitude of that Nova has a native API.  If you read my first email, you'll see very clearly that the native original API in OpenStack is the EC2 API. That is what it was built with. The Rackspace API was added later and it was checked in called Rackspace. And then it was renamed to Nova at a later date. And it's not an unopinionated API. It's a new different opinion from the AWS API. And that's a huge problem because it constrains OpenStack in as many ways. And people say, oh, Rackspace contributed. No, they contributed specification, not the code. It was actually done by Anso Labs. That's number one.  Like, there's a password reset capability in there now that many people probably don't want or care about. You pull that out and it impacts Rackspace's public cloud. Now, if we really want a native API in Nova, we should say, what does it need to be? What purpose does that API solve? And we should build it from scratch. Boris, in the core or outside of the core? Definitely outside of the core. And I would like to kind of... I feel that the whole argument is a little bit flawed because it's based on the premise that the OpenStack community historically has been very anti-Amazon. And frankly, I don't see any of that. You're advocating, you know, the community embracing Amazon, but I don't really see any manifestation of a community kind of going the other direction. There are indications if you're sitting from far outside and kind of observing that, yes, OpenStack is kind of an anti-Amazon competitor, but I can completely... I understand it. And the reasons for it is first, it was started by Rackspace, effectively. And yes, this API was called Rackspace API originally, but since then, the situation has changed dramatically. Rackspace is no longer very heavily involved in any of the stuff. In fact, Rackspace is not even in the top five contributors. They're smaller contributors to OpenStack, in fact, today than even Mirantis, a much smaller company. Second, it's because OpenStack community never really was going around like everybody else and screaming, or we're out there to support Amazon API. And the path for that was really kind of laid by guys like Eucalyptus. And the Eucalyptus guys, they took this approach, they understood they cannot be OpenStack, so they have to kind of hinge themselves on Amazon and create this marketing push and say that we are not OpenStack, so we are Amazon. That all predates OpenStack, so that's not how it went down. Eucalyptus predates OpenStack, but Eucalyptus has moved to embrace Amazon and the whole PR push. That's how they started. That was their entire business model from the very outset. There was a big PR push. Wait a second, let me go back to it. They started as, you know, yet, okay, maybe, but Eucalyptus made their strongest push around API compatibility when they made this big PR spiel where they supposedly signed an agreement with Amazon where Amazon has licensed them the right to actually use their API. And there was a big shebang around it and the whole thing was just a PR stunt because they can't really license a public API.  So this whole momentum started and OpenStack was just quiet.  They don't need this kind of PR stunt. So there was a whole response like prior to that where Citrix left OpenStack and went to the Apache Foundation and they made all these claims about AWS compatibility at that point in time.  So you're talking about an anticlimatic kind of thing. But that thing is a long time ago and that's completely different. Where Rackspace is today, in terms of the OpenStack development velocity that's like a thousand years. And you can't take it. So this is debating timelines and I think you know that's going forward, right? So I guess I'm going to ask one more question and I'd invite whomever wants to ask the next question please start coming up. I think there's a microphone, a mark. Can you help get a microphone whomever wants to ask the first question? So I'm going to beg the proposition or beg the case, right? Is what's important about being Amazon compatible? Is it about the API or is it about that ecosystem that Amazon has created? Where if you get plugged into the Amazon cloud you're surrounded by all sorts of other services that you can consume. Some from Amazon, some not from Amazon by people who have set up shop in there and selling platform services. How much does OpenStack really, how much does OpenStack deployments really gain if they don't have that ecosystem? How important is just the compatibility from a business perspective, from rollout, from hybrid clouds. How important is that for what you're seeing in the field with customers to be able to transition back and forth between those two environments? Tactically speaking it's not important and that's what we have seen in the context of now over 50 OpenStack implementations. This is early days, strategically speaking the importance is going to grow. But I do not think that you can ever really reach the cross-platform compatibility with two independent ecosystems innovating and building their native APIs independently. Anybody who is in their same mind and is trying to run an application on top of OpenStack that is running on premise and maybe burst into AWS they will use some sort of proxy in the middle. There's plenty of libraries you can do. You can use something like Fog, you can use J Clouds and if your application is dependent on two systems you will always have a guy inside and a library inside, a guy responsible for that library and that's going to be the single kind of a check point that you control. You will never trust two communities to maintain compatibility and just run across. I mean APIs don't matter. I don't know why we're stuck on this and I kind of made the point that it's about the architecture to begin with and I don't understand why people don't get this. APIs always expose a subset of functionality. It's impossible for them to provide the entire richness of the architecture that they basically talk to you. They're an application programming interface. So they inherently are a contract to the system behind it. So right now if you go to any of these clouds as a for example and you spin up an instance there's no way to guarantee that instance comes up in any amount of time. You can't specify it with the API. You get no SLAs from the provider whether it's a private or public cloud. There's no time between a few seconds or a couple hours, right? So if you build your application even using an abstraction like J Clouds and Fog and it assumes because it's been running on AWS that instances always come up within 10 minutes and you go and you stick down on another cloud and the behavior is different. You're screwed because there actually has to be a way that you've got a reference architecture that you model against and then you're measuring how that behaves so that when you're actually doing the cloud compatibility you're doing it based off of the behavior of the system not the APIs, right? APIs can be semantically equivalent. If you look at Google Compute Engine and AWS they're the exact same API except the APIs themselves look totally different because the syntax is different the semantics are the same and they expose a very similar architecture behind them. I agree.  And in fact you wrote a blog about that and I said I agree. That has a question here for us. Okay, I thought I'd... Okay, I won't tap. I guess it's not for us, okay? It's for the... Sorry about that, folks. Okay, so let's just say for argument's sake that it was a good idea to mirror the AWS APIs. I can imagine how that might make sense possibly for compute, storage, some of the basic components that applications use. But it would be absolutely insane for the entire community to say, okay, you know, Cart Blanche, we're gonna go replicate all of the APIs Amazon ever does. They're a for-profit company trying to pursue their own interests. There's no freaking way they have the best interests of everybody else in mind. So where would you draw the line? So this is kind of a long lines of Amazon isn't asking us to use them as a standard for proliferating projects and services. It's not gonna stop. It's not only that, but let's just say that we all of a sudden said, okay, let's go replicate their APIs. Don't you think they'd find that amusing and perhaps use that in some way? Of course. Yeah, that's exactly what Randy was talking about, basically. That, you know, you can't have... If we're talking about native API, you can't have two systems that have the same low-level native API. You can have an awkward attempt at it and then it'll boil down to just you kind of mimicking the system awkwardly and exposing similar same API. But I think today we are still way too early along the innovation curve. Both, it pertains to Amazon and it pertains to OpenStack squared to actually really even concern ourselves so deeply about those issues. And the reason why I think the community today in OpenStack is not really proactively embraced Amazon API, even embraced the Amazon compatibility issue because the stuff that the OpenStack community is struggling with today is much more basic and concrete.   So why are you starting to think about this cross-stuff compatibility when it's such a challenge to just deploy an OpenStack cloud and make it work? I mean, I think that it sort of gets to a pretty deep divide in our perspectives. You know, I would say that OpenStack is more akin to the Linux kernel and the idea that it'll ever be a complete cloud operating system is completely ludicrous and it's really a framework that will allow us to build cloud operating systems that do different things. Just like you can take the Linux kernel and wrap a distribution around it and run it on monovista, on an embedded appliance, or you can run Kray Linux on a super computer and everything in between. And I think it's really a mistake to pretend that OpenStack will be something that's going to be this single unified reference architecture that, you know, is totally interoperable because in doing that interop you're going to reduce innovation. It's the same kind of problem as having the standards-based solution because you have to say that this drive behaves like this just drive. It's inherent in the issue of creating interop.  And so the thing is that if you sort of give up that OpenStack isn't a complete cloud operating system, if you say it's just a framework and I'm always going to have to add stuff, then this kind of notion that people should stop innovating around like the AWS APIs doesn't make any sense because there needs to be room for people like me to say look the best way to deploy OpenStack successfully in production is via this model that I developed that does leverage the AWS APIs and AWS as a reference architecture and then that becomes the AWS flavor of OpenStack and everybody else in the community is allowed to do what they want to as well. And I have absolutely no objection to any of this and I think that there should be an AWS flavor and I think you guys should take the lead and I think you have been doing that to a large extent already and build this AWS flavor but I guess the point is, you know, how much sense does it make to focus on it right now and I think that I agree with you completely that OpenStack will never be this one monolithic thing. So I didn't say focus, I said embrace, I said stop pushing away. But that goes back to my first argument that really OpenStack I didn't have a chance to rebut that. Okay, well go ahead and rebut that but I remain convinced that there's no kind of opposition in the native opposition in the OpenStack community against AWS and then again what does it even mean? Like the open source community just go ahead and commit code and you drive it and everybody drives it. Absolutely. There's no one guy that says we're going to be against AWS. Code rules. So make the code and you get AWS compatibility. Absolutely. But that's not the that's not the point. The point is is that in many ways Rackspace poisoned the well on this, right? I mean, you know the Rackspace APIs aren't in there as an accident. It's a very deliberate move. There was a decision as much and so I think Randy's point is saying, hey, let's at least embrace this. After that they were the top number one contributor until recently. Granted, I'll give you their influence in the community is waning so it is a good time for me to go frankly in some ways kick them in the teeth and say look I think we were led down the wrong path here which is what I did. Jeff Arnold has a question. I'll repeat it since he's not near the mic. You'll go over the mic. So I guess my question my question is did politics constrain Linux? I mean Linux only succeeded because they started off saying we're going to do a politics an open source politics operating system and without politics compatibility Linux would have never got accepted because it would never it would never have been an easy safe adoption move from Solaris or HP or X or whatever. So this conversation so far has completely ignored customers, completely ignored the ecosystem.  So nobody has said what's the cost to the customer of having these incompatible APIs. Randy is right in saying that we can have multiple APIs but I would like to be able to take the Netflix OSS and just run it. And I can't. Now it's not just a simple saying well let's full support for the APIs. It really isn't that simple. And the reason it's not that simple is because we've poisoned the well in two ways. One is we've poisoned the well by putting in APIs which have constrained the system in certain ways.  Too much variation. Too many options. Too many extensions. And as a result it's very very difficult and I speak of somebody who's waiting for a company that's building plugins and building components to go into OpenStack. It's very difficult to create a subset of that collection of all stuff we built which actually provides the right level of semantic compatibility. Yeah so why is it that we can't as a community say hey running Netflix OSS on OpenStack is an objective. And then make it happen whether it's on the damn OpenStack APIs or not. It should be. And while I've got the mic I'll say one of the things we recently celebrated the third birthday of the project. And a lot of people were very happy. Look how much we've done. I was disappointed. In three years we have not even replicated the basic services through AWS in 2009. Just the services. Where's elastic load balancing? We don't have basic cloud services. Come and talk to me about the stifling innovation when we've actually out-innovated AWS. Until that happens all I want is to get a really kick-ass open source system which meets the basic functionality. I think that though this comment is really not about the compatibility or compatibility of APIs or embracing AWS basically what you're saying is that you're unhappy with the existing structure of how the development process and how the ideas bubble up to the top and get implemented in OpenStack. It's too distributed to many organizations involved and they're getting poisoned from all kinds of different sides. Instead you should have more control more of a kind of benevolent dictator mentality that was present in Linux and is absent in OpenStack. And that's the argument that I guess that you're making. It's a whole different debate and I have my opinion on that as well but you know. I think you bring up a good point around the kind of the undercurrent of customers and using these services. And I think where at least each of our companies were involved in just working on our customers' projects and we're contributing back as we're meeting those needs as functionality develops. I don't know about what you guys are finding but at least what we're finding is that customers are adopting OpenStack because sometimes they have some pretty unique requirements. So in terms of what you guys are seeing, how important back to that question, how important is it for having complete compatibility between what you're developing to solve some unique problems at the customer's site to bridge that out to the public environment or to answer Jeff's question I guess directly. I think what you said is basically OpenStack and you mentioned that as well that OpenStack is really not a product it's more like a framework and you can build all kinds of different clouds out of it and because it's early and because it's being innovated against so much this variability is just great and there's so many different configurations and yes I agree that's definitely a curse and if you come into OpenStack and you expect to download OpenStack packages and get where everything just works and all the decisions have been made for you then you come into it with a wrong mentality ultimately yes there will be different kinds of OpenStack. There'll be cloud scaling OpenStack, there'll be merantis OpenStack there'll be different opinionated kind of implementations all that and then opinionated to a different degree but the reason OpenStack succeeded to begin with I think is because of that flexibility and because that's why everybody started embracing it because there's an enormous spent-up demand there for some sort of framework that gets you 80% of the way to the functioning cloud and allows you 20% where you can build plugins and make decisions and change around the API and that's really been the primary driver behind OpenStack's success so far. Alright so we have an online question from Craig Tracy and he asks what I have not heard is how API adoption will help or hurt the OpenStack adoption curve so while embracing these APIs help or hurt like is it more important to create this alternative ecosystem that people can latch on to or well why wouldn't we want the OpenStack ecosystem plus the AWS ecosystem plus the GC ecosystem plus the VM where like why wouldn't we I can't imagine why we wouldn't it's a matter of focus right in terms of what came into it. EC2 APIs are in there today well for example like Amar just mentioned the S3 API for Swift something that we track as well and we've been adding architectural components in there so we can better support the S3 API because architecture maps down to that API but we only do that once we hit a customer who has that issue and now we need to start folding that but you are hitting those customers who have requirements around the S3 API we are pulling people off of S3 is what we're doing and so we need to take the fire hose from over here and point it over here into their private environment and so when they do that they have specific tools and they have specific use cases that they're using and if we need to we'll patch them up but we'll also they'll also new applications use the native API because that's what they want we see the same in our customer base a lot of people want the AWS API so they can migrate off and it eases that but they also use a lot of the open stack APIs natively and we allow them the choice of using whichever one works best for them and it's interesting because it turns out that in many ways those two different opinions surface in some strange manner so if you look at the EC2 API things like EBS or VPC are a subset of that entire API and it's networking functionality that's part of the compute API and in open stack there's like nine different APIs and you kind of got to know how to talk to each different one and it just winds up looking very different I would like to add one thing before we move on just kind of from our perspective and the reason why I'm kind of you know DED how would you say it like putting less accent on the whole API and getting an open stack today because in our maybe skewed experience so far we've seen two kind of entry points into the customer where they are embracing open stack so one is you know they're just green-filling an internal cloud or they're trying to maybe get rid of VMware and the Amazon in that case is not even in the picture they've never touched Amazon you come into open stack and you know it works and they buy and it's an easy sale now we've had a number of enterprise customers where we try to enter at a different point the guys that have been using Amazon for a long time and they have a bunch of applications that are written to leverage Amazon API the whole ecosystem is inside and they come in and they're like Amazon is kind of charging us a lot of money we can build our internal cloud open stack in that case what happens is these guys they do research around they look at cloud stack they look at open stack they look at eucalyptus and virtually every single case that we have seen so far they stick with Amazon anyway simply because of Amazon's current superiority over all the other solutions so would have helped if we would have said that we have this API compatibility no because they use the 90% of other features that Amazon has that none of these open stack or cloud stack eucalyptus systems have we're seeing different we're seeing a ton of people cloud back from Amazon can you state your name in the company you work for so it's an interesting conundrum because in one hand being open means that you can allow anything but at the same time we can't support everyone every API it's kind of just making money but in the other hand you don't have a dictator who would be on rails where you could say I'm just going to cut it and just use one I wonder if there's not a solution for this whereby we can use the customers and use D so the forest API we are right now we instrument them and collect data then we can figure out what the customers are telling us in addition to surveys and so on and in that way we can make decisions that are not just emotionally involved but based on the data so I'm actually totally in favor of this the problem is is that you see a lot in the community the fact that people are like oh I'm not sure I should use the EC2 API because I should use the native NOVA API except the native NOVA API is the Rackspace cloud servers API so there's already inherent bias if we had a different low level API that didn't have any opinion to which there was the Rackspace API the EC2 API and whatever else then we could let the market decide and we could use that real data so there's inherent bias that already exists because the Rackspace APIs are somehow the native APIs but I think that realistically I agree with it's been kind of poisoned but this is again going back to my original argument but I think that they tried to influence it they did open their APIs the community started to innovate around their APIs but I mean it has gone so far now that it just the former Rackspace API it's gone for open stack and I'm not saying it's a perfect API it probably could be improved and I'm all for improving and making a better native API but I disagree with the premise that the existing open stack API is Rackspace API and it's somehow by that today inherently poisoned I have a question David from Puppet Labs my question is something that has been touched upon at all in this conversation is governance and that's where AWS is very different from positives for example or in a long way it feels more like in the early days asking Linux to adopt the Win32 API, namely an API in which the community has no input, no way of getting any changes in there from a technical point of view in AWS to really make a standard API you would want to have some sort of discoverability in there but there's no way no chance in hell that anybody's going to convince Amazon to put that in there and that's also how the open stack API even though it used to be the Rackspace API is a very very different animal because it's now governed by the community and there's an open process around it and foundation and all these things that make this really a community driven approach whereas AWS is a vendor driven approach it's a great point we notice it from the Swift world they don't rev the version number and they change the API I mean they do that because they can well I mean to range this point AWS API is pretty stable because they have the ecosystem around it they can't afford to change the API just like that because they will kill the ecosystem it's more stable than open stack when you go talk to the Eucalyptus guys when you go talk to the Eucalyptus guys I think they have there's a bit of chasing that they're having to do it's always chasing but then I think we're missing the whole point the point is embrace and extend and allow people on Amazon to easily get off on to open stack or to build hybrid clouds that are connected to open stack we constrain things and we say okay we're only going to do the open stack APIs we inherently limit the total addressable market of open stack I've heard this ridiculous statement about how very few of the open stack deployments are using the EC2 APIs according to the user survey it was 30% 33.5% but that's a third and that's a lot in market share we don't want to shut out those people we don't want to shut out people who want to have AWS compatibility just like we don't want to shut out people who want Google Compute Engine compatibility and VMware vCloud Director compatibility we want all those people to come over and use open stack and one of the best ways to do it is to support those APIs as well and it's okay if they're outside of core and then allow an on ramp on to open stack I mean don't we want open stack to win we have another question so my name is Victoria Lipschitz I've been actually running services company that's been doing open stack work funny enough actually before Mirantis did so it's been a long time but these days I run a different company actually a PaaS platform as a service company and that color is a lot of my perception around the issues that we were having today so I want to pick up on the theme of community and also of interest so when we try to debate what's in the interest or against the interest it's the first question is whose interest and what are we optimizing against or for so open stack is a collection of bad fellows who are each by larger commercial entity who made a conscious choice to embrace open stack for their commercial interest right as opposed to other alternatives now looking at from an ecosystem perspective we have at least six ecosystems we have Amazon for sure we have Microsoft we are fast having Google coming not just with the Google App Engine but also underlining cloud as well and then in a private world we have at least Citrix, VMware and open stack right and probably more so here is six of them and let's assume we are all competing for consumer dollars so open stack community collectively actually does compete with Amazon so when we talk about friend or foe almost by definition of the structure Amazon is a foe of anybody who's commercially betting on open stack or a frenemy well I mean a frenemy a friend and an enemy we can argue about the best way to fight and the best way to fight might very well be to obtain their customer base so here's a question that I have for the panel given that the name of the game is optimized the interest of open stack community where the focus should be late and speaking of API I find it interesting that it's framed as AWS compatibility debate but AWS is neither compute nor storage it's a tremendous amount of web services APIs that are more than what pause platforms tend to provide than what compute and storage infrastructures are so the question that I have of community do we want open stack compute and storage the best that it can be competing with EC2 and S3 or do we really want to how are we going to play that game one level up that's a great question right so I think Boris touched on it like Jcloud and other provisioning low level APIs there's platforms as a service companies like the one that you're building now and you have engineer art and haroku and dot cloud and then the ones from VMware and Red Hat they're all producing them I guess they got spun out in the pivotal so why why not use that as a mediating layer. And I think Rob Hirschfeld from Dell on the chat also mentioned between automation tools between Puppet and using Chef and tools like that. Why isn't the abstraction layer up there rather than why are we mucking around down here trying to bridge API compatibility? Why don't we rely on that layer above that infrastructure to do that abstraction for us? Okay, you go. So just one thing real quick. I want to push back just briefly on some of what you said. You know, when we were at GoGrid, we looked at, when I was at GoGrid, we looked at Amazon and we said, man, these guys are amazing. They're going to make our business. They're like educating all the customers. They're building this massive cloud. Some of those customers are going to peel off and we were like, yeah, we're working in cooperation with those guys to make the pie as big as fricking possible because if cloud computing is something that displaces enterprise computing like that displaced mainframe computing, what if it's 10x bigger like enterprise IT was than mainframe IT? We're talking about a massive, massive market. So just driving the whole thing as quick as possible, as fast as possible and making customers as successful as possible is all the fricking matters. Now to the issue about why can't we bring a compatibility layer like J Clouds or Fog or something like that and run it, the thing is that, you know, I've done a lot of these deployments on Amazon Web Services.  I could do all 100 servers by myself, spin them up in five minutes, run the cluster, spin it down. Clouds don't behave the same, right? I talked about spin up times earlier, but there's other problems too. Something like Chef or Puppet interrogates the system that it runs on and it determines what its IP is. Like in Chef, it's called MyIP. If you've got one network interface, which one that, which IP that is on your box is very apparent. If you've got two network interfaces, it's not as apparent. And if you allow people to have arbitrary numbers of network interfaces like you can with a V Cloud, then, you know, which one is MyIP and which VLAN is that plugged into? And how the Frick do I even find that stuff out? Because Chef is going to have to do a whole lot more heavy lifting and figure out what the front end VLAN is on a V Cloud as opposed to AWS where there is no choice. There's just a Frick in network interface and that stuff is all over the place. It is all over the place. You know, early customer for us that, well potential customer with Skype and they're telling us how they would take their stuff off of Amazon and they put on bare metal and they suddenly got two, three X performance and it was the same basic configuration. Now here's the problem, right? If your pass or whatever assumes that the box is this big and then you move over to this cloud and the box's performance is half or 25%, then suddenly like all of your logic that's scaling the system could be in jeopardy. So these things that just because you have semantic equivalence on the front end of a cloud doesn't mean you have architectural equivalence and that is a huge problem. And those abstractions cannot fix that problem unless there are better APIs that allow us to like, you know, measure the resource in an accurate way. So then what about the projects that are more pass oriented? With what we're seeing, you know, for example, with the Swift API, the API maps very directly down into how the architecture works. And so there's some slight variations in how things are done with S3. Absolutely. And then that's not, I mean, you have, I mean, it's not, there's the provisioning APIs, right, which would be great to have compatibility between, but then there's the other ones like that aren't necessarily provisioning APIs or services APIs, you know, between like Keystone. What's the, what's the ADBS equivalent of Keystone? It doesn't matter, right? Because here's the thing, right? If you go and you measure Amazon Web Services, like revenue streams, and which are a measure of the adoption of the various services, that's not some even usage pattern. It's a power law distribution curve where you've got EC2, and you've got S3, VPC, EBS, ELB, something like that. And then there's this long tail, like I haven't encountered one customer using Dynamo DB, not one.  All we care about is the fat end of the tail, and replicating that to make it good enough so that people can get off of AWS on the open stack. It's like a no-brainer. I don't even understand why it's contentious. It's ridiculous. I think we maybe got away from the question a little bit that was originally asked, but I think you touched upon it. I think my, I mean, in general, it's always better to interface with a low-level API of a system. If you have a choice, you want to be able to do that. As soon as you move just a little bit up and you introduce something like Fog with J Clouds on top, an abstraction layer, and you start bursting between the two environments that have different implementations, you start running into all these kind of incompatibility issues that on the surface are not apparent, but once you start doing it, they will come up. And the higher up you go, if you start moving higher up into kind of a pass-level abstraction, then this all multiplies by as an exponent, basically. Any more burning questions from the audience? One more? Yeah, come on. Thanks for this effect. I mean, I torrented what you just said that I think open stack is going to be more than just a foundation. It's going to become a full stack eventually that will get optimized down the stack, in the middle of the stack, and then up the stack. And that whole stack is going to be the ecosystem that we're trying to create. Now, as far as interoperability, I think, you know, to make it right, it has to work on its own native API. And the native API should be optimized for the system itself. For the interoperability, it's no different from what happened in the database world where you had Oracle building its own API, Sybase building its own. And then people came up with ODBC and then JDBC and they, you know, built reasonable level of interoperability, but suggesting that Sybase should win because Oracle's native API should become Sybase's API. They're building off of SQL 92. If there hadn't been an agreement on at least some base foundation syntax, the syntax of all the SQLs are almost exactly the same. That's why an ODBC or JDBC is possible. If it wasn't for that, if there wasn't some baseline syntax, you'd be talking about huge differences like here's a JSON database, here's XML, and things like ODBC would be tremendously harder to do. Well, I hear you, but the counter argument to that is that what makes Oracle a winner, you know, in many, in many cases today is not just the SQL itself, but the, you know, PL SQL and all the other things in stored procedures, which are a lot more powerful and optimized to Oracle engine. And so it's not interoperable. Exactly. But, you know, but for interoperability, those who care to use the subset, and we should do the same thing. And there will be people who will do the subset that will talk to both. But if you want to solve the complex problems that you yourself just mentioned exists, you have to do it based on the based best architectural decisions that are optimized for the system itself. So the native stuff must be native and different. But for interoperability, that will happen. We will all drive it because we have to, we have customers who are coming in with that requirement. And, you know, people will build it. Yeah. Excellent point. One more. Let's do one more question. And then we'll wrap this up. Thanks. Sorry, Dave, you already got one. What's that? Hi, David. We're all winners. Hi, David Bernstein here. I did, you know, when other industries have gotten pretty mature, they have served customers well with with standards. And there's been several of them.  And there's they're still innovation. And yet, there's lots of different standards. But, you know, that has served customers well. I know that a lot of customers are nervous about AWS APIs or other APIs, not so much from the legal side, but maybe just how do they specify what kind of cloud they want? Right now, governments and big companies are used to specifying, you know, standards to buy stuff in RFPs. Do you guys think that we could help the adoption of clouds in mature, you know, markets like governments, enterprises who want to specify this by using, you know, standards in this equation somewhere? I think that this is a point I've made many times, I think that definitely standards are good. But standards are really only possible when we're talking about the industry or rather, you know, even specific technology or sub segment, where there hasn't been very much innovation. And I talked about this before, it's like a lot of people, they compare, you know, infrastructure to the outlet on the wall. And the idea is that, you know, it's like, sometime down the road in the near future, all of infrastructure is just going to be standard. And you can just, you know, like plug in your application anywhere and it'll work and everything's commoditized. And this electricity thing, it works, but there hasn't been any innovation in electricity in the last 100 years. But the infrastructure market is so dynamic, and so much moving forward of such velocity, that you simply can't create a standard. You create a standard and then Amazon creates a new service, and open stack spins up a new project, and then you make a new API, and you're done. And that's all that is pretty plug and play, right? I'm sorry. Well, I mean, the thing is, is that I think we're still sometimes I feel like every time we get into this discussion, we wind up, we wind up in the whole zero something again, there's been tons of innovation in electricity, right? I mean, solar power, you know, different LEDs, different to standard. They can standardize one thing, you can standardize like the networking protocol, but you cannot standardize a cloud API, because it's too high level, like it's too, it touches upon too many things. Is it too much innovation happening around there? Okay, I think let's we've been going on for 55 minutes on this. I think it'd be great for us to get a chance to socialize with each other, at least for a few minutes, we were off to head back home to summarize. I think someone said, let's do a straw pool. I think that'd be kind of fun actually. So we have so statistically state the well, I think this is the end core outside of core. And I think what we develop strong affinity or completely outside of well, that's like neither one of us really. So if we if we are to summarize, I think, what I was going to say is that if we are to summarize ultimately, there's not going to be any disagreements. So but let's how about you summarize and then I summarize. Okay, let me summarize. Let me summarize first. I think it's a novel cause to pursue API compatibility, not just Amazon, but across everywhere. Open stack community should not be eliminating Amazon or doing anything to the contrary of not embracing its API and trying to feed off of its user base and things like that. Is this something that's priority one today for the open stack community, given the all other opportunities around the innovation and simply augmenting the stability of the system? No, I think it is not a number one priority. Randy. Well, it's problematic, because I'm not claiming it should be a number one priority, right? I'm just claiming it shouldn't be forgotten in the mix. And that you know, I don't want I want the fact that rack space is now shrunken as a instigator of a lot of these sort of poisoning the well around Amazon to go away. And I want it to be really clear that we care about compatibility with a variety of different cloud systems. And the open stack native APIs absolutely are the primary place for innovation. But we should continue to have compatibility. And I think it's a mistake to to ignore it. Okay, so the straw poll is if you have more affinity towards Boris's arguments, raise your hand, please. Sorry, Boris. Wait, wait, wait, let's let's see if it's a non participatory. And then for those for Randy, you know, the the other hand here, a little bit more affinity. Thank you very much. But there it's a very we had a bunch of abstains. So we just tried to put a patch set back working with Juniper on the all the VPC capabilities into the EC two API yesterday, but Russell's not going to take it because it's a little late in the cycle, unfortunately. And we just tried to push back the GCE APIs. It's the same story as well, because it's a man of free. But you can expect both of those in ice house and we'll put them in the very first ice house released after Havana drops. And there'll be more after that. Randy, so how do people get a hold of you or follow you? And what's the website for cloud scaling? Randy bias r a n d y b I a s blogs or anything be surprised if you can't find me. Just typing in a Google, you'll be good to go for us like same thing. Yeah, just Google me add zero to its merantis.com, zero treats with a zero. Yeah, Joe, Joe Arnold Swiss stack.com. And we'll hand it back to you to close us out. Okay, so the replay of the video is still live right now, but we had over 300 concurrence. I just checked the stream of about 252 live concurrent viewers. So lean leaning back watching live go to YouTube.com slash Silicon angle, you'll see on demand replay of this video. And we're going to have some great comments on the crowd chat.net, kind of the Twitter chat room that we put together for this and it's going to be on the record. So if you want, we're going to keep it open for an hour, then we're going to shut it down. So if you want to go there, log in with your Twitter handle, or LinkedIn handle, leave a question and comment threads, we're going to have that be a document of record for this event. So go to crowd chat.net slash open stack for the next hour. So guys, thanks a lot. And thank you guys for coming. Appreciate the broadcast. Thanks a lot.


So I've had a unbelievably long time working on this Sony PVM14N6U project. Now this is one that I've fully restored and I'm gonna jump forward a little bit. I've not finished that restoration video yet, but I did have a huge repair happen right towards the end of this restoration. So I thought it would be more beneficial if I broke the video up and just jumped right into this repair from what happened while I went through and restored this monitor. Now again, this is the first time I've had a chance to work on the N series really on film. So I wanted to make sure I was very thorough. And so I went through and I recapped this entire PVM. Now that's not a huge job by any means. It was less than 60 caps in total. However, once I had everything finished, all my new caps installed, I was putting the monitor back together, which is the footage you're watching right here behind me. And then I went to turn it on and you'll see in a second here kind of the troubles I had, but just I really was wanting to show this to kind of fade to the light, the truth behind some of these repairs where oftentimes you put a lot of time, money and effort into something and it doesn't always work out the first time. It's best to just remember to stay encouraged and hopeful. And that way, hopefully down the line, you could figure things out. But when you're right in the thick of things, sometimes you can get quite frustrated, especially, let me explain a little bit at this point where I had finally gotten this monitor back together and I was ready to test, I was excited. Cause again, I had changed every single capacitor. I'd cleaned the entire tube chassis and everything else. And I was hoping that it would be a pretty simple job of getting it restored from this point on. At least my work would have been downhill where I just would have to do calibrations. But what actually happened was something completely different. So I went to plug it in. Again, right after I had recapped in everything and put it back together and I got nothing. Well, I didn't get nothing. I didn't get any life to the tube. I did hear the DGOS initially ding one time and then it just fizzled out like the power fizzled out on it. And I really didn't know what had happened. So I did look around a little bit and I was really kind of starting to feel pressure and frustration because I thought that I had done everything right. Cause again, this one worked fine before I decided to recap it. I mean, the picture wasn't very nice but everything else on it did work fine. So again, I tried to go through and reseed everything, make sure everything was reconnected. I tried a couple more power tests and I really got nothing. So what ended up being down, after finally just saying, hey, enough is enough, I had to give it an entire night to sleep on so I wouldn't just lose my mind. And the next day I said, it's really time to get in here and inspect the board. Every inch of it to see what I could have done wrong in my repairs. And so, again, this is probably an hour after I had tried to reseed things. I pulled the chassis two or three times just to see if it was sitting against anything or if anything noticeable was wrong but there was nothing noticeable. So I had to go through and just meticulously, visually check every single one of these little connections and after I took the time to do all that, I noticed something that was not right about a certain point here on the board. And that is where the positive end of this capacitor that I did replace was attached. It originally was attached to the board but I noticed that it had gotten completely lifted and it had been lifted from this diode right here. This, there was a thin trace connecting it to the capacitor and then the capacitor was connected to this pad here which actually flowed on down through the monitor a little more. So it needed a new way for that current to flow through the capacitor and then down to this pad here. So I was quite happy to actually find that but I did know that I would have to go in and rebuild that but most likely that's what was causing the issues. And this is after the rebuild. So what I had to do was I stretched out the leg from the other side of that capacitor and when I put heat on it again that entire pad just lifted right off and attached to my soldering iron. So it was definitely just gone. So I stretched the leg of that capacitor. I pulled it through a little bit further and then I just bent it and touched it to the other end of this diode where it should be running the trace. And then I soldered that with plenty of flux. And then I made another bridge with just that leftover end of a capacitor leg from here. It's a here. So that way I was rebuilding that point there. And I felt like this rebuild right here was actually gonna work pretty well. It seemed pretty solid. But again, it was super frustrating. I know it seems easy when you look at it from this video point of view but it took me a good two hours to find this issue after I had tried to test the monitor and it wasn't working. So this is the capacitor on the other side. It's apparently one of the more vital caps in this monitor. C514, but it's not, I mean, this is kind of funny but this one is one of the smallest. I tried to show it there but that's one of the smallest capacitors on the board. It was a 0.47 micro faran. And obviously one of the more vital ones to work. So anyway, after all that, I finally reassembled the PVM and I again had a pretty good feeling this was gonna work but I wasn't 100% certain. So I put all this together. This is one continuous shot. I just wanted to show it so you didn't have to wait for the monitor to warm up but it did work and everything worked fine after that. So that was the issue why I was just getting a straight dead monitor where this went from dead to back to life again all from a tiny trace on a 0.47 micro faran capacitor. So the monitor looks pretty good right now but it does need a lot of adjustments on it.  And it definitely has some geometry issues that we need to take care of. So that's gonna be part of a third video. So we'll have, next you will most likely get to see the video where I've initially taken this apart and I do the capacitor replacement and right up to the edge where the beginning of this video is so you'll probably be watching this one first but I thought it would be more beneficial to everybody if they could see this repair video separate from those. Because I'm gonna call this when you bring in that PVM back to life where I thought possibly this was dead I didn't really know what to do but if you do have a situation like this I can't reiterate how important it is to just take a second to step back from the project and even if it was take a night to sleep on things rethink things and then you could come back with maybe a fresh amount of nerves fresh energy and ready to get back and take care of the monitor because now it looks great and it's working perfectly and eventually it's gonna be really crisp up on the picture and then this one will have the full video series and then I will be listing this one for sale. So I just wanted to show though this really quirky little repair and how one little capacitor can really affect the performance of an entire PVM. So anyway, if you guys have any questions or comments please leave them below and again, look for the other two videos coming on this monitor. Thanks again, I'll see you next time with some more retro content.


While this past weekend marked the unofficial start of summer in Minnesota and the city of Bemidji will kick off the summer vacation season in grand style with a beach party. The city of Bemidji will celebrate summer once school lets out for the year on this Friday. There will be fun and games for kids of all ages at the Lake Bemidji South Beach. This is the second beach party that has been hosted by the Parks and Rec department and they're looking forward to yet another fun event. We have an awesome beach party planned. We have a DJ lined up. We have sandcastle competitions. We have our camp counselors going to be down at the beach running some really fun games and it's just a great way to kick off the summer. Now prior to the start of the beach party the parks department will host another event. The city of Bemidji will unveil its strategic plan along with a new logo for the Parks and Recreation department. The strategic parks plan has been in the works for the past couple of years. We will kind of be showing off our new strategic plan which includes our new vision mission statement. Some of our core values and then our goals for the next couple of years of things we're going to be working on. So we'll have cake as a way to appreciate everybody so we just encourage the public to come down and any of our partners who have helped us with this process. Now the strategic plan will be unveiled at 2.30 Friday afternoon before the start of the beach party which is set to begin at 3.30 and run until five.