 I want to tell you about a use case for GitLab that doesn't involve code or documentation. And that's the, as we just heard, the use of GitLab for development of formal business and technical standards. So I'm going to be talking a little bit about the open group, because some of you may have heard of us, and some of you may have not. I want to talk about how we typically, in many standards bodies, do standards collaboration currently. Then I want to get into this concept of standards as code following on what you've heard here. Everything is code. And I'll give some examples of specific use cases of GitLab. And then I want to talk about where we want to go with this, how we want to go beyond simple collaboration by our community. So first, how many people have heard of the open group? Good. I suspect many of you might be members of the organization. The open group, for those of you who haven't heard of us, we're a global consortium or member-based. And what we try to do as we try our mission is to enable people to achieve their business objectives through use of business or technology standards that are open and vendor-neutral. We were about, I think we were 740 members when I checked on Friday. I think we're 742. And so again, many of you may be members, which doesn't title you to participate. And our vision is what we call boundaries information flow, getting information to the right people at the right time in a secure, reliable, and timely manner. It's a global organization. Those 700 members are in 47 countries. We've got staff around the world as well. And we have big companies who are our Platinum members, who are our governing board. But really, the members of the open group are companies at all sizes. We've got one-man shops. We've got these large vendor companies. Amazon, the AWS is one of our newer members. So thank you for joining. But we've got people like, we have a lot of emphasis on buyer-supplier balance that we have the buy side of the company, the people who consume IT technology, helping drive these standards as well as the vendors. So we've got agencies like government agencies and USDUD and things like that. So there are some standards that you may have heard of from the open group. The UNIX standard is probably one of our longest known standards, maybe not our best known standard these days. And that's been around, as you can see, that's been around since as long as the organization has been around. Some of our more recent standards, one that I've been very heavily involved with is our digital practitioner body of knowledge. And that's a standard for what's the skill set that a digital workforce should have if they're going to turn their company from one that's sort of a traditional product management company into one that's sort of delivering their value through digital first means. And this one is interesting because this is the one where we pioneered this idea of standards as code. And I'll get into some examples of how we did that. So how do these standards originate? Now, we've talked a lot about community on this stage. And community is vital to the open group. The contribution of the volunteers from our member companies is the fuel of standards development. These people bring the ideas, they bring the work to create the words, and they share their ideas. They hammer them out sometimes through interesting consensus processes. But that's really the heart of where all of these standards come from. They don't just come from above. People like you come together and build them, not unlike how you might come together and build code. And so the core to enabling these people to work efficiently together and to deliver these standards quickly in a way that's timely for the business need is something called the open group standards process. And this standards process involves both the development of the materials and also the mechanism by which we determine that people have reached consensus. We've actually got the right ideas and the right information in the standards and getting that published and adopted by the world. Again, very similar to the idea of going from creation to delivery of value in the marketplace. That's set against some really core principles for the open group. We're very much committed to openness. It's in our DNA that we have open processes that are both really open, but also that are seen to be open. People can come in and look much as GitLab has transparency in their company. People can come in and look and say, oh yes, we know that this was a very standard that was arrived at by real cooperation among the people and there was no funny business. That it's all done through consensus process. We don't have voting where 51% of the people vote and then somehow that goes through. That works out so well in politics we decided to avoid it in the standards process. So we want to have the broad consensus of the participants in there. It's got to be timely, deterministic, again, that value cycle time. I'll let you read the other ones here. And because we are so, and you can read about this again, transparency, you can go to that URL and read everything about the open group standards process and because we put so much emphasis on this idea of openness and consensus and good process that the open group is what is called a iso publicly available specification. We can take these standards that are developed through consensus of our members and bring them right to the international standards community. So of course what people think about and quite often the hardest part is in fact the standards development, how you bring people together and create the ideas for the standard, actually create the wording, polish the text, polish the product and all of that. But then that's followed by this idea that there's a process by which we determine the consensus, we document the consensus and we produce it that in an auditable way. And that's the core way of working with the open group. And then of course the mechanics of getting those standards once they're created and approved, published to the marketplace. And you can start to see some parallels here between the development phase and what the standards operations phase is. We actually call that forum operations inside the open group. And so we're, and this is all a very well established and well modeled process here. You can see it here and again I won't go through this in detail but you can see this on the left side here, the creation of the draft material by our collaboration of our members and then the formal process of approval which involves people proposing how they want to change it and voting on the results of that and then getting that published. Before anybody asks, standards at the open group are not just written. We do code as a standard, something we call the executable standards principle that obviously things that are in code quite often accelerate the adoption. We're all about again that cycle time and getting to the market in a timely and deterministic way. So if that is background of what the open group does, let's look at how we've traditionally done standards. So traditional way of doing these formal standards is kind of what you might expect that people write these documents in proprietary word processing formats. They share files. We have our own tool. It's called Play-Doh. It's a website that helps organize our members. They can upload drafts. They can schedule meetings. They can have discussions on all of that. And this works. This is how we've developed a lot of standards and it works okay. But as you can imagine that it's kind of labor-intensive. The fact that you have to, you know, you're floating all these drafts around can be error-prone. And it does not lead itself to distributed development as, you know, we heard everybody wants to work remotely when you've got 740 member organizations around the globe. You have to work remotely. And trust me, mailing a word processing file around and getting people's comments is going to cause a ton of work for somebody. So we want to change that. Oh, before I get off that, I mentioned part of our process is a review, a review by all of our members to say how you would like to change a document to make it acceptable to you. This is an example of our review tool. And you can see there are places where people have made a typical change request that says, oh, you know, we need to change how we describe cloud. So I want to change these words to these other words. And again, somebody, some poor person has to, and we've got a hero at the company who does all this, has to implement those in the text. But take a look at this one. This is not like the others. You can see here there's the issue that the person has a concern about. But what's in there for the change? That's a merge request. So this is an example of how we're moving from this old world of word processing documents and mailing them around to the use of these modern tools. What are we trying to do? We want to move from these proprietary and monolithic documents that are handled by humans to go through human processes to bring all of the changes together, all of the consensus together. And again, some poor person gets to be the editor who puts all these changes in. And we get few large reviews. And of course, because all this is sort of upload and download, it's a real barrier to global around the clock participation. So we want to kind of move on from that and get into having structured and modular standards so that it's not just one monolithic document. We want to use that, do that in some way that's using a lightweight markup language so that any tool can be used to edit the documents, including no tools at all. I'll show an example of that in a second. We want to have fully distributed authorship. I want to make sure that if I'm writing a section and, you know, somebody else in this audience is writing a section, we can be working on that at the same time. I want to make sure that the reviews can happen continuously. And I also want to get the humans out of the loop. I don't want the humans doing heavy lifting on the standards. But we have to do this all while maintaining the integrity of that standards process I showed in the earlier diagrams. So this is something we call standards as code and it's been enabled by really two things. One of which is managing the content and workflow using GitLab and offering the documents in a lightweight markup language. We use ASCII Doc, we've looked at markdown, both work. I can discuss the pros and cons offline. So that's what we're moving to and let me give you some examples of this. So here's an example of, I know you can't read it, but this is an example, you can maybe see some of the syntax markup of a document that's authored in ASCII Doc in the GitLab Web IDE. And you can see here some of those things that we talked about. You can see that the document has been broken up into smaller modular pieces so we can have independent and parallel creation going on. Because we've got this Web IDE, I don't need to have, I don't need to buy somebody's word processor. I can just go to the GitLab Web IDE and start authoring. That really lowers the barrier for our member contribution. And of course a cool thing about GitLab is that you can put it in preview mode and you can actually see that lightweight markup rendered the way your page or your section of the content is going to be. So these two things together, they dramatically lower the barrier for people coming in and creating some content. Now of course not everybody uses the Web IDE. I actually use a Git client and a text editor on my iPad. I've got a great story I can tell. I don't have the time to tell it on the stage, but I'll be glad to tell that offline. Of course we now have started to make those change requests using the GitLab issues mechanism. We actually use GitLab boards to actually progress some of these change requests through the approval process. Great thing of course, of course in GitLab the issues can be implemented by merge requests. So somebody can write up what change they want to make, put that in their issue, and then we can just push the button and have that merged. And then through putting the ASCII doc tool chain as part of our CI CD tool chain, we can build automatically. Every time somebody submits and we approve a merge request, we automatically build the HTML and PDF documents. And again, that helps that continuous availability, the continuous reviewability so people can see what's being changed in the document and help bring that whole community together in consensus on what the right output is. And the really cool thing is there isn't an editor. There isn't a person actually saying, oh, I'm going to take all these sources and compile them into one version. All just happens through the CI CD tool chain. So that's where we are right now and you can see that we've gotten to the point where the contribution and some of the reviewing can be done using the features in GitLab. And I want to really thank GitLab for supporting the open group in doing this. I want to talk a little bit in the last couple of minutes about where we're going. So we've been rolling GitLab out across all of what we call the forms of the open group. These are the subgroups that work on specific topics. I gave the example of our digital practitioners work group, which created the digital practitioner body of knowledge standard. But that pioneering effort has spread to many forms of the open group. We've got it's being used by our agile architecture. Because many people know the open group for the TOGAP architecture methodology. We're developing some new agile architecture methodology work, which you can take a look at on the open group website. We are developing new commercial aviation standards. We've got our IT for IT best practices for using for managing IT shops. That's now moving into using this. So we're getting really, really good uptake. And of course, people see the benefit. People can see the benefit of that parallel contribution, the lightweight markup, global access. And even that UNIX specification I mentioned at the beginning, that one, they have 50 years of uptime. That has now been moved out of TROF into this modern tool. And that's how we'll be maintaining that standard going forward. We want to move beyond just the document creation phase. We want to get to something that we're liberally stealing the idea from elsewhere, something called standards ops. You noticed earlier that there's the development phase and then there's the operations phase. We want to have the consensus development of standards that fully implements that open group, open and transparent process and the collaboration among our members using GitLab as the one source of truth, both in the development and the delivery phases. And we want to do that with minimal manual processing. And it's a big step. Heritage of a lot of software development projects is the small agile teams. And that was exactly the right thing for them to do. We have a slightly different problem. We have very large teams. We have hundreds of people who work on these standards. And so the challenge for us is, again, sorry, I blew my own build here. So we want to do this both for our current use in the development phase, which is working very well. But also the challenge, again, is to move that into the delivery phases. So the challenges that we're working on here, and I hope we'll be working more with GitLab and others, of course, all our member organizations, what are we working on right now? Determining group consensus. GitLab has excellent tools for determining consensus among small groups. We're figuring ways to scale them to hundreds, consensus around hundreds of people. There's things like how you announce, how you tell people what to vote on, and when. It takes a little bit of organization when you get a team that's hundreds of people. So we need things like time-bounded voting, how you report on issues and things like that. Because we're so concerned about being seen to be open, about the transparency, we have to work a little bit on reporting and auditability. We need more automated reporting of issues to large groups. We need to know who's involved in the process. We need to know who voted where. We just need to know who's in on it at all. And we need to be able to do summary reports. You go from phase to phase to phase that we can say, here's what happened in each phase. One of the things that's kind of important, I mentioned those platinum members of the open group, one of their key responsibilities is that they're our audit board. They're the ones who look at each one of these standards and say, did you follow the process? So we need to report to them, so we need reports. And again, I've mentioned how to operate community scale, how do we go beyond small groups of members where this all works great, how we go to hundreds of members participating. We are open to any and all ideas. We would love to work with people. I'm hoping we're going to work more closely with the GitLab folks on this. But if you've got ideas and we're not the experts on this by any means, please come and see me in a break. And so I'd love to get your ideas, so thank you very much. I really thank GitLab for the time to present this hopefully unique approach. And if you want to come hear more about it, you can join us at our upcoming event in San Diego in a couple of weeks. So thank you all.