Metagov Panel Standards Governance As A General Design Pattern
Speaker 1: Well, cool. Welcome everybody to, standards governance as a a design pattern. This is the second in, of two conversations about standards governance. Standards governance is when you get a bunch of people working together by get by making up a way for them to work together and letting them all voluntarily opt in to doing it that way. Way. So it's very hands off and has all of the...
Top Keywords
- standards 0.015
- group 0.009
- robin 0.007
- work 0.007
- well 0.005
- gatekeeping 0.005
- good 0.005
- groups 0.004
- standard 0.004
- three 0.004
- successful 0.004
- corporate 0.004
Transcript
Well, cool. Welcome everybody to, standards governance as a a design pattern. This is the second in, of two conversations about standards governance. Standards governance is when you get a bunch of people working together by get by making up a way for them to work together and letting them all voluntarily opt in to doing it that way. Way. So it's very hands off and has all of the upsides and downsides you'd associate with that. And and given how unique and peculiar it is way to govern anything, It's it's a remarkable fact that the Internet is very much governed that way. It's very much governed by people who volunteer from all over the world and learn to work together in a very open way. We got a wonderful education in a lot of the basics of that on Monday, and we're continuing that conversation now getting into the general idea. There's a lot of interest in our community as we can see from all the people joining us today. And who we've got with us, well, we've got quite a team. Could I get one let's see. Who you are who are we considering as on our panel? Steve, I know you're kind of on the edge of joining us with the standards governance hat or as an audience member. Where where are we placing you?
I just wanna talk a moment about the idea of governance regarding AI at some point and trying to do a panel about what type of AI is allowed and what type of spaces. So
Great. Great. So I'm gonna be a fairly bossy moderator and keeping it a bit on on that, but I would love to spare some time to kind of pitch your brainstorm at the end. They're like, you wanna share a question. So but I'm gonna put you I mean, I'll have you as audience at. And then, Chad, did I, for some reason, do I imagine you as a no. No. Okay. Alright. Well, in that case, did I get one set of introductions from, I believe well, Liddy, it may be wonderful if you started this often, Charles, Robin, and and John.
Well, I can start off by saying, as the oldest person here, you must wonder why Charles brought his grandmother. I guess because we've been working together in standards things for decades now, actually. I keep on thinking I can retire and escape this work, but it seems to keep growing. So, but I'm gonna be very quiet today and enjoy listening to what you've got to say and recognize some faces I know from the past. Nice to see you.
Yeah. So I'm here. Yeah. Because my mom's here. Now I have done a lot of work in w three c for a long time, a little bit in a tiny bit in IETF, a a bit in ISO. I've spent the last six years leading a bunch of standards work in the enterprise Ethereum alliance, which is sort of building standards that sit on a a parallel track to the EIP process where a lot of things are done for Ethereum, and we could get into the reasons for that. And here I am.
Robin? Hello?
So hi. I'm Robin. I've I've done a fair bit of w three c work, about twenty years' worth of it. No. I'm 35 by now. I forget. I'm currently I've chaired a bunch of groups. I've edited a bunch of specs, some of which you might even have heard about. I'm currently on the board of directors there. I've also done, a decent amount of work in other standards organizations, a little bit of ITF, bit of MPEG, bit of things you've never heard about, like TV Anytime and and, you know, a bunch of Bondi and a bunch of other stuff like that. Yeah. Yeah. Yeah. Not all of them good memories, but but and and I've also become interested in things at the sort of at the overlap and contact points between open source and open standards governance. There's a lot of open source projects that start to build some protocol like things that need interop and start to need standards, but they don't know how to do it. And there's also going in the other direction, work about governing open source implementations of open standards that can get, quite tricky. So, yeah, that's it.
Thank you, Robin. And, John?
Yeah. I'm John Kunze, a computer scientist. We're specializing in persistent identifiers and metadata, and I've done a lot of standards work in the IETF, responsible for standard informational standards over URLs, Baggett, web archiving, and a number of other areas. So that's where most of my standards work is. I think there's there are some things that qualify as sort of de facto standards as well, but it's having to do with software, which I could say something about too, which it it's not it's like, you know, we're all using Unix system Unix like systems in heritage from various sources, and I happen to be in the right place at the right time, contributing to the Berkeley UNIX software base. I didn't know what I was doing. There were, you know I was complaining about all these bugs in UNIX, and they people got tired of listening to me. They said, go fix it. I said, where? How? And then here's the source code, and they pointed me to it. And so I fixed it, and I sent I emailed patches, and we didn't even have the concept of patches at that time. They just did diffs. And then I saw my changes in the next release of Berkeley UNIX. And I there I couldn't tell you what kind of thrill that was. But there was no knowledge, no sense of explicit governance. There was there were these computer science research group at Berkeley was putting these things out, adjudicating what went in or what didn't. It didn't say it's running on your Macs right now, some of the stuff I did, and I didn't know that was gonna have that effect. Maybe they didn't either, but there was a an unwritten standard written into the code simply by the way that software was managed. And this was, like, twelve, fifteen years before the word open source was invented or that I first heard that word. So that's a de facto kind of thing. I don't know. Is that a standards body? It certainly had governance by a little core elite. It wasn't it didn't feel it was too small to be abusive or considered abusive as just a big bunch of colleagues.
This this is actually a wonderful, thing to work up. I wanna do a little work motivating this conversation. So imagine ending it starting off like that, people who are colleagues who care, who have been selected or self selected through pretty narrow technical knowledge and passion, enthusiasm, small community, high trust. Everyone knows each other. Now it grows and it grows and it grows, and it starts to have money attached to it. It starts to attract all kinds of agents and entities. One thing I learned, in our last conversation we have is that the IET app, the Internet engineering task force, which governs the standards around the Internet generally, and the w three c, which which governs standards related to the World Wide Web specifically, but they're similar to each other. The IETF was first. The w three c came out of it. The w three c has minor design changes that were intended to learn a bit from the the maybe some of the mistakes and also adapted from some of the unique needs of the world wide web relative to the Internet, and that we suddenly have little differences. Hopefully, the history I'm giving is wrong so I can be corrected with passion by our panel. And I wanna set but but kind of what's important about all this is that as the stakes go up, we start to see standards governance really succeeding. Standards governance really failing. Single body doing both at the same time. Different bodies that are seemingly identical, crashing horribly or or or performing wonderfully in really different ways. Some being irrelevant and and just popping up left and right. And so what we have I don't know. There's this ecosystem, and I feel like we can learn from it. But and I wanna know just the general generally, how do I feel about governance as an approach to doing things? The volunteerism is radical. You can even call it anarchist, but it's also deeply vulnerable. And so with all that, I wanna start us off with the kind of first question. Oh, and ground rule for the panelists. Give me examples. Give me anecdotes. Give me facts. Keep it concrete. I don't wanna I don't wanna be in three realm. I want little stories I can walk away with, like, my stop signs are red from last time. So with examples, how does a standards organization encourage participation from everybody while avoiding gatekeeping while evading corporate caption? And then this is a little bit of a nod to what I learned about the difference between w three c and, IDTF. Since they both struggled with capture, IDTF by not defining an explicit corporate track for participation, and w three c by defining an explicit corporate track for participation. Maybe the what's worse, being captured because you tried to manage the problem or being, captured because you didn't. And consider that just a bunch of inspiration to riff, whoever whoever would like to start.
Alright. I'll go because I'm Slack on the mute button. The and the how do you how do you encourage participation? You know, you you go chasing people. You go looking for people. The the people who are trying to get a a standard to become a standard. So so the fundamental framing, anybody can write a specification for anything they like, and it can be a good one or a bad one. It can be very, very formal or very informal. So, you know, on the one hand, there's there's lots of very formal standards that people know of. There's a standard called SRT, which describes how to do captioning for videos and stuff. And for the longest time, the standard for SRT was a short text note in attachment to an email in an archive, and and that was that. It was like, here here are things you can do, and people sort of sat down and it more or less worked because you got captions everywhere. But if you if you want to make things go, then you yeah. If if you wanna produce your standard and get other people to use it, which is what makes it a standard, then you go out and find people who want to. So I think a a lot of there's a lot of, yeah, hey. Come and join my standards effort. Come and work on this. And, you know, so that's the the how you get people in. And people just turn up because they get excited by whatever it is you're doing. That's the loveliest thing. In terms of how do you how do you avoid CAPTCHA? How do you avoid failure? I mean, I think, you know, I I am not sure that I there's a a clear answer, certainly not a general answer. I think the the groups that start off with a corporate or corporate ish structure are actually in a a fairly good position often because they have some corporate backing, at least in theory. And that means, you know, they they can demonstrate that there's, you know, big name companies you've heard of interested in, you know, building whatever this thing is. It it is then up to the group as it as it does its work to demonstrate that it's not, you know, just reverting to the, you know, the biggest gorilla in the room always wins. And so there's a lot of different processes. Robin has invented some of them at w three c and should talk about them. If if you don't expect, you know, companies to to represent themselves as companies, if you don't expect people to behave as company employees. I think that that's a harder road to follow. So the there's a there's a pattern where a few people make something for themselves, and they're like, you know, they're all friends because they got together because they were friends, and they knew each other, and they knew each other, had the same need. And then you find that there are people out there in the wild and they want something slightly different, and you've gotta figure out
Yeah.
How do we how do we balance these now, sometimes competing needs? And, you know, if if you're wildly successful, then you're going to face the, you know, what what corporations are here and what are they trying to do issue. And if they have the capacity to put the most people on the panel, then, you know, they might do that because that's their that's their corporate interest. So I will
Yeah. Alright. So that sounds like a good description of the problem. Though I was I'm I'm I'll still keep trying for kind of examples. This happened even though it shouldn't have. This didn't happen even though it should. This one, we thought it would go awful, and it actually turned out fine and vice versa. And we'll set
it up I'll let Robin and and Rudy go. I know.
Perfect. Robin?
I mean, I I I think in terms of the question of how we successfully encourage broad participation, prevent gatekeeping, and prevent corporate capture, I I don't think we have an answer to that because as far as I've noticed, no one has succeeded in in achieving that yet. We've all failed in in, you know, in various spectacular ways. Part of the problem there is is the manner in which we approach standards for something, that of the size and scope of, you know, the Internet, the web, and all that is ridiculously underpowered in terms of governance compared to the size of the problem. Basically, it all comes down to what is called what is known as voluntary standards. And the idea of a voluntary standard is basically that it's market driven adoption. Right? It's like your standard succeeds if it's implemented in real world, systems, and those real world systems only count as properly real world if they have any kind of market significance and if they have the means to deploy at any kind of scale. And so, you know, that sounds like maybe that's okay. You know, we we have if you have a competitive market out there, you build standards. You know, people compete to build the best implementation of the standards. Because they're competing, they have to collaborate in in in those parts, and that works. But that only really succeeds if that market is actually competitive enough to maintain that kind of pressure on the system. And if we look at WPC, for instance, well, the structure of the market that, you know, undergirds voluntary adoption, is that you have one search engine, Google, that has 91% of the market, and it only has 64% of the browser market, which is key for for for web standards, but it pays 92% of the browsers based on its search engine dominance. And then it uses the browsers to lead to to to maintain its search dominance, to pay for browsers to maintain search dominance. There's only it pays it pays for every single browser that is larger than 1% market share except for Microsoft Edge. And Microsoft Edge is a Chromium browser. So that gives you that is the that what I just described is the entirety of the market structure that sits behind voluntary standards, on the web. As you can see, it's it's completely captured and it's completely gatekept. Try building a search standard at W3C. You know, you could define it, but, like, Google's never gonna adopt it, and that's the end of the conversation. And so, you know, what we're dealing with is a form of standards washing or market washing dominance, and we're not very effective at countering that level of power. We do find occasionally some parts where you know, those businesses don't have a strong reason to pick one way or the other. So if you think of, like, accessibility, internationalization, these are things where we manage to apply some pressure and actually have some influence over the process. But these are all things that, of course, they matter a lot to people, but they do not matter in terms of that power structure. And so I think so far, you know, standards Internet standards are in crisis today, and we really need to reinvent the way they work and to work on, you know, next the next generation of how the system should operate.
That's provocative. Thank you, Robin. Libby.
I just wanna add something very quickly that, one of the things that I've encountered is, having universities involved because academics have a need to continue doing work and don't really want a solution. So almost differently from corporates, they they have an interest, but they it is often something designed to make it easy for them to get the next grant and the next grant. And I think with I've my experience, particularly within ISO, is being captured by that kind of university gravy train rather than the the solution or some particular commercial interest.
So
I'm go ahead, Charles. And I'll I'll be moving the next question shortly.
Yeah. Sorry. Mean, there there's what what Lindy said about universities and stuff, you know, you you get people who have their pet project and and it's, you know, fundamentally a a vehicle for students to do PhDs. And so they bring all of these things into the the standards world and say we're we're implementing this stuff. Often, it's not actually relevant in the market as as Robin pointed out. But because people are looking for participation, because you don't know what is going to be relevant, you know, and because in an effort not to be, you know, a a nasty gatekeeping cartel, Standards organizations do allow people to turn up and do things and appreciate people doing things. It it's common to see things and this happened, you know, arguably, at one level, the the failure of XHTML was an effort at, you know, capturing the the way HTML was done by people with a a very strong academic interest in technology that was really good and worked well, but without any real value or apparent value at the time to the real market. And went down that path. There are, you know, any number of cases of talking about, privacy requirements or accessibility requirements where, you know, corporates have weighed in. I'll I'll call out the Adobe exception. Section I have to tell a bit of a story. Section five zero eight is a requirement on US Government purchasing. If you're spending government money in The US, then you have to make sure that the things you're buying are accessible for people with disabilities. W3C wrote up, you know, masses of of work has done thirty thirty years nearly of work on how you do that. And when the US government first tried to figure out how to deal with that, they sort of adopted stuff from the guidelines and then rewrote them. One of the things they took out one of the exceptions carved out. You have to be able to do things by keyboard. This is the the late nineties, remember? Everyone had a keyboard. And many people can't use a mouse for one reason or other. Except if you're doing something like, you know, choosing a selection of brushes in a drawing program. I don't know if anybody ever used a program like Photoshop. But, you know, essentially, this was a a clear carve out for a particular company to change the requirements on them. And it was bizarre because the first open source project that I ever, you know, was involved with, again, like John in the eighties before people called it that, you know, before people called it that, was a drawing program entirely keyboard driven with a massive selection of brushes and styles and things. And there's no reason why you should have this exception beyond a company wants to do it. So so part of what fails is companies go shopping for the right venue to make their argument to to achieve their goal. And and companies often have more resources to do that than any given standards effort they're involved in.
I like I really like this set. So what you're telling me is that Internet accessibility standards kind of required by the government have a carve out specifically for color pickers.
Yeah.
Oh, that's great. That's great. LMT But
for brush pickers, which is even less
Yeah. Yeah. Brush pickers. Right? Beautiful. So, you know, I'm so I'm getting a picture that if I'm outside if I'm not in the eye of Sauron, I have a chance for a a sense governance to really recruit diverse stakeholders who are invested, who care, who are driven by the social good. If I as John kinda the picture John painted. Right? If I'm inventing the idea of open source, inventing processes by which other people can improve my code, we can all share code. If I'm just there in the beginning, then I can get, again, maybe not diverse stakeholders. Right? But but kinda great for social dynamic of people serving each other. If I'm directly in the gaze of of of finance or capitalism, then I have a lot to be worried about. So, I don't know, give me a couple more archetypes. What are some examples of groups or bodies that maybe have worked just by everything? Maybe the work both really work well and both really work differently. Are there examples on these instances maybe where there's enough people power for community minded or university minded representatives, have a collaborative, successful kind of work with corporations. Give me throw out some cases. What what's what are what's the emoji board like? What's I I don't even have enough, like, knowledge to throw some things out, but I'd love some examples. Robin Robin, I saw you not
I mean, yeah, I I I can I can think of two groups I've been a part of that I think worked pretty well for different reasons, or maybe those reasons sort of meet somewhere? And I'm sorry this is gonna involve, like, a million acronyms probably, but so one of those groups is the T. A. G. Privacy Task Force. So T. A. G. Is the technical architecture group, which oversees the the architecture of of the web. And that group basically is solely focused on privacy principles. And so it's not doing any implementation work, and which is unusual for for for for a status group in in in that space. And I think the group was successful because it was assembled quite deliberately by going out and finding people who would be good for it and convincing them to participate, but picking people of very different perspectives. And with a willingness from the get go to go very deep, you know, into philosophy and and however far you needed to go into the weeds to get this as right as we could get it. And that means, yes, the work took forever. It's knock on wood, almost finished. But I think it created a very, very powerful group dynamic that was very discursive. And I think everyone's mind was actually changed in the group, which is not something that happens very often in standards groups. And so I think that worked quite well. A very different group that I thought was also successful was the XBC group, which is the XML binary characterization. And I'm not going to bore you with what that actually means. What I think made the group successful there was almost the opposite. It had a very strict deadline. It had to succeed inside of a year because a lot of people wanted to see it fail. And so it was only given a year within which to to deliver to deliver the goods, after which it would be shut down if it and and considered a failure if it hadn't delivered. It was entirely based on existing testable implementations, and there was very strong alignment between people in terms of what they were trying to get to. They didn't agree on the solution, but they agreed on what they were trying to push towards. And so completely different groups, one very philosophical, very divergent in terms of interest, the other one very focused and very practical. But both of those, I mean, at least the XBC group succeeded, on time, which also never happens. And the tag privacy test test was, I think, is is successful even though, like, we're, like, probably a few months away from the finish line.
Gold star for sticking the prompt. Charles. John, please. Yes.
Yeah. We're going with that prompt. The I don't have that much. I mean, I've standards I'm not gonna talk about, like, the IETF, but maybe a working group within the IETF or a working group from a certain community. But and that's really about the group of people that you get there. So I would say one thing that's helps that's, you know, the Bagot standard went forward because everybody needed it finished, And so that's one characteristic when you're picking a group of people to work on this, you want them to, they need these, they need the solution more than they need their opinion heard. They need this a solution. So you're hungry, and another key factor in getting I think a good group together is is people that are that have actual expertise as opposed to rank. It's very common for like, a company will send their we got this senior person here. They used to know this field really well twenty years ago. We're paying them too much, but we don't have anything for them to do. Let's send them these standards meetings. That's a really bad bad choice for your standards committee. You want people who are active experts, and often they're low ranking people who don't get to get on airplanes and fly around, but they're the people who should be at those meetings. The metadata practitioners, we didn't have many of those LITI in double core degree. So we have a lot of hypothetical discussions, almost no field testing. So those are anecdote ish, and I'll stop there.
Yeah. And Charles?
I thought I'd I'd not yeah. Work very well depends on your concept of of very well. If you look at and I I'll take it from my own current life. The the Ethereum Foundation has this whole process for building Ethereum. And Ethereum, there's it's a blockchain built on standards. You They take very seriously the idea of competing implementations and interoperability. And they are absolutely, anyone can turn up and do anything. And and, you know, you can just write EIPs. There is zillions of EIPs because anyone can produce an an EIP. But there's this sort of small group called the AllCore devs, which is anyone is allowed to join it. It primarily consists of the architects of Ethereum execution clients and and consensus clients. You know, the the people who are really driving the core software. Like like the people who are in charge of browsers, except browsers are now too big and complex for any one person to be in charge of them and and engineering them. Seriously. So that sort of has this defacto gatekeeping culture. If if I turn up and I, you know, don't fit into the community, they basically are free to ignore me, and they do. And so it's a it in one sense, it's very, very clicky, in fact. And it's it's but that's what makes it work. It means that when they say, this is how we're gonna change the protocol. This is the next thing in a you know, we're gonna completely change Ethereum. We're gonna break the the current Ethereum and do something else. All of those people agree. So all of the software that that runs most of Ethereum stuff in their main net gets, you know, updated and they flick a switch and it changes. And this has functioned successfully. I mean, the the merge, they claim, is their their biggest success, and they're probably right. They got rid of proof of work. That was a pretty substantial shift. Yeah. And then contrasting that with EEA, the where in principle, you're supposed to, you know, pay to play. You're supposed to sign up. You're supposed to be a corporate member. You know, you come along because you've paid your money, and you you know, there's a clear process that says you can, you know, get EEA to do something, anything, if you have, you know, a bunch of companies who are like, yes. We want this to happen. In practice, it doesn't work like that either in in the same or in the way that that John alluded to. What actually happens is you often get, you know, people somewhere down in the depths of of companies who actually care about this problem turning up to work on something. If it if it doesn't, you know, attract people and get worked on and do something useful, we kill it. So EEA produces very few specifications. But I think the and and, obviously, there's a there's still, of course, a a proportion of things that just don't work out, or we thought they were interesting right up until we realized they weren't. But you get a a very different approach of, you know, to set this up, you need to start out by having a bunch of people interested and saying, yes. We're going to drive this in a real situation, in a real market. A little bit more like w three c model is in principle. But then, yeah, I wonder if Robin wants to talk a little bit about the difference between w three c working groups and w three c community groups, seeing as the existence of that is Certainly. Fault.
Yeah. Especially if you can get a sense of what problem they solved.
I so first, the disclaimer, they're not entirely my fault. Some some other people were wrong as well. So I basically, the the idea behind community groups was initially to support wider community incubation. You get these back and forth dynamics in all organizations and standards. Organizations are not immune to that where the system you're working on becomes extremely popular. That happened to the web. Lots of people come in to structure things so that you can have a group that guarantees quality and that essentially does some gatekeeping on essential parts. But that creates problems because it also does, as a side effect, gatekeeping on non essential parts. And so because you have these people who are experts and basically are able to maintain the quality of your system, they also decrease the ability of your system to bring in new ideas and to incubate, new things. And that's, you know, that's that's the iron north oligarchy. It's it's it's pretty old, and it's been well researched. So what we thought we would do with community groups is basically have these groups that any three people who agreed they wanted the group could spin up. And so that basically broke down the the the barrier that working groups create where you need, you know, a chartering process and the review by the team and review by other groups and review by the members and then a vote and it takes forever and you have to do political host trading, etcetera. And so, you know, with the effect that that very few working groups ever get created. And so we create we open the the basically, the the the, you know, the we open that up to to the world with what at the time was considered really helpful, which is that you got a mailing list that came with it with an archive and and all kinds of, like, nice little things like that. The problem is I think it was actually a decent first step when we took it, but it should have been followed up by more work to actually educate that community and support people in, you know, becoming, people who could create standards that would, you know, basically have a a a good pipeline into main working groups and all that, and that didn't happen. And so what actually happened with working groups is that you create a system with fewer checks and balances than the existing system, and basically the most powerful actors just take over because there's literally nothing that it's we already have too little to push back on them, and there's even less in that context. And so basically community groups are almost entirely dominated by by Google engineers. There's a few exceptions that have been successful. They often involve people with a lot of experience running them or pushing them or getting organized. But basically, the magic of, like, hey. Let's open the doors and the developer community will create this wonderful world of incubation has not functioned at all. And I think today, we should seriously be looking sorry. Just to I I I've been going a bit too long, but just to googood on the on this, I think we should be looking to basically shut down community groups as they currently exist and try to find better ways of of making things, you know, open and and and providing an input feed line into the existing process.
To hone that, can you give an example of one rare one of your rare success stories?
Yeah. I think early on, and the thing that that fooled us into believing that that the system was working, early on, a group of web developers organized the responsive images community group. And responsive images are basically a way to specify in in in HTML that you you want images of different sizes and resolutions and and weight to be used depending on on characteristics of of the screen. And so if you have, like, a super wide screen, you can up you can do multiple optimization, basically. You can you can have, like, that super heavy image for the for the for the massive screen and then only send something much smaller to to to to a mobile device. Makes a lot of sense to a lot of developers. None of the browser vendors were interested. They were they were they were all grumpy about it. They were like, oh, no. This is like it breaks or yada yada scanning thing that you've never heard of and don't care about. And the group was successful in mobilizing really passionate developers who had not been involved in standards before. They educated themselves about how to write a proper specification, which is challenging, especially if you're dealing with the kind of complexity that that is involved in image loading. And they they created basically a political force that managed to ram this feature through, and the feature was extremely successful. So not only were the browser vendors sort of like co not entirely coerced, but like really, you know, badgered into implementing it, but they were proven wrong in that the feature was extremely successful and is now used quite a lot. And so everyone thought, oh, this is great. You know, the the system works. It's gonna work again. And that pretty much never happened again.
So I I think the way I'm getting from this is alignment, seems to be a secret recipe for success. Whether that's alignment around, a deadline, alignment around a clear goal, alignment around, values, alignment around technical expertise, or or maybe just being all in the same place at the same time. Now I guess that almost raises the same question, which is in, yeah, in bodies where, you know, anyone can hop on and become part of it. What are some some it almost starts to sound like gatekeeping is a good thing. What what's the difference between good gatekeeping that maintains the alignment of an effective group that's serving all good and bad keeping that does doesn't doesn't do
that. That's very simple. Good good gatekeeping, you know, keeps all the people we want in the group and reject everyone else. And and bad gatekeeping, you know, excludes people who should have a seat at the table. That's a tough organization. And they have both example.
This brings me to an example you offered at the last session, which I really like a lot. So we think of corporate takeover, corporate power as, oh, we'll just just throwing money around and buying people out, kind of explicit bribery or whatever. That's our, like, little picture of that corporate power. But, Charles gave us a story on Monday. Let's see. How did it go? You were you were be you were kind of subtly marginalizing one corporate agent and empowering others by just sort of, like, sidestepping them constantly until this person, because they have a salary, they're paid to do this. Just infinite resources and time, Just read everything. Read your entire history of your entire organization, every single email, and was able to bullet point how you'd been sidestepping. Am I getting this right?
Well, so so it was a an effort at a company, you know, essentially trying to change at the last minute a bunch of the standard. It was an accessibility standard. They wanted it watered down, and they had been entirely welcome to participate and encouraged and invited every you know, to everything and had sent people along at various times, but had not done anything. So they were playing what I would call now dodgy politics, and they got called out on it. And and they wrote back and said, oh, we're sorry. Nothing to see here. I I will point out that, you know, that that I think was a success of, you know, the the governance. Key things were that we had a mailing list. It was archived. You know, all of all of the contributions were reasonably well organized. So this this was one of the early accessibility groups, the authoring tool accessibility. All of the minutes all of the meetings had minutes, and those minutes were written up. And summaries and action items and resolutions were all very simple to extract. So someone could sit down and look through three or four years of history in an evening and actually be able to to make those kind of arguments. So that's the that's the rough story. And in in that case, I think it was a, you know, successful effort at resisting, you know, capture or or, you know, one player twisting the playing field. But but that depends on a number of things. It depends on some tools. It depends on, you know, the the archiving attitude. So w three c in particular archives everything, or at least that's the philosophy. There I I have been looking for explanations of stuff that was done in the late nineties and is now in accessibility guidelines that are adopted by zillions of countries as,
you
know, legal pseudo legal requirements or legal pseudo requirements, things that are getting forced. And, of course, things have disappeared. And if you can't find them, you know, you you end up going around the same circle. So I think, you know, one of the but one of the key points is all of these things are about communities. Right? I mean, it it's all about how do you make the community work. And this is this is not actually unique to standards in many ways. Standards people can be quite weird. So but then so are communities of train spotters or, you know, dachshund lovers or anything else. And so what makes a community work is partly about the the rules you set very substantially about when you're actually sitting around a, you know, virtual table, who is there and what are they what are they trying to do? And are they being good gatekeepers or bad keepers? Because Robin said in comments. So you can tell. If they agree with me, they're good gatekeepers. Otherwise, they're bad.
But yeah.
So your questions, Seth. Yeah.
Yeah. Yeah. Yeah. Yeah. Yeah. Because because one thing I'm getting from all of you is you've all been around a long time. You've all seen their problems. You've all tried to solve them. And in doing so, you've all created new unexpected problems. And so I would, so Rob and me give us a beautiful example of creating the community process and watching it backfire and creating easier route to capture. We haven't heard as much from from from, Libby or John. Is there a system either of you have created to solve to prevent to protect against some kind of failure in group decision making that just created another one?
I was gonna do something very simple. One of the things about being in a group that is productive and successful and so on is it's a very nice feeling. And it becomes a bit of a risk because it's rather nice to be in the club. And maybe we better find something else that we need to do because we're a good club and and we do well. And I think that can be a bit of a trap, and you lose sight actually why you should be there. You should be there because something is urgent and needs to be dealt with. But, actually, you're there because it's nice to be there, and you'll try and find something that can be considered urgent. I I I think that's a a hard one because it's what makes the the group work well, sometimes makes the group actually a a hazard to itself.
And you were you were hinting on a back channel, similarly about the the kind of inspiring leadership, inspiring strong leadership that everyone can rally around. I've gotten little hints that that has its own downsides and creates its own problems. Can you share a bit on your experience with that, Liddy? People being in position too long?
Sorry. Who are you asking?
Liddy, you were offering Oh,
a I I was just suggesting that, but I think that's I've said what I I meant by that f. I just think it's a risk sometimes that we we find that something is is stimulating and exciting and good fun, and we wanna keep it going. I mean, perhaps, we actually don't need to. We need to be doing that somewhere else.
But you described also an issue at times of people being in a position too long. Or is that the same as the standard creating the company join? I see.
Yeah. I think I think it's been just going on together. Yeah.
Got it. Got it. Got it. Got it. Alright. Thank you. How about you, John?
Yeah. I'm thinking I think there's a quote at maybe James Madison. Someone said, whatever system of government you have, you have to destroy it every twenty years and start from scratch again. And it may just be sort of true, and it kind of related to your the questions you just asked, which is every system that you create will it will draw success, and the success will draw the seeds of failure in the sense that people will learn how to join that system and game it. And then the metrics that used to work are gonna stop working. It's gonna get creaky. And as as violent as it sounds, it might just need to be, you know, some severe pruning like you do with the guard gardeners notice. Right? When you see a pruned garden, you think, oh my god. They killed this beautiful garden, but just be patient. It'll come back some kind of hard creative destruction should take place on a regular basis because whatever system you put in place will be it'll it's gonna rot no no matter how well you've crafted it. Wow.
Can we think two steps ahead on that? Let's say that, you know, existed, some kind of, a bureaucratic jubilees where we just get to start from scratch again. That causes problems too, power vacuum and so on. Right? Because the system is co evolved powerful entities. Now the now the playing field is open for them to take. So I don't know. So play with me a bit. How do you design that pruning system to not create to not create the the problem the same problem faster or or or a different set of problems? How do you craft it in a way that it solves the problem you wanna solve and supports maybe you wanted to see?
I'll give I'll give a partial example just now, which is the every IETF working group that starts up has its own has to create its own charter and included in that is its own death date That we will close and shut this working group down in this date. So you have to project your own death. Doesn't project the rebirth of something after it, but it's a pretty bold move. And a lot of people don't like that idea, but it's it's healthy. It's halfway there. It it's also,
I would argue, an an an example of the problem that, you know, the the same thing happens w three c groups are chartered and they have a very explicit run time and they're supposed to die. In the early days of w three c, you know, this was fine. They produced the the ping image format. They produced CSS. And then, you know, people discovered it's like, well, actually, we probably wanna do more maintenance on CSS. So the CSS working group is chartered every I forget, two or three years to do roughly stuff involved with style and CSS. And and you could accuse them credibly of being an example of what Liddy said, a group that is successful, is doing great things, is achieving lots of good stuff, and goes around looking for more things it can do because they like each other and they get along well and, you know, they enjoy meeting and working. People lots of people respect their work. Lots of people implement their work. So they just sort of they just keep on going forever on these two year charters. Anybody who suggests that, you know, the CSS working group is not going to be renewed is either busy building the successor group that will take over and, you know, and and this happened to HTML, for example, or it's just nuts because it it ain't happening. Yeah. So, you know, I I was going to look at a slightly different thing. The w three c has a process document which describes how it's meant to work. And this was managed for many years. Well, it was initially managed by the w three c advisory board, and then it just stopped being managed at all for some years. And then at some point, one of my crimes was to to be on the advisory board and say, we should actually try and get the process to match the way we think we work because it's changed quite a lot. And the the first thing was, well, how do we get the group to pick this up? And to do that, I actually just had to you know, I produced some drafts and said, hey. Look. Here's here's some ideas about how you could change things. Here's some shaking up, and here's some stuff that doesn't match reality, and we should try and match reality. Let's try and make our own governance at at least vaguely match what we say it is. Or or let's make what we say about our governance vaguely match what we do. And it describes how you charter a working group and, you know, how you run a a vote and what are the processes to get a spec from brilliant idea to w three c endorsed recommendation for the web. As part of that, I set up,
you know,
a community group because you could create community groups. And the way the community group was originally set up is, this group is basically a a petitioning group. It can, you know, ask w three c to make changes that that the people who come along think it should make. In some ways, it's very successful where a lot of the work happens now, so it's more transparent, visible in some ways. It's a total failure. It's just being captured by the people who have enough time to dive into the nitty gritty of the governance rules at a incredibly detailed level and they said that sets the agenda, that sets what, you know, actually gets changed and doesn't. And so there are there are some dedicated volunteers in there and there are people who are highly paid by very large companies and the dynamic is as usual, meh.
So, thank you all for indulging me. One thing I'm coming out with, even without having to ask the question, is a little zoo of the of the ways that we can all go wrong, and, actually, some nice examples of what it means to go right. So I'm I'm coming out with clarity, but I got to drive. What I would really love to do, because of the really impressive, group of folks we have here, is leave the floor for at least one, burning question from from any anyone with, I guess, a video off. It's the power search we've created. Anyone in the audience, or, you know, I I wouldn't mind a question from one panelist to to another. But I'm just sort of sitting tight, eagerly waiting for the chat to fly or for a hand to go up. Alright. That's wonderful. We'll do we'll take it, Charles. Who wants to take that one? Who who who can confidently claim that their worst standards group they've ever been on was the worst? Lydia, with all your years of experience?
I think that's a question I definitely don't want to answer.
Oh, don't worry. We're not recording.
You are too recording.
Okay. It's wonderful. Yes. Robin, can you take Casey's question? What are you what's your advice for a new signage body?
I I think I I I would say one thing that I would try to think about in terms of approaching any new status group, you mentioned being into consumer products, but I think I don't think it has to, it would be limited just to that. I would say, spend some time thinking really hard about the dynamic of the system in which you want your standards group to operate and how you want to shape it. And actually like write that down as essentially the end goal because everything should be in service of that. And you should have, you should build in advance the tools to detect when you're going off the rails. Because the thing is, if you're not successful, it doesn't matter. But if you're successful, it's gonna go off the rails at some point. You're going to develop a parasitic and that you don't want. It's going to happen. Like, no no group is, you know, if it were a a perfect, system, you wouldn't need the standards group to to start with. Right? The reason we have consensus is to manage the census. The reason we have institutions is because there's conflict. And the thing is that conflict is gonna is gonna shift. And it's very easy to start being successful and start getting the sense that the rules you have in place are sufficient and will be good forever. You really need to think of capture resistance as basically a cybersecurity exercise. It's like, you know, no one says, oh, I secured the server. You know, we never need to look at it again. It's going to be secure forever. It's going to be perfect forever. No. You always need to be aware of, you know, new new new new exploits and new new issues that can arise. And I think that is absolutely something to to instill from the start. Rules in your initial group are it's going to go wrong, and it's going to someone is going to try to capture it, and so you need to develop capture resistance as a built in practice from the get go. I yeah.
I'm furiously taking notes my hence my silence. That was fantastic. Thank you very much. I appreciate it.
And and thank you, everybody. What I'd like to do what what a Medigob thing we do is on three. We all unmute so we can give actual human applause. One, two, three. Alright. Thank you. Thanks, Charles, Robin, and John. Thank you so much. Thank you everybody for for, listening in, especially for those of you up at a very strange time of day. I'm really glad we're able to make all this happen. Good night. Good morning, and good afternoon, everybody.
Goodbye. Thanks. Thanks, Seth. Thanks, everybody.
So much.
Yeah. Like Robin says, reach out. Stennis people like talking out, in case you haven't noticed.
We won't
shut up. Well, I
have to say it's a lot of fun, and I'm not always in a place like this with my little boy. He's not so little, is he?
Thank you so much, Lydia. It was really a pleasure to meet you. Well, it's fun
to meet you guys.
Really delight.
Yep. Good seeing you, Libby. Libby.
Yeah. Good to see you too.
Alex, I think a number of us are on Slack in metagov. But if you look up our names, you probably find the email addresses or other
contacts. Stuff like that. Yep. Yeah. Great. Or or or using a search engine that doesn't do AI, that should succeed.
Yeah. So so the other thing that's very nice is to be in, you know, the time zone where most of the world lives and actually have something that's during our normal working day time because that is surprisingly rare Yeah. International organizations.
That's extraordinary.
And and I thank all of you who got up at, you know, horrendous ridiculous times. But to be honest, it's like, yeah, that's how, you know, the other half leave. So
Yeah. It was nice. It's nice to do events at this time. There should be more. I have to learn how to be more awake during them, but it's a nice time, especially in the summer. I think the sun's coming up. Thank you all very much. It's nice to hear all the stories and also nice to I mean, it's been a while since I've seen some of you and also first time seeing some of you. So, yeah, the stuff about the, like, archival practices and how to end institutions, really very interesting. Maybe something to follow-up on in a future conversation.
Yeah. That's interesting.
Would be good. Yeah.
It is important to plan for ending and to think about ending. I think as as Robin said, you know, it's really key to plan for success because that can be a a huge trap. And Mhmm. And and I think part yeah. Your plan for ending because you failed is fairly straightforward. It's like, go on. Don't let the candle give it up. The the hard bit is the when do you say we have succeeded and we should go home? We should stop and leave this to other people or we should just stop because this thing is more or less ossified. Yeah. Often stop and leave it to other people is something that you should do, and it's really hard to get you around actually achieving it.
Yeah. It's awesome. I mean, with standards, it's kind of an interesting like it's not like the practice of standards would necessarily stop. So it's kind of unclear, like, what's actually stopping. I mean, it's the power structures can do, like, in the text, but the, like, the practice seems like it's I don't know. That's another interesting question. Like, what is, like, an alternative practice to standards making?
I think there's a little problem as well about if you have multiple you keep going and don't you might end up with multiple standards, which actually means nothing's a standard. And and you're picking and choosing between standards, and that that can happen too. And that I I don't know whether a real shared standard that's not so good is better than a fantastic standard that's one of many. You know? There there's that problem, I think, in the standards world.
Yeah. I mean, I'm curious how how have you been thinking about this question of because you've been taking a lot of an ecological perspective to some of your thinking and particularly with the browser, but just in general, I mean, how are you thinking about what it means for, like, not like a charter to actually be renewed, but to actually stop? Oh, I'm sorry.
I have to
say that I'm very quiet. Sorry.
Just be right. No no worries. The the the the problem with stopping is actually, let me rephrase. It's probably wrong to think in terms of stopping. Mhmm. You need to probably think in terms of where the work is going to go. Yeah. If unless unless your thing is dead, which, you know, happens, that there are dead standards and well, in that case, you just stop because there's nothing to do. It's dead. Right? But if it's not dead, there is something to be done. There's always no standard is finalized. There's always some maintenance. There's always a problem. There's always a new thing that it needs to integrate with. But it might be the case that, you would benefit or, like, the world would benefit or someone would benefit from the work that your group is doing, shifting to another group, being split, being reconfigured, being merged into something else. And so I don't have a general answer as to, like, when situation x arises, you know, you should you should be thinking about that.
Have there been any standards for, like, easily forking or merging organizations? I remember talking to someone, I can't remember who, but they were talking about how, like, one of the biggest challenges that organizations will have is how to successfully fork and do that easily and, like, deal with all the legal implications of that. So I wonder if there have been any standards around making forking as, like, easy as possible or, like yeah. Like, it seems like even the process of doing the kind of thing that you're talking about has its own kinds of not, disfluencies. But
Yeah. It's it's it's difficult because, basically, what what you're managing if you think of in terms of the results that you're managing as as a standards organization, you're managing a starting point. Right? This is this is where the agreement happens. If you fork the shutting point, well, there's no longer a shutting point. And so you want to enable forking because you you do want that possibility of challenging it because you want it to be possible to move it somewhere else, but you don't want it too much.
You don't want it to actually happen. Right, Luke? Right. You want it to be possible so that it keeps you honest, but you don't want it to happen because that's next title. Exactly.
Yeah. It's the opposite of a check of gun. You want it on the table so that no one uses it. Interesting. It's it's actually there there is there is that thing there's, the philosopher Jean Paul Saint de Saintie talks about his approach he compares his approach to philosophy to how people would play games when he was a kid in his native Corsica. And the way they they played card games is they would, you know, meet up at the cafe with with bring out whatever card games they were playing, and everyone would put a gun on the table. And he never saw anyone shooting it or even picking it up. Right? It was just there. And to say, this is the this is the card game, therefore it's serious. And and you sort of want the forking option to be to be like on the table, but like no one no one ever picks it up. Right? And that's the institutionally that's impossible. Right?
Yeah. Yeah. The I mean,
the other thing to bear in mind is that that as well as managing this magic, you know, magic meeting place point, you're you're managing actual human beings. And one of the the clear reasons why, you know, bureaucracies are self perpetuating is there's quite a lot of people who discover that they've got a job and they're getting paid to do something. And they don't really want to go and look for another job because that's just not, you know, for for a large number of people, that's not a fun hobby. It's a, you know, highly stressful thing that they'd like to avoid. And and so that just plays into how these are all sort of institutions or communities, and they will have that dynamic behind them. And so that's like a just a constraint you can't
get rid of. Mhmm.
Politics, Alex. I'm I'm gonna challenge Alex to and say, politics, you know, a guy I know often says, you know, people get into technical standards because they they want to have good technology and avoid politics, and now they've got two problems. Politics is is just the art of figuring out how to get along with each other and how to do things. And and you can if if if politics is good, it's actually about keeping things smooth. It's about people relating to each other well and being able to work together effectively. And if it's bad, it's miserable and pain. And it's the miserable and pain of bad behavior in groups that I think people are trying to avoid when what they say they want to avoid is politics. They don't mind politics if it's just everyone that agrees with them. And and yeah. A little like
the conversation earlier about gatekeeping. I should I mean, I did not mean to, like, turn it into a a second panel of the second panel. But it's nice to see some people stayed around, and thanks for the kind of post panel discussion. Lots to pick up on later on in future conversations and when I'm less tired. But thanks again both and everyone else for coming, and I think I'll go ahead and close the meeting now.