 and thank you for joining us for the second day of the open source strategy forum 2020. Well, I really genuinely wish that we were meeting in person this week and I'm sure many of you do too and probably my kids who would like me out of the house. I hope that you enjoyed the content yesterday and I am excited to kick off day two. So just before we get started, a few quick reminders. We welcome and encourage you to engage with the community. We've had some great lively conversations over the Slack channels and there you can chat with other attendees and presenters on really a wide range of topics, maybe related to open source and finance or maybe related to your pets or food and really anything that helps engage you with the community. And we want to keep this conversation going so the Slack channels will stay open for a while. You can carry on having the conversations and we also recommend that you subscribe to our community at Phinos.org mailing list and this is just a place where the community provides updates about things that are happening in the foundation. We also hope that you will spread the word for your own networks and social media and the bigger our community, the more we can do together. And finally we want everyone to enjoy the event so please be sure that you follow our code of conduct and treat all of the attendees with respect. You can find the code of contact in multiple places including under the information heading at the conference site and if you encounter any issues or find anything at all concerning please don't hesitate to contact Trisha Barker or Angela Brown and you can do this via Slack, direct chat on the conference platform or even on email. I would also like to give a great big thank you to our sponsors, our leader sponsors GitLab, IBM and Red Hat, our contributor sponsor Tidelift and our community sponsor TradeWeb. This wouldn't be possible without you and attendees please make sure you stop by their booths, check out what's going on, engage with them in Slack and we really are very grateful for all their support. So let's kick off with today's keynote. Yesterday Gab spoke briefly about the noteworthy progress that our financial services community has made in adopting open source and the value it brings to all participants both on the technical and business side. And today I'm going to focus a little more on how the finance industry can build on that and tackle some big challenges. And by way of introduction I'm Tasha Ellison, the Chief Operating Officer at FNL. So this morning we issued a press release announcing that two new projects have been contributed to the foundation and that we've kicked off an important new initiative. So the first, the Symphony Java toolkit has been contributed by Deutsche Bank and as adoption of Symphony grows, this is an ideal time to collaborate on tools that address common concerns and workflows. And this suite of libraries really does just that, you know, it's been used in production at Deutsche Bank and it focuses on delivering client functionality, things like request for quote, building orders, sharing acts information. And these are useful utilities that should be developed once, collaboratively, not multiple times across multiple firms. You know, doing it once, that means you have more time to focus on the price that's actually in that RFQ or the customer order for your client and really the value add for your firm. And if you didn't catch yesterday's talk, it's worth watching the replay to learn more. We also announced that OpenMama has joined Venus. Now OpenMama is a vendor neutral cross-platform API that interfaces with a wide variety of message oriented middleware systems. It provides a simplified way of sharing market data across investment banks, proprietary trading companies, hedge funds and data providers. And if you've ever done an implementation of a market data feed, you know, it can be complicated and take about a lot of time. So, you know, having this common project can help reduce the cost of ownership and the time and the time to market for all of the market participants. Now OpenMama was already open sourced under the Linux Foundation. But when Phinos moved to the Linux Foundation, it made sense to join together where we can jointly benefit from the alignment of our members and community. So where is this taking us? You know, we're excited about these contributions and they really highlight part of what has been a great year for us. You know, as Gavin Dove mentioned yesterday, we've had a record number of contributions from banks. And this is a strong indicator that financial services is more fully embracing open source. You know, with this growing community and ecosystem and this greater comfort with open source practices, the finance industry is in prime position to collaborate on bigger opportunities and innovate the open source way. And, you know, one of the opportunities we see is in red tech. You know, we think that there's the open source software and standards can really change the way that financial regulation is interpreted, implemented and supervised. And that's why we started the OpenREG Tech Initiative, really to explore and promote opportunities for collaboration between financial institutions, technology firms, service providers and regulators. I co-lead this initiative for Phinos alongside my colleague Aitana Mial and we're thrilled with the interest that we've had so far from all of these different market participants. You know, and as a result of that interest, our board has approved the creation of a special interest group focused on this topic. Now, before I get into a bit more about the special interest group, I want to give you a little bit of a sense for just how big of a challenge this is and why it's important. You know, there are a very large number of financial regulators across the globe. And many financial institutions provide services in a large number of markets and so they need to address the requirements for those many different regulators. And those regulators might all have different models or different approaches to how they deliver and want to receive information related to the regulations. You know, and these regulations can be very lengthy and dense. For example, Dodd-Frank's regulatory definition of swaps, the swaps is 160 pages long. You know, these many millions of pages of regulation ultimately result in the production of billions of data points. Former Bank of England Governor Mark Carney said last year that the bank can receive 65 billion data points in a single year. And there's a reason for this. You know, financial services is an extremely complex and often nuanced industry covering a huge range of products and services delivered to hundreds of millions and in some case, billions of people. And as you can imagine, with this level of complexity and scale, there's a cost. You know, it's costly. It's expensive to interpret those regulations. One report showed that bank compliance costs jumped more than 50 billion dollars a year after Dodd-Frank. And that's before you even get to the implementation. And for each of the regulated entities who has to implement those regulations, there's a technology cost, you know, a systems cost. Lexis Nexus recently estimated that 40% of financial crime compliance costs are associated with technology. And then there's the expense of making, understanding what all of that data is telling us. You know, but with all of this, it's important that we get regulation and compliance right because if we can get it, if we get it wrong, there can be disastrous effects. So with that as a backdrop, I'd like to tell you about our regulation innovation SIG, which we announced this morning. This is being led by AIR, the Alliance for Innovative Regulation and ING. In fact, you can chat with the SIG leads in Hollerbred and David Erick in our Ask the Expert session just after, during the break, just after the keynote today. And the goal here is to bring together individuals who are interested in creating open source solutions for regulatory and compliance issues. And we provide a neutral, trusted environment to explore the challenges, identify opportunities, and ultimately build open source projects, standards, tools, models, documentation, reference, reference implementations, really anything that is open but governed that can help. You know, and we recognize that it's important to have representatives and insight from all of the different participants in the industry. So from financial institutions, we need compliance professionals and architects and engineers. And we need regulators at the table too. And, you know, there's some great innovative regulators, the FCA, the Bank of England, FINRA, CFPB, who you can hear from later as well. And the tech and advisor community has a huge role to play also. And we need the reg tech consultants, other foundations, associations. We all need to come together to figure out how we can solve these industry challenges. We had, the first, the SIG had its first meeting earlier this week, and two items that came up repeatedly were standards and interoperability. And we discussed a number of different potential focus areas, digital regulatory, digital regulatory reporting, AML, horizon scanning, payments. And these discussions often came back to the importance of standards and interop, and this really underpinning the ability to be successful in making change. You know, so we had a great initial conversation. We have lots of directions for future conversations. And, you know, we're really looking forward to finding some exciting projects to work on together. If you want to, you can learn more about the SIG and find out how to get involved on our website or on our GitHub repo at finnos, github.com, finnos open reg tech. And so, we know that this is an easy industry challenge to solve. It's hard. It's going to take time and effort of many individuals and many groups, but open source in all of its variations must have a prominent role in how we make it faster, better, and easier to produce, interpret, implement, comply with, and supervise financial regulation. Now, this is just one of the big issues we think open source can help solve for the industry, but we do think it's an important one. So, with that, I'll wrap up. You know, we have many more projects and initiatives, and there are lots of ways that you can get involved, you know, whether that's coding or providing insight, so many different opportunities. So, please do reach out. You can reach us on Slack via email, lots of different ways. And there are a number of sessions today that touch on different angles of regulation and also a number of other topics. So, we're pretty excited about our lineup today, including our fantastic keynote. And with that, I'd like to introduce our first speaker today, Chris Ferris. Chris is an IBM fellow and CTO of Open Technology for IBM, and he's been involved in the architecture, design, and engineering of distributed systems for most of his 40-plus-year career in IT, and he's been actively engaged in open standards and open source development since 1999. Today, Chris will talk about the importance of securing the open source supply chain. So, please welcome Chris Ferris. Hi. My name is Chris Ferris. I'm an IBM fellow and CTO for Open Tech. And I'd like to talk this morning about securing the open source supply chain. So, I think we can all agree that it's really critical that you secure the software that you deploy in your enterprise. I don't know anybody who disagrees with that particular point. What I'm talking about, though, this morning is securing the supply chain. Where did all of the open source dependencies that comprise the projects that you're deploying, whether it's Kubernetes or TensorFlow or PyTorch or what have you, where did all of that come from? Who was developing and so forth? Open source is the foundation for almost everything that we do in software these days. And when you think about it, open source projects can have tens, hundreds, even thousands of dependencies upon which they're built. And the sheer reality is that not all open source software is constructed equally. It's really fundamentally important that you understand where did the software come from? What team was developing it? Do they have security engineering practices in mind? Are they developing it in the community that's going to quickly address any vulnerabilities that might be discovered? You don't want to be in a situation where basically you have all of this infrastructure deployed on the right hand side of the screen there. And then there's one little tiny dependency that's developed by one guy in Nebraska who gets hit by a bus and nobody understands or has even paying attention to. And it fails in some way and brings the whole house of cards tumbling down. I don't want to get anybody alarmed. This isn't really something that we have to be fundamentally concerned about and stop using open source. That's not my point here. My point is that we really do need to focus on how do we improve the process for developing software with these open source dependencies, ensuring that indeed they're going to be secure as we deploy them. So last fall, there were a number of different threads that sort of started up. Each sharing a common mission, we were trying to figure out how do we improve the security of the open source software pipeline. So the Linux Foundation had been working on a project called the core infrastructure initiative. Some of you may be familiar with. But it had come to an end in the previous year and Jim Zemlin and others at the Linux Foundation were trying to figure out what do we do with the core infrastructure initiative, its assets and so forth. We need to sort of continue that program but in a different form factor. GitHub had gathered together a number of partners, including Owasp and JP Morgan, Microsoft, Google, NCC Group and a number of others and they formed something called the open source security coalition and their mission was basically similar. It was to figure out how do we improve the process of developing open source software to ensure that it's delivering securely. And then finally, there was another group pulled together by Google, IBM, Microsoft, GitHub, Red Hat, Intel and the Linux Foundation. Again, focused on just about the same sort of things. But we were doing this all independently and we sort of found out about each other through our commingled members here. And we decided that it would be important that we sort of pull all these things, all these different threads together and launch a single initiative. And that's where we have launched as of August, we've launched the open source security foundation. It's been three months now since we've launched and we've accomplished quite a bit and I'll talk about that in a moment. We're currently 35 different member organizations of open SSF and there are about 110 individuals that are collaborating on the various working groups and technical committees. As you can see from the membership, it's pretty diverse set of members. It's not just software vendors, it's not just hardware vendors, but consumers of technology as well. And again, we're growing pretty quickly. Again, this is all during the pandemic and so forth. So this is a function of getting the word out and I would encourage you to think about participating in the activities if not becoming a member. It doesn't actually cost anything to be a member this year. Because of the pandemic, we figured, look, let's just launch this, let's make the membership free to all and let's just grow this and see what we can do with it. And we in fact are getting some things done. That's the important aspect of this, isn't it? We've launched six different technical working groups to think about various aspects of securing the open source security pipeline, identifying security threats. What are the means by which open source can become compromised? So identifying where those security threats are is really a fundamental piece. Security tooling, how do we scan and fuzz test our open source software as it's being developed? And how do we scan images that we're deploying in our enterprise? Let's improve those tools and let's make them available as open source where we can. The best practices is now sort of brought into itself the work that was ongoing in the core infrastructure initiative to improve and publish a set of security best practices for secure engineering and so forth. The vulnerability disclosure group is looking at efficient vulnerability reporting and remediation. We've got a digital identity group that's looking at how do we ensure the provenance of open source code? How do you know that you're using this source code that was actually published by the Kubernetes community, for instance? And then securing critical projects. This is really sort of taking the work that was done in the core infrastructure initiative to take a look at what are the most critical projects to be focused on. Again, we can't do all of them, but we can maybe look at the top 10 or 20 projects, the ones that are most heavily used, the ones that if there were a security vulnerability would be the most important to focus on. And we're looking at how can we help those communities improve their secure engineering practices, incorporate scanning and fuzzing in the production of the software and so forth. And then finally, we have a technical advisory council that's looking across all of the different initiatives and will be incubating others as they come along to sort of keep everything sort of coherent, if you will, in terms of from a technical perspective. We've accomplished quite a bit in the first three months. We have six working groups, as I mentioned, and a technical advisory council all up and running. We published a couple of different press releases, including one last week. We had our first town hall meeting just a couple of days ago. The recording will be out on the internet soon. We've had added 16 new member organizations, and we have five new governing board members that we've added to the mix. We published our first edX course on secure engineering practices, I'll talk about that in a second. And we've, as I mentioned a couple of times, we've started to consolidate some of the output of the core infrastructure initiative. And then finally, there's a cool store where you can buy cool swag with the open SSF goose on the front label. I mentioned the edX course. This is something that's free to anybody. If you want to have the certificate, you'll have to pay, but it's free for anybody to take. And I think this is, you know, a really a great opportunity to learn more about secure engineering practices. We're pretty proud of this course. And as I mentioned, we've been working to consolidate the output of the core infrastructure initiative, including the survey of critical projects and other census that was done as a function of, okay, so of those projects, which ones are most important to have follow on work. And then we had a program called the CII best practices badging program, where you could basically have a scan of your project to see based on the repositories that you're using, are you following secure engineering practices? And then you can get a badge to indicate that indeed you are. And again, this is something that we're going to be continuing to work on as we go forward. I would encourage you to get involved. Again, as I mentioned, it's free to join. And we'd love to have new members, both from a organizational perspective and but also in terms of the working groups and committees that we have launched to date. There's mailing list meetings are all online and open to anyone to join. We have Slack, we have Twitter feed. Come on down. It's really, it's starting to really take off and we would encourage everybody to come in because as we all know, this is really critically important and nobody's going to secure it for us. We all have to pitch in and help to secure the software that they're pulling. So thank you very much. I appreciate your time. Take care. Now I'd like to introduce our next two speakers, Joanne Barefoot and Matthew Van Buskirk, who will be discussing the future of financial regulation. And Matt is the co-founder and CEO of Hummingbird Red Tech. Hummingbird is giving superpowers to the people fighting financial crime. And they're doing this by reducing paperwork, providing smart, data rich analytics and enabling collaboration for compliance professionals and law enforcement agencies. And Joanne is CEO and founder of AIR, the Alliance for Innovative Regulation. And she's also the host of Global Podcast Barefoot Innovation, which I listen to regularly. She's a noted advocate of regulation innovation and has incredible industry experience, including previous roles as deputy controller of the currency, staff member at the U.S. Senate banking committee, committee and as co-founder of Hummingbird Red Tech. And among many of her other current roles, she's also serving on the FinTech advisory committee for FINRA. I'm really looking forward to this conversation. So please welcome Joanne and Matt. Greetings, everyone. I'm Joanne Barefoot. I am CEO and co-founder of the Alliance for Innovative Regulation or AIR. We are a nonprofit dedicated to digitizing the financial regulatory world. And I'm happy to be joined in this fireside chat with Matt Van Buskirk, the co-CEO of Hummingbird, who is also an advisor to us at AIR on technology in general and especially on open source. So Matt, welcome to this conversation. Looking forward to it. We are going to make it a two-way conversation. We actually talk about these issues all the time. So we're just going to have that conversation to share with the group today. So when we think about bringing open source to the financial regulatory space, a lot is at stake. The financial system is the circulatory system of the economy. If it doesn't work well, bad things happen. If it works really well, some really good things can happen in today's technology world that weren't possible in the past. But if we're not careful, the regulatory aspect of this, since it's such a highly regulated section, it'll choke off the innovation that we would all like to see accidentally. And it will also potentially allow new risks to come into the system. And the regulatory system needs new tools for the digital age. And the pandemic in particular has really accelerated the recognition of that and the readiness to adopt it. So Matt, let me start by asking you where does open source fit into that challenge? I'd like to draw parallels to the tech world when we're thinking about where the regulatory situation is today and where we would like it to go. It's basically like the tech world was back in the 1990s with a bunch of different providers sort of building their own closed ecosystems, whether that's the Microsoft versus Apple comparison or the sort of fragmentation we saw on the internet space with AOL and CompuServe and all these other solutions that didn't really speak with each other at all. That's basically where we are today in the regulatory world from a technology perspective. And in some cases, the technology that's being used actually does come from the 1990s kind of vintage, maybe even older in some cases. So the revolution we've seen in the software space moving towards more interoperability and more reliance on shared protocols and standards, more open source code bases is non-existent really in the regulatory world. And there I think it presents a major challenge to innovation widely in financial services. As we've seen sort of fintech expand and the banking industry tried to adopt more sophisticated technology, we're still regulating using the same approaches and tools that we did 20 years ago. And it's going to continue to become a bigger and bigger anchor weighing down innovation unless we can move to a new footing using the same themes I was just talking about in the regulatory space as well. So we could really unlock innovation to a degree that we have not seen before if we can start to think about regulation as more of a open source software challenge as opposed to sort of lawyers and papers and spreadsheets. Yeah. And this thinking is quite new in the regulatory space. We do have some financial regulatory agencies that are using open source techniques in the United States, the financial or in the UK, the Financial Conduct Authority has done this in the United States, the Consumer Financial Protection Bureau has open sourced some of its work, but regulators still tend to react to the thought of open sources sounding insecure and risky. So there's a lot of education and part of what we're trying to do today is to offer an issue, a call to action for the people in this virtual room to do more. But they're tremendous potential benefits to regulators and some of them are just what this audience already knows about open source. But part of it is that regulators today reinvent the wheel every time they need to develop something we could tell you horror stories about agencies spending tens of millions of dollars to create some new platform for doing their work, that type of thing, completely inside their own silo when there's maybe already a better one at a sister agency that they don't even know about. So you could get beyond reinventing the wheel. You could get the benefit of regulators being able to build on each other's work. You could get the benefit of scrutiny from the open source community on these tools to find the bugs and the weaknesses and the vulnerable spots in them and get those fixed quickly. You can get the ability to constantly improve, continuously update and build these tools out much of the financial system and certainly the financial regulatory system is half paralyzed with rigid old technologies, as you said, that are really hard to update. And you can also build interoperability of the regulatory system, which would foster interoperability of the financial system, which would be very beneficial, especially to international financial organizations. And you can also get the benefit of regulatory agencies being able, to some extent, to get away from their procurement processes for technology, which are very cumbersome and difficult and inflexible and let them start to be able to build tools just by finding the open source material for it and be able to move in a much more adaptable way. So toward that end, one of the exciting things that I want to talk about today is that we at AIR are partnering with Vinos and creating a special interest group, a SIG on reg tech in the Linux ecosystem. We want to invite all of you to join in that. We're just at the very start of it. I think it's going to be a very exciting opportunity. But Matt, let me ask you what you think are the obstacles to being able to bring open source approaches into the financial regulatory space? I touched on some on the regulatory side. The existing procurement processes are one of the biggest barriers. One of the agencies that we've met with in the past, which I will not name, said that if they wanted to get their hands on a new piece of technology, it would probably take them seven years from kicking the process off to when they would actually have it deployed. I remember that meeting. We think about how it would be no good anyway. Yeah, it would be way out of date. So there are all sorts of structural barriers that the regulators face. And another challenge is that since they're typically forced to go through normal procurement processes, the companies that are often the best at navigating procurement, the procurement world in government are rarely the ones that are the most cutting-edge on technology. So there have been multiple instances we've seen in the past where a contractor gets deal deployed to technology. And it's already many years out of date by the time it's deployed. It probably costs five or 10 times more than it would need to if they had taken a more open-source development model. So there are a variety of legal structural impediments that the regulators face. The Air, the last sort of regulation, and the Buckley law firm released a memo or report earlier this year, which was analyzing several of those barriers, which if adjusted slightly could enable the regulators to adopt this approach more readily. But another, I think, is a challenge they face is that the regulatory agencies themselves are used to needing to be authoritative and fully understanding of all the risks and opportunities presented by something before they come out and make their view publicly known. And that typically involves them sitting back for two or three years and studying something, but they don't have the in-house expertise to understand this technology for the most part with some notable exceptions. And the process inherently doesn't lend itself to staying on top of things as they evolve. So the lack of exposure and lack of in-house expertise, or at least enough in-house expertise, is one of the biggest barriers. And I think that's one of the largest opportunities presented by the open source community here. I think one major learning I've had as a former regulator, but a techie at heart. There are not too many people in the regulatory world have a full understanding of what the cutting edge capabilities in the tech world are. And if you go to a technologist and tell them about or speak about the regulatory world, they probably would be falling asleep immediately without realizing that there are some very meaningful and impactful challenges that could really benefit from bringing their talents to bear. So we really need to be able to cross pollinate, have people understand regulation getting in the same room with people understand the technology and start to develop common approaches to things. And I strongly believe the most effective way to do that is through open source development mechanisms and putting projects out on GitHub for people to contribute to and start to build a community that can brainstorm solutions to these very meaningful challenges that we face. Go ahead. Go ahead. So there will be areas where certainly regulators will need to keep their data not shared, although there be some places where it would be good for them to share data so that, for example, companies in the industry can benchmark themselves against other information or trends and that type of thing. But your view is that there's not too much reason to fear that putting methodologies into open source will compromise them. You do a lot of work in financial crime at Hummingbird, and there's certainly a concern raised that if regulators were open sourcing their techniques for detecting financial crime that the criminals would all go figure out how to game it. What's your answer to that? That's sort of the same response to the information security angle on open source where there's sort of a common stereotypical view that open source means open data. In reality, it's sort of the eyeballs comparison question like how many people are looking for vulnerabilities versus how many people are looking for vulnerabilities to exploit versus how many are looking for them to protect against them. That holds true very significantly in the money laundering world as well where the criminal world are not, they're not hiding information from each other. There's been an advent of a concept of crime as a service where people are developing tools and finding vulnerabilities in financial services providers and they're often not exploiting them themselves. They're building those tools and selling them or licensing them to other criminal people. So you have an average level of sophistication in these tools that keeps getting better and better. But on the financial industry side of the table, we're often combating these bad actors by going to conferences once a year and learning what the latest developments are. So best case scenario, there you may learn about a new approach a year plus after it's been commonly deployed. So there's an equivalent challenge there where I would argue that if we were developing capabilities and that we're much more sophisticated and robust and even if they were visible to the criminal world, it wouldn't be any different than it is today where they're freely sharing information about themselves. But every financial institution out there, regardless of whether they are a major bank with thousands of people doing this work or a community bank that may only be able to put half of a full-time person onto it, they could all coordinate and defend themselves more effectively and it would even the playing field significantly. So I think there's a lot of parallels to there. There's there are shocking statistics from the UN saying that the volume of money laundering annually is somewhere around two trillion dollars and that we catch less than one percent of it with the tools we have now. So we're going to have to have better tools if we're going to combat crimes, for example, like human trafficking that rely on laundered money. So I know we're going to run short on time. We want to share with the audience some things we want to urge you to do because this is a revolution that's coming. We think it may be coming faster than people think. There's a lot of energy globally gathering around really transforming the financial regulatory space. So for the people in this room who may be working for their major financial company on the product side, what should they do if they want to get involved in helping their company do better on the compliance side with open source tools? I think part of it is just educating, getting involved with the compliance team and letting them know what could be done. Compliance teams very rarely actually have engineering resources that they can bring to bear on the challenges that they face so they don't know what could be done. So it's getting interested in your compliance team's work. Obviously, they're sort of stereotypical view of compliance that they're the people that say no to all of your good ideas. But in most cases, hopefully, it's just because they may not understand fully the opportunities or the risks presented by adopting new tech and investing technical effort into your compliance function could really unlock a lot of potential for you to do other things that are consumer facing. So that's one piece of it. I think another would be participating in the SIG and with nonprofits like Air and the Finos that are trying to bring collaborative efforts to bear on this. There are other issues you would highlight. I think one thing that would be a good practical step would be as you talk with your compliance teams about this, talk with their examiners as well, especially if you're a bank and let them know that you're thinking about doing some work along these lines and bring them along because Matt and I are both former regulators and we know we're not criticizing the regulators. They've been doing the best they can with the technology they've had, but getting that community comfortable with newer technology is a learning process and we need to engage in it together. And maybe to close just to say that working with this effort, as Matt said, there's a stereotype that regulatory work is boring and box-checking and bureaucratic and that's really not true. There are very interesting problems in this space. There are problems that nobody has touched yet with good technology and that you could really have major impact and the good that it can do if you want to fight credit discrimination or you want to fight trafficking in children or you want to figure out sustainable finance because you care about climate change. I mean these are the big issues on the regulatory agenda and these kinds of tools are going to be the secret to doing it. So we hope you'll work with the new SIG and go back to your offices or virtually go back and talk with your regulatory teams about how to bring open source innovation into this very important sector. So thank you Matt. Thanks everyone. Thank you. Thank you Joanne and Matt so much and you know if you have any questions or want to pick up the conversation please do join the Slack channel on on regulation as well. Now it is my absolute pleasure to announce our last keynote session a discussion between co-author of the Create React app Dan Abramoff and Phinos's director of community James McLeod. Dan is a well-known software engineer at Facebook and a member of the React core team and prior to joining Facebook Dan co-authored Redux a predictable state container for JavaScript applications and this really catapulted Dan to be an influential conference speaker and successful Twitter commentator and I know that James has really been looking forward to this conversation so please welcome Dan Abramoff and James McLeod. Hi I'm James McLeod Phinos director of community and I'd like to welcome Dan Abramoff software engineer at Facebook co-author of create react app and Redux and Twitter open source commentator to the Phinos open source strategy forum. Dan it's an absolute pleasure to have you here today to answer questions from the Phinos community but before we start can you introduce yourself for those who aren't familiar with the work you do within the wider JavaScript or Facebook open source community? Sure thank you for the introduction so I guess I'm mostly work on React itself so React is a JavaScript library for building user interfaces so I was like you used to react a lot before I got the job at Facebook and I work on the React core team so that involves mostly fixing bugs maintenance helping develop new features writing documentation and talking to the community which is what I'm doing now. That's awesome so firstly what are your thoughts on the funding of open source projects and sustainability would a project like react work without the backing from Facebook? Yeah that's that that is an interesting question I think there is it is definitely possible that projects like work without like a specific like a single corporate I mean obviously they do need some sponsors right and like usually those would be corporate but I think like Vue is a there is a kind of like a competition library called Vue that is fairly popular and Vue doesn't have a single corporate sponsor so it's multiple sponsors they change over time so it is funded by the community and the users so I think it's it's definitely true that this model can be successful it's it's not very easy to like replicate it you need a critical mass of users so I think it mostly works for already established like pretty big projects but it is it is definitely possible as for React itself I think there is a like it's hard to say like what if like I don't know I think there is a there are definitely differences in like how we would work and I think like one particular area that I think people underestimate the value of like a company that is that is stable that that is not like a startup but like a stable corporate sponsor is the ability to do long-term research so because for for a lot of at least in my experience and like I'm not like I don't want to offend anyone but I think it is true that when like for smaller companies the return on investment is like it needs to be very concrete like it's it's support it's developing like particular features that they ask for and while that by itself is obviously valuable and that's fine I think sometimes this this comes at the expense of like not being able to do kind of moonshot projects where like you might or whereas like a bigger company might be able to fund like three years working on some idea that is there is maybe more ambitious than usual and not all of them pan out and I think that that is what I I appreciate about Facebook back in React is that we have the ability to go for like really big ideas even if they take time so from what I understand when you're developing Redux you had to get multiple different sponsors in order to keep your work going is that true um so Redux was just kind of a unusual case because it is it was developed as a proof of concept for a conference talk it was not meant to be meant to be this like heavily used library in production but people started using it they liked it and then for a few months like I didn't have a drop at the time because like my previous the company when I was working it has folded and so I did I did have the community funded for like maybe three to five months something like this but I was primarily focused on documentation and and like examples that was not even coding that much and I would say that Redux hasn't really changed since like that that was like five four or five years ago like it's it's a very it's a very unusual library in that it doesn't really do anything it's just like a pattern and I would say like even like maybe an overused pattern but it is what it is yeah it certainly has its competitors now and so you've sparked some inspiration in the rest of the open source community with it so um last month I actually noticed that there are various different tweets about Hacktoberfest and you know the value that Hacktoberfest actually brings to the open source community and the the value of the contributions um now Hacktoberfest has ended did the react team actually see an uplift in bogus contributions or did digitalization address the community concerns yeah I think it was a complete mess in the beginning and in part I think like the from what I gathered it was just like there was a person like a youtube person who like uploaded the video that said basically here's how you can get like free t-shirts and so people got carried away I don't think like a lot of them were even familiar with like open source um so that that that was a bit strange but that lasted for like three or four days and then I think like just ocean changed it to be often or something like this we did not often and so it's it's hard for me to say if like aside from those early like noisy aprs if there was like actual uptick in contributions but that's mostly because it's just like I'm doing a pretty bad job of like actually checking those because we're like we're in a kind of a final stretch of like a few multi-year projects that we're just trying to wrap up and get to completion and so we have intentionally de-emphasized like looking at contributions and and like commutative pull requests so I haven't really been keeping track and like I don't expect to you until like several months after now yeah because I I suppose the react team would have to label some of the issues that they're inviting out to the hacktoberfest community and so it kind of puts a bit of arm pressure on the team to review and then accept yeah and I think for especially for react case uh it's pretty tough because like it's not a new project there aren't many uh linear like simple bugs you can just go ahead and fix um so it's like there are issues we do want to work out but they require like multiple months of like just gaining context and like what the problem is so it's not particularly like amenable to just like drive by contributions uh whereas and I think like that's that's fine I think like a lot of people who think about oh like I want to contribute the open source like they think about big projects but it's really like I would encourage to go beyond them and instead just like fix something that you use it's often like small components small libraries that would appreciate the you know like the actual like bug fixes and like there's plenty like opportunities for like performance improvements and stuff um so I would say just focus on the uh you know on the long tail uh not on the uh like on the uh just a few highly visible projects absolutely I know from a financial services point of view um having react be an open source it means that you know engineering leads can actually take a look under the hood at the code that's there and so it gives you reassurance about the quality of the product rather than you know the odds of you being able to contribute into the project um so from that point of view you know open source you know does increase quality and it keeps the engineers accountable for the work they're doing um so if people actually follow you on twitter and you know look at all of the tutorials that you've been putting online you actually spend a lot of time on community engagement would you say that's essential for project success and what works best for building that community um yeah I I think I don't actually do as much of that now and it's kind of a tough balance like I wish I I had a good answer but like I'm just learning um because I think like early on uh it really helped to react that uh there was a uh like I think reacting that sense was unusual because uh like usually you would have dedicated people like developer advocates uh actually uh like helping people understand the project and like document and so on and I think react from like from very intentionally from early days it was like most of that work was done by engineers working on it um and so the downside of this is that uh he um so the upside of this is that it's uh like the vision uh of the people promoting the product is this like it's it's guaranteed to be the same as the vision of the people actually were like working on it so there is no like chance of miscommunication or like framing something that is like not entirely correct uh so it is very uh like it is very honest um but the the downside of that is that um as the project grows it doesn't really scale so like you can't keep responding to everyone and also I think like one thing that I'm kind of uh trying to figure out now is like I think uh like a few team members like including myself become kind of the center of attention where like all this energy is concentrated and that actually makes it harder for like newer people to break out into the like in the ecosystem because um like they're not the ones being asked questions like they don't get the same opportunities and so it becomes this very top-down structure uh even like unintentionally um and I think that that's something that uh like that's why I feel like like I don't really have advice because like I want to figure out how to uh like decentralize it a little bit and maybe not not have to be as involved yeah actually that is a really good well that that's an unintentional consequence of you know that momentum that your own personal brand is built um so how do you actually invite other engineers from you know the open source community or facebook into that you know how do you delegate you know all of that focus that you have outwards so it becomes more federated and less centralized yeah and like I feel like some teams are better at this than us like I think view team is a good example uh like they even though there is a small kind of um like the project itself is driven by a uh a small number of people they do a pretty good job at distributing knowledge even like um things that do that are top-down like there is there's a particular like direction that the team wants to to take um they do kind of find ways to uh distribute it across uh like educators and and like so that it's it doesn't seem like it's coming from like just a single source so I think that that that helps um but another part of this is just um better documentation for sure like uh because like the reason people ask me questions is just because like something's not plainly stated in the docs um and there's like also partially like like our fault because uh for some things like for example like uh react hooks right like it's a it's a it's a pretty big shift in how you think about react components it's like an api been introduced uh two years ago almost I think it's almost three years ago by now um and actually a bit over two years um and it's like at the time we didn't know how to use them like sure we wrote the docs but like we didn't have two years of like nobody had the experience it's a novel concept it's like nobody like wrote code quite the same way before and so of course we didn't document a lot of things and we're just because we are just finding them out and like we are finding them out through those conversations and through those questions but it's it's like you know you need to take time to kind of gather things and then you need to like consolidate them and I think that's that's the phase we're in now is like we've learned all of those things from those conversations and now we need to put them in a like in a reference so that other people can refer to them without asking us yeah so we were talking about um federation versus centralization so we've done react to spin an example did the requirements or the idea for that come from the community or did it come from the react team yeah um it's an interesting question I think it's uh like there is a broader question here of like the where does the direction of react come from I think it's it's actually something that is quite misunderstood in the community so like there there are people who think that like Facebook sets the direction of react and I think like maybe we have set something to that point that like that's the reason people are saying that is that we we have miscommunicated earlier but I think it's it's really neither it's it's neither Facebook nor the open source community I think the so like the the way I see it happening is that we we look at different problems and like people bring problems to us right so and that happens both at Facebook and externally and like there are different characteristics of like how that happens so like um externally we get a larger volume of problems but slightly lower quality because the barrier like to to like file an issue is so low that people can just like fix my code so it's uh you don't like the signal to noise ratio is not very effective uh but the volume is so large that you pick up on like you notice things that you wouldn't like have you wouldn't have thought of otherwise uh that like people run into so that gives you breath and then I think if Facebook it's more about depth so if Facebook we also like people also come to us with problems and we can spend much longer time kind of because like we have access to the product we don't just take their word for it that it's a problem we can like literally run that code and see oh like I see what they're saying I see how that influences the product um so we get a lot of like much more depth from those conversations and those those investigations um but the solutions don't come from that either like that's just inputs and um I can't really say where solutions come from because like I'm not the primary person who comes up with them it's mostly like Sebastian or Jack lead but the way he works is more like a scientist in the sense that he accumulates all these problems but then he kind of takes you know like how you need to take a step back and see like how like how did we how did we end up in this situation and like what are the different things we could do um but I think what is unique about Sebastian from like my perspective like compared to people I worked with is that he takes like 10 steps back or like 15 steps back and he he discovers like pathways that like other people didn't take for whatever reason uh that are actually like pretty interesting and so and like I think he's he's thinking is shaped by first principles which means that like it's not about Facebook not about open source it's about what is a user interface uh how does a computer work how do we make those things work together and it sounds really vague but uh I think like he finds those solutions and he's inspired like obviously he takes a lot of inspiration from things happening elsewhere right um so it could be like compared competitor frameworks but also again like his uh like he looks at uh like things in programming language research or like low level graphics or like all of those things that he would usually not necessarily connect to front end but like he finds inspiration there as well and I think it's just this work like the way he comes up with solutions is just this synthesis of different things that he learned from like different places that's um an amazing observation because it's very easy to get caught in you know delivering features or doing what a business analyst asks you to do you know and you know computer science is actually very creative and it's a good opportunity to go back to the science and explore you know our roots and what we need to do in order to further things so within financial services um in a source is actually a really big um uh topic and that's all about the collaboration inside teams and inside firewalls before you even get to open source so what is the strategy at facebook regarding in a sourcing and open sourcing projects how does each team decide which project to open source yeah um I think this really comes down to individual engineers um because like you can't force somebody to open source a project and I think uh projects that have been open source have always had somebody who like felt really passionate about it and kind of convinced uh like other people that it's it's the right thing to do but then even if you open source it right there's like there's different ways to do it and um a lot of teams like they might open source something and then they don't know well they just threw something out of the wall but they don't work with the community or they um like they don't really explain what it is or they stop maintaining it so like in that case it's it's it's better not to open source than to open source poorly because that that just creates like a burden for your users or you need to be very clear in expectations so we do have a process like we have a open source team that supports open source efforts that is there like if you want to open source something you send them a request and they like follow up with you just to check that you understand that like open source is a commitment uh that like it's it's not just throwing things over the wall um like what this thing is how is it different from what we already open source because like we have a large portfolio project um and we also they like they have a stage process so we start in like uh something called like facebook incubator which is just a home to like all expert and i think like facebook experimental maybe that's what it's called but it's like a home to all the projects that we don't really know if like they're going to work out as open source and then if there is like if there is adoption and the team is still interested like eventually they cannot graduate um but there are plenty uh there are plenty of libraries and solutions that um like the authors are just not interested or they just feel that they bring more value to the company by focusing on uh on like internal integrations and so they they explicitly decide against open source and um and i think like that's also a that's also a way of doing things um i think just my kind of mantra there is just that it it's better not to open source than to open source broadly so you you need to really know like why you're doing it and what what you're hoping to get from it because like you're probably not gonna get contributions like that's that's not the i think like a lot of people think that that's like oh facebook is getting so many contributions that's why the open source uh for react we actually get sure we have a lot of small contributions but uh the vast majority of the work is done by uh like false employer facebook or our partners like companies that we partner with um it's not really just like drive by fixes uh that are like uh really making the big difference so open source is not about like getting something it's more about like if you feel that you want to influence the industry you want to share what you learned and you want to put your approach under the scrutiny uh like i think that that's one of the most positive things about big company open source is that it keeps you honest uh because internally it's easy to stagnate there's like there's a solution everyone uses it too hard to migrate away from and it just uh it's just like uh it just dominates within the company because there's nothing better but in the open source you're forced to confront that there are other solutions and they have different characteristics and now you have to compete and so that makes your product better because you have those like uh abstraction boundaries that that they can check that those actually make sense yeah so i think that it's it's a good like self-check if your code is actually like good yeah that's amazing thank you very much for that advice um say the final question say take a look at your own personal projects uh within your own personal uh repay we noticed that you have a project there called um so this is the acronym say i know this not actually called this but it's um called by some wider name but that wtf is so so what is that and what's the motivation behind it yeah so um it's kind of like a side project i actually forgot about it so i need to add a few a few more definitions but it's uh it's a glossary of uh of like terms you might encounter in javascript um like closure hydration you know like things that sound like uh something that can be uh computer science concepts like nemoization uh some of them are just like uh some tooling or uh like just concepts that don't really make sense but that people kind of like that made their way into a javascript developer for capillary um but the point of that glossary was i just can find anything quite like if i wanted to explain like one of those words to somebody i couldn't find like a place to link them to because uh wikipedia is just impossible to read it's like on computer science if you open something it's just i i don't know there's they assume so much existing knowledge and like exist in context and like uh they're over complicating things and then if you if you just search for like simple definitions uh on like blogs and articles a lot of them are plain wrong or misleading uh like the person misunderstood something and then and then like wrote an article about it that's super calm and i mean like i i i can follow to the same thing as well hopefully because like my material gets a lot of circulation people will point out the mistakes um but yeah that's kind of the motivation is just to have something that is worded in a way i would explain the concept to someone over lunch yeah yeah and what i was thinking so earlier in the interview you said people should actually be contributing to the smaller libraries and the more long tail kind of solutions and so this could actually be a perfect um you know project for people within the finos community to raise pool requests against to help you maybe flesh it out yeah i don't think this one is a good example because it is also intentionally um it has a very kind of um well defined voice so it's it's like my writing it is very intentionally i don't think like uh anyone would write in exactly the same way and like i wanted to be written with my particular voice that that's kind of like an aspect of this project but similar projects sure like they would sure and like especially because people don't contribute as much to like they want to contribute code they don't want to like contribute documentation as much but that's actually documentation is one of the things that can be like really really difficult especially writing good one um so so maybe one way people could actually help you is by raising an issue you know something that they found that you might want to consider for inclusion in the glossary for sure yeah that's awesome so thank you dan for joining me today but before we leave how can people follow the work that you're doing in the open source community and potentially leverage it for their own projects yeah um i i don't i don't know uh because i i have twitter but i i mostly just like post random things there um in part because like especially lately i feel like twitter has gotten so uh like i mean technical twitter has gotten very unapologized um in terms of like oh like this library like is bad at this library is like but it's it's just it's very emotionally taxing so i kind of stepped away from like technical discussions on twitter um and i prefer to have them on github so but if i think like if we release anything important like if you're interested in react just follow the reactjs twitter account that's anything important will be there for sure and on the reactjs blog so again like we post anything that's on the blog that's going to be cross posted on twitter uh so you can follow reactjs that's for my personal work uh you can definitely follow me like uh twitter com slash dan underscore abramov um but just be prepared that it's a lot of random stuff and then somewhere in the middle maybe i post something about a project i work on that's amazing thank you once again dam for joining us today and i'll really appreciate your time thank you have a good day et thank you very much thank you so very much james and dan and thank you to all of our speakers today um i do hope you all enjoy the rest of today's session and we look forward to seeing you back at 235 for a wrap up and our awards announcements have a great day