Welcome to Building Tomorrow, a show dedicated to the ways that tech and innovation are making us happier, healthier, and more prosperous. With me today is Matthew Feeney, Director of Emerging Technology here at Cato. As usual, I'm your host, Paul Matzko. And joining us is special guest Brent Scorup, the Senior Research Fellow for Kind of All Things Tech at Mercatus. Welcome to the show, Brent. They grabbed me. So today we're going to discuss your plan for new drone, a new kind of drone and light aircraft. And so, but I think before we get into the details of what your plan calls for in terms of regulation, let's lay a little bit out about where are we at with light aircraft, the drone airspace use? Like, where is this tech pushing us as consumers in America? There's, because of various technology advancements over the last few years, what most people would call flying car technology, I try to avoid that term because people roll their eyes and there's stigma. But when you're like in newspapers, you have to say this, so people kind of understand what it is. But flying car technology, air taxi technology, it goes by various names, vertical takeoff and landing, VTOL. So all these are somewhat interchangeable. And because of various technology advancements, as I mentioned, things like battery improvements, ride sharing software, autonomy improvements in the last 10 years, many companies around the world and governments are starting to think of air taxi service as a viable commercial service. But no one's quite sure how this regulation will work out. And I saw a room for a paper on the subject and about air-track management and these so-called passenger drones and VTOL aircraft. So whether we call it vertical takeoff and landing or flying car or air taxi tech, where are we seeing this being implemented? Like my understanding is here in the U.S., there's the promise of it taking place, but we're actually seeing experimentation elsewhere in the world. It seems like most of this is going on in other countries. New Zealand pops up frequently. The government is fairly accommodating to companies in New Zealand. I think it's Sergey Brin of Google has a company called Kitty Hawk that is doing a lot in New Zealand. China is a major player and they seem to be doing a lot of work in China, but also Dubai. There have been some test flights of autonomous VTOL, autonomous air taxis. The European regulators recently, a few weeks ago, put out proposed regulations. They're starting to think about this commercial service. And the U.S. seems to be lagging a little bit. The U.S., I should say, has a very commendable safety record, but that also means they're very cautious about this. Maybe give us a sense of the actual capabilities of the technology as it is. Are we talking about a technology that is really in development or something that's being kept grounded? If today there were no regulatory barriers, could you and I get in one of these on the roof at Cato and fly to Dallas Airport or would we crash on the White House lawn? How far would we get going? We could fly today in one of these battery powered. And I should say there are what's called EVTOL, electric VTOL, which are battery powered, of course. And the range seems pretty substantial, 50 miles perhaps, and they can carry multiple people. And I should say the capacity for these, typically one to six passengers at six is about the highest I've seen. And that's EVTOL. There's another related technology, hybrid VTOL, which is battery fuel hybrid. And those can do several hundred miles and similar to commercial aviation. And these have different issues. I think the EVTOL is more exciting because that's an entirely new market. You're just interested in getting across city, getting into the airport. And getting to the airport is what folks think will be kind of the immediate market because going from downtown areas out to the outskirts where the airports are and you just have business customers. So all that to say, yeah, you could hop into one of these today. I'm not sure I would do it today. There's only been a few flights that I'm aware of, but yeah, you could do this today. Who wants to be the guinea pig for, yeah, someone will. Some brave soul. But you can imagine the attraction, which is we live in a congested city here in D.C. or if you live in New York or any kind of urban center where if you can do just a hop, a 15-mile hop from the suburb into the center city might take you 20, 25 minutes in one of these air taxis, but that's an hour, two hours in bad traffic into the city. That's a significant savings in time if you can just go kind of as the crow flies. But as you're describing this, I'm just thinking, well, that's a helicopter. So how does this differ from a helicopter? Is it just a helicopter? So as we think about this, why is this such a big deal since we already have things that vertically take off, move, and land somewhere else? So some of the benefits relative to helicopters, one is noise. It's expected these will be not quiet, but significantly quieter than helicopters and in urban areas, particularly in the U.S., one reason we don't have many helipads and helicopter infrastructure is because of the noise, inevitable complaints and the disruption. I live in Arlington, Virginia. It seems there's frequent helicopters. It's pretty disruptive. So noise is one benefit, lesser noise. The other is that helicopters, the single rotor means if something does go wrong, it goes seriously wrong. So with multi-rotor V-tolls, which might have between four, 16, maybe 32 rotors, and they can all be independently controlled, if there is a problem, these can still stay in the air and still land safely. Maintenance on helicopters, similar. Particularly with the engines, there's a lot of maintenance and it's a huge ongoing cost for helicopters as maintenance. And it's expected with these electric motors, the maintenance will be much less. So when we're discussing this issue in particular, I suppose it would be worth plugging the actual paper. So anyone listening can go to the Maketa Center's website and take a look at Auctioning Airspace. And the title is, I guess, sort of revealing the conclusion, right? Why are you taking approach of Auctioning Airspace? People might listening who don't follow aviation policy might be thinking, well, who ends the air now? And how would this change things for me, just a homeowner on the ground? This paper comes from... I've done a lot of telecom history and policy. And as I was learning more about this technology, I thought there's a lot of analogs with spectrum policy in particular. And in this paper, I look at analogs of federal property that is owned nominally by the people. It's managed by federal governments. And we have many examples of federal government auctioning federal assets off for commercial use. And spectrum is a big one. The FCC has done spectrum auctions for 20 years now. Gained a lot of revenue. Companies have a semblance of property rights to make the investments needed in these capital-intensive industries. Offshore oil leases in Gulf Mexico in particular. This is federal property. It's auctioned off on a geographic basis like spectrum. And companies, again, have the investment incentives necessary to build and to operate oil extraction. A newer example of this is offshore wind energy, offshore wind mill sites. These are auctioned by the federal government as well. So we have all these examples. And I think airspace resembles these much more than, say, a roadway, which is kind of a traditional open access. It's just an ancient tradition that roadways and rivers are open access to the public. And I think that's the wrong model. I think an exclusive use model works better. And the difference of airspace, and airspace is, has been, it's owned by the American public. It's owned by UME, but it's managed by the federal government exclusively, all navigable airspace. And so anyway, this proposal, I think this looks much more like spectrum or offshore wind energy where you need large investments and unlike roads and rivers, there is no history of mass use of this. And people might say, well, why don't we auction roads or rivers off? And I think one answer is that we don't have millennia of practice of humans actually accessing this. It would be hugely disruptive. And the other thing is our roadways, we have 30, 40,000 deaths a year on roadways, and part of that is because it's open access. No one would tolerate that in airspace. You need much safer airspace. And so for all these reasons, I think an exclusive use model, and I make clear on the paper, I'm not saying air taxi companies should have fee simple, complete private property to this for various reasons. I don't think that's the right model. I think much like spectrum. These are conditional multi-year licenses with many attributes of property rights, but not fee simple. Well, let's dig into some of those bits here in a second. We'll talk about fee simple property and auctions in a little more detail. But I think some of our listeners are going to wonder, well, why do we need to change anything? And to understand that question, they need to know how does it currently work? If you were part of a startup that's creating an X-Gen VTOL, what does low altitude airspace look like for you? Who gets to use it? How is it defined? I know there's different classes of airspace. There's restrictions on how the airspace is used. So dig into that a little bit for our listeners. How is that airspace currently used? Yeah, it's great. It's important to back up and say what my paper covers. So my paper, and I kind of draw these lines arbitrarily, but there is some thought behind them, is airspace above 200 feet altitude all the way up to 5,000 feet altitude. Is that below or planes? Yeah, yeah. So in planes, I think 30,000 feet, 35,000 feet altitude. So this is fairly clean federal resource. There's not many users. There are some helicopters, hang gliders, some generally small aircraft. But this is a fairly clean federal asset. So I want to make clear in the paper, it's not talking about drone airspace. I think there are entirely different issues with very low altitude, below 200 feet. You have property rates of issues and other things. So it's 200 feet all the way up to 5,000 feet. And this is where people expect V-tolls and air taxis will occur. And so right now that relatively low altitude space is just kind of a free-for-all. Anyone can use it as, I mean, so if you're a hang glider operator, you don't have to go get permission from the FAA to fly your hang glider in that space, right? Or, I mean helicopters are though regulated by the FAA flying within that space. So how does that, like why couldn't V-toll operators, why do they need to do what you're proposing? Why can't they just keep operating like helicopters or hang gliders or small aircraft that fly in that current space? Well, right now a big obstacle is the federal government hasn't quite figured out how to classify these. And there's various ways, you know, are these fixed wing aircraft? Are these like helicopters? So they need a regulatory classification. And the FAA does tremendous amounts of pre-approval certification of airworthiness. And so right now these have not been classified by the federal government and therefore can't fly. There is a waiver process, but that's ad hoc and you can't really develop an industry that way. So you could do it, but not, you're in a legal gray area and I mean that's trouble. Right, and it should be said, none of these companies are looking to move fast and break things as you might in, you know, with software and internet-based things. I mean, so these companies, they want this industry to be safe. They want to cooperate with the federal government. And to NASA and FAA's credit, they have been fairly accommodating. They want to see this develop and they're working closely with companies about how to make this safe primarily, but also efficient in a commercial market. So when people say, or when you say more accurately, a auction of airspace. Are you talking about auctioning layers of airspace or someone could auction a thousand feet to 1,100? Or are you talking about auctioning, for lack of a better analogy, roads in the sky, certain specific geographic lanes? Or is it a mixture of both? A mixture, a mixture. So it's hard to say at the outset what the best model is. You gain flexibility if you've kind of auction off cubes of airspace. I say in the paper, maybe about neighborhood-sized and a few hundred meters tall.  Companies, if they acquire a bunch of these, they can change routes as time goes on. They can put these vertiports, basically huge helipads at various parts in the city as demands change, as new customers come online. I think the fixed route auctions, I suspect... Well, it should be said, companies are already expecting there'll be fixed routes for safety reasons. What they envision though is much like traditional aviation where these routes are shared by competitors, like commercial aviation. They share terminals, they share routes. My paper is trying to avoid the sharing of routes and terminals. I think you create all sorts of problems and many of the things we hate about traditional aviation arises from the fact that competitors have to share terminals and routes. What about the issue that will inevitably arise? You mentioned Arlington, Virginia, where I live too. I can imagine a lot of my neighbors not being particularly happy if suddenly there were dozens of these things buzzing overhead. Even if they were at 1,000 feet or 1,100, do you envision some kind of mechanism for firms to deal with the privacy and noise pollution complaints that people will inevitably have? I think the noise issue is possibly one of the biggest obstacles. Aside from, I think the technology is advancing fairly predictably and will be there soon if it's not already there. The regulatory system, it'll eventually happen. I mean, what scale will these be commercial? Eventually these will be permitted. The noise, the public acceptance, I think could trip this industry. I think a lot of it is education and particularly with officials at the local level. In traditional aviation, Mercatus put out a paper a few years ago. I can't remember the exact numbers, but you see a power law of noise complaints. Basically, in D.C., for instance, I think there's a handful of people, maybe five people, who make up a massive amount of the noise complaints. I think data analytics is just showing that there is this power law. It's a few people who, for whatever reason, are sensitive to these noises. I think there needs to be research about how loud are these? There's studies going on, if you follow this industry, about noise profiles and ways of what people can handle and baseline noise. I think it's a fruitful area. I hope the companies and the federal government will continue to study this. Maybe someday it'll be a safe harbor. If you're below this decibel level at this height, then you're presumptively approved. The noise is a serious concern. Which puts me in mind of something else, which is that one of the early complaints about the beginning of vehicular transportation on the roads, on the cars, was that they were loud.  But especially those early pre-muffler engines, vehicular traffic was really loud too. People were concerned about the externality created by loud cars going through residential neighborhoods. And we found a way to solve that. And it was a long conversation. To some extent people just got used to it. I mean, we have cars go outside of our houses. And there are, in a sense, we price that noise into the price of our houses.  We recognize that it creates an externality. We manage it through education. We manage it through different regulatory means. But it wasn't something that, you know, we were able to overcome that barrier. This brings me to mind of something Matthew, you mentioned before the show, which was, I mean, so if we're thinking about roads, road lines, as a way of directing traffic, and among other reasons to keep the noise and kind of define corridors, how might that apply to airspace? Oh, well, I've been working on drone issues for a while, mostly in the law enforcement context. But of course, we're having to consider commercial use of drones. And everyone's very excited about delivery drones and talking to people in the building. Yeah, I haven't published anything on this. But there is an ongoing debate about, well, what would rule look like if we just said, you can fly drones, they just have to go above current public space. So as long as you stick to the roads and you're flying above them, then you're fine. Just as a way to avoid the inevitable problems of people complaining about privacy issues, people shooting them down with shotguns, all these problems that you can imagine having. But I think this technology raises different kinds of issues. I think people are going to be less likely to take a shotgun to something that there are human beings inside of. And yeah, one hopes. And there's obviously probably in virtue of the fact that they'll be bigger, less chance of them actually flying above a lot of roads, depending on the altitude, right? But this is, of course, a difficult conversation because of current regulation, which is why I think we need proposals that, like Brent's, that are talking about, how can we think about airspace differently? And the road analogy, I agree with you, I think there are serious issues with that. But something that did occur to me when looking over some of the material, how do we stop in a monopoly emerging here? What's to stop if we had an auction system and it's a tracks system where you have these airlines? How do we ensure that a little startup is able to actually get in the air if Google, for example, or some other big company has come in and bought all of the airlines? So I think we can learn some lessons from spectrum policy and again, offshore oil, at least. So typically, to prevent the monopolization problem, there is a cap to what one company can control in a market. I haven't looked at this too closely, but intuitively that seems to make sense for me.  And so you can imagine some kind of cap on what you could control. The other thing is just what's the size of the air tract that you're auctioning off and just how those auctions are carried out. You can prevent monopolization problems. I say in the paper, for instance, one auction off one tract in Washington, D.C. would clearly create a monopoly problem.  That would be an excessive, everyone could afford a piece, but you would have a fragmentation problem. And in the paper I say, again, it's hard to say at the outset what the optimal competitive size is, but I would say somewhere around neighborhood size so that you could have multiple providers per city. But again, and what the government does with other auctions is they consult with industry about what size is practical and they also need to ensure that there is competition. And just a second for our listeners, think about this in 3D. So you're not getting all the air in that whole range. It's layers. Do you have an estimate of how thick those layers should be? So between 205,000 feet, how many layers are we talking about? Are they 100 foot wide or tall, I suppose I should say? Yeah, I haven't even gotten that detailed yet. I mean, I would expect a few hundred meters tall just to give plenty of buffer and allowance. But we're talking about potentially dozens of layers in this space. Yeah, and also if they are on a cubic basis, not on a route basis, that opens up because it's just 3D. Even if a company, let's say if you're in D.C., a company has a foggy bottom for a deport station and they're flying to Dulles. And another company has a Capitol Hill station, foggy bottom gets in the way on the way to Dulles, but with 3D you could acquire parcels that would go around and still get out to Dulles. So yeah, the 3D nature of this opens up more competitive options. It might not be a perfectly direct route, but it improves the competitive potential for this market. One imagines that innovators in this space would want to have entry as frictionless as possible. It seems unlikely that a firm would say, yeah, well, we're just going to fly these 300 feet over people's homes and we'll deal with issues as they arise. But presumably they are aware that there will be growing pains and concerns and will take steps. But that's just a guess, who knows what will end up happening. Never underestimate the willingness of an uncaring corporation to be like, eh, we'll figure it out. This made me think of something that we're on our notes. Have there been any preemptive discussions about the potential environmental impact on these? Are these going to kill a lot of birds? Are they going to freak out animals? Is there any kind of discussion about that yet? I haven't seen anything about that. I guess that's a when, not an if question, right? Functionally, that seems like a non-unique problem to your plan. You put more stuff up in the sky, it's going to run into more birds, it's just the nature of it. No matter how you end up managing the airspace, it's just a question of filling that volume with more objects. I suppose the reason I'm asking about birds specifically is not just the potential environmental impact, but a few birds can bring down a commercial airliner, right? And I don't know what the safety issues are with this technology in particular. Brent obviously knows more than both of us, but if a bird flew into one of these things or got sucked in above my house, and it fell in my house, that's something people would worry about. Yeah. I haven't looked at this issue too closely. I do think the multi-rotor, independent rotors is a big safety benefit, whereas a twin jet engine, one or two goes down, it's pretty catastrophic. But yeah, I haven't looked into it too closely. I do think it's interesting, so I know folks, this is not an original thought to me. In fact, I think I've heard it brought up at some of our gatherings before, which is, you know, this tech can be kind of geotagged, right? I'm talking more about drones, but I think this can also be applied to air taxis or the VTOLs, which is that you can tell the drone not to go within so many yards of a military base, of other sensitive airports, other sensitive locations, and now that can be hacked, there are concerns about exactly how effective that is, but for 99% of ordinary users, it's pretty effective at keeping drones, or potentially effective at keeping drones away from sensitive places. So, in theory, you can program those drones to stick to their lanes. I mean, I think that's quite interesting, or if you only auction off the airspace over roads, over, you know, already public land, you can make sure they stick to their lanes, which helps mitigate some of the problems we're describing, which is that if a bird does hit one of these things while it's flying over a highway, and the thing comes down that much better, but it's not come down the house then, so the externalities are a little bit different. I mean, at some point, one of these things is going to come down. At some point, if it lands on a car, well, cars have accents. I mean, it's going to generate some externality just because things moving run into other things eventually, and injury, and death, and torts are generated by that, but there's a way of making sure that it falls in areas where we currently expect death, injury, and torts to take place, which is on highways, or, you know. Yeah, you could take that approach, Rachel. Yeah, I'll just say on that topic, this geofencing is going on today with commercial drones, and I know DJI, which I believe is the biggest drone manufacturer in the world, I think every drone now, they have this geofencing capability, and the FAA even has the beginnings of a real-time geofenced system where a drone operator can get real-time permission from Air Traffic Control and the FAA to fly.  In talking with a drone operator, the altitude is a little trickier, but the geofencing, yeah, that's fairly well understood. Do you see these competing with logistics or delivery companies? We've been using the word taxi, so the idea, I suppose, being that these kind of devices will be competing with Uber or traditional taxis. In your research, after doing research, do you think it's actually feasible that they could be used for short-haul Amazon deliveries or things like that? I'm not sure. I expect drone deliveries will cover most of this, and thinking about this, it would have to be fairly heavy that you would need a larger than a drone. I expect there would be some, particularly maybe with large medical shipments. I met at the Uber Elevate Conference, which is kind of devoted to this air taxi industry a few months ago. I heard of an entrepreneur who wanted to do this for, I believe it was pig heart valves and just the immediacy and just kind of organ donations. There's all kinds of ideas out there. I don't know if human organs or animal organ and that sort of thing, but I think in Madison particularly, this is just drone delivery particularly in Rwanda. I saw recently Rwanda, 35% of blood donations to hospitals delivered via drone at Rwanda, and there's a company called Zipline that does this. Medicine seems, what drone delivery seems like a useful application for this. A few other concerns that I think folks, particularly our listeners who tend to skew, a little more libertarian, a little more skeptical of government regulation in general, I think one of the things that's going to pop up in some of our listeners' minds is, well, why should we have a one size fits all FCC, federal government agency policy? Why are there federalism concerns here? Why shouldn't this be left to the experimental laboratories of the states or of municipalities to determine how they want to regulate drone airspace in their town or in their state? Your whole model is predicated on a federal model, the FAA, sorry, auctioning off airspace. Why is that? What's your answer to people who are concerned about federalism issues? Yeah, there are important federalism issues and in short, my paper tries to avoid all that. The airspace I'm talking about, 200 feet and above, I don't know where that line will be drawn. I expect the federal government will need to draw a line at some point and say, what is covered by the jurisdiction of the state and what is federal? Right now, all navigable airspace is federal and according to the FAA's current interpretation, that means two inches off the ground, outside is navigable airspace. The model, I think, will eventually see as much again like offshore oil where in the 1950s, I think it was the Submerged Lands Act, the federal government said three miles out is controlled by the state and the state controls how that property is managed, but beyond three miles generally is federal property. We haven't had this issue before of multiple parties at different layers in the airspace. My next paper, I think, we'll talk more about these federalism issues and that deals with below 200 feet. Above 200 feet, though, it's my belief and assumption that this should remain federally controlled. In a sense, though, this paper is kind of agnostic to the question of who should be controlling which regulator should have oversight. This is the way it's currently done, but in theory, the real model is the auction model, not which regulator gets to, in a sense, run the auctions. You're dealing with the lay of the land here. One more question that came to mind on kind of the same theme. You're going to have folks who look at this, and for those of us, I also come from kind of a telecom history background. You've referred a couple of times to spectrum auctions, so like radio, television, wireless spectrum. Back in the 1920s, there was a debate over how should, essentially, it was the same kind of debate. We have this new technology that's allowing us to access electromagnetic waves and turn them into commercially useful endeavors, radio at the time. Who gets to regulate it? How do we determine who gets a hold of it? And there were a couple of models that were proposed, one of which was kind of a British-style national monopoly. The BBC, the British Broadcasting Channel, would just run it themselves. It was a national monopoly. So that'd be like the FAA, we keep this airspace, we control it. In fact, everything that flies in it, we essentially get to determine where it goes. We might even own it ourselves. If there was a very command-and-control model, then there was a, well, we'll kind of issue licenses, a license model, which we did here in the United States. You get a radio station license to operate on a particular wavelength. Later on, a kind of libertarian-leaning economist proposed an auction system, COS. Coase? COS? COS. Proposed an auction system, kind of like what you're proposing. But I think there's folks who are going to say, well, why should we do this auction system? Why can't we just do command-and-control? So what are the problems with these other models of running what we do with VTOLs? So the auction system for Spectrum has, I mean, part of the model for this is Spectrum auctions. The allocation via auction on an exclusive basis for multi-year periods serves a few benefits.  It can be used for anything. So Spectrum could be used for broadcast TV, it could be used for cellular, it could be used for satellite, all these things. And with auction, the government is auction off a commodity that's flexible use. Companies can use it in whatever manner they wish. And this has helped make the US a leader in wireless technologies. Companies can change their technologies without government permission, unlike in the 1980s. Yeah, the auctions in the 90s, but the flexible use, yeah, so this has all been fairly recent. And as you're familiar, the FCC used to be, they would dictate what the service had to be, where it could be, and they would give away for free based on some imaginary public interest evaluation. Which was bad for innovation. Right, terrible, terrible for innovation. And it basically politically connected, got access to this federal asset. And that's been much improved. It's night and day, once auction started, companies could make their investments, they could transfer something valuable to a newcomer if they designed a better mousetrap. And you didn't have that in the past. So the same thing with airspace here potentially, which is that we want to avoid underutilization of the airspace because folks, you know, like we don't want to stymie the innovation that's going on, the competition between these operators. Yeah, so what I fear with low altitude airspace that we're talking about with VTOL and air taxis, is that if this technology does succeed and there is commercial demand, how do you allocate it? And my fear is they allocate it for free to whoever is in the market at the time. And this is basically what happened with traditional aviation where once the jet age came, you had tremendous congestion problems, for the first time you had to figure out how do we allocate this federal asset. And in the paper I point to, in New York City in the late 1960s, much of U.S. aviation delays were based in New York City in the three airports there. The Air Traffic Control, they raised landing fees $20 in 1968 on all small aircraft called general aviation. General aviation traffic plummeted 30% with that $20 fee and delays fell over 50%. That's a remarkable change with a very small fee, $20 per landing. So that just suggests there was tremendous amounts of low value flights going on because it was unpriced. It was clogging up the airspace for other more efficient uses. And so that's why I'm worried, particularly in a fast moving sector like VTOL, where we know there will be advancements and companies will design better systems. If it's allocated by agencies or in cooperation with the incumbents who are already in the marketplace, which is what happens with traditional aviation, you harm the innovations, you harm the innovators who want to enter the market. The incumbents have nothing to transfer because they're sharing this resource with regulators, with competitors. And so that's why I want to avoid. I want companies to have something to transfer if someone better comes along. And so you need exclusivity for that. And on the congestion, how do you allocate in times of congestion? A few months ago, NASA put out a report on this very topic. NASA and the FA are doing regulation of this sector. And they say our plans right now, which is basically a centralized allocation mechanism, which might be some kind of public-private allocation of airspace, say this will work for modest amounts of traffic, which raises the question, what if there's not modest amounts? And they answer, they say, well, we as regulators will step in and allocate it on as needed basis. And so that's not it. I see all kinds of problems with regulators doing that. And it gets back again to Spectrum, where basically a politically powerful and the incumbents, I think, will control it. And I think that would be especially damaging in this sector, again, as I said, where this is moving very rapidly and we don't want to bias the regulatory system towards today's companies. There's kind of a perverse unintended consequence, which is that in theory, I mean, this happened for radio, which is that there were always concerns that dominant players in the marketplace, the big networks, would gain essentially monopoly control. And therefore, there was pressure on the FCC to implement regulations to make sure that wouldn't take place, to take a heavier hand, a more involved hand. But that actually played into the interests of the major, of the incumbents, because they were better able to lobby the regulators to tweak those rules in ways that favored them, to, yes, there was a lot more kind of corruption, regulatory capture. They also better able to just comply. They're big. They have lots of capital investment. They can, you know, they can comply. They can make better, more convincing bids for the licenses. So you end up with this whole system meant to, in a sense, diminish incumbent control. That actually ends up increasing incumbent control. Whereas if you auction it off, well, the folks who own that property, right, I mean, there's a kind of a natural competitive element baked into the system. You can't buy off the regulator to tweak the rules because someone else owns that chunk of airspace. So I find that quite interesting. So Brent, one last question here. So again, some of our listeners are going to hear this and say, OK, so I get why we don't want this to be like traditional aviation. We want to avoid the problems that came with the congestion that came with the way general, general aviation was handled. I get why an auction is attractive. Why, though, and you say this in your plan, and you've referenced it here in the interview, why can't we just make this fee simple property? Why can't we completely deregulate the airspace? Why do we need any kind of regulatory oversight of this at all? And that's going to be a default position I think a lot of our listeners are going to be attracted to. And I should say this was a tempting idea to me initially. And I found in the course of doing my research, I don't think that would work well. And this cuts against some libertarian tendencies and free market tendencies. But I came across, and to shore up my libertarian cred, I came across a bunch of Richard Epstein essays about, and he's a prominent free market libertarian law professor who writes a lot about property, dating back to the history of property all the way back to Roman times. And there's this idea that you find, and it's a fairly ancient idea. There's some property that is collectively held by the public. And Epstein points out, when there's congestion, it's not unheard of, and actually it's pretty useful. Occasionally, you have to be careful not to take this too far, of course, and there's more in my paper. But occasionally, when there is congestion, it makes sense to have a single owner, and sometimes that single owner makes sense, it's the government. He points out the example of in England, in the 17th century, navigable rivers had, via the common law, acquired basically state ownership and management of the rivers, because it was impossible, the holdout problem is one factor, and also the free writing problem is another. So with navigable rivers, you couldn't coordinate all the owners on the rivers to do things like dredge the river and make it commercially viable for those upstream. So you have all these, particularly in transportation networks, and transportation networks I think are special, even Milton Friedman conceded in a paper a few decades ago that downtown road networks are always going to be controlled by the government. And it's because this holdout problem and free writing problem, they're just intractable problems, it makes sense to have a single public user. Now, there's all sorts of debates about once we set that out, how do you do it, and that's where my paper contributes, but so I don't think fee simple makes much sense. I trace this in the common law. There was this old doctrine that a homeowner owned property all the way up to the sky, down to the sun and the earth, and even common law courts started eroding that once you had airplanes, the beginning of airplanes and blimps and other things, and I don't want to go into the history too much, but it's in the paper. I think I hope it's persuasive to people, and Richard Epstein has done tremendous work on this idea of public trusteeship and when it makes sense for a single owner, a single government owner. Well Brent, thanks for coming on. I think all three of us, I mean, whether or not the exact particulars of this plan make sense, and like even as you said, there's room for tweaking within how many layers and how large the units, the cubes being auctioned and exactly who's running the auction. So there's a lot of room for maneuver kind of within this plan, but it does. I'm fairly convinced it's an upgrade over what's currently being proposed, which is just a holdover from traditional aviation. I can see the advantages of some kind of auction system bringing the power of markets to bear on the issue of what to do with this airspace. And I should encourage our listeners, we'll have a link to Brent's Mercatus White Paper up on the show notes, so take a look at that if you want to dig into some of the more nitty-gritty details. If you are compelled by the example of 17th century riverine water rights in Tudor, England, is it still Tudor? Yeah, I think so. In Tudor, England, you can find the link in Brent's paper. So thank you, Brent, for coming on, and until next week, be well.


All right. Thank you. Hello, everyone. This is the weekly TSC call. As you, I think, all know, given the list of attendees we have or participants we have today, or as Gary, here is coming. So you all know that we have to live by the antitrust policy, the notice of which is currently displayed on your screen, and the code of conduct governs the way we're interacting within hyperledger and to stay out of trouble. To get started, I just want to start with a bunch of reminders. As we talked about many times, there's the newsletter is still up. I listened to the recording from two weeks ago when Tracy you know, chaired the call. You guys talked a lot about breaking silos, and it seemed like the newsletter was referenced a few times as maybe one of the ways that could be leveraged to increase communications across the community. And that does imply that people jumping into the opportunity to use the newsletter. So please do consider the newsletter contributing to the newsletter. The Global Forum, the first period for the call for proposals closed last week, at the end of last week, but they have extended it. So you still have a few more days if you haven't managed to submit your proposal before the first deadline. And then the mentorship program, on the other hand, the period for proposals has closed. And so we are now going to review by the TSC members. And basically, we were asked to submit a review by March 24. So you should all have all the TSC members should have received an email in that regard. Please do respond. I mean, there's a lot of interesting proposals, but it doesn't take that much time to go through them and get an idea of what's there. So that's for the announcements. Is there anything else anybody wants to announce now? I don't see anybody raising their hand on getting off mute. All right, so we can get going. So quite a few reports. We've received two reports. So Silas responded to my prompt. I pinged him, you know, as Tracy pointed out in the call a couple of weeks ago when I wasn't there, that, you know, I told her I was going to ping Silas and I did and he said, yeah, I'm busy with release, but I will do it next week. And he did. So we have a pretty comprehensive report. As I had indicated also, it was pretty clear looking at the inside dashboard that they had a lot of activity, even though we had not heard from them in Hawaii. And it wasn't, you know, because they were not there and they had disappeared by no means they have. They have actually been quite busy working on their code and they have added a whole bunch of things. And you may have seen the report that they have a piece that they would like to socialize beyond their project because they think it's relevant to other projects. It's called vent. And so I've invited Silas to present. It will will take 20 minutes or so of next week's call for him to present to everybody what vent is about and how it might be relevant to other projects. Okay. Is there any other questions or comments on this. Otherwise, there was the there was a report from the Ursa project. There was no specific comments other than the usual please, you know, if they are interested parties, we're always welcoming input and feedback from others. So, I mean, this was posted yesterday so I understand that everybody may have had a chance to look at that one but if there are any questions, heart is here. I'm sure you can answer questions on the first part is there anything you want to add. Did I do a good enough job but bringing us perfect. That's perfect. Thank you. All right. If there is no comments or question. Go ahead. You can't hear you. I saw it. Yeah, so you raise your hand and unmute but we can't hear you Sean. I imagine shouldn't fighting with this machine trying to figure out which level has been needed. I would just like to make the bar. You come through by the various crumble that you can try. Can you hear me now. Very poorly, but we can hear you. Yes, I just wanted to make the point that apart from then borrow now has complete. No, sorry. I'd like to take the point that apart from. It's breaking up too bad we can't really understand. Yeah. Could you ask in the chat. In the, in the TSC chat channel, Sean. Because I see that. It's something about the room, but I don't know. He's typing. There we go. Suspense is killing me. Maybe we should continue anyway and we can get. Okay. Thank you and keep an eye on the TSC channel for some input from comment from Sean as well. Okay, so that gets us into the discussion. Part of the agenda. There are quite a few items I wanted to bring up today. The first one is with regard to the implementation of the decision we had made regarding the common repository structure and the use of people. We actually have a decision that was recorded. That says something about the fact that every repository should have a copy of reporting to just son file. This is the configuration file. As we discussed a few weeks ago, you know, we've realized this is a poor idea because it makes it, you know, it creates like many, many different copies, and it's going to become a maintenance nightmare. As we had said, we should try to see if we couldn't all use the same, you know, common repository. I mean, repolinter config file instead. I actually spend a bit of time. There's a, there's a way for repolinter. There's a, you know, an argument that allows you to reference a URL. You can actually download the config file from the net. And so I sent an email to the maintainers list instructing people to try and do that. And the idea is that so in the lab in the community tools repo, we have this config file that we can all share. There are changes that need to be made because you know, nobody says the config file is perfect as it is. We should try to change that one common file. And so I have asked people on the maintainers list to try to, you know, to experiment with it, and several projects already have reported success in doing so. If you have problems, please pick up, let us know what's wrong and possibly make proposal for changes, you know, you can submit a PR against the config file. Just keep in mind that it should be usable by everybody. So it's not a matter of just taking out what's the relevant to your project. And that's maybe one of the challenges is when you know this approach requires that we tolerate things that are maybe not relevant to our projects and sometimes repolinter sense, you know, it will report stuff. And typically they're not flagged as errors. They are more like warnings, and just have to ignore those, which makes the, the output a bit more verbose and a bit more, you know, kind of inconvenient to go through to spot the errors. But I think it's a small price to pay. Now, there are people who have reported problems running repolinter altogether. I personally have been using it against node version 12 without problems. But I know people have had problems. Dano has pointed out there is actually the fabric team actually put together a container that you can use instead. And so if you're not on maintainers lists, or if you know, please you should subscribe. I have to give, I want to give the right credit on the maintainers list work he has done. He went through, you know, major, how do I say that update effort to try to add as many people he could find, you know, scrubbing all the different repositories we have around hyperledger and adding people to the list. And I have to say, I've never seen that maintainers list with that much traffic before which is very encouraging. I think we need to try and do that more rather than less. I think it's a good claim that this list was pretty much silent always. And so I'm kind of encouraged to see a bit of traffic. And so this is one of the topics that you know I brought up on the maintainers list and so if people want to have, you know, guidance on how to do this or if they have feedbacks on the use of people enter, they should actually go to this list report and do some calculations, you know, that kind of stuff. I think it's a good progress. As I said, there are people who have had problems running it. So I said it doesn't work with the newer version of node. I mean, I don't know what else to say on that one. I mean he was saying we need better tools, which you know it's hard to argue against but I don't know. But this, you know, is a complete showstopper either. So I think we probably need to get to help repolinter to get better as well if we can at the same time, repolinter is produced by the to the group, which is just another, you know, bunch of volunteers. And so if there is a, if there are problems, we should just try to fix them and improve repolinter as well. So I don't know if anybody else has any comments or questions on this. I wanted to give an update. That's where we are. If my my idea is that, you know, I'm sensing that we are still following the right thread here the right, we're on the right path. And what I would like to do is, if we can confirm that this is a workable approach, I would like us to basically make a new decision that would override the previous one which was, you know, which said that we should all have a copy of the config file in the repo. And instead, you know, change that decision to say this is the common use the use the file that is shared by everybody as the config file. But I didn't want to jump again and make that proposal already. I figured well at this point is might as well keep continuing the experiment. And as people get, you know, we can sort out the problems, then it'll still be time to make that official. Roy. Oh, yeah, I was just going to say I don't think we're ready for that. It did make modifications to make that work in areas framework go. I think that's one point I think another point is just go rules in this thing. And I think a third point relates to what we talked about earlier that I think there is customizations for repos about like how to exclude certain files test files these kind of things. And I understand the idea that, you know, it just shows up as warnings but those warnings are kind of useless when you can't customize it for your repo. I'd rather create them as errors and actually have a very specific to the repo. So that, you know, if there's a license missing or any of these kind of things, all the all the files for that particular language are properly ignored, and can be addressed. So I'm not entirely sure yet that it's true there can only just be one, one file and I am concerned that, you know, this, we talk about know it a lot but what about go. You actually just touched on a question that I have, which is, can we do code based per repo overrides, like can we specify multiple config files. So I think it's a, you get to a fusion of both right, you have like the main one and then on repos where the main one is kind of two per both. You have the per repo one. Yeah, I don't know the answer to the question I agree it's a good one and maybe, you know, maybe even if we pull into doesn't do it today maybe be a good extension to try to get. Because I would be more comfortable with that if we had like a common config file and then we can say well, here's the way you can, you know, override some of the roles locally, but at least it would still kind of, like you said right get, you know, the good of both ways. Any other comments. Maybe in the end, you know, the decision is well, try to use the common one and if you have really a good reason then create a local copy. And that could still be, you know, a reasonable outcome. I still think it would be better than the general rule of just create a local copy, because creating local copies just for the sake of it is kind of just creating a problem of for no good reasons. So that's why I didn't like, I don't like the the current decision that's on record that says create a copy. But I can appreciate that in some cases this may not be the right thing either to use the common one so there may be some middle ground that we can find there. Sean did comment in the TSC. I'll read this into the record. Sean Young says, I just wanted to point out the borough now also has E-wasm support. This means that with Solang we can compile Solidity and run on borough. It works end to end. This will also work with other E-wasm tooling since fabric sawtooth and a Roa already use the borough EVM implementation, merging E-wasm support as well should be easy. So this would bring E-wasm and Solang support to those ledgers. So that's what Sean said. Yeah, thank you for reading it out loud so it can be on record. Thank you for pointing that out, Sean. All right, anything else? Otherwise, I think we'll pursue the experiment with repo linter and yeah, it goes.  Everybody has to kind of chime in and try, you know, try for your own repo and send feedback. That's the only way we'll be able to make progress and come to a resolution that works for everyone. All right. If we're done with that one, I don't see anybody raising their hands. We can move on to the next item. So I sent an email about that. You know, so what happened is a Chris Anisek from the Linux Foundation gave a presentation to the Hyperledger governing board on Monday about the lessons learned from CNCF and Kubernetes. And there was a lot of very interesting information. And the idea was, well, is there anything we can leverage to make Hyperledger a better place, you know, learning from other projects. And in, you know, I'll talk more about that in the next item. But one of the things that I found, you know, as we was going through his charts is, you know, they were he was talking about the different phases they have in their life cycle for the project. So they have something called Sandbox, which is very similar to the labs, very low entry barrier, and people can create that pretty, you know, easily.  And then they have something like archived. And so it's not very different from what we have. But as you know, we use the words active for the status, which is like, you know, the main one after incubation. And I, we've always had problem with this. It's been a very difficult thing to communicate. People interpret it, typically the wrong way unless they've been educated the hard way. So I, you know, I thought, wow, this is such a much better word graduated. And honestly, part of me was like, okay, but it's just not worth the trouble of changing the names we have. They forget it. But then I was like, no, maybe that's the wrong approach, we should be more proactive and say, no, we have something wrong. It doesn't work well. And here's a better solution. Let's just make the move and change the name we have. After all, you know, we do when I'm sitting stone, we can make those changes and if it's an improvement, why not doing it. So I actually would like the TSC to consider renaming the active status to graduate it. And as I said in my email, I think it has actually quite a few advantages over the current name. You know, active is just such a poor characterization of what is conveyed, right. You all know what's in the incubation exit criteria. And there's a lot of things way beyond whether you being active or not. And so, and then there's this, there was this notion that it was brought up several times like, well, maybe some project that, you know, did got out of incubation, they wouldn't meet the exit criteria anymore. And that's a bit of a problem too. We don't have this way of, you know, reevaluating. It's a one time thing. And when I was thinking about graduating I was like, you know, it's exactly the same when you talk about graduation. It's a thing you have done at one point in your life, typically you graduate from high school, university, college, whatever. And that's all it says. You graduated at one point, right. And so I thought this is much more fitting than what we have today. So I, I saw, you know, there was one person who said, yeah, I like this. I think that's a good move and nobody else commented on the mailing list. So, I don't know. I really don't know if people think this is just silly waste of time. If they say sure it doesn't no brainer. Or what, even a room we typically speaks up on every issue we raise. And that's a good thing don't get me wrong. I'm not criticizing by the means, you know, has not said anything. So I would like to invite the TSC member to speak up on this issue. Tracy. So I added a comment to the proposal or the decision entry that you had. We currently use graduated in two different places. And you can find that basically by Googling. But we use it when we talk about labs that have graduated to top level projects. We use it when we talk about projects graduating from incubation to active. So I, my concern is that we've already used the word for meaning potentially something else. And I'm, you know, wondering if there's going to be confusion over it. Okay, that sounds like a very concern. Thank you, Nathan. I liked the explanation that you just gave our know about the way we use the word graduation for kids in school, and how it's okay to graduate more than once. I think it, I, my main concern was the same thing that Tracy expressed that the graduating from labs versus graduating to act or to active, or becoming graduated I don't know how we will say that all the time going forward. But I do really like the improvement in the terminology in the sense that right now active projects apply that the other projects are inactive, which is a very negative connotation and doesn't do what we want to do from a community where as working to achieve graduation or putting more effort in so you can graduate seems like a much more reasonable connotation. And I think my opinion of that is the same one that you expressed earlier that it's an improvement in the language. It certainly doesn't seem to be. It's interesting. It seems like it. There are some problems with it, but it feels like there are fewer problems than what we have now. So, you know, if we just decided to vote on it I would probably vote in favor. All right, thank you. Tracy. Yeah, sorry. So Nathan, maybe think about how we might reward if we want to go with graduate it. So right now we say graduate it to. We may want to say graduate it from so graduate it from labs graduate it from the incubation grace grace. Yeah, just echoing. I like what Nathan and Tracy have said about, you know, active is not. It's really misleading to outsiders, especially for projects that are very active but not haven't had that kind of promoted status. So in the proposal I'd love it to be more specific as Tracy said, for the language of, I think, I think cnc f does promoted to graduate status, and the promoted kind of, and that kind of indicates that process. I have a question though and I apologize if I'm missing something, but the, are we going to be taking this decision kind of separately from the badging proposal. I feel like we probably need a decision on both the to then decide if we're using. I know there are some conversations about getting rid of the active and incubation statuses for the project badging proposal. I'm not sure where that sits so then it feels a little premature to then have this decision if we're not sure if this process is going to stay around. Beyond that, but but I could be. So just wanted to clarify. This is absolutely a fair question and you know, I have wrestled with that myself. It's like, we are working on this badging proposal. And there was this, but we haven't really, I mean we have said well maybe that would eventually replace the phases the status we have, but we haven't made the decision. And, and there are people I've heard, and maybe, you know, correct me if I'm wrong but I think I've heard people say they were not necessarily comfortable with that. And so I have come to the conclusion that well this the future on whether badging will easier to stick and whether even further than that it will replace the phases we have is highly uncertain and I thought, well, this renaming is a low hanging can do. And if we get rid of the whole phases eventually, well there's not much home. It's a bit of a waste of time admittedly, you know, there'll be some effort to update the docs, but I think it's still fairly minimal. And so I figured, well, I don't think we should hold off on trying to make the situation better, just because maybe down the line will have the badgers. So that's why I decided to, you know, bring it up anyway now.  Let's just go for the end goal of badging and forget this.  So, back to the, the, I wanted to clarify what you said Grace on the promoted. Are you saying where can you repeat that part because it sounded interesting. Is that a solution which we can avoid that we're graduated the way we use it today for labs to project could we say they've been promoted to project and then we can keep graduated for projects that go from incubation to graduated with that solve the problem. Yeah, that was the proposal I was making just because I think in the proposal we want to be clear on, yeah, that exact language just so that way every project can be using the same thing but yeah that that was one one idea. I think this is interesting. Tracy, I mean you brought that up which is again thank you because I did not realize that to admit. That's why we have more than one person here, and it is good. But do you think something like this could solve the problem or do you think it's so entrenched people talk about graduated project or labs to project. We can't really fix that we have to use a new term. I mean, I don't know. I think we're still hanging on to people who want to use the word hyperleder or the phrase hyperleder project, when and at some point in the past, it was changed to hyperleder. Right. So, I think, sometimes changing language can be hard, and it takes a concerted effort for people to do that. I mean, I've, I'm more than willing to make the concerted effort, if that's the direction that we had so I just think that we need to make sure that everybody is thinking in that way because otherwise I do think that it can get confusing. Right, especially if you say a lab graduated to top level project. Some people might take that to mean oh they're in the graduated status right. And that's not really what was meant by that right. They have to really make the effort to say that a lab was promoted to a top level project. Yeah. And I mean you know there are other issues right I keep wrestling with the fact that I mean, and I don't blame anybody. I say that sometimes people talk about lab projects, and we have to say no. You know, a lab is a lab a project is a project there's no such thing as a lab project. But so it's a bit like this I think, you know, there's only so many terms we have at our disposal, and we have to disambiguate and sometimes it does require a little bit of, you know, like a brain gymnastic kind of thing to not confuse things. But I kind of like the idea of using promoter to talk about labs to incubation, you know project incubation, and if all the docs were clear on that. Maybe we should have an FAQ somewhere and say what has graduated me that we say, you know, people may refer to this but the reality is, and we kind of, you know, specify what is the right interpretation and the right usage for those terms. Could I ask what the potential downside is, because the people who are going to be reading these, you know, tea leaves from the TSC are going to be new contributors, new people who are coming on board, who unlike me, haven't been exposed to calling it the hyperledger project.  For people who are new, they're not going to have that baggage. I would just ask, you know, what is, what is the downside we say, you know, before this flag day, is that sorry for the confusion. I see how it said on the chat channel, what about using another term like mature or something else to adult. I think that was actually at some point this came out but I don't think anybody wants to be called. I have a mature project for some reason. It doesn't sound very positive to me. Hi. So when, when I'm not explaining about CNC, I find the way Kubernetes does work today. It sounded so simple. It sounded there are just three stages you start at one and then you eventually mature and then find final goal would be I mean, I hope project would continue but there is some archival stage right when there is no project we're going on. So it sounded very simple that everybody knows there are just three stages on in its life cycle. And, in fact, one of the comment which I added, I'm not sure probably I added yesterday night late night in their time on on that proposal is right now we do are when we are trying to solve this understanding issue, which is in with the using multiple proposals I guess this is the same question which is brought up by crazy and and grace as well right little while ago. So should we focus on one and then make it simple large should we make this intermediate. I mean for me this is kind of a interim solution, but we change naming and then we switch back to another proposal, keep working on it. One personal experience which I have seen within the community is because I also interact with many people here in India. So they kept asking me that areas is now become active. So people did not have that concept of activeness. They thought project became stable as part of this active. So until then people were saying, Okay, it is was still under development. Now it is kind of stable. Hyperledger has released it and they are recommending areas that's that's the kind of feedback that I heard within the community here. So these kind of words, they do make a difference on what we choose. So probably we take some time and then finalize on one approach. Yeah, I mean I agree that those those words are, you know, they do carry some weight right and but so you're saying you'd rather wait. I'm not sure what you're recommending in the end. Right, so since we are solving similar problem through multiple means. Probably we should, we should wait for some more time. So like doing the badging is what you're saying. What other ways that you're talking about. Is that what you're referring to badging. Badging. You're saying you'd rather we keep working on the badging and touching anything until we are sorted out the badging. Okay, because badging is also kind of defining maturity status and so this this word, the choice of word that we are making here active or graduated. It is also kind of defining the maturity status. So probably we should finalize and then I like this wording, there's no comment on that, just that I feel like we should finalize on one process. Okay. I appreciate that you know it's definitely a viable option. Anyone else. I mean Daniel you're proposing the badging. How do you see those things do you think that we shouldn't touch this, it's a waste of our time or are you okay with us doing this kind of change. Why we are experimenting with badging. I mean, I'm a mixed feelings of it. As far as badging my understanding is we were waiting on people who wanted to see the automation to come up with counter proposal. So that's kind of why it's called there, you know to get the details of what they were looking for in the automated values. So if, if we're going to change the name of the current process that does give weight that we're going to keep the current process so it is kind of forcing the issue of whether badging, you know, I really feels like we should do one or the other. We should either move the badging or we should change the name, because doing both is going to send mixed signals. So I think we really need to have to have a decision and come to a realization of, are we going to stick with the current process or are we going to change the name of the badging. And then from that, you know, we would move to one or the other. Yeah, that's that's just, that's my main concern is, you know, we're trying to do both is like not doing either justice. Right. Thanks for the input. Anybody else. Otherwise, I'll take a bit of time to respond to it because I have been struggling with that myself before bringing it up at all. But I think it's very differently because part of me. I kind of expect we will still have those statuses, even with the badging. I think the badging where I've started with a set of badges that pretty much trying to capture what's in the incubation exit criteria, but there is no reason to limit ourselves to this. You know, a lot of other things. And the problem is, you're going to have a whole series of badges, which, you know, is going to be practical for everybody to refer to all the time. But there's still some value in having some kind of high level label that immediately only capture one dimension, not all of them, but, you know, that I still might have some value in having that. So I'm kind of somewhat expecting that we might the bad, the badging won't put an end to the to the face. This is kind of where I am. I mean, you guys might say no, I know you're wrong. I think there's room for fusion in this to where to say to go to incubation, you need to have this set of badges at the same time to go to graduated you need to have another set of badges at the same time.  You got graduated when you get graduated, you always have it. And then we could create this extra rank above it that have, you know, a certain set of badges above beyond the time and go. Maybe we have premier projects that have, you know, more and you got to renew that premiere every year. So you would need to change some of the expectation that these these ranks you have, you can lose premiere because you didn't keep your contributor decentralization up. You know, I think there's opportunity to kind of keep the care out from the projects if we, and then we need to figure you know what is coming on me like bonuses. I think there's room for this but I really think we need to get the foundation settle before we can really discuss some of these deeper possibilities. I think these are indeed the possible things that might happen down the line but yeah, this is interesting. Angelo has his hand up. Yeah, yeah. I must admit, I'm not an native speaker, English speaker so I don't see all the nonsense is the nuance between behind the wording. And the studies that there are different understandings of what's behind this, these words so to me, the word itself doesn't mean much as long as we have a clear definition written somewhere or what's behind this word. Now if it's active or graduate or any other word I don't mind I mean the if we change just the word but that we don't make the concept more clear. I mean we are not. What's the point of renaming the renaming variables I mean if the variable is still the same meaning. Either the meaning is not clear and therefore we have to write a better paragraph for for the meaning or otherwise, maybe I would agree that it's better to move to a solution that would deeper solution that will solve more problems like can be badges. Actually, even though I'm not very, I'm still, I didn't make my mind around that but I kind of agree that changing names and then proposing badging and do this and that I mean it probably can create more confusion that other things, but just my opinion. Thank you. All right now but I appreciate your input. Thank you. And just to answer one thing is, I agree with you that, you know, those things need to be defined anyway, no matter what term we use. And the thing is the problem today is there is no primary I think in terms of, you know, defining what active means the problem is people don't go to the definition to figure out what it means, they will infer some meaning just based on the name. And this is they will run with that in their head and talk about it with that kind of assumption base, you know, right. And what I'm trying to do is try to make it so that maybe for those people were not going to follow link and figure out okay what does it mean for project to be active or graduated that they would have a better or more likely, you know, a better understanding of what it might mean. That's all. But look, there's more things on the agenda. I appreciate the reactions and input from everybody. This is not, you know, I didn't expect a final decision on this. I just wanted to bring it up. I encourage other people to continue the discussion on the weekly page or in email whatever you prefer. And we can talk about it some more. Let it sink in and think about this. We have 15 minutes left. I wanted to touch on some other points that I got from this presentation that was given that is more food for thoughts. And it doesn't require us to make a decision per se, but it was really, you know, in keeping with so, you know, the crux of the presentation was very much like okay what are the things that a project like hyperledric and do to try to, you know, favor growing the community overall. And it's interesting because so they have very similar, you know, characteristics in some ways. So for instance, and there is a link to the charts I think you can access them. And the link on lessons learned from communities and see a CF point to the charts, and most of them I think self is explanatory for the most part. You know, there are things like I said, the number of phases there is quite similar. They also have this policy to allow competing projects to exist, let the market decide. And, and so there's quite a bit of similarity in some ways.  And I did mention in my email the GRPC case, which is highly popular, used everywhere. But, you know, Google is dominating GRPC and for that reason they're still incubation. And they're just being told that's how it is either you fix your community or you stay in incubation, which I thought was kind of interesting. But so, practically speaking though, they were in that presentation some tidbits that I thought, wow, this is really interesting. We really need to be aware of those things. We being hyperledger community and see if we can implement some of those, you know, activities within our own communities to try to improve and grow the community. So the first one was this idea of gamifying the issue triage. And the idea is to basically allow a broader set of people to contribute to, you know, prioritizing issues that are being tackled by the developers of a given project. And so there's different tools you can use for this.  There's a tool that was developed by Google, where you can have like, you know, the maintainers, they're sitting there and they go and they can vote and decide how, you know, what should be addressed as a priority over others. And this is done in a much more collaborative and dynamic way and also with input from the broader community. So instead of being just the maintainers decide, oh, this is what we're going to tackle next, you can say no, let's, you know, leave it to the community to vote on those issues and and try to sort out all the different issues. And then so I'll go through the different points that I wanted to raise. There's two main ones. So this was the first one. And the second one was to do with release manager. So they what they're trying to do is rotate the release manager. So within a given project, they tried to rotate the release manager, every word, every release. And in support of that, because what happens often right we most of our projects they have one, you know, dominating manager, and they typically are the release manager. And one of the reason I mean one of the ways to increase contribution from outside, you know, outsiders is to give them the control over the release. And in fact, it's interesting because it's not necessarily something that's that critical in terms of like, you know, it's not like a company is going to be necessarily worried about, or, you know, giving up control or, you know, polluting the code by, you know, that kind of stuff that sometimes people reluctant to to outside contribution. The release management is something very important obviously you need somebody who is dedicated to do the right thing. But at the same time, it's something that's fairly mechanical, and that you can actually train people to do. And so that's the other part, they have a shadow program where basically, they are making this effort, so that, you know, somebody who is interested in becoming a release manager, can volunteer to shadow the current release manager. So they go through a release cycle, maybe to depending on how they are comfortable, you know, taking over, and then the next release, they do it themselves. And this is a good way to bring all new people on board, making them part of the community. So I wanted to bring those things up. And ask, you know, if there are any reactions and this is the kind of ideas that I find refreshing and business school. Why can't we do this, you know, and we don't have to make that a policy I'm not talking about like you know making a decision at the TSC level saying yeah everybody should do gamify, you know, should give me find a solution to prioritization. I'm not talking about any of this. I'm really talking about like, hey, these are cool ideas, what do you guys think, and try to socialize them in a community, so that people can maybe be, you know, enticed to trying them out. Yeah. So, Daniel. I think it would be helpful, at least for the release process is to get our arms around. Who does the releases for each projects today is it one company always doing it they have a dedicated team, they share it around, you know, is their release process documented. Is it some magic checklist that exists in someone's head. So, even if, if we don't, you know, do this there's some stuff to learn about it that would I think help stabilize the projects because as far as release management goes let's say for example that, the idea gets out of software completely not going to happen. But you know can they still the project still live if other companies can release it. And that's the value I see, and having other contributors able to drive the release is what if the person who's got all the magic stuff in his mind, you know, which the industry that way if it's rotated around people, it increases the bus number from one. So, I totally support the idea of that, but what's on these things. All right, thank you. Any other reactions. And maybe, maybe there are projects that do this kind of stuff I don't know it also be, you know, it's kind of a prompt as well to others, you know, to everybody. I mean, to speak up if there are things like this you've been trying or thinking about that, maybe, you know, we would all benefit from using you know trying at least, I, you know, and I don't know how much of these actually works cost or any of this. But when I saw the presentation I was like, damn, this is really good interesting ideas, we should try that out. So that's why I wanted to bring it up. I don't see anybody raising their hands. Troy. I think sometimes these discussions based on previous decisions. We might forget that there are sub projects even though the TSC doesn't see them as sub projects and an official capacity. And I think what happens in some of the projects is there are different release managers for these different sub components. So I'm not entirely sure this ends up with only one company even within a project because some of these projects have multiple components to them. I agree but I think that the difference at that level to me is irrelevant because you make it at the repo level whatever you know there's always a point where you have some release manager and the same principle can be applied at that level. Same for issues and all right in fabric we have many different repos and you know we have issues are not all in the same bag right. So, you, you could imagine including implementing this kind of processes at the repo level. That's fine or sub project as you call it. So I think once you get specialized like that there might be less. I find this little bit in theory sometimes it's just when you have component breakdowns like that they're just isn't necessarily as much diversity at the so called sub project level as at the parent project level. So it's just a little more difficult. Okay. Nathan. There's something that's really a good thing to encourage and a good thing to promote, but it's, it can very easily cross and over into too much governance meaning too many rules or too many prescriptions that make it feel like to the developers there's just, there's more hoops to jump through than it's worth than it's worth the effort. And for most open source projects you want just enough governance and no more. The kind of less is more. And just because it's hard enough to keep track of the project itself, especially when you're working as a volunteer that if there's a lot of both work of the governance that's involved a lot of rules to follow. It gets to be too much really quickly. And that doesn't mean we shouldn't point to it and say this is a better way of doing it. And if you do it this way you'll have less problems and you can keep your governance smaller because it will go better for you. But I think if we start saying, here's the checklist that you have to follow, or, you know, if you if you can't stop and think about whether there's an exception to the rule here for instance, maybe you're in a sub project that doesn't have sufficient diversity for this to work. You know, you, you need to be able to think on your feet and apply these principles in an intelligent way. We don't want to just say do this or you don't qualify. If that makes sense. Yeah, no but and again I want to be very clear on this by no means proposing we make any of these things requirements or policies that need to be implemented across the board. They're really only meant as food for thoughts ideas. I mean, you know, you have to recognize that a lot of the reports from group from the projects, often call for help from the TSE to, you know, grow the community and so on bring new contributors and whatnot. And so I felt like a, here's some tips that you can take on, you know, in your own project and try to leverage this, maybe as a way to grow your community. So this is really what it's all about and nothing more I want to be clear on this, I agree with you. I think I wouldn't want to add extra burden in terms of governance requirements. David, and then we're going to close the call. Well I think this is great I mean bringing in good ideas from other projects is a really smart thing to do I think so thank you for sharing it and I think you know based on the comments it doesn't necessarily port over exactly like they're doing it there but I do think the idea of a shadow program, maybe for a range of different roles maybe beyond just the release manager or not even for the release manager does tie into things we've talked about in this call. But how do we, you know, foster more mentorship in the community so I think you know just the idea of a shadow program for any community role there might be is a good one so yeah I would encourage people to see how it might apply. So, and let's look at other, you know, things that are working well in other communities to bring in those ideas. Absolutely. And this is also what I mean, what I meant to do there is to say hey look, when you look around their ideas that can be worth leveraging for our own community so if you know beyond the lookout for other good ideas that we might bring up and maybe they don't get used that's okay but I still think it's interesting to bring them up. And that being said, thank you all for your participation. I'm going to close the call on this, and all of this is food for thoughts. I hope you'll find it useful. And we'll talk again next week. Bye.