[00:00.000 --> 00:11.000] Thank you everyone for coming. Today, Justin and I will be talking about full stack digital [00:11.000 --> 00:15.920] public goods at the start of this dev room. We went through a very brief what digital [00:15.920 --> 00:19.480] public goods and digital public good alliances, but we will also be going into depth again [00:19.480 --> 00:29.120] for those who are not aware. We want to start with our introduction. The recap of what digital [00:29.120 --> 00:35.040] public good is and the context around it, what we mean by full stack digital public [00:35.040 --> 00:42.680] good and also levels of scale that digital public good, how can they be full stack and [00:42.680 --> 00:50.960] where does the community participate in that? So who are we? Your first speaker, me, Vipalsiddharth, [00:50.960 --> 00:56.200] I work at UNICEF as open source technical advisor and have been contributing to Fedora [00:56.200 --> 01:04.360] project for almost one third of my life. And I love making coffee, maybe not drinking [01:04.360 --> 01:10.560] so much because of the anxiety. And then we have Justin. [01:10.560 --> 01:18.640] Hey everyone, my name is Justin. Today I'm working with Red Hat as a community architect [01:18.640 --> 01:25.440] for the Fedora project. But in a past life, I was also at UNICEF working in the Office [01:25.440 --> 01:29.500] of Innovation, not directly with the digital public goods alliance, which we'll tell you [01:29.500 --> 01:35.960] a little bit about in a minute, but around the DPG ecosystem of projects and many different [01:35.960 --> 01:42.480] organizations that are all engaged and working around this big topic of digital public goods. [01:42.480 --> 01:46.800] So even though I'm not still with UNICEF today, neither of us are really directly representing [01:46.800 --> 01:52.400] our employers, but we're coming more as fellow free software activists and open source fans [01:52.400 --> 01:56.640] and sharing some of our thoughts around, you know, when we have a standard around these [01:56.640 --> 02:02.960] kinds of important things around public goods, maybe there's something that's still a missing [02:02.960 --> 02:07.440] ingredient. And that's what we'll tell you a little bit more about. And yes, I'm still [02:07.440 --> 02:14.040] using buying CDs and ripping them with all free software tools, a little old school there, [02:14.040 --> 02:19.160] but I'll pass it over to Vipal for a quick recap for folks who weren't here on DPG. [02:19.360 --> 02:25.240] Yeah, so we are going to do a quick refresher on four things today, three things. What is [02:25.240 --> 02:31.600] a digital public good standard? What digital public good alliance is? And how UNICEF Venture [02:31.600 --> 02:41.640] Fund acts as a digital public good pipeline? So let's start quickly. How is a DPG defined? [02:41.640 --> 02:49.040] We'll look at the DPG standard, which is maintained by digital public good alliance. So at the [02:49.040 --> 02:56.440] heart of digital public goods, there are main three components. A digital public good comes [02:56.440 --> 03:03.200] with certain promises, promises of open source licensing, platform independence, transparency [03:03.200 --> 03:09.240] in decision making and the roadmap. But also it aims to advance the sustainable development [03:09.240 --> 03:14.920] goals by United Nations, which is addressing social or environmental issues and strive [03:14.960 --> 03:20.040] to ensure accessibility, affordability and equity, equitable distribution of the technologies [03:20.040 --> 03:30.280] through sustainable development goal relevance. And the tools do not do any harm. There are [03:30.280 --> 03:37.360] different relevant best practices that tools have to follow. So they can be open source [03:37.400 --> 03:45.920] software, content, models or documentations even. As long as they're there to relevant [03:45.920 --> 03:52.400] best practices, they do not harm and they push SDGs ahead. They are eligible for digital [03:52.400 --> 04:00.880] public good. We believe such goods, such tools needs to be identified, recognized and supported [04:00.920 --> 04:09.160] because their capacity to help achieve our goals. So those three components expand into [04:09.160 --> 04:15.040] nine different indicators that we have. Starts with relevance of sustainable development goals, [04:16.440 --> 04:24.040] licensing, platform independence, but also it should have good documentation, data that [04:24.040 --> 04:31.960] is accessible, a commitment for standards, best practices for privacy and security and [04:31.960 --> 04:40.560] demonstrate that components do not do harm. In order to become a digital public good, [04:40.560 --> 04:46.720] it's quite simple. You nominate your software, content, model. There's a technical review [04:46.720 --> 04:51.520] against all those nine indicators that we spoke about. And if it all matches, then you [04:51.520 --> 04:56.680] are listed on the registry which is an application to list all digital public good solutions that [04:56.680 --> 05:05.440] can be further looked into. Now we want to look at what digital public good alliance is. [05:05.440 --> 05:15.640] So it's a multi-stakeholder alliance founded by UNICEF, government of Norway, [05:16.240 --> 05:22.360] government of Sierra Leone and iSpirit. And it has a mission to, as we discussed, [05:22.360 --> 05:28.800] accelerate attainment of DPG's sustainable goals, especially in low and middle income countries [05:28.800 --> 05:36.720] by facilitating the discovery, development, use and investment in DPGs. And one of the core [05:36.720 --> 05:42.520] functionalities of DPGA, which is the alliance, is to maintain the standards of DPG. How do we [05:42.560 --> 05:50.400] recognize as tool? Today, this is a public good association alliance has grown a lot, [05:50.400 --> 05:55.360] started by four, but now we have many more. And if you attended the keynote yesterday, [05:55.360 --> 05:58.520] the latest edition is open source initiative in the alliance. [05:58.520 --> 06:10.520] Finally, we are going to look into how UNICEF Venture Fund acts as one of the pipelines to funnel [06:10.520 --> 06:18.200] more DPGs into it. Now, it may be weird to think that UNICEF acts as a venture capital, [06:18.200 --> 06:25.800] a small portion of it, but we invest in early-stage companies, solutions that have a working [06:25.800 --> 06:32.080] prototype with a lot of promising results. They match with our goals of doing good for [06:32.080 --> 06:40.480] children women, improving our sustainable development goals for UN. And so our main idea [06:40.480 --> 06:45.360] is that we take risks in emerging technology that may work or also identifying what does [06:45.360 --> 06:51.040] not work. Early investment can accelerate our finding of good with using technology that we [06:51.040 --> 07:01.480] have not found yet. So far, we have invested in 128 companies across 75 countries and this [07:01.480 --> 07:06.480] number is growing because we just invested four more last month. And I think another country [07:06.480 --> 07:14.120] is added to it. We are very concerned about the diversity of the female, just founders [07:14.120 --> 07:24.320] of the companies and how many countries we are touching, their levels of development. [07:24.320 --> 07:32.240] And we invest in technologies like drones, also blockchain, AI, data science, VR, a lot [07:32.240 --> 07:36.720] of this emerging technology that we have yet to see impact directly. Some of them are doing [07:36.720 --> 07:44.920] it. That's where they lie in this graph, but our goal is to identify what's not been proven [07:44.920 --> 07:55.000] yet. And last, how does the UNICEF open source, where does open source part comes in? Because [07:55.000 --> 08:00.000] at the heart of digital public good, there's open source. And the way UNICEF identifies [08:00.000 --> 08:05.960] this company is three ways that it must different. First of all, the investment is equity free. [08:05.960 --> 08:11.000] We do not take any equity from them. So almost like a grant, but we have certain contracts, [08:11.000 --> 08:17.520] certain expectations, milestones to achieve. And the core of it is open source. Any solution [08:17.520 --> 08:22.600] that UNICEF invest in that must be open source, ideally at the start of it, or by the end of [08:22.600 --> 08:27.840] investment round, it must be a open source solution. And not just with open source license, [08:27.840 --> 08:31.680] but have all those indicators that we just discussed, must have good licenses, must have [08:31.680 --> 08:40.920] a public roadmap, a place where you can open and report issues. So, and other way that's [08:40.920 --> 08:46.720] very unique is that UNICEF provides mentors who will work with companies to help them [08:46.720 --> 08:51.520] develop. We have business mentors, we have software development mentors, and the place [08:51.520 --> 08:55.560] where I come in is open source mentorship in making sure that we are following the right [08:55.560 --> 09:09.080] practices. So far, out of 127 or 129 as per last yesterday that I saw, at least 16 of [09:09.080 --> 09:14.280] those companies come from UNICEF, where we have guided them, helped them achieve certain [09:14.280 --> 09:19.080] standard and now they are digital public goods. And at least that I'm working with 15 companies [09:19.080 --> 09:25.680] that are planning their nominations within the next few months. And now I'll pass it [09:25.680 --> 09:32.280] to Justin to talk about what we mean by full stack digital public goods. [09:32.280 --> 09:37.680] So earlier, like Vipple talked about, there's that nine point standard, which goes a long [09:37.680 --> 09:42.200] way on building on this, you know, open source base. We talk a lot about licenses in the [09:42.200 --> 09:45.840] open source world. But if you look around us, there's still all these other parts that [09:45.840 --> 09:52.360] are very important and often don't get factored in as with as much emphasis as maybe we focus [09:52.360 --> 09:58.480] on like copy left or permissive. So the digital public good standard does a good takes good [09:58.480 --> 10:03.000] steps forward of trying to provide more of a framework around how we can look at a digital [10:03.000 --> 10:08.960] solution and its impact on again, like the sustainable development goals, but also sustainable [10:08.960 --> 10:12.900] as an open source product or open source project. [10:12.900 --> 10:18.880] So what does this full stack piece mean? So first, understand that this isn't something [10:18.880 --> 10:23.320] that's in the standard. This isn't something that's been published by UNICEF or Red Hat. [10:23.320 --> 10:26.560] This is just something that Vipple and I have thought about as we've been working with these [10:26.560 --> 10:31.160] companies and teams from all over the world, like you saw on that map, people who are often [10:31.160 --> 10:36.200] approaching these open source business models and challenges with building a community for [10:36.200 --> 10:41.600] the very first time. So we've noticed some things that come up a lot across these mentoring [10:41.600 --> 10:46.200] that we were running with these companies and these teams. So this concept of a full [10:46.200 --> 10:52.640] stack DPG is something that we made up for this talk to help identify a possible gap [10:52.640 --> 10:57.680] in today's DPGs and one possible way that we can address it. [10:57.680 --> 11:02.960] So let's look at four challenges with the current DPG standard and then identify what [11:02.960 --> 11:12.200] this concept of a full stack DPG is. So first, the DPG standard is indeed a standard [11:12.200 --> 11:19.680] that's been reviewed and has a change process, but the actual review process itself is not [11:19.680 --> 11:24.440] quite standardized. There are indicators in the standard that give some guidelines around [11:24.440 --> 11:29.440] what you should look for around documentation, what licenses are acceptable thanks to the [11:29.440 --> 11:34.200] open source initiative. And we have other kinds of things like, you know, for adhering [11:34.200 --> 11:38.600] to data privacy and best practices, making sure that wherever the product is based or [11:38.600 --> 11:43.240] if it's a company, where they're registered, they're in line with any local laws and requirements [11:43.240 --> 11:49.240] that are obligated to them. But while the indicators provide guidelines for whether [11:49.240 --> 11:54.720] they're satisfied, again, that review process itself remains without a common standard. We [11:54.720 --> 11:59.520] take kind of a best effort approach to dig into a product when they come and submit their [11:59.520 --> 12:03.200] nomination and understand, are they meeting these indicators? Have they taken the right [12:03.200 --> 12:08.680] efforts to address these parts of the standard? But as it is today, only the DPG Alliance [12:08.680 --> 12:15.240] can truly reproduce a review. So if a different organization attempted to review, maybe unlike [12:15.240 --> 12:19.240] some very specific indicators, like the ones that are more loosely defined, like maybe [12:19.240 --> 12:25.640] documentation, possibly even the ones around do no harm, because that's a worthwhile thing [12:25.640 --> 12:30.040] to try to standardize. But that's also really hard to try to think about all these different [12:30.040 --> 12:34.280] ways that something could be used. I mean, we can even look at the last history of 20, [12:34.280 --> 12:39.680] 30 years of open source and even ways that this is spun off in different directions. [12:39.680 --> 12:43.800] So where I'm going with this, it may depend on the level of consultation that's sought [12:43.800 --> 12:47.280] out and what backgrounds people are bringing to the table when they're going through that [12:47.320 --> 12:52.800] review process. And also how closely you're following a legal strictness, like what level [12:52.800 --> 12:57.000] of adherence you're paying attention to when you do that review. So while the standard does [12:57.000 --> 13:02.520] provide guidelines around what we're looking for in a sustainable, healthy, open source [13:02.520 --> 13:08.160] project and community, not every indicator provides an easy policy decision. There's [13:08.160 --> 13:14.640] no binary here, like yes, this is do no harm. Yes, you are in line with the sustainable [13:14.640 --> 13:20.520] development goals. We have indicators, but there's no fixed standard. It's not binary. [13:20.520 --> 13:25.040] So it doesn't always provide an easy policy decision or firm rules for proving itself [13:25.040 --> 13:32.080] as satisfied. And of course, that can also change over time. So will this will a technology [13:32.080 --> 13:37.200] stand the test of time, true of not just of digital public goods, but truly of any open [13:37.200 --> 13:42.960] source project, you'll see a lot of conversations around supply chain in the open source space [13:43.040 --> 13:49.320] today, also relevant to digital public goods. So will something stand the test of time? [13:49.320 --> 13:54.600] Will these newer ideas last into the decades ahead of us as we go into this new era of [13:54.600 --> 14:02.600] free software in these 2020s? The answer varies from DPG to DPG. Some DPGs are accomplishing [14:02.600 --> 14:06.880] their goals with ubiquitous frameworks. They're used by several projects and they have a very [14:06.880 --> 14:12.840] solid base that's maintained by a wide community. Others of them take a new approach to solving [14:12.840 --> 14:19.480] a problem in an innovative, but perhaps unproven way. So meeting the DPG standard only applies [14:19.480 --> 14:25.320] to the submitted product itself, but it does not necessarily mean looking upstream at the [14:25.320 --> 14:30.440] building blocks that are chosen by that specific project. Sometimes this is actually really [14:30.440 --> 14:35.400] beneficial because we might have these new ideas that are emerging in the field and take [14:35.400 --> 14:41.320] a new approach to an old problem and make ties into that innovation piece. But sometimes [14:41.360 --> 14:47.200] it also means that unforeseen risk will emerge. So simply this question is something that [14:47.200 --> 14:53.960] Vipple and I believe cannot be firmly answered by the DPG standard alone, at least in its [14:53.960 --> 15:00.960] current version. So again, on this whole part of funding and financial sustainability, a [15:01.640 --> 15:07.400] big piece here, DPGs don't necessarily come with a promise about their funding or their [15:07.400 --> 15:13.760] financial stability. It's not always clear when a DPG is very well funded and supported [15:13.760 --> 15:17.760] or when it's still early on and that maybe you've seen that innovation bell curve, the [15:17.760 --> 15:24.160] early adopters and the laggards. It's not always clear where a product might be in that [15:24.160 --> 15:31.160] innovation curve. So this is perhaps by design, but without better guidance for these downstream [15:31.160 --> 15:36.000] consumers of the DPG registry that we talked about earlier where you can find a huge list [15:36.000 --> 15:41.600] of digital public goods. It's hard to know as a consumer whether you're choosing an enterprise [15:41.600 --> 15:47.960] grade open source platform or you're going with an emerging cutting edge platform that [15:47.960 --> 15:53.960] may come with some adoption risk. The point is not to say that every DPG needs to have [15:53.960 --> 16:00.560] some endowment and guaranteed funding from the start, but it should be easier as consumers [16:00.560 --> 16:06.960] of DPGs to know what grade of a DPG you're working with when you're shopping the market [16:06.960 --> 16:13.960] for an open source platform. So change of ownership, change of direction. As with any [16:14.760 --> 16:19.440] private sector company, a change of ownership can mean a significant change of direction. [16:19.440 --> 16:23.960] Now the DPG standard does have in the third indicator a requirement that you demonstrate [16:23.960 --> 16:29.160] clear ownership of the tool or the product, that copyright is managed, that the person [16:29.160 --> 16:34.640] submitting the DPG actually can represent the material, the intellectual property that [16:34.640 --> 16:39.840] is being nominated. So there's steps to make sure that you're not using some other bits [16:39.840 --> 16:43.360] and pieces of other people that you don't have the legal rights to, which kind of comes [16:43.360 --> 16:48.040] into the, again, kind of the supply chain piece a little bit. But if you look at the [16:48.040 --> 16:54.540] very recent history in tech acquisition, in the tech acquisition world, it may support [16:54.580 --> 17:00.580] this notion that sometimes things change and might put what was once a very stable platform [17:00.580 --> 17:05.460] or product in a very different direction. But if this happens to a DPG, what will it [17:05.460 --> 17:11.100] mean to downstream consumers who are maybe taking certain trusting in part of the DPG [17:11.100 --> 17:16.260] standard to find a reliable thing that they can build some infrastructure or some tool [17:16.260 --> 17:21.340] on? So while it might be standard practice in the private sector for a pivot when hands [17:21.340 --> 17:28.020] change, it doesn't have to be this way for DPGs. So we would say that sustainability [17:28.020 --> 17:33.140] for the DPG standard should include greater protections if there is an unexpected change [17:33.140 --> 17:39.060] of hands and a DPG pivots in a way that goes against the standard. This could result in [17:39.060 --> 17:43.380] a new form of vendor lock for customers using an open source platform that might be later [17:43.380 --> 17:48.300] forked to a proprietary model. We don't want that. And in the worst case, the merit of [17:48.300 --> 17:53.460] having more IP under open source licenses provide greater assurance that maintenance [17:53.460 --> 18:00.460] on an open source platform is feasible. So where do we go from here? Do we need some [18:01.780 --> 18:08.260] kind of indicator around sustainability? How do we measure that? Sadly, this talk is [18:08.260 --> 18:14.300] not coming with some magic solution around how we patch sustainability. We can definitely [18:14.300 --> 18:21.220] have some conversations. But, but we have a pathway. We have some ideas and we hope [18:21.220 --> 18:27.980] to actually inspire curiosity about how sustainability should be measured in the context of a digital [18:27.980 --> 18:34.260] public good. So we wonder what does an indicator for sustainability mean? What might it look [18:34.260 --> 18:41.260] like? So this is what we propose would make a DPG into a full stack DPG. So this very [18:41.660 --> 18:48.660] draft version of this concept is that the DPG is with enhanced visibility to their operational [18:48.660 --> 18:54.660] stability in their applicability for downstream consumers in various parts of the innovation [18:54.660 --> 18:59.260] life cycle. Going back to what we said earlier, sometimes you're really looking for that, [18:59.260 --> 19:04.260] that very stable platform, something that you can guarantee has a strong base, a strong [19:04.260 --> 19:10.260] foundation, has that, that good support. And sometimes you're looking for that, that very [19:10.300 --> 19:15.500] support. And sometimes you're looking to take some risk and try a new idea to solve a problem [19:15.500 --> 19:22.500] that the existing solutions that have that proven base may not be able to address. And [19:22.740 --> 19:26.580] this is where I'll pass to Vipple to talk a little bit. Well, we'll be back and forth [19:26.580 --> 19:31.340] on this one a bit to think around like, how are ways that we could try to promote this [19:31.340 --> 19:35.140] idea of sustainability into digital public goods? What are these other things we can [19:35.140 --> 19:41.460] do perhaps around the standard to enable this idea of sustainability and helping people [19:41.460 --> 19:46.140] know what they're getting into when they find a DPG? So I'll pass. [19:46.140 --> 19:53.140] Thank you. So we believe to build early, to build sustainable DPGs, early stage investment [19:54.220 --> 20:00.220] and community and resources are the key, inclusive and diverse community, collaborations, [20:00.220 --> 20:05.340] transparencies, how they evolve and occasional revision of the project charter, implementing [20:05.340 --> 20:10.180] governance model that includes community. So now we are going to look at three different [20:10.180 --> 20:17.180] levels of scale and each example demonstrates some or many level of qualities. At first, [20:19.700 --> 20:25.580] early stage. So if you remember UNICEF venture funds invest in very early stage companies [20:25.620 --> 20:30.820] and we provide structured mentoring to provide high impact payoffs. I discussed about open [20:30.820 --> 20:36.300] source mentoring where we work very early with what right licenses to choose, how to [20:36.300 --> 20:42.020] draft our project charter in a way that it reflects our mission, vision, community statements, [20:42.020 --> 20:47.900] slowly building knowledge base within the company about how to be a model DPG or open [20:47.900 --> 20:52.900] source project and move away from there. [20:52.900 --> 21:00.300] And actually I might just go back to this one and add on Vipple's point here too is [21:00.300 --> 21:05.460] I think one of being of my former UNICEF hat. This was something that basically when these [21:05.460 --> 21:09.660] companies have questions and they're trying to figure this stuff out, having that mentor [21:09.660 --> 21:14.340] or someone who can help kind of be a seer, someone who's been down the open source road [21:14.340 --> 21:18.220] before and can help answer some of these common questions and sticking points when you're [21:18.220 --> 21:23.220] just getting started. This is one of the really key values of that mentoring is you [21:23.220 --> 21:26.860] get someone to talk to when you're trying to figure all this stuff out on the beginning, [21:26.860 --> 21:31.540] someone who either can help answer your questions directly or help connect you to somewhere else [21:31.540 --> 21:35.740] in the ecosystem. So again, that early stage piece can be really helpful trying to think [21:35.740 --> 21:41.340] through these challenges from the start instead of like, I can think of a few projects where [21:41.340 --> 21:44.700] maybe it would have helped them if they had thought about some of these challenges from [21:44.700 --> 21:45.700] day one. [21:45.700 --> 21:48.980] So basically around data and privacy mentors who can come and help you audit what kind [21:48.980 --> 21:52.940] of data you are collecting which can later fire back. So all of this mentorship really [21:52.940 --> 21:57.460] impacts the future alignments. [21:57.460 --> 22:02.940] So I did mention I changed hats recently so now I'm at Red Hat and while I've been in [22:02.940 --> 22:12.180] the Fedora Linux community which is the upstream for one of Red Hat's core products, I'm still, [22:12.180 --> 22:15.300] I've been in the Fedora community for eight years but I'm new to Red Hat. So I'm kind [22:15.300 --> 22:18.900] of still learning my way around and one of these things I think is really cool as I've [22:18.900 --> 22:25.180] joined the open source program office is we have this team called Vertical Community Architecture. [22:25.180 --> 22:30.660] And so this team at Red Hat helps establish and continuously refine upstream and community [22:30.660 --> 22:35.660] strategy for vertical markets particularly trying to understand this upstream business [22:35.660 --> 22:36.660] model. [22:36.660 --> 22:40.900] So if I look at my Fedora piece like we're always talking about upstream first and not [22:40.900 --> 22:45.020] just trying to keep all of our patches downstream, we're always trying to go and help all these [22:45.020 --> 22:51.900] dependencies that were part of our building blocks for our products. So this team is helping [22:51.900 --> 22:56.460] other people who might not be, you know Fedora Linux is going on 20 years old now, we've [22:56.460 --> 23:00.780] been doing it for a while but our movement is growing, more people are coming into the [23:00.780 --> 23:06.140] fold and so this team at Red Hat in the open source program office is trying to help bridge [23:06.140 --> 23:12.300] that gap to help people understand these things. So investing early has long term payoffs but [23:12.300 --> 23:17.380] the value add is not always packaged so well and so that's where I feel like this team [23:17.380 --> 23:21.860] tries to help with that packaging for the partners and people that we work with. [23:21.860 --> 23:27.980] I should give you an idea from our, how we talk about this team inside Red Hat. So this [23:27.980 --> 23:34.260] team supports vertically focused projects and initiatives inside and outside the company, [23:34.300 --> 23:38.580] creates potential new project engagements, places that we want to be involved that might [23:38.580 --> 23:45.380] help our upstreams or our own products, helps map and cultivate a range of upstream options [23:45.380 --> 23:50.340] to these vertical growth initiative goals and gaps. We track upstream engagements on [23:50.340 --> 23:56.740] an ongoing basis making sure we're sticking true to that upstream first ideal and we also [23:56.740 --> 24:02.700] help, they also help develop metrics and processes for successful vertical engagements. [24:02.700 --> 24:06.980] They also have a part of their charter around this community leadership support. So this [24:06.980 --> 24:12.460] is actually providing very close strategic support to Red Hat led projects from inception [24:12.460 --> 24:18.100] and they're just getting started as they reach this cruising altitude after they launch. [24:18.100 --> 24:23.700] It also helps to plan Red Hat's engagement focus and strategy and opportunities for leadership [24:23.700 --> 24:28.500] in these emerging and growing communities and provides community expert consultation [24:28.500 --> 24:33.780] for strategic vertical accounts seeking open source strategy engagement. How does this tie [24:33.780 --> 24:38.780] in to what I was just talking about with DPGs? This is part of this early stage conversations [24:38.780 --> 24:42.700] when you're getting into these topics and you're trying to think, especially with DPGs, [24:42.700 --> 24:46.020] we're not really looking at the short term view here. We're really trying to look at [24:46.020 --> 24:50.260] the long arc of where we're going with these products and even if they're in that very [24:50.260 --> 24:55.780] early stage innovative part of that curve, we want to make sure they're thinking around [24:55.780 --> 25:00.200] this long term. So eventually you can progress through that innovation curve instead of having [25:00.200 --> 25:05.980] that abrupt drop. So this is I think one really nice example that I found inside Red Hat that [25:05.980 --> 25:11.340] I think around how this team is engaging with our upstreams and our dependencies to help [25:11.340 --> 25:18.180] these people who are coming into the fold think around some of these challenges and problems. [25:18.180 --> 25:28.380] Back here. This is just me. No, this is me. No, I think this is the middle stage. Yes, [25:28.380 --> 25:40.820] sorry about the confusion. The lapel mic. Little dance here. So what happens once a company [25:40.820 --> 25:45.300] coming from UNICEF perspective? What happens once the investment round is complete and now [25:45.300 --> 25:51.300] they're at a stage where they can operate in the right way that we set out to be. We [25:51.300 --> 25:57.820] also have further level of funding, but it also ties into a general normal community perspective. [25:57.820 --> 26:03.460] It's about finding a framework to identify the right community for you. Where exactly [26:03.460 --> 26:09.140] do you go and talk to people? How do you form community? How do you attract contributor? [26:09.140 --> 26:17.060] So discussion around that, but also creating evidence of impact. What metrics to observe? [26:17.060 --> 26:22.420] What communication and how is the conversation going on around tools? Focusing on that and [26:22.420 --> 26:27.580] again coming back to setting governance model, revisiting project charter, all of these things [26:27.580 --> 26:35.980] are equally important when thinking of community around the middle to early stage companies. [26:36.260 --> 26:42.740] I want to give examples of two companies who were graduated and they later got more funding. [26:42.740 --> 26:49.020] First company is a thinking machine. It's a powerful AI to mine data-driven decisions [26:49.020 --> 26:58.300] to decide that. Along with UNICEF, East Asia and Pacific Ocean country offices, they are [26:58.300 --> 27:07.260] scaled into eight countries, seven is in country by now. And second is Pixframe, which just [27:07.260 --> 27:13.980] secured 1.5 million licenses with Gwantamalai government, which is the first of such scale [27:13.980 --> 27:27.620] with the government. And Pixframe is a game-based learning tool for children. [27:27.740 --> 27:31.180] In this part, I can talk a little more freely because this is where I fall into the Red Hat [27:31.180 --> 27:34.980] open source program office. I won't try to bore you with reading all of this. That's [27:34.980 --> 27:40.500] kind of like our public-facing part. You might find it interesting, but in a general sense, [27:40.500 --> 27:44.740] how this team inside Red Hat's open source program office ties into this middle stage [27:44.740 --> 27:51.980] piece. So as a project is growing and scaling and we're upping our engagement with the community, [27:51.980 --> 27:56.820] Red Hat's open source program office will actually assign a community architect for [27:56.820 --> 28:02.460] a project or an ecosystem of projects depending on what the scope is. But this is where we [28:02.460 --> 28:06.860] actually get very hands-on and we are actively engaged in the project, trying to help keep [28:06.860 --> 28:14.140] an eye on these issues and key areas of focus around sustainability and trying to make sure [28:14.140 --> 28:20.300] that we're both practicing active listening of the challenges in our communities because [28:20.300 --> 28:24.780] we're not just working with Red Haters, we're working with people across all ranges of spectrums [28:24.780 --> 28:30.980] or different, it could be companies, it could be in Fedora's case, many volunteer contributors [28:30.980 --> 28:37.060] or other partners or customers at Red Hat. And that was the first part. The second piece [28:37.060 --> 28:44.980] is, so it was around the engagement and right. And so also trying to make sure that we're [28:44.980 --> 28:48.700] acting, living our values basically when we're working with these communities that we're [28:48.700 --> 28:53.260] actually putting our money where our mouth is and working with our communities and supporting [28:53.260 --> 28:58.020] them as they continue to grow and scale. So this is the part where I think as I'm working [28:58.020 --> 29:02.180] in Fedora, which is an older community, but I also have many colleagues who are working [29:02.180 --> 29:06.180] with these newer projects who are kind of slowly approaching that cruising altitude that [29:06.180 --> 29:11.540] I mentioned. This is a way that we help provide a more sustainable focus for these projects [29:11.540 --> 29:15.740] to make sure that they're getting their voices heard, that active listening piece. And then [29:15.740 --> 29:19.340] we're actually taking steps and actions to make sure that we're supporting them and helping [29:19.340 --> 29:28.860] them grow in a sustainable way. [29:28.860 --> 29:37.460] So this is a small slide. Our point is middle stage or early stage, investing in community [29:37.460 --> 29:42.940] really supercharges you and it matters a lot as early as you can start. [29:42.940 --> 29:47.620] And I think also to build on this, part of this whole theme of this talk around full [29:47.620 --> 29:52.420] stack DPGs and kind of what we're getting at with the gap in the DPG standard that we [29:52.420 --> 29:57.900] talked about is this whole community piece isn't really defined, not just for DPGs, [29:57.900 --> 30:02.020] I would say probably across the board in the open source space. But when it comes down [30:02.020 --> 30:06.580] to it, you really have to take the steps early on. And if you do that, when you get to this [30:06.580 --> 30:11.660] mature level stage, it makes it so much easier to avoid these challenges that will prop up. [30:11.660 --> 30:16.660] If you, you know, you'll still have challenges, you can't solve everything in advance, but [30:16.700 --> 30:20.540] at least you can try to avoid some of these bigger challenges, existential ones that might [30:20.540 --> 30:24.420] be governance or in some cases, license change. [30:24.420 --> 30:38.900] Oh, sorry. So the idea was when sudden change in community around this slide, we were talking [30:38.900 --> 30:43.300] about what does the change in community looks like at a larger scale company who have been [30:43.300 --> 30:46.900] doing for a while and then suddenly they want to invest more in community or there [30:46.900 --> 30:51.180] already exists a community but in change in certain directions. And we were discussing [30:51.180 --> 30:56.980] about community with flash on how it can fire back because suddenly some people, your partners, [30:56.980 --> 31:01.300] industries you are working with, they may not be aligned with you. So at a larger stage, [31:01.300 --> 31:06.380] it can be challenging while you may have more resources to invest into, you may have more [31:06.380 --> 31:11.020] people to work around building a community and looking at how can we do the right way. [31:11.020 --> 31:15.980] But it can also hurt a lot of people who are already using your tools and suddenly they [31:15.980 --> 31:21.100] were not expecting it. But thankfully it's for all the way the good way, but communication [31:21.100 --> 31:27.220] can matter a lot. Certain examples, even though changes have done for right, if not communicated [31:27.220 --> 31:31.940] properly it can be taken the wrong way and it can hurt a lot. For example, this is a [31:31.940 --> 31:38.380] personal example I felt, centristream. If you know how the communication around centristream, [31:38.380 --> 31:45.500] it was a long time coming, it's actually done for good in certain cases, but when communication [31:45.500 --> 31:52.140] not done right at a larger scale, it can create a lot of chaos in the community. [31:52.140 --> 31:56.660] And kind of a part of this is when you get into this mature stage, you're not quite that [31:56.660 --> 32:00.660] young early stage project you once were where you can make decisions fast and quick and [32:00.660 --> 32:05.220] there's fewer people to consult and be your stakeholder. When you reach that mature stage [32:05.260 --> 32:10.300] that again kind of building community in from the start, it comes down to building consensus [32:10.300 --> 32:16.340] and acting with consent. You might not always have that 100% consensus, but at this point [32:16.340 --> 32:20.660] when you're reaching this mature stage and as a DPG, something that's really important [32:20.660 --> 32:25.340] to make sure you're reaching your right stakeholders, is making sure you're getting that consensus. [32:25.340 --> 32:31.420] You're engaging with your key partners or people who have a clear stake in the project. [32:31.540 --> 32:35.500] And ultimately it comes down to this piece of making sure you're acting with the consent [32:35.500 --> 32:36.500] of your community. [32:41.500 --> 32:47.300] So to wrap it up almost, and for some time for Q&A, our point is just the code does not [32:47.300 --> 32:53.740] matter. There are multiple technologies, multiple angles to it and it's not just your IP is [32:53.740 --> 32:58.140] not just about code anymore, it's all the things around it, all those different indicators [32:58.140 --> 33:02.460] that we talked about, but almost more, something that's missing on how do we identify the clear [33:02.460 --> 33:08.700] path forward in future. There are multiple angles to it and we are ready to discuss that [33:08.700 --> 33:18.860] with you. The value of DPG lies in what it's created around the code, not just in the [33:18.860 --> 33:29.660] code itself or not just the model itself. So let's invest in full-stack DPG, which [33:29.660 --> 33:36.060] is also a call. How can we decide what full-stack DPG means and how can we ensure the sustainability [33:36.060 --> 33:43.060] of it? That's us and we are ready to discuss or take question and answers. [33:49.060 --> 33:50.060] We have a mic. [33:50.060 --> 33:51.060] No, we can repeat the question. [33:52.060 --> 34:07.060] Part of global harm, who decides, how it starts, there must be some political agenda somewhere [34:07.060 --> 34:12.060] that decides who is going to decide what's harm and what, and then from that starting, [34:12.060 --> 34:17.060] because I can give examples of really bad things in my opinion, like the Pegasus software [34:17.060 --> 34:30.060] despite people, some people say that that software can present more harm. The question is who [34:30.060 --> 34:41.060] decides what is no harm. To this, that's where we discussed how digital public good alliance [34:41.060 --> 34:46.060] makes digital public good standards and in those standards is how we define what is [34:46.060 --> 34:52.060] do not harm. Collection of PII's, right? That's the harm that we don't want to have [34:52.060 --> 34:55.060] when it's a digital public good and there is a software that's collecting your information [34:55.060 --> 35:00.060] that's not adding to the best relevant practices. If it is collecting for the most important [35:00.060 --> 35:04.060] needs, is it following certain right security and deployment practices? [35:16.060 --> 35:32.060] I'll add maybe three prongs of this that I'll say. The first one I think in your question [35:32.060 --> 35:37.060] was kind of like who says, who gets to define this? Part of that goes back to the slide from [35:37.060 --> 35:41.060] the digital public good alliance is all those key stakeholders that are there. In a sense, [35:41.060 --> 35:45.060] those are probably the biggest stakeholders who have a, that doesn't mean they're always [35:45.060 --> 35:49.060] talking about the standard and every member organization is voting on what is do no harm [35:49.060 --> 35:54.060] or not, but this is kind of the body of like where some of the voices are. But I also say [35:54.060 --> 36:00.060] at the same time, all of these things are open and have open processes on GitHub where you [36:00.060 --> 36:05.060] can open an issue and discuss with the, I guess it would be like the program management [36:05.060 --> 36:11.060] and the co-secretariat where people, anyone in the public can come and flag these issues [36:11.060 --> 36:16.060] and open a discussion around like, hey, like what about this part? All right, so we're at [36:16.060 --> 36:20.060] time. I'll just add one more piece on that question. I think around like the open source [36:20.060 --> 36:24.060] bend is that, you know, around this protection from harassment piece, I think is a nice example [36:24.060 --> 36:29.060] in the open source context because in that UNICEF open source mentoring, we help people [36:29.060 --> 36:33.060] with code of conduct and helping them think through like how do you handle like this case [36:33.060 --> 36:37.060] of harassment when you have either it could be users who are interacting on the platform [36:37.060 --> 36:42.060] or contributors who are engaging in the community. Not a perfect answer, but I also would [36:42.060 --> 36:48.060] encourage you to check out the DPG standard on github, github.com, slash DPG Alliance, [36:48.060 --> 36:53.060] slash standard. Maybe we should put that link on the slide next time. But I think we are all [36:53.060 --> 36:58.060] out of time. Thank you all for joining us and hope to see you around Vosdem.