 Welcome back from lunch. Good afternoon. My name is Jory Burson. I am a program director at the Linux Foundation where I get to work with a number of really awesome projects, including the OpenJS Foundation, which is home to a number of important open source JavaScript projects like NodeJS, the Open Source Security Foundation, which recently secured about $10 million in new funding to help secure our open source supply chain. And of course, the Joint Development Foundation projects, which I'm really excited to tell you more about today. On the surface, the projects that I work with are really, really different, but they share some important common denominators, one of which is a strong foundation in collaborative standards development activities. LF standards exist to support that collaboration, driving the innovation cycle as technologies move from new ideas to reliable products to commodity solutions in the marketplace. And today we'll talk a little bit about how we do that at the LF. A good specification is really a marvel of technical collaboration because it represents agreement. And if you spend much time with engineers and developers, you know that agreement can be very hard to come by. If you haven't been part of a spec drafting process before, let me generally describe how that works. Throughout a drafting process, participants are going to be working together to constantly reference their objectives, use cases, requirements that have been gathered and so forth in order to prevent scope or feature creep. The participants will work together to document what is the minimum agreement necessary in order to ensure technical interoperability with either existing standards in the marketplace or between implementations. Great specifications take even more into consideration beyond technical decisions. The regulatory environment, potential threats and harms, misuses of the technology, social impact, things like that can be factored in to create specifications that more people will want to use. That's what we want. The level of agreement, the depth of consideration, all of these things can influence whether the spec will be successful and that's generally measured by the number of implementations that you see out in the marketplace. So that process can start with just a handful of engineers and an idea and that's it. And from there, evolve to potentially change the world as we've seen with really impactful specifications like TCI IP, Wi-Fi, 5G, etc. So that said, there are a lot more standards and specifications driving our technical world than most people are even aware of unless they happen to be in that particular industry or field. Even here in this extremely dramatic theater, which I am very much enjoying, we're unconsciously surrounded by dozens of standards from say the width of the aisles and the doors, the fire retardants of the fabrics, the size of the seats, the type and the strength of the construction materials, all that, which have been developing since frankly the late 1800s to keep us physically safe when we come to shows. I guess Artemis is showing in here and that's why this looks so awesome. And all that makes a lot of sense, right, because you probably don't need to know that there are over 250 standards, technical interoperability standards, implemented in a modern laptop in order to do your work unless of course you happen to be in the computer manufacturing business. You don't need to know all of those standards. The average consumer and indeed a large number of technologists are not really aware of all of the invisible infrastructure that exists of specs and standards that are working together to protect them, let alone are they aware of the hours of discussion, of process, of arguments, of debates, of testing and so on and so forth that have gone into each spec in order to make something we can use. It's one of my personal goals and also a goal of the JDF to make that system of standards development activities a lot more accessible to people and certainly you all here included. Standards development activities also build on themselves over time. It's kind of interesting how that works as new specs are created, they extend and they gradually replace or directly build on top of each other. That sort of creates this rich soil from which new efforts can grow and from which we can learn from the best efforts of the past. Depending of course on your own experience with this process, if you've had experience in debuting standards development work in the past, you might be thinking, why yes, Jory, making dirt is a great analogy for standards development because it is messy, it takes a long time and it's boring. That may be true, it may have certainly developed that reputation over time, but if that were really true, would a very cool millennial such as myself be up here talking about standards? No. So thanks to open source development processes, also how a lot of our tools become more web powered and developers centric in terms of how we collaborate with each other. The modern decision making frameworks that we have, we're speeding up the spec development process and driving development and delivery of interoperable products to the market faster than ever before. So a specification project really can be a critical and efficient part of your technical strategy, adding to your open source and product development work rather than slowing it down. As you all know, highly regulated industries such as financial services have some pretty unique challenges and constraints when it comes to technology and collaboration. You have rigorously audited mandates and policies that create constraints that kind of narrow the solutions that may be viable for you in order to serve consumer privacy, personal data, independence, financial protections, and other government regulations. That reinforces the reality that such industries like this are generally are and really, really need to be highly networked ecosystems where in each of the market participants can work together in order to find interoperable solutions that meet regulatory requirements. This cross network cooperation in these areas doesn't really provide a competitive advantage for any given player, but it does de-risk and expand the market for everybody. Your firm's ability to meet a regulatory requirement is not generally a competitive advantage. From a technical perspective, capabilities like that are prime areas to turn these industry utilities into something that can be shared where the investment costs can be shared by everyone. So let's look at PSD2 as an example. In 2015, the European Commission revised payment services directive with the goal of increasing competition and consumer security in the payment services markets in the EU. The goal for implementation was 2018, although the actual rollout began in late 2019. Given the relatively short implementation deadline, a lot of banks chose to employ consulting firms to implement the PSD2 APIs at their individual banks, and only the UK chose to implement the mandate through a specification setting process. So the result was a pretty wide variety of implementations that came to be across the EU with no single specification for the implementation of that mandate. Then of course, other countries seeing this want to do the same thing, they start to express interest in implementing policies similar to PSD2, but there's no readily available single source of truth that would have allowed them to easily approve in advance the PSD2 features in other countries. So looking at the project across all the banks, the implementation would have logically cost more than a standardization process. Each bank developed their own solution and implemented the solution within the bank with relatively little coordination between each other, between the implementations. But with a standards track solution, each bank could have contributed resources to a common implementation and attracted a pool of developers and engineers who could have interacted with the standards body when bugs or implementation problems arose. Then that standard could have been updated as new requirements emerged or enhancements were proposed and test suites could have been developed to ensure interoperability between implementations. So the implementation of the mandate essentially just installed new plumbing in the banking ecosystem. It didn't differentiate one bank from another, it just added functionality that all the banks were required to add. That kind of non differentiating functionality is the classic example of where a common standard or utility really could have benefited all of the banks for a lot less cost. Why didn't they do it that way? Great question. I don't know. But perhaps one reason is that they over weighted the coordination cost of a cross industry effort. Most standards bodies are topic specific. They have customized governance structure that's negotiated among founding members that takes a long time for that kind of negotiation. They're distinct legal entities that have a custom set of bylaws established by the founding members. They have custom licensing terms and of course staff to maintain the legal entity. All of that really does take quite some time to stand up from scratch. Historically the spokes standards bodies are populated with have been populated with standards engineers who specialize in contributing to standards bodies. But within a lot of companies these days those folks are being moved out of those centralized roles and into product teams. Many of those engineers used to report to a centralized standards function within their companies. And now the specialist ecosystem that did exist has been kind of distributed throughout an organization and contributed to perhaps a reluctance from other industries to start collaborations of a technical nature. So again as time has passed those folks moved on and were absorbed into product divisions and they've been replaced in these technical forums by working engineers on the product teams. Also as software has eclipsed hardware projects in the standard space and as open source has become more of a powerful segment in the software development world. We're definitely seeing a lot more diversity of forces shaping what our standards development landscape looks like. That has had the effect of really upending the traditional standard setting ecosystem from what you might be familiar especially in areas of new standardization activities like green software, software supply chains, common data, that kind of thing. As well as in modern or is in traditional fields such as video codecs. Today we see that system of standards forming up which embraces changes in technology and acknowledges the need for living specifications. Standards projects are increasingly software centric, they're involving working developers, they're using collaboration tools which are commonly found in software development like Git and GitHub. And they also are incorporating open source licenses. Of course a lot of that change creates challenges. One of the hurdles has been project formation. Creating a legal entity is really a significant time sync type problem for starting a new project especially if you want to get work underway really quickly in order to meet deadlines. But it's really necessary. A project needs the protection of a legal entity for the benefit of the participants and for the integrity of the specification. It requires a lot of time and experience and lawyers in many cases to get that up and running. And then once it's created the legal entity also requires a lot of ongoing maintenance, fundraising, tax reporting, etc. And those are costs that can be really hard for new collaborations to estimate or control over time. As standards development continues to move away from like the theory driven R&D based research technologists to more practicing implementation focused engineers and developers. Another challenge is the experience gap. New projects really do need experienced people who have led standards efforts and are thoroughly immersed in what the current best available practices are for collaboration in the standards community. They need to know IP and copyright licensing expertise, process knowledge, and of course they should know what a well formed standard should look like. The LF has been in the middle of that dynamic for quite some time, smoothly facilitating technical change. And we've learned a lot about what it takes to be successful in these efforts and so today we're glad to share that knowledge with you. I'll come back to applying this to finance specific standards in a minute but let's take a look at what good looks like when it comes to a specification and why that process is important for long term success. So good specification should yield a common set of requirements and use cases that should be shared, understood, shopped, vetted by the participants. It should have a consensus view of how the implementation should work. So lots of agreement amongst the parties for what is intended. A referenceable public specification which allows for interoperable implementations. Some groups love reference implementations, others don't but either way such documentation that's viewable by the public is very, very helpful. Clear definitions of the licensing rules for contributions and use. Very, very important not just for licensing but also all the definitions within the spec itself. And of course a good specification should yield something that developers and users can easily adopt. Specifications improve their chances of adoption by providing supplemental information and materials a lot of time so that's something you can add to. Test suites, implementation guides, conformance tools, etc. All those things can help users understand what the specs requirements are and then meet those requirements which may be very important if you're looking for developing a conformance or compliance program. Of course setting up those processes and schemas requires experience and at the very least a lot of knowledge and access to best practices and templates so that your effort is not wasted on reinventing wheels that other groups have already have invented. At the LF we have a variety of options that provide assistance for specification development projects. We can set up very, very simple unfunded pre standardization collaborations and migrate them over time as they mature to fully funded projects that utilize traditional standards practices. We can submit specifications to international standards bodies so that they can be recognized and implemented as national standards through our ISO pass submitter status as well as our extensive liaison relationships with other disarray organizations. We also have a staff of standards and open source experts who can help set up proper process and governance to meet consistent licensing and governance policies that are again consistent and compliant with industry norms. We can provide the staffing to projects to help relieve the administrative burden on your collaboration which allows your projects and your participants and your team to focus on the technical collaboration rather than the bureaucracy. And we can bring existing incorporated projects so if you've already got something up and going under the legal and administrative umbrella of the LF or alternatively we can help you create a green field project really quickly and inexpensively using our joint development project resources and that allows projects to form up distinct legal entities using sort of consortia in a box templates. These are but some of the considerations that you might think about and options you might think about as you consider a new collaboration. Which of those paths and options are the best for your particular situation? Of course can vary depending on a number of factors and also, you know, your project ecosystem. Not the least of which of course is what the context and reality is for your members and contributors. What does life look like for them? With banking and financial services, the participants tend to be large organizations with complex and also often static regulatory policies and technical requirements that have to be balanced against maybe more progressive social impact and brand equity goals. So, you know, in a head to head battle between those types of concerns the question might be which of them should win? Is there a framework of decision making around how we address those competing concerns and is that feeding back into your project? Is it informing your product, your open source and your spec development strategies as you consider them? To be truly efficient you need to create that feedback loop in a way that balances the multiple considerations your project and its stakeholders have to evaluate. And while at the LF all of our technical communities are different, they also share some core needs. And we've developed several patterns that give projects the flexibility to prioritize and tackle what's most important to them. So here's a few examples of how this works at the Linux Foundation. GraphQL, anybody use GraphQL? GraphQL is a data manipulation and query language which was created in 2012 by developers who were then at Facebook. In 2015 they open sourced it and in 2018 the GraphQL foundation was created to home those assets. So project that came out of a company, pretty standard story. The open source reference implementation and its connected projects live quite happily under the LF's open source umbrella. But in order to move the language to the next level in terms of I guess legitimacy and other things, GraphQL decided to utilize the joint development foundations existing collaboration frameworks in order to get started really quickly on a community-driven specification development process that has compatible licensing, contribution, and governance policies with its open source side. And that combo allows the community to easily update the spec as the open source implementation updates or to update the open source components as the spec changes, as spec bugs are addressed, etc. And that happens in a continuous and cohesive collaborative manner. And instead of taking months or years to do that or to set up those processes and refine them, it took us just a couple of weeks using existing templates. So now you can go to their website, you can see their live spec, it's updated continuously. Just like a real web technology. Another example here is the Alliance for Open Media. This is a little bit more traditional in terms of being a traditional consortia. It started from scratch in 2015 under the JDF umbrella and was able to get going really fast in about two weeks because it leveraged JDF's existing legal boilerplate. So all of the open source compatible W3C-based patent policy options and straightforward membership structure, all of that was already settled, already defined, a large number of members already behind it. So they didn't have to spend those months and months with their legal teams addressing how to create this entity. They could just get up and going. So given the competitive and patent encumbered nature of that particular space, it was also really important that all of those legal pieces, especially the IP assurance tools, were really nice and buttoned up. And today, AOM is over 40 members strong with a world-class technical program of royalty specifications and source code. It's also really well-funded and well-positioned now as they choose to continue advancing their standards nationally through the de jure processes and liaison relationships that they've established. Our last example is C2PA. That's one of my pet projects. C2PA is a technical specification project that was born from a couple of different industry policy orgs, Project Origin and CAI specifically, which these are groups that are home to news media publishers, other types of groups like that. And they wanted a neutral place to develop standards based on some of the emerging requirements and cases coming from our current and extremely relevant conversations about digital malicious synthetic media, aka deep fakes. They wanted an approach for developing a technical standard to address this problem, a big problem that was really neutral, that was lightweight and could accommodate a set of global stakeholder concerns because this is an issue that's really being tackled internationally. They just launched at the end of February of 2021. And then this week, they just launched their second call for public comment on their draft specification. V1 of their spec will ship in just a few weeks and that will ship complete with implementation guides and some other supporting material for users. So that's going from zero, from absolutely nothing, except for a general agreement that this is important, we should do something about it, to an implementable, shippable spec with cross industry agreement inside of 10 months, which is wicked fast. And I'm from Boston so I can say that. So JDF has a lot more, and the LF have a lot more options and examples that we could discuss and share with you than we actually actually have time to share today. But I'm really hoping that this presentation has helped you think about specification development processes as something that can be quick and useful to your tech strategy and perhaps inspired you to learn a little bit more about our community specifications, our JDF projects and then we've got other comprehensive standards projects at the LF like SPDX and Open Chain. There's a couple of links that I'd love for you to check out. Jointdevelopment.org is more about the JDF work. Community specification, the 1.0 repo is a great resource if you have an open source project that wants to dip their toes in a spec drafting process, please check that out. And yeah, I mean, I hate to say that it can be that easy, but it really can be that easy. In closing, I just want to say thank you to my colleague, Seth Newberry who helped prepare this deck, who's not able to be here today, also Scott Nicholas, Mike Dolan and Dave Rudin from the JDF. Thank you all for coming to listen to me talk about standards in a very dramatic setting for standards. If you want to reach out to us, you can do so here. And I don't know if I can take questions. Is that something where you can do? Yeah, I have time. I mean, I have two minutes, it says. Any queries? Query me this story. Yeah, we're excited to work with Phinos. And, you know, that would be something that we would love to, I would love to meet you if you're one such person. Tasha, others, I'm sure too, if you're interested in what Phinos specifically is doing in this space, come chat. Okay, cool. Thank you all very much.