 everybody and welcome again to another OpenShift Commons briefing. Diane Euler, your host and the person behind most of the Commons efforts. And today I'm really psyched. We have been puttering around trying to figure out how to best expose the great minds that are part of the global transformation office and get some of their work around DevOps and community development and all kinds of things into our slipstream here. And today I'm really happy to have Jay Bloom from the GTO office. I have no idea what your title actually is. I think we all just make them up at Red Hat is my theory. But Jay and I have had a little bit of an ongoing conversation about community Commons and I thought it would be great if we brought him in to have a conversation about and set the stage for it by having Jay talk about his theories around the three economies and Commons and all those kinds of things. And then we'll do that probably for 20 minutes, 30 minutes, depending on how long Jay rattles on. And it's always entertaining and educational. And then we're going to have sort of an AMA conversation. So if you have questions, you can ask them in Twitch if you're watching us in Twitch or in the BlueJeans chat if you're watching us in BlueJeans and we'll wing it. So I'm going to let Jay really introduce himself and then take it away for as long as it takes to set the stage for this. Thank you, Diane. Thank you for having me. As we're about to discuss, the work of creating and sustaining Commons is a gift to a community. So thank you for your work establishing this and inviting me to participate in it. I appreciate it. I'm Jay Bloom. I work at the GTO, the Global Transformation Office inside of Red Hat. My official title is Senior Director. I'm not sure exactly what that means in relationship to the world, but that's my title. When I'm not Red Hatting and trying to help people through transformations, I'm getting a PhD at Cardi E. Mellon. And some of the work that I'm going to show you here is from my PhD. And what I kind of want to explore is just this idea of what is a Commons and then try to understand how enterprises could think of or engage in Commons or what I call recombining. And so in order to set that up, we kind of got to go through some theory to set up a place to talk about it. So first thing is just what is what is the Commons? What do we mean by a Commons? So Commons have kind of specific attributes. First of all, there's something like a common resource pool. And that means there's there's things that people share and use together and that they get value out of, right? So I'm going to try not to use the word common to describe common things. But anyway, so a frequent example of the Commons would be something like a fishery or a water source or a pasture land, right? Those types of Commons are exposed to what is called subtractibility. And all that means is that if people over-harvest the resources out of a Commons, the value of the Commons degrades quickly in the near term. So that basically means like if you fish too much, you'll be less fish for everybody. And the quality of the fish goes down. And therefore you got problems in the near term. And the result of that near term degradation of value is long term degradation of value because people are unwilling to invest themselves in sustaining something that's not providing them value. So the other thing to think about really quickly is that a Commons is essentially established because the users are both consumers and contributors to the long term sustainability of the Commons. So they both, everybody who's using a Commons is both consuming from it and taking value from it, but also contributing it to it by not over-harvesting it. So in other words, restraint is a form of contribution in these types of Commons. So my friend Dimeje, who is another PhD student, or was another PhD student, he's Dr. Dimeje nowadays, wrote his dissertation on the concept of recombining. And he summarizes Commons like this. Commons have been said to have a space between privately held property and public goods. And so it's critical to kind of think of Commons for a moment here that publicly held goods are things that are governed by governments, nation states, things like this. So like your local park is not a Commons because it is held and maintained and managed and governed by your city government. So it's not really a Commons. That and private property, my backyard is not a Commons. I own it. If I don't want you to be in it, I can ask you to leave, right? So Commons kind of lives in the space in between those two things. And one of the kind of important things about the idea of recombining, which we'll get to, is that Commons used to exist as kind of like just commonly held land. In other words, it wasn't held by the government. It wasn't held by individuals. It was just anybody could use it. And that was a thing. And we'll talk a little bit more about that. They're not only, it's not only that resources get consumed and overexploited, but also the idea of a Commons is that there's a set of governance practices and communities that sustain the resources as they're used. So in this conception, there's an idea that the Commons is a form of commoning. In other words, there's an activity involved in creating and sustaining a Commons. It's not just a set of resources. It's a set of practices, social practices and interactions that are, that enable the Commons to exist in the first place, right? And so then we can kind of extend the idea of what's valuable about a Commons to include things like social practices, knowledge, shared space to work together, governance. All of these kind of activities are part of what a Commons is and add value as well as just the physical goods that they produce. And the other kind of thing is that Commons is a interaction between what we would call local rationalities or what Herbert Simon would call bounded rationality, which means roughly that the decisions you're making are contextually bound to a specific location, time, place, so that your decisions are not driven by universal rationalities or global rationalities, which are normally represented by the concept of homo-economicists, which roughly says that there is some sort of universal way of rationalizing economic decisions. So there is a perfectly, a perfect way of calculating how to divide goods among people. That's a global rationality, right? So local versus global, so that what a Commons exists in is in the intermediary between the values that are produced by paying attention to local concerns and the efficiencies and important rationalities that are represented by global rationalities. So what's the problem that we're trying to point to here? We kind of described a thing. What's the problem with the Commons? How do we kind of think through that so that we can talk about how to apply it and then solve the problem? So there's two that I want to point out. The first one is just called the Tragedy of Commons, and the Tragedy of Commons is quite simple to understand. What it says is that given these two dominant rationalities, individualistic private concerns and local rationalities versus communal global rationalities, communal concerns causes a collapse of the Commons. And the way this works is that imagine we have a cowfield and anybody can graze their cows on the cowfield. There's no local government that's putting regulations on the cowfield. The way that the cowfield is maintained as a Commons is that everyone kind of knows that if there's too many cows on the pasture that the pasture will be overgrazed and it will collapse. And so the problem with this is that if someone adopts kind of Adam Smith's invisible hand-of-the-market greed concept of interaction with this resource, what they will immediately decide is because it's a zero-sum game is they will decide that they should put as many cows on the pasture as possible because if they're the only one who overpopulates the pasture, they will have more cows than everybody else and therefore they'll get an advantage. And if everybody puts too many cows on the pasture, well, nobody will have cows and therefore nobody will get an advantage. So in this kind of game theoretic, one version of it produces I get more cows than everybody else and the other one produces nobody gets any more cows but I'm also not... I don't lose in the game of kind of competitive tit-tat, right? So that causes what's called the tragedy of Commons. It causes this idea that the Commons cannot be self-sustaining and in the original framing of this by a man named Hardin, he was trying to point out that Commons are essentially unsustainable because these two rationales cause the collapse of the Commons at all times. And so there's gonna be some interesting things we need to talk about about why that is true or false but the result of this kind of thinking led to what is called the enclosure movement in Europe, especially in England. So the basic idea of the enclosure movement is roughly we have a bunch of common land that is not being managed well because of these kind of cyclical collapses of the Commons and the theory becomes, well, the reason why the Commons keeps on collapsing is because no one is personally responsible for maintaining the Commons. So there's either no government structure that's governing the land or there's no individual who's personally responsible for the land. And so what they do is they basically carve up all of England into little pieces. They eradicate the Commons. In other words, prior to the enclosure movement, there was land in England that was commonly held not governmentally controlled and not owned by individuals. People could hunt on it, graze on it. Classic examples like sheep herds would traverse them, all those things. After the enclosure movement, every piece of land in England is either private property or public property. There is no longer commonly held property. So this leads to what is called the tragedy of enclosure. So the tragedy of enclosure basically says that the problem with this is that you either lose local needs because you enclose the resource and give it to a government that doesn't care necessarily about the local needs or you destroy the global concerns by giving it to a private citizen. So by removing the Commons, you have a tragedy that was there things that were valuable in the Commons that can only be held in common. They can't be held in these other two kind of economic rationalities. That's one of the things to kind of poke with. So that's kind of Commons theory really quickly. What does this have to do with IT and enterprise IT? Why am I ranting about this in relationship to IT? So I think this should ring true for most people. Inside most organizations, we see what we call a core conflict. The core conflict is this. We see on one side of the organization a need or drive for radical accelerated differentiation of customer value. So this is the value system or the economic drivers of part of the organization are to create new novel functions, features, applications, business lines to address expanding markets, new customers, new customer needs. So this is one side of the equation. We see in a lot of organizations a drive to centralize operational excellence and create efficiencies. So this is your central IT department in most organizations. And what we see is we get these kind of idea that there's a bunch of business lines and they're almost always in conflict with a centralized IT organization. And this conflict is what we kind of want to play with a little bit here. So what we have is a paradox. And the paradox can be roughly kind of structured as one side of the organization is arguing that we have to increase variety. And the other one is arguing that we have to decrease variation. And these two economically, so both of those statements are about what creates value for the organization. One side of the organization argues that increasing variety, in other words producing things that address new markets, new customer needs, adds value to the business. And the other side believes that decreasing variety by increasing the application of economics of scale, that is what creates value for the business. So you can see that this causes kind of a direct problematic interaction, right? So what we get is, again, we get this idea that we've got business lines and product lines and business units with agile feature teams. And what they want to be governed by are concepts of autonomy, agility, and ownership, like product ownership, or you write it, you run it, all these kind of conceptions of an organization where the teams are, value is created for these teams by reducing dependencies. Let's say it that way, huh? The other side of the system, of course, is interested in things like change control, governance risk and compliance, approved reference architectures. They interact a lot with procurement to prevent people from purchasing non-standard technologies. They're very worried about things like availability, reliability, things like this. And they are hyper-focused on kind of enforcing resource constraints in order to enable capacity planning, right? So these are maybe two sides of the argument again. So what we have is these ideas that the value that they're trying to create, again, is more customers, new markets do things differently versus control consumption, use best practice and do the same things repeatedly, right? So these are the two governing theories. And the result of this is that one side wants to be able to maximize the ability to respond to local variation and adapt to environmental change. And the other side wants to maximize the ability to harvest value from owned assets, things that the company has already developed and are running in operation, and the predictable nature of commodity goods, right? So what we look at here then is this idea of one side wanting to deploy what we would call local rationalities in order to create context-specific responses to market stimuli, and the focus is more on what's effective and what works, and the whole idea is to develop unique resources that solve customer needs and expand markets. On the other side, we have this idea of global rationalities, so we want people to leverage repeatable processes. We want to decrease variation. We have a hyper-focus on efficiency as a source of value. A lot of what we're doing is we're not working with kind of unique, rare resources. We're working with commodity and utility resources, things like, again, the cloud might come in play here. And the whole idea of this ends up being that there's a difference between what we're designing for. On one side, the value that we're designing for is a customer's experience, and on the other side, we're designing to be able to maintain a system and lower the cost of change of that system. So this leads us to some interesting questions about what consumption is, and these different kind of areas when we think about consumption. So again, the whole point of a commons is that there are certain resources that are consumed. What we see here is that the organization that I've labeled here, the differentiation part of the organization, relies on consumable publicly held resources in most organizations. And by publicly held, I mean centrally governed, right? Because on the other side, which I've labeled here on the scale, these people are responsible for governing the consumable publicly held resources. So that kind of ends up being the application of this paradox to IT organizations today. So great, we have a nice paradox. Now we might actually make some progress because paradoxes help us to think about things new without accepting old dogmas. So is there a way to think about this paradox differently? Is there a way of understanding how these two governing rationalities might be turned in from a zero sum game to a win-win game? How would we take these two ideas about how to govern an organization and instead of having one side always win and one side always lose have a way of thinking about this where both sides could win? How would we do that? What would we look for? So the first thing to say, I think, is what do we mean by consumable inside of an IT organization? What is consumable inside of an IT organization? And this has to do with this, again, this misbalance between the reproduction of a resource and the consumption of the resource. So it has to do with sustainable creation of certain things that are consumed, but specifically things that are consumed in a subtractable way. In other words, if they're overutilized, the value of them goes down. So I think clearly inside of IT organizations, this is things like network storage, compute, and databases. There's probably others, but these are four nice big ones. So you can think about a network. A network is a thing that is managed. There's a capacity to it. We manage the capacity by a capacity planning. If it gets oversaturated, the value of the network to everybody attached to that network goes down. Same thing with storage. It's possible to overrun the storage. Therefore, you have to plan for how much storage you want. Compute is kind of a set of resources that are driven by certain other economics that are shared in modern kind of cloud-based utility-based compute clusters. They're shared resources. They're not private resources at that point. So this is, I think, a set of things inside of an IT organization that is consumable. So you get a central IT organization that is built up and economically driven to govern the consumption and reproduction of these things, these kind of reliable primitives. And importantly, these resources, these types of resources like network storage and compute, are not driven by the needs of any individual organization because they're commodities. They are driven by kind of global market pressures, not local market pressures of a particular business. So what I mean by that roughly is if you want to use a certain compute, it's like a certain CPU, that's great and you can invest in it. But next year, because of Moore's law, you should probably replace it because you're going to be able to create more compute power at a lower cost or trade the lower compute, the lower heats created by the new dyes to create electricity efficiencies or air conditioning efficiencies. There's also two trade-offs that are involved in choosing how you deploy the physical infrastructure of your compute. And those economics are not driven by any one firm's concern. They're driven by a large economic market that is out of control of any one firm. And therefore, the people inside of this Central IT organization are captive to certain economic cycles that they cannot get out of. It doesn't matter how much the organization wants them to do things differently. They're trapped by it. And you can imagine things like parts of the organization becoming overly dependent on specific implementations of, for instance, storage or network or compute. And the result of that being that the organization's Central IT department becomes handcuffed as to the cycle time of replacement for those things and therefore the efficiencies that they're expecting to get by following market efficiencies is reduced and problematic. So, is there something inside of IT organizations that isn't consumed in use? Like, is there stuff inside of modern IT organizations that if more people use them, it doesn't go away, but it actually gains in value? So you can think of an idea of like, is there stuff inside of an organization that if I get more and more people to use that stuff, it will become more and more valuable instead of less and less valuable, right? So network becomes less and less valuable after a tipping point. Is there stuff that doesn't have tipping points like that? And so I think these are like three big buckets of that. There's common data structures. There's well-factored functions. And there's patterns for configuring those and utilizing those primitives that I pointed to that are managed by the Centralized IT department. And the kind of value of the patterns is that they reduce the combinatorial complexity involved in integrating those various primitives so that they create resilience. So one of the ways to think of that roughly is that Centralized IT departments only ever provide reliable things, whereas this idea of getting people to use those reliable things in certain ways actually creates a resilient system. And there's a difference there that I think is important to point to. So now we get to this idea of three economies. This is what I've kind of walked you through right now is the description of what the three economies inside of an organization are. We have the economies of differentiation, the economies of scope, and the economies of scale. And what we can say is that, starting from the economies of scale, economies of scale are responsible for the efficient reproduction of these primitives, right? And then if we go to the other side, economies of differentiation are they create value by creating differentiated functionality with rapid cycle times. They're often highly disposable. This is kind of like that you fail fast conceptions of the world. And they're often just sets of preconfigured versions. So snap together Legos, so they stay really thin and move really fast, right? And then in the middle, in the middle is this new thing that I think we want to point at. And in the middle is this economy of scope. And in the economy of scope, we get these resources that are commonly held, but actually increase in value in use and don't decrease in value in use. And again, that's things like cloud-native patterns, common data structures, and common well-factored functions, right? Okay, so great. What's the problem? Why doesn't everybody just build these scope economies? That looks like a platform, I guess. Why don't people just build platforms? And that will solve all this, right? That's just build it and they will come. But we know this isn't right. We know, based on a lot of practice inside of kind of software engineering, that kind of design for reuse upfront is going to hit you with the, you're not going to need it hammer, right? Like eventually you're going to end up building too much stuff, or you're going to build something and nobody's going to want it, or build something and people won't need it. So I have some doubts about building the platform first, right? So what is it that we're kind of worried about here? What are we trying to get to? How do we think through that problem, right? So Copeland, there's a nice job of saying, listen, you don't have to design for reuse. On the other hand, good design makes it easy to reuse. So one of the things that I think that he's pointing at here is that maybe this is like a sequence. There's a way in which reuse doesn't come first, but it can come later. And how would you design or thinking about designing a system to allow that second, now it's reusable concept to kind of come into play. So why am I pointing at this? Well, again, we talked about this idea that differentiation has to do with lots of different customers with different needs and those needs change and when we're successful we actually accelerate the change of those customers' needs. So what we can think about is that this kind of differentiation economy, we actually are only able to kind of create value by paying exquisite attention to the customer's needs. How the customer defines value is very important here. And the good news I think here is that it starts a flywheel that allows valuable things to be created inside of an organization and to be tested inside of small, safe-to-fail niches. So there's elements that allow us to really experiment and play with an idea and that only then, after we find a set of customers who value these things, then maybe we can look up and say, hey, is there anybody else who might need this data that we just created? Is there anybody else who might need this function that we've created? So what is this thing that you guys all came here to talk listening to me rant about? This idea of recombining. You've already heard of commons. You've heard of the three economies now. You've heard of the paradox that we're trying to solve. But what is this idea of recombining? So recombining I think could be the most simplest way to say it is maybe some of the things that start in differentiation may eventually be more valuable in the economy of scope. So maybe some of the things that you create using the techniques of differentiation eventually need to be, let's say, promoted or converted or adopted or recommend into this scope economy where the value of that unit now becomes the way in which other people can use it to achieve value for themselves. It's a shared common resource. And then the other side of it is maybe some of the things that we, because we currently don't have in most organizations a concept of the scope economy. We don't have a way of thinking about shared resources. We only have a way of thinking about privately owned differentiation economies, logics, or essentially owned scale logics. So maybe sometimes part of the friction that's caused between the parts of the organization that want to create new value comes from when they give that thing, that new valuable thing. They give it to the scale economy and the scale economy causes that enclosure problem, that tragedy enclosure. They don't actually leverage it well. They don't understand how to respond well. And so those things maybe, maybe some of the things that we currently attempt to rationally manage via centralized governance, maybe those things instead would be more valuable managed in a scope economy, inside of a platform system. So this maybe what recombining is, maybe recombining is the idea of taking things from these two other economies and putting them into a scope economy. So my friend Dimeje literally wrote a book, wrote his dissertation on designing, design-led recombining. So the whole idea here is driven by my interactions with Dimeje. And I owe him a huge debt to some of these ideas. And he basically says that he makes this kind of platform part even more explicit. So maybe a platform could be conceptually understood as a set of guiding principles to enable a two-sided market, in other words the kind of private public market, to create and reveal a middle mass and opportunity in which we could intervene and create better outcomes. And therefore platforms help us to recombine through new approaches to negotiating, right? What would those negotiations look like inside of an IT organization? Well, I think one of them is simply to understand the nature of resources in somewhat like the way that I described them here. The way in which resources have different economic value in different economies. And therefore some of those resources would be more valuable if they were treated or were held in different rationalities or different economic rationalities or governance frames, right? So then if we understood the nature of the resources and we could determine what type of economic rationality would be the optimal place to hold those different resources, then we could start by working on establishing governance and social practices that enable us to transition these resources from one economy to the next. Now, I think that this is largely what many enterprise organizations are going through right now. What they mean by transforming their organization is to understand we've been doing scale economy for 10 to 15 years. We've been doing Agile now for anywhere from 10 to 15 years. Why isn't it working? Why are we still having problems? And I think that this is a proposal of why they're having problems and what we might have to change. So, J.B., you're ranting about social practices and governance and economics. Is there some examples of the importance of these things in practice? Can you point at why I should listen to you? Can you give me some examples? So there's a book by Joachim Benkler who basically argues that Southwest, Toyota, Wikipedia and Linux all share these ideas of reciprocity and the creation of cooperative work systems, in other words, the commons, as a way of thinking through how to create value for their businesses and that those people are prime examples of people who are primarily motivated by creating a common system and not motivated by these other forms of rationality. So that's Joachim Benkler's version of it. I think Jim Whitehurst's argument about the open organization, particularly this concept that an open organization engages in participative communities both inside and outside. And what that does, again, and what I think the three economies tries to explain is how do organizations who do that both respond to opportunities more quickly and leverage resources and talent inside and outside their organizations more effectively? And I think that's one of the arguments that you could point out. And then finally, the idea of a platform and the idea of a commons, the way I want to tie these together is to suggest that these are kind of attractors, focal points inside of an organization that enable people to work together, to have a space and a place to work together to create value based on their local concerns while also negotiating their shared and communal concerns. And I think that organizations who learn to do this most effectively will excel, right? My very brief kind of suggestion here would be Google's SRE organization is an organization that is developing a commons. That's what they are doing. They're developing a set of regulations that are negotiated locally and enforced globally in order to create a common resource that is highly resilient, right? So that's an example. So I think, and I suspect that open source communities have something to tell us about how to do this. I think that open source communities, in fact, are well described by commons. And they are capable of creating commons and thinking through the social practices and governance needed to create a space to work together. I think that's a really good description of what we see when we look at open source. But how could we think about that differently? What challenges might we think about that differently by saying instead of pointing at source commons, instead of pointing at the idea that the resource that we're creating that's commonly held as source code in order to make the challenge something that causes us to rethink it, what lessons could we take from there and apply to something like a data commons where the commonly held resource isn't source code but data? How would we kind of think through that? And what lessons would we take from the open source community in order to establish a data commons inside of an enterprise? Because God knows no one has siloed data inside of organizations that's hard for other teams to use. And maybe the simplest version of this talk is this idea about how can we make stone soup in the enterprise? How can we get people to contribute to the common plate? And how is the transformation from these organizations that are in conflict between two primary dominant rationales, how is the transformation started in a way that enables this third economy, this scope economy or the commons to create a space to negotiate value and value creation inside of our organizations? So my question is what can the open source community teach us about recombining? And that's a question for you guys. So thank you for listening to me rant. I have a lot of resources and I'll make the slides available. And I'm going to sit down now. Yeah, take a breath. Thank you so much, Jay. And I love that you closed with stone soup because that is the book that I refer to so often when I'm talking about open source and community development. And it's really, it's wonderful that you share that image and that story with people as well. I think what you've done is articulated a lot of things that we use in OpenShift Commons that I've used to create the space that is OpenShift Commons and in some ways the platform that OpenShift Commons I hope is for our community that is around the ecosystem of OpenShift, which is kind of why I really liked having you here today and invited you to do it. Because I think one thing that often in open source we're very focused on the software, you know, the code, the pieces and parts of that from a community point of view. And so this conversation kind of opens us up to a bigger, a higher level conversation that I would like to continue with you with the OpenShift community and other communities that are, you know, part of that ecosystem, which is huge. You and I have talked about what I call the jellyfish effect. All of the different people in the network of all the cross-community collaborations that we do to bring people together, whether it's upstream, downstream projects, it's end users or different use cases. It's a huge, tangled mass of jellyfish that connect in different ways through their tentacles. That's the best metaphor I could find for what the OpenShift ecosystem actually looks like. And you talked about a lot of things here and I'm going to kind of back up a little bit, too, because one of the things in the beginning of your lecture talk or however we want to frame that educational process that you dragged us through, which was wonderful. I want to talk a little bit about the idea that for communities, you talked a lot about compute resources, networks, things, enterprise, IT stuff. But I think the gatekeeping resource for a lot of communities and commons is people. We can teach people agile. We can make people dev-offs. We can shut off the waterfall or whatever we want to talk about. But for us, software is, like if I write a piece of software, I share it as open source, it's infinitely reusable. It doesn't cost me anything to give people that software in a GitHub repo. But if I want to maintain it, get tech support on it, have engineering resources, debug stuff, those are people. And people have limited bandwidth. So, you know, how do people fit into, as a resource, fit into this commons thing? That's one thing I'd like to tease out a little bit. We talk about what openshift commons is. But that was one of the things at the beginning. It's like it was very focused on, I would say, tangible resources, even though cloud was never considered tangible-ish. That's right. So I think one of the things to think through, and we can think through it, at an open source community level or even inside of an enterprise, one of the things to think about is the view of an individual person. So like, what is, again, we have this idea of something consumable inside that individual human. That's their time, their life force, their attention. All these things are consumable. And we get all sorts of interesting theories about how to manage that limiting WIP or project management centrally controlled versus individually controlled, all types of things, right? But the scope economy wants to kind of, or the commons style economy want to point us, I think, at a subtly different thing. And that's to say that, how do, if I release something, what are the practices for rapidly establishing other people who share my concerns so that they will help me maintain it? How do I expose the common concerns of the thing that I'm putting in the world so that I accelerate the adoption of it, but also make clear that the value of it is a shared value. It's not something I'm going to manage, it's something we're going to manage, right? And I do think that in lots of organizations and in lots of communities, this is a difficult negotiation because the dominant concepts of governance are either you centrally control it and therefore you have to go out and pay for resources or you privately own it, in which case you do it and you have to sell it for value, right? And one of the weird kind of things that I didn't put in here but I would kind of point at is that a lot of that negotiation about value as an individual has to do with the difference between what's called transactional relationships and reciprocity relationships. And so transactional relationship is really easy. It's either a centralized group that's governing or a private health group and every time you do something, you think of it as an individual transaction with that group. I'm going to do something and I'm going to get value immediately from it or not but it's a when I'm done with this interaction we start anew, right? So that's kind of like traditional and the other way to think about it is that this isn't the only way the only time I'm going to interact with this is that I'm going to get into it a lot over time and over time I'm going to like repeatedly come back to this resource and therefore it's not a transactional thing. It's not something I can walk away from. My contribution or my consumption at any one moment isn't the problem. It's my contribution or my consumption over a long period of time. So like the really silly way to say this is like you and I go get beer and I write down Diane, I just paid $5 for your beer put it away and then we keep going I just got you another round so you owe me $10. That's a transactional relationship, right? And it's unlikely to create a trust system that allows us to kind of expand our network of trust and there's also a whole set of ideas that say that trust is like a resource in itself that organizations that have high trust can do things that organizations that have low trust can't do, right? Absolutely, yeah. I think that's the nail in the head there is that building the relationships with the trust factor embedded inside of communities. I think that's the goal of everyone like myself who does community development and tries to build engaged communities around any ecosystem is that how do we ensure that there is trust and that's where some of the governance stuff comes in but it's also about building the peer-to-peer networks and the trust relationships inside of that community. That's quite nice. There's a couple of questions here in chat and they might be so Mario is asking would you expect that team units to be building artifacts supporting all three economies or would those ideally be distributed among many? The control-based thing, you know. I do think, so here's my very short answer is that I think most organizations who don't have a platform team are going to have problems like there has to actually be people who own this space and who work with others to establish it, right? I think that the three economies points away from conceptions like you run it and points towards conceptions like I build it we run it. In other words, there's a conception that I'm responsible for building a thing that is operable in all three economies. It doesn't mean I have to operate it in all three economies but that it responds to and understands enough about those other economic value systems that it doesn't frustrate them. One could argue like DevOps is simply the argument that people from efficiency economies should explain themselves better to people of differentiation economies so that people in differentiation economies understand how the way they write code is creating value in an operation or not. So operability, design for operability, design for manufacture all these concepts. So yeah, I do think in enterprises, big enterprises, you're likely to see different different I would almost suggest in most organizations there's going to be different VP level structures for each of the economies and that those people will be, the VPs will be the people who need to be primarily driven to understand how to negotiate the differences between the economies. I hope that it gave you some light on that, Mario. There's one more question here and I'm going to go through the questions as they come in and then we'll go back and forth on some of the things that I am going to tease out and if you can stay longer please do so. We'll hang out until we run out of things to talk about which loves that. Barbara Frontera is asking in most enterprise transformations I've seen you run into the scalability wall at some point whether it's legal, finance, etc. Can companies really overcome the paradox of variety? Yeah I think so I do think that a lot of those walls I don't have a great answer for that one. I think that there's lots of things inside of organizations that are put there intentionally to kind of prevent certain parts of the organization from growing too quickly and growing out of control and I think that has again one of the ways to think about kind of common common resource consumption which again, Central IT is also concerned with is that if the rate of change increases past the adaptive capacity of that part of the organization it will break the organization so there's a limit on how quickly things can grow so again, kind of negotiating that and therefore but one of the other parts of the three economy theory that I did not talk about here is how you invest variation across the organization one of the arguments is to say that if you can only scale so much then you should be focused on scaling the right things and understand how to determine what those things are and who creates value that will scale the fastest right and so I would also point out just really quickly that I think what you're the question is driven by questions about how to scale as opposed to scale economies so one's about growth and one's about efficiency and there's they're the same term but they're different ideas I think that I think we see like in the open shift commons and in the conversations that I have with people there's an interesting thing and this is different than enterprises so we're talking about an open source community built out around the open shift ecosystem which touches on lots of open source projects not just Kubernetes but a bazillion other ones and what we see is this huge amorphous software side of things so like the stack of things that become open shift and then there's the wild of the use cases of people who build applications on top of it so like all the different use cases and I'm just drawing this back to community development a little bit and the open shift commons idea is that we want to support all of these different use cases we want that wide variety but what we have to do and this is just conceptually slightly different but what we have to do is make sure that our platform supports them but then an edge not in terms of edge technology but the edge cases too we have to make sure that our platform we don't go too far off to the edge to support some of the edge cases so that we don't lose some of the bigger loads here or we force some of the bigger loads or use cases on our platforms to help with that as well because we said that something else has to happen so that to me there's a lot of commonality in what you're talking about with these three economies that apply to open source communities which is why I'm so interested in this topic I think one of the things and I'll just step back a little bit about open shift and tell a little context setting about open shift commons so open shift commons itself we launched I think almost four maybe five years ago when we pivoted from the open talking software here now not enterprises when we pivoted from being a standalone platform as a service built on Ruby and Rails and MongoDB and all that goodness to re-platform on Kubernetes so what we did at that juncture is we joined this bigger community software effort that Google open source Kubernetes and Red Hat jumped on board almost immediately and became part of that community bringing along all of our end users and all of their workloads and all of their use cases and all of their enterprises and asking them to take the risk with us to trust us to move to that new platform it turned out to be a really good bet which is great but it also changed the way we did community and which is hence we needed to do something different than like oh please contribute to my little GitHub repo here or my Ruby on Rails or whatever my installer process was back then or we had gears and cartridges believe me we don't want to talk about them but it changed our whole metaphor for community I think that was a really interesting tipping point for me in terms of community engagement and community development because it no longer was about please please please contribute to my open source project it was please please please contribute to the upstream here contribute to the upstream there give us your feedback we'll contribute that so it just changed the whole model which caused us to have to rethink what community was and that's where back four or five years ago he started re-reading the tragedy the commons and all this stuff we came up with or I I really didn't want to start another foundation so I had this and anyone who knows me knows that you know as much as I participate in a lot of foundations I don't have a great love for them in terms of them big tenting or whatever it is there's just a lot of politics involved there and I personally didn't want to create yet another foundation I think there's an acronym there and what we came up with was to take this all this stuff around commons and to apply it to our community and make common space for peers to come together to share to build some trust to share stories lessons learn best practices while still motivating people to contribute to all of these other open source projects and to give us the feedback so that we could successfully do that and I think that has made all the difference for OpenShift and for Red Hat because one it applied some of the principles of things like the open organization that Whitehurst has really helped us move forward as a company and I think those kinds we talk about transformations that was a transformation for us making the decisions to go to a commons model was huge and we still struggle we still struggle with having enough and this is why I brought up the people resource issue is having enough people to engage with everybody successfully but the trick or how is it Kaiser Soze said the devil once how did that phrase go the trick the devil played was people never even realizing was there or some and that is the trick with the commons I think is that because it's become if you go into the common slack or in the chat channels anywhere you'll see peers who are non-Red Haters talking to other peers who are non-Red Haters and exchanging best practices that's the whole idea behind the gatherings and what we do there is to there is no better commercial for OpenShift than a customer standing up on stage and speaking the truth or their truth and or a customer or an end user or a developer in one of the upstream projects coming on and saying oh this is how Prometheus does this and this is and please give us your feedback and we'll see if we can fix it or please join our so facilitating those things those are the kinds of toolings I think we're bringing open source methodologies to the commons and our open organization practices that we have at Red Hat so they're enterprise practices but we're also really opening up the gate we're giving away the podium we're allowing peers to talk to each other without Red Hat in the middle there's an interesting thing and I think that's what fits in the scale economy that is the thing that makes commons not just OpenShift but things that are commons we've recommend open source basically what I've been trying to do over the past three or four years whether I'm successful or not I don't know I mean I still do a lot of hand holding and that's where the people stuff comes in is how do you scale that and I think some of the using other technologies like Slack or you know all of the tooling that we have so that's an interesting thing to tease out about what is recombining and like I think it's not what can open source teach us about recombining how can we recombin open source is how I would rephrase that the question you're asking here is because I think open source has I mean you've got a little gray on your beard open source is aged whether it has aged well it has changed to being something that's very corporate entity driven very much not where we were back in when I started back in Deacus and Digital Equipment Corporation days because I've got some gray here too it's really it's very much changed but I think it still needs to change again I think that we have to find a way to make it not as gate gatekeeping so the control aspect that you talk about which is on one side and then and have the wide variety and the scoping of open source and the way we do open source so a lot of the principles you talk about applying this stuff to enterprises I on the other hand want to apply it to open source and to the way we work and it's not that I want to break foundations it's that I want to change the whole model and I think it has to in order for open source to really go to the true next level of being able to scale both of those things and we see constantly things breaking down we always hit with the foundation model this tipping point like with open stack and it's big tent model and we're starting to touch on it with some of the stuff in the Linux foundation the CNCF so I want to have this ongoing conversation with you over the next couple of years or however long it takes about both bringing this three economies to enterprises as well as to open source community development I love that I just the importance of realizing that there's other ways of collaborating together is really critical and again I like the idea of recombining open source where it means like open source started as a commons and then was privatized and now needs to be recommend and in which ways has it been privatized and how is that working well or not and I think it's super interesting to talk through those ideas but I also think again we can think about things like the reason why open source projects are successful is because one of the questions I always have about open source projects that I think is interesting one of the observations I always have is like the successful open source projects tend to be large infrastructural pieces databases, operating systems platforms they don't tend to be like little applications, they don't tend to be differentiation stuff they tend to be big stuff and part of that I think is just has to do with that you actually have to create something that addresses a large enough audience of concern that you can find enough people to support it because you're asking for small contributions at scale in order to create this space right? You get this weird thing where the negotiations that you pointed to about like I want it to do this versus we need it to do this these kind of like edge cases versus core cases and things like that all that stuff is part of the negotiation that I think is critical for large enterprises to understand because right now the way that I generally see one of the big problems inside of enterprises that looks that is at least fractally like what you just described is lots of business units building something that is initially only valuable to them but eventually becomes valuable to other business units and then they don't have anywhere to put it they don't have anywhere they either going to put it in the centralized IT department which they believe will destroy the value of it and make it harder for them to use or they keep it for themselves and so they don't have a way of creating a community around a common resource they don't know how to do that and so that's part of the transformation journey for me is to help them and help other communities understand that certain things are only valuable when they are shared at scale or that they gain value by being shared at scale and they don't go down it goes up for everybody involved and that's the trick is to try to figure out how to get people to understand the economic rationality to that and then my only last weird little comment is like we only have so many people how do we deploy them well economics is the study of rare resources applied to hard problems that's the whole idea of value is rare resources being applied and the question of any economic rationality is how do we apply that rare resources to get the most value in our economic frame and part of the importance of understanding the scope economy is to say that the other two economies literally destroy the value of the commons so we need to understand this other economic resource and this other economic rationality in order to deploy the limited resources we have to create the most value we can that's the fun little weird part of that Ben who I think is one of your colleagues had a comment in the chat he says I fear commenting isn't a value commonly held what behaviors do organizations start changing towards valuing recombining and I would actually answer that quickly that one of the things that changed it for us in the open shift context was looking at it as an ecosystem so when we realize that we were more than just depending on the stuff or making a profit from the stuff when we changed our world view or our paradigm to be more ecosystem focused that was something that then shifted everything at least within our organization and within the commons and I think that's one thing one behavior or way of thinking that changes things to make people understand commenting as a thing and recombining so there are other people who have other concerns that are involved in the thing that I'm involved in and if we all optimize it for our personal concerns none of us will get what we want absolutely so how do we negotiate that where we are basically volunteering to limit our extraction of the system in order to make sure that we can extract from the system there's nothing wrong with profiting off of the commons people do it all the time it's whether or not that profit is sustainable and how the ecosystem effects of that profit apply and that's exactly it the economic sustainability of the system that we're looking for and the other thing I think that's really interesting and this is where that jellyfish research comes into pack is the impact of our work and other people's work on each other I think a lot of what happens in enterprises we aren't aware of our peers and what they're doing and what the impact of what we're doing is on them and they're not aware of what they are doing so the more we can do and this is where I go back to the ecosystem approach for community development people understand and figuring out ways to visualize to surface that information of how we are connected to other projects like how when open tracing or Jaeger or some other project does a new release all that filters down to the open tracing functionality that built into open shipping Kubernetes and I think at a large scale one of the things that we need to work on better whether it's at CNCF and the foundations or Linux foundation or any of those folks or in the commons or just in general is building tools or ways of being visually being notified so connecting that because the first step for me has always been awareness of others and if you aren't aware of other people in your space or other use cases or whatever it is same thing applies in an enterprise if you aren't aware of what's going on in those other styles and even at Red Hat you've seen things like a product get released that has ripple effects on other people and it's not even you know all open source and you think we'd be good at this but every once in a while someone will release something and be like holy crap Ignition 3 whatever those kinds of things I think that's when we talk about I like using the concepts that people are exploring with observability to point out what you're talking about one of the things about observability is to say what conversations do we want to what decisions do we want to be making how can we make the system that we're managing together visible how do we get the data we need to make those decisions together so that everybody understands the decision because the data is presented in a way that makes sense to everybody there's a great set of literature around this idea that one of the things about commenting and recombining is that in privatized systems or in centralized systems the decision structures and the data presentation can be narrowed because it can be narrowed to either address the private owner and or the governing body but in commons the data has to be presented in a way that everyone participating in the commons can all understand what the data means and therefore we can make a decision together based on a common understanding what the data means there's a whole set of what observability does inside of a system and how you make things more visible and then the other thing is making things observable in a way that modifies the behavior of people participating in the commons so that you support the ability to maintain certain behaviors by showing people helping them understand what's happening so I think exactly you were using the concept of visualizing but communicating this information across an ecosystem in a different way frankly than the hierarchy summarize up because that's not really what we're talking about here and that doesn't work particularly well and it's also not necessarily about addressing a governmental body who would give you like here's a standard sheet form for you to fill out to determine whether or not you are fitting best practice right now and therefore are pre-approved to continue right both of those are extreme opposites of the type of interaction we want to point at I think I think and there's a lot of three cheers you know observability for the win and good things in there and I know one of the as much as I say things like I must sound anti foundation I'm not like I do a lot of work with the CMCF and all of the different projects there and if you ever look at the landscape diagram for the CMCF it's just chaotic and crazy there's so many projects and things at different levels and even within like breaking down within red hat the barriers for everybody not just upper management but participants in different engineering projects and that to see where all of their colleagues are touching points inside of that ecosystem so if we break there's the openshift ecosystem which is expands well beyond just the CMCF stuff but trying to create I hate to use the word dashboard but a way that's open and transparent across just red hats this is an enterprise problem inside of red hat is letting everybody know who's participating in the CMCF we've got people working on all kinds of sakes all kinds of projects and no one place where they can all go to see observe shall we say where their colleagues are at and where there are resources from red hat alone and I know that's not existing inside of CMCF in any way so there's this whole idea and I think we are just at the very cusp of it it's not what is this silly phrase it's not what we know but what we don't know we know or what we know it's what we don't know that we don't know it's the physics of the thing it's like it's crazy and until we can observe it we really can't do much more and I think we're only right now in the recombining of open source or my efforts around open shift commons at the awareness level we are aware that we don't know stuff and that's actually a good place to be because that makes us aware of the opportunities definitely so there's one other person who's just labeled guest who says much of this sounds like de hock's ideas about chaotic organizations could that be correct so I think that there's probably some relation between this and chaotic systems to the extent that to the extent that de hock is trying to point towards other forms of governance as potentially more optimal than highly ordered structures so I think he kind of maybe lays out what I would think of as kind of a gradient between highly structured highly ordered hierarchical structures and anarchistic structures and tries to point towards things like what would eventually become holocracies and things like this and I think that's interesting the thing that I would point to that I'm not sure enough about de hock having not really studied him particularly deeply I'm not sure that he shares what the three economies is saying in that the three economies model argues that all three different economic systems need to coexist it's not we're not trying to replace the other two economic systems we're trying to mediate the other two by creating a third and that's not true for all organizations like I would assume that something like the OpenShift Commons needs to just be a commons it doesn't need to have those other structures but if you are a enterprise you do need to care about efficiencies and you do need to care about differentiation and solve for those problems and I think you can't do that effectively over a long period sustainably without creating this third economic paradigm inside your organization and like really quickly one of the ways to think about this is that we've gotten really really really good at creating software quickly and that has created huge amounts of sprawl and redundancies inside of enterprises and I mean just go to any open source repository and there's like 16 different versions of the same project all owned operated by different people trying to solve the same problem now again nothing inherently wrong with that but in an enterprise there is because that is long term maintenance of redundant functionality and data siloing of different functionalities inside the organization and frankly a lot of politics happening between business units about ownership that are not productive or valuable for the organization and therefore if they had a way to rethink what it means to own a common resource then they wouldn't necessarily need to have those conflicts because they would want to put as much of their stuff into the comments as possible once they had identified it as being commonly valuable and then they would want other people to adopt it and accelerate the use of it because they would know that that would increase the likelihood of being sustainable over a long period of time so there so there there's so much there there so I think that we could probably do this every week have this conversation and I really think that I want to keep diving into some of this stuff with you on a regular basis and with Ben and other folks and Barbara yes I definitely will I think this is really valuable and thought-provoking stuff because one it informs me as I do the community development for Obershift and as we bring these what I try and do is hopefully lead by example but also to really be open to new ways of engaging with communities and building out platforms and tooling and whatever it takes to make this ecosystem live and breathe as you all are probably trying to do for your enterprises and I think it's not what you can do for open source or not what you can do for the enterprise it's what we can do for each other and that I think is the crux of all this I think and I will have to tease this out on this I think I'm going to have to digest everything we've talked about here today a little bit in this video again but I kind of think that commons or what we're doing with Obershift commons is that scale economy it is that thing in the middle and it doesn't get rid of either side and I think now if I understand things correctly what we're doing in these conversations is flushing out how to scale the scale economy and how to build the base to be effective and that I think is a great thing to keep doing so on that I'm going to bring this to a close because we've gone over 20 minutes and if any of you are listening want to be part of this conversation or have some theories or practice or lessons learned doing this kind of transformation within your organizations please reach out to jabe or myself at commons.obanshift.org you can join the transformation sig I don't think it's on the home page yet I think I still have to do that but I will shortly just reach out to us you can find us on Twitter and we will definitely give away the podium that is my whole shtick in life as much as you think that I like to talk I don't even like the sound of my own voice I much rather give jabe talk so thank you all for joining us today again this will all be uploaded on YouTube and available on TwitchTV to listen to in your leisure and go back make sure everybody's bedtime story is stone soup please still get a copy from the library go buy a copy whatever it is just find it and read it it is the book I grew up with and I think it really formed the basis of free open source Diane how things go thanks for watching