They should at least trim it. I'm just going to trim it. That's it. There you go. Yeah, it's good. This is a satisfying thing to do. It's very careful. It'll lose piles. So that can manually, when you put it on the metal tapp, it's usually that way. I guess you like a multi-tool. Right now. Well, man, all the people that you have have to trim it. You know what I wrote down there? I don't know what to say. I don't know what to say. I don't know what to say. I don't know what to say. Hey guys, so please, calm, take a seat. Okay, so please quiet. So in the next 45 minutes, Jan Szapani is going to present you with a part of the persistent storage and open-shift. So in this talk, you will learn how open-shift brings persistent storage into the world of state-based containers. So Jan, it's your turn. By the way, one note, please don't regret the rate. Yeah. I will check it. So thanks for coming. Welcome to my talk. As Jerdra told, I will be talking about open-shift storage. I am a software engineer working in Red Hat. I work on Kubernetes, actually. I don't work on open-shift, but open-shift is just Kubernetes when it comes to storage. I will show you how to use existing storage inside open-shift. If you have some legacy application and you are now trying to containerize it and run it in open-shift, so it can access the old data. I will show you how you can create and delete storage dynamically in open-shift. And in the end, I will try to show you if time permits how to build a scalable application using persistent storage. That's the goal of this presentation. So before I start, I will very briefly talk about open-shift. Open-shift is a container orchestration framework. It runs containers on a cluster. And it doesn't run containers only. Like single entities. The smallest entity it runs is POT. POT is a collection of containers. Typically it's just one container, but you can have as many containers in the POT as you want. For the purpose of this talk, POT and container, you can take as synonyms. I don't... I won't talk about many containers in the POT. It's the same like one for me from the storage point of view. And as I've said, open-shift is Kubernetes plus additional features. And when it comes to storage, we don't have any additional features for open-shift. Everything I talk about will work in open-shift. It will work in Kubernetes. And I will talk about future open-shift. What you will see in the next release. 1.5 And that means I can show you Kubernetes 1.5 which has been already released. Talking about future open-shift, I will talk about current Kubernetes. 1. Difference between open-shift and Kubernetes is that in open-shift, we take security seriously and, well, more seriously. There is a distinction between administrator of open-shift cluster and user cluster. User of this cluster in this case is somebody who deploys applications on open-shift. Typically, it's a developer or some DevOps guys. This guy, this user in an open-shift sense is administrator of application inside open-shift. So, as I have said, open-shift and Kubernetes they run containers. The containers are fMRO, they are started, they delete it and every change that the container does everything what it writes is lost when the container dies. So, to bring some persistence into these containers we mount stuff into the containers and we can mount many things. We can mount third file system like NFS Blaster, CIF, we can mount full-block devices like iSCSI, FiberChannel, CIF, QuoBite, Flocker and Photon. If you don't know what it is, these are QuoBite and Flocker are new startups in Silicon Valley. Photon is something vSphere invented. And we can mount storage from cloud.  I think it's called EBS. If you run on Google Cloud Engine, Google Compute Engine you can mount persistent disk you can mount native OpenStack storage, native Azure storage native vSphere storage and so on. We have also some special file systems which I won't cover in this talk because they are not persistent. In Kubernetes or in OpenShift you can define a secret which is just key value map where you are supposed to put credentials the application you are deploying needs to connect somewhere for example to the database so you create a special secret object inside Kubernetes and Kubernetes can mount or create a file system inside the containers which will hold the credentials for you so your applications can find it and can see the username and password and can connect to the database. And last but not least we have a flex volume which is only important thing all these plugins on the slide are hard coded inside OpenShift they are not plugins actually you cannot dynamically load and unload them they are hard coded in Kubernetes and OpenShift so if you have a new storage and you want to talk to it using OpenShift you have to write the plugin and the flex volume is for you if you don't want to write it you just distribute shell scripts which can mount the storage and unmount it and Kubernetes will call these scripts when it needs to mount the storage to your containers or unmount it and this will get extended soon I hope and most of the stuff here will move from OpenShift code and it will move into flex hopefully because this is hard to maintain there are so many plugins to maintain and everybody wants his own storage there and it's very pain to maintain so as I have said for you who don't know OpenShift a container is fmro and if you want to use some storage outside of OpenShift you can directly type the coordinates of the storage if this nfs share you type the server address and the share name into the pot directly into the pot you can if you want I have an example I think, yeah so this is the pot definition in OpenShift everything is defined by YAML files and this pot runs one container it runs a busybox inside the busybox it runs some busy loop that writes something to mnt.demo.txt and it mounts nfs server from this address this share and it mounts it into this directory so if I now cross your fingers because if I oops I have this pot running and it writes I can see that OpenShift mounted this magic share if somewhere inside OpenShift well as I've said I'm not running OpenShift I'm running current Kubernetes to show you future OpenShift so it mounted somewhere into Kubernetes internal tree and if I look on the nfs server I can see it's writing something so this way if the pot dies and it's restarted on a different node it gets the same share mounted and it can continue writing the data to the same file so that's how we ensure persistence in Kubernetes and OpenShift but to for application developers and OpenShift users they need to know where the storage is they need to know the share address the nfs server address the share name and this is not portable if I have this application in my test environment I have one share with data and if I move it to production then I have different share with the data and we don't know we don't want users to know details about the storage we want to hide the storage so in later I will show you how we get rid of this magic IP addresses and share names in definitions and move them somewhere else it can be managed by administrator and the user doesn't need to know anything about the storage at all so why am I using this direct connection to the storage it's quite useful if you know what you want if the user really knows hey, this is the storage I will never use I will never use anything else then this is useful for debugging purposes you don't need to create any other objects you can connect to the storage directly and this method where you put storage details inside the port definition this is useful for the non-persistent storage like the secrets, like the config map and I will show you empty directory which is kind of special storage it's not persistent when the port dies the empty directory dies and what does it do it provides just a storage for your data outside of the container so you don't pollute your container with files because you don't know how big it can be you can put typically some caches there and how does it work this is the same port up to this line it's the same like before you just won't mount NFS share into the port you will mount empty directory and memory that means you will get really fast tempfs based storage inside your port so even unprivileged and privileged port can use tempfs for some fast caches so that's basically the only reason why you should use the storage directly as I have said if you really know what you want for debugging purposes for non-persistent storage and for caches so now it becomes interesting so as I said we don't want the users to know letters about the storage before I start talking about the objects we have for persistent storage I have some analogy in OpenShift everybody use this every time in OpenShift if you start the port the port is basically a request to compute something request for CPU, for some memory and to run some container inside it and in OpenShift we have node object which represents some compute resources outside of Kubernetes and if you submit a port to OpenShift there is a scheduler and it schedules a port on a node and something very similar we have in storage we have request not for CPU and memory but for storage and we have a sort of scheduler that finds a storage for you so let's assume you have some storage outside of Kubernetes, be it NFS shares, iSCSI Amazon volumes, whatever the administrator, the OpenShift administrator creates a persistent volume objects representing the storage outside of Kubernetes so for each volume or NFS share or anything it creates one persistent volume object that represents the storage the user who wants to run the port he creates a claim as a request for storage the user says I want to store 5 gigabytes of data somewhere please OpenShift find me a place and what OpenShift does it has a sort of scheduler it finds a volume for you and finally the port OpenShift looks at the claim the claim points to persistent volume it points to the storage and the storage is mounted into the port and the port is happily running so is this understandable, any questions about this persistent volume represents the storage persistent volume claim represents the user's request for storage and it's bound together this binding between volume and claim is pretty strong nobody else can use the volume while it's bound so nobody else can steal your data basically the volume is bound only to the claim and the volume is available only through the claim and here is how it looks persistent volume it's a pointer to the remote data I mean there is the pointer the NFS IP address and share name it has also some metadata for example capacity which says how much storage it can hold and how it can be accessed for example is to rewrite many means that this volume can be mounted to several ports because this is an NFS this is a shared file system you can mount it several times it's typically mounted only once and it would say read-write once and on Google there is a special kind of storage that can be read-only many times so you can mount it read-only to several machines I will talk a lot later so the persistent volume represents the storage can be used only by the single claim and it's a global object so the OpenShift administrator creates the PVs ahead these PVs can be used by anyone I will talk later about how to restrict some volumes to some namespaces but by default they are global and they are managed by the cluster administrator there are some details each persistent volume has in the metadata it has its own reclaimed policy by default it is retained but it can be also deleted and recycled and the written policy tells what happens to the data when the user says that the data are not needed anymore so the user has a claim has pods running writing some data to the volume through the claim and when the user is done and says I don't need the data anymore then the reclaimed policy is executed and written means that the volume is there forever and it cannot be bound to a different user because there can be credit card details user names password on the volume and no, OpenShift doesn't know so we won't allow anybody to read the data but administrator can get to the data if the user changes his mind says oops, I deleted something accidentally please give me back the data then the retained policy you can actually get the data back with delete or recycle policy you won't get the data back if the user says I don't need the data anymore we either delete the volume completely or we delete all the data on the volume and make the volume available back to any user so I have an example how it works so user has asked for some storage using a claim, PVC and runs a pod a user can run as many pods as he wants with the claim the data is still available when the pod dies he can start the pod again or different pod and still it has access to the data the way how user says that he doesn't need the data is that he deletes the claim when you delete the claim as a user you say you don't need the data and if the reclaim policy is deleted then OpenShift will delete the volume and delete the persistent volume and OpenShift and you can't get the data anymore so please don't delete your claims unless you really know what you are doing and how does the claim look like as I have said it's a request for storage where user says I want to store in this case one megabyte of data somewhere please find this storage you can specify narrow the volumes the set of volumes you want to claim and important about the claim is that it is namespaced in OpenShift we have objects and pods and namespaces so different teams or different users don't clash with each other so if a user creates a claim and gets a volume eventually then the claim can be used only from the namespace you cannot share one claim among namespaces the claim can be used by multiple pods as I showed you and beware deleting claims is dangerous so some demo I have it depends on the persistent volume if it is shared file system you can use it from different pods at the same time if it is block device it depends on the file system typically you don't and if it is access mode read write only once is there something that checks that? the question is if the access mode is read write once there is nothing that checks that typically the second mount fails and the user gets some error message the retention policy is managed by the guy who creates the volume that means administrator but we ensured if you delete the claim you can't get your data anymore so it's either deleted recycled or it's retained that data exists but nobody can access it through OpenShift unless administrator do something so I have a volume again my favorite NFS share I created I have a claim which asks OpenShift for one megabyte of storage and come on I created a pvc and they get bounced together immediately so my claim says it is bound it is bound to this volume I have two megabytes I asked for one megabyte but I got two because the smallest volume we have I can access it from multiple pods and I can run a pod now I have two pods that use my NFS share so what happens and they are happy both have writing to the same file I should delete one I will delete both actually and if I look at the persistent volume details it has a status bound that means that it is bound to my claim and where is the retained policy here the claim policy is retained so what happens if I delete my claim that is bound to this volume it says that the volume is released now nobody can bind to this volume anymore so if I create the claim again the old claim the claim is pending that means there is no volume for you sorry and it will be pending forever until somebody creates some volume that can bind with so nobody can access this release volume so I will delete it and let's continue question the question is if the size of the volume is enforced and it depends on the volume if it is NFS share it is not enforced actually if it is Amazon basically block device restricted to the size of the block of the block device if it is shared for this time it's usually not so it's just the number that nobody enforces so now how can so now the administrator has created a lot of persistent volumes and if you want to what if the user wants a specific volume the persistent volume claim the user can say what kind of storage he wants and he can he can request something that can be shared among pods that means he wants read write many access mode this is for NFS cluster and this kind of shared file system or the user can require something can be read and written only in one pod that's the read to write one in Google there is one special kind of storage you can mount read only to many pods and it's block device actually it's not a shared file system so this way the user who submits a claim can say what he wants I want a shared file system I want the block device basically so each persistent volume lists in its metadata how it can be used for example in NFS share you can use it from single pod and you can use it from multiple pods and in the claimed user says what he wants I want something that can be shared and OpenShift then compares these requirements and the existing volumes and chooses something that fits their requirements and is small enough is as small as possible we are binding the smallest volumes first then you can require a storage class storage class is a quite new concept in OpenShift and storage class puts together volumes the same characteristics like speed or redundancy or price or anything this is defined by the class administrator what the class he wants so this way the administrator says that the persistent volume belongs to storage class fast the names are completely arbitrary administrator can define any classes he wants and to put a volume into a storage class he just says he just puts this magic annotation into the claim into the PV and when the user wants storage of some special class he puts magic annotation into the claim and Kubernetes matches this and finds the best PV with storage class fast in this case then we have something very similar to storage classes which is labels in Kubernetes and OpenShift we use labels for anything every object can have labels it can have as many labels as you want which is different to storage class storage class can be only one in a PV and the user then can request a volume with specific labels a volume that has labels shape square and color green and the user wants some persistent volume with shape square and this will match if the user will want shape, I don't know triangle it won't match so when to use classes and selectors these are kind of the same concept you label PV with labels or you take it with storage class this is the same basically but there is one difference if you don't say anything in the claim if you omit the selector then you say I want a persistent volume with any labels give me something, I don't care what it is on the other hand in the claim with no class requirements then the user says give me the default storage class that's the difference this way you can restrict some volumes to certain namespaces using quota because do I have slides about quota? yeah I have so I will say about quota soon so that's the difference between classes and selectors if you don't specify any selector you get anything if you don't put any class into the pvc you will get the default storage class and how can we use this quota? I have an example I hope where am I? it's 4 so I will create a quota that's just it says that a quota is part of the space so this namespace can now have 500 gigabytes of volumes with default storage class the class named default can have 0 because if I label my volumes I can say that this expensive ssd rate array is gold and I can make it available only to finance department because they are paying gold and default rotating hard drives I will give only to IT because they only dig bitcoins and they don't need storage so the quota and storage class is the way how to do it do you understand at least a bit? I see some notes it's per namespace quota is per namespace so I can create as many claims as I want I can create as many posts as I want but the claims I can't claim more than half a terabyte after that if I do I have a claim I have a claim that requires gold storage class and if I create the claim Kubernetes OpenShift immediately says that sorry that extends your quota so I cannot create just a claim that wants 10 gigabytes of gold and this namespace cannot claim anything in gold at all with labels and selectors you cannot do this if you label your storage like fast and slow there is no way how to restrict these labels oops only 10 minutes left so I'll speed up you cannot restrict it using this what I've talked about is I call it static provisioning somebody from OpenShift administrators creates the volumes ahead creates the persistent volumes inside Kubernetes and user can claim it this way the user doesn't need to know anything about IP addresses of your NFS servers, share names volume IDs anything it just creates a claim I want 5 gigabytes of something give me that but who is in trouble as your administrator he doesn't know how many TVs should I create in the lines how big should they be and for that we invented dynamic provisioning in dynamic provisioning we envision a situation when there is nothing created outside of Kubernetes no persistent volume exists and user creates a claim I want 5 gigabytes of something OpenShift creates the storage by itself creates the volume binds everything together and user can happily run the pod so for that we need a storage class object storage class as I've said it puts together persistent volumes with the same characteristics and it's a new object in OpenShift 1.4 and it contains parameters for dynamic provisioning this is the important enhancement now so the storage class it's again defined by the administrator it has some arbitrary name the admin can define as many storage classes it wants with different names what's important it has the name of the provisioner and parameters for the provisioner so that means in this case it will provision Amazon volume with the best you can get there so it's really fast and in OpenShift 1.4 1.5 we will allow a default storage class to be defined that means if user submits a claim that says just give me 5 gigabytes of something he will get the default one and how he does it the default storage class has this magic notation it will move somewhere here into the parameters but now it's notation in OpenShift 1.4 we have provisioners for Amazon Google OpenStack Cinder in 1.5 we will get more and what's important we have external dynamic provisioners that means that somebody can write a piece of software run it somewhere it can run as a pot inside OpenShift it can run outside of your OpenShift infrastructure if you want and it provisions the storage outside of OpenShift so you don't need to write a plug-in inside OpenShift which is, it's not hard but it's hard to get the code in and pass the reviews and such you can write something by your own and we have NFS Provisioner where is my NFS 05 we have created NFS Provisioner which runs as a pot and it creates NFS share inside the pot that means if somebody kills the pot the data is gone so it's not for production use definitely not but it's good for testing and development so on your local machine you can have something that's dynamically provisioned I see some question was this relation to OpenService broker? I don't know anything about that so probably none I have a storage class which is very simple it defines a storage class named default which is default and the Provisioner is it's a string it's nothing magic in that and this string is provisioned by the pot I'm running I hope it's not running because of stupid network so I need a pod with this now it's here it should work but from some reason oops no network is busted sorry I won't show that ah no time for wires I'm handling user permissions for persistent volumes but in case we run a container under a non-user I want to make sure that that user has permissions to run to the persistent volume the question is how user permission works if I have if the containers run as basically random users and the answer is you can in the definition you can specify supplementary groups and FS group parameters and open shift will then run the pod with these groups with a random UID but the groups will be there so if you make the storage available to the groups then it's kind of way how it should work so it's not bound to user IDs it's bound to groups so in this dynamic provisioning if it worked you would see that I have NFS share but I don't the user doesn't need to know anything about storage if he doesn't want to of course the user can use selected storage classes and whatever but if the user says I want 5GB of data that's fine administrator just configures the storage classes to provision something and everything magically happens so this is the way we envision for a new application when you are building a new application you don't have any legacy data you should use dynamic provisioning if it is possible


Hello everybody, my name is Tobias. I'm a designer at the GNOME project and I also work for Purism and this talk is going to be about the general approach to icons in GNOME and how that's changed over the last few years and some of the developments in that area. When it comes to icons in GNOME and I guess the free desktop in general, everything sort of goes back to the Tango project, which was this big standardization effort in the mid-2000s that created the framework that all of the sort of icon infrastructure that we have now is kind of based on and I think it's important to like talk about that a little bit as a start. One of the big ideas with Tango is that there are multiple sizes for every icon. So there's one for 16, 24 or 32 and they're all pixel-hindered for one exact resolution and a big part of that also statistically is that there are these one-pixel strokes that are exactly on the pixel grid so it will be sharp at that specific resolution. And then if the icon is used as a different size, then a different variant basically of this is used. Stylistically, Tango icons always have like a photorealistic kind of 3D perspective icon at the large sizes and then at the smaller sizes, they generally the perspectives pair back a bit, so it fits better on the pixel grid. So all that Tango stuff applies to all icons, but in terms of actual use cases, there are two relatively different categories. On one hand, there's the app icons, which are the identity of an app and the thing that you click on when you launch an app. And then there are the icons that we use in applications, for example, like that three line icon for the primary menu. So over the last few years, the way we approach both of these categories has changed quite significantly and that's basically what I want to talk to you about today. So first up, app icons. I think this is gonna be the majority of the talk, both because it's more kind of exciting and interesting to look at and also because it's a bit further along. So if you use GNOME or are generally following the free software desktop ecosystem, you're probably aware that we've made some significant changes to the way we do app icons over the past two years and a big part of the reason why I wanted to do this talk is to tell the story of how that happened a little bit, give some background and kind of share some fun behind the scenes stuff. Let's look at the status quo in app icons before we started this whole initiative. Basically, what you would do is you would first draw one super high-resolution photorealistic version of the icon and then you would sort of scale it down and pixel-hint it and like make it work at each of the smaller resolutions one by one. And then in the end you would still have to draw a symbolic, which is the black and white version. So this is a breakdown of all the sizes that you would have to draw for every single icon and yeah, it's a lot. And the funny thing is that a lot of those sizes were never even really seen by anyone because in the shell we either use the really large size or the symbolic and so a lot of those smaller hinted ones were never really exposed anywhere. And then of course with this very complicated workflow with the super high detail like large size and then all those hinted smaller sizes that takes a lot of craftsmanship and very few people, especially in our community, which doesn't really have many designers, are capable of doing those. And even for those people it used to take weeks to make one single application icon. And that over time like has the effect that the style kind of stagnates because updating all of the icons was basically an impossible task. Of course, if there's only a handful of people who can do these icons and it takes them a long time, there is no way they can do icons for every single third-party app, even if the third-party apps come asking, because it just doesn't scale, right? And so you end up with third-party apps having really bad icons. And another problem we had was just that general industry visual trends have changed over the last decade or so. And with that sort of the assumptions that app authors that ship applications across platforms have when it comes to icons. And so for example, the new Firefox icon is a lot flatter, a lot simpler than it used to be. And apps like that started to stick out compared to the pre-installed system apps, and that wasn't great. And the other thing that's changed is just the hardware people have, because if you have a high DPI display that scales everything to X, that kind of changes the assumptions that are like sort of behind those ideas of pixel hinting and one pixel strokes and so on. And we really felt like we needed a more future-proof approach for that. To illustrate the issue with third-party app, as I mentioned, these are some of the icons of major third-party apps for GNOME at the time. And as you can see, a few of them did have decent icons that fit in with the overall platform style, usually when a GNOME designer sort of like came in and helped out. But generally the picture was pretty bleak and it really didn't feel good to have some of the best apps for the platform have icons this terrible. And that brings us to the beginning of our story here. So in April of 2018, I visited Jakob Steiner in the Czech Republic. Jakob, if you don't know him, he's one of the earliest, I think, designers who got involved in free software ever. He's been on the GNOME design team since forever. He was involved with Tango and various other things in the past. But basically we were meeting up to work on some shell stuff at the time and I think one day over lunch we randomly kind of came upon the topic of icons and discussed all the various problems that I just enumerated and started throwing around some ideas for how to improve that situation. I think fundamentally what we realized is that we needed a style that would allow it for other people, not just us, the GNOME design team, to draw like good icons for apps. So how could we do that? Obviously the elephant in a room is all those different sizes, a lot of which weren't used because that we found is a major issue for new people starting to draw icons and a major tinesack when updating things. So one core idea was to have a single source of truth sort of color icon. We only draw it once and since we aren't really using it at the smaller sizes, we felt that we could probably get away with either unhinted or some kind of trick there and we also definitely wanted a simpler style with less details and a simpler aesthetic that's like much easier to draw without all these highlights and shadows and so on, but we definitely didn't want to go all iOS kind of flat. We definitely wanted to keep some dimensionality but sort of make it more accessible and then other things are for example previously all of these different apps had baked in drop shadows, but they would all do it differently and the perspective was different and somewhere bigger others didn't have a shadow at all and so on. So that was pretty ugly and so the idea was we don't do a baked in shadow at all and we'd apply it in the shell or in GTK or whatever displays the actual icon and we also had some ideas for how to improve the actual workflow of drawing icons to make that more approachable such as having an icon grid so it's easier to sort of size and place things in a way that will look good with other icons so that some icons don't go all the way to the border and others are really tiny and also a better color palette with a better system around that and various other kind of tooling related ideas and then on the train home to Berlin I started sketching out some of these ideas so I put together a very basic icon grid where I just took the 64 pixel base size and split it sort of 16 times and then made these base shapes on that and started sketching some icons on that grid as you can see they're pretty terrible, but they sort of started us off in that path of simplifying to this relatively high degree and like going in a more geometric direction. I also tried this this inset shadow to get a little bit of depth without having to actually you know draw perspective which obviously didn't work, but yeah, it was a start and then I sent this to Jakob and we iterated on this a bunch of times sent things back and forth and that's that's kind of how the whole thing got started. So over the next few weeks we started sketching more icons exploring the style kind of like how would we do depth playing with the base shapes and so on and also setting up a more comprehensive new color palette and just generally discussing some ideas for how tooling could could support this whole workflow and one thing that we discovered relatively early on is that the one-size-rule-the-wall idea actually really works surprisingly and once you've tried that sort of single source of truth workflow, it's just so much better. It's really good. So you might be asking yourself, but what about pixel-hinting? and what we discovered is that we can draw at 64 nominal size but if we keep the 32 in the back of our minds while doing that and kind of align as many things as possible to the 32 pixel grid, then we basically get 32, 64, 96 and 128 kind of for free with one size because basically those are all multiples of 32 and those are all the sizes that we actually use app icons at other than really small ones which are symbolic anyway and then yeah, basically with these two sizes, we covered the entire range of places that we need app icons for. For the app icon grid we iterated a number of times. We started off with this very simplistic geometric thing that looks great if you just look at the base shapes, but if you actually sort of make icons with it, they look weird.  You want the narrow shapes to be not quite that narrow because otherwise they look weird next to others. And you really want a baseline that most of the icons rest on so that if you see them next to each other, they kind of are aligned. This is the color palette that we ended up with after a few iterations. It's nothing too spectacular. It has five different shades of each of the main colors. There's a slight hue shift there between the lighter ones and the darker ones. It's a little bit more vibrant than the tango palette we had before. It's also worth noting the grays. That's something we kept from tango. The grays are tinted. They're not like just sort of straight up gray grays. There's like a little bit of color in each of them and that gives things a bit more of a distinctive vibrant feel. So after a few weeks of just me and Jakob playing around with things, sending stuff back and forth, Lapo Kalamande joined us. He's also a longtime gnome designer and did many of the old icons. We started drawing a lot more icons. We started trying some stylistic flourishes, trying to see how this was going to work for a lot more of the core icons. I think this is also when we started coming up with this perspective thing that we ended up with. The perspective is I think one of the most interesting aspects of this whole style because basically we wanted to keep some kind of like 3D depth in there. We didn't want to go like all flat or material or whatever, but we also wanted it to be really easy to draw. This kind of flattened perspective is really interesting because it basically glues together the top and the front of the object, thereby sort of keeping it really easy to draw. Like you can just use rectangles or circles or whatever, but it still has that depth. And then in a lot of cases, since we have this standardized 8 pixel rounded corner on a lot of things, there are these shiny gradients on the corners and that's a small like stylistic flourish that gives it a bit of personality, but really like keeps it easy to draw. And I also have to note that I was initially against this whole idea. I think my view initially was that this was going to be too complicated and not applicable to enough things, but I think it was Lapo who convinced us that this is the way to go and we evidently stuck with it and I think it was the right decision. One of the motivators for this whole initiative was that GNOME had recently started doing nightly versions of apps. So basically, thanks to Flatback, you could already install like the in development version of the next release of, I don't know, like GNOME clocks or something during the previous cycle. And obviously we wanted to have separate icons for that so you can tell the difference when you have them in the shell. And the prospect of redrawing all of our icons like with as a nightly variant in the old style wasn't very appealing. And one of the ideas with this new style was that we would have a way to automatically generate a nightly version from the original icon. Initially, we tried a whole bunch of things such as a color filter or like this beta batch on the left here. But eventually what we ended up doing is basically this overlaid semi-transparent stripe along the bottom. And that's basically just like taking this stripe shape that covers the bottom third of the icon and intersecting it with the alpha channel of the icon. It took a while to get all the tooling pieces in place but now we actually have an automatic way of generating these nightly icons from the regular icon in icon preview. And it's pretty magical. Huge kudos to Julian Sparber for figuring all of that out. So timeline-wise we're somewhere around late June, early July now. And that's when Sam Hewitt joined us who's also a longtime GNOME contributor and a really good icon designer. And as you can see around that time the style really started to stabilize. We had the perspective more or less figured out we had the color palette more or less figured out. And as you can see this still uses the old grid with the really narrow shapes. But we would figure that out eventually as well. And we started feeling like this was going to be a real thing that is going somewhere. In July we were also at Gwadec in Spain. Gwadec is the yearly GNOME conference. And but at that point we felt confident enough with what we had that we gave a small internal presentation to some interested people. And I think it was very well received and we felt after that that this was something we wanted to actually pursue and try to get into the next release. Which would have been 3.30 in the fall. And around this time we also started working on some new tools to support this whole new style and workflow. And the way it started was very kind of random and organic. I think Xander Braun was initially trying to debug a symbolic icon issue in some app. And so he made this little demo. And then somehow that developed into an actual app to preview sort of a symbolic icon and see if it renders and recolors correctly. But then I convinced him to add support for high color icons. So it could basically like show those as well. And like so you could see the icon with the actual proper shadows at multiple sizes. But then later we also added the new like source formats so that in the same file you can have a symbolic icon and a high color icon for an app. And so we added that. And then eventually like we added export and like nightly icon rendering. And then to sort of like bring things full circle in the end we actually removed the symbolic rendering part from this app and split it out into a separate symbolic app called symbolic preview. And so there's like a long and complicated history there. But yeah basically the whole initiative started then and kind of has been going ever since. And so in the weeks after Wadek with UI freeze coming up we basically tried to finish the set draw all the missing icons for core apps and utilities and all of the things that are hidden in a folder in the app grid that you never really use. And like the folders and the mind types and all of that. And as you can see from these examples the style was pretty solid at that point. We had the final iteration of the grid with the thicker base shapes and the baseline. And yeah things were really coming together. Unfortunately in the end we didn't manage to get it into 330 because while we were like done with most of the assets in time we also needed to actually get them merged and making merge requests to like 40 apps is pretty time consuming. And I think we had like maybe another week or so before UI freeze. So in the end we like had to push it to the next release which was 332 in March. And then that fall we had another hackfest this time in Berlin which was basically Jakub and I because I think Lapo bailed. And yeah essentially we worked on polishing the core apps that we had and various third-party apps because we were already starting to submit icons to third-party apps even though like sort of we hadn't actually shipped the style for the core GNOME stuff yet but we were already using it for third-party stuff and like new apps that were coming out and so on. And these are some of the first app icons that actually shipped in apps. As you can see quite a few of these apps are among the ones that I had on the slide earlier with third-party apps with bad icons. So those were among the first that we wanted to get fixed. And then also just like new apps that were coming out like the Librim 5 calls app or podcasts where we just went straight to the new style. And then in January we finally made the actual official announcement of the whole initiative with the blog post kind of explaining the rationale and like various details and the new developer guidelines were out and all that. Basically you get people ready for the 332 release in March so that ideally apps would already start thinking about changing their icons. And in early March we had another hack fest again in Berlin. And this time there were also some developers Julian Sparber and Jordan Petridius. And the focus was basically getting nightly icon support in AppIcon Preview. And then a week after that GNOME 332 was released with the new icons for all of the core apps and some changes to the system to accommodate that. And I think it was pretty much universally where we're saved which is unusual for changes this big. But yeah so that was good. And then a few weeks later distribution started to actually ship with the new GNOME version and the new icons. This is a screenshot of Fedora 30. And one of the interesting things that you can see here is sort of the difference between first party and third party icons is so much less pronounced than it used to be. If you sort of look at Firefox or LibreOffice they fit in so much better with the new icons than they did with the previous Super 3D ones. And while we're looking at the icons in the wild they were not only cool on the desktop but also on mobile. This is a photo of the Libre 5 with all of the core apps and the whole bunch of third party ones. And they're all using the new style. But of course the release of GNOME 332 was not really the end of this initiative. In some ways it was just the beginning. Because one of the things that we had really wanted from this new style was the ability to more easily and more frequently update the core app icons. And that's also what we've done the last few cycles. So for example between 332 and 334 we updated the simple scan icon because we found that people like couldn't really tell it was a scanner I think Sam came up with this very nice x-ray idea and now I think it's one of the coolest icons we have. Or for example last cycle we changed the image viewer from this like low contrast yellow gradient to something a bit more contrasty. And I think we'll keep doing this maybe updating three, four, five icons every cycle to keep things fresh and also improve things over time. But one of the most exciting things about the new style is that with this new faster workflow it's really possible to do an icon within a few hours and over the course of a week like do multiple iterations and so on. And that's really allowed us to help third-party developers out with icons at a much larger scale than we ever could. So these are a few of the icons that I did for third-party apps but there's many, many more and the situation there is so much better than it's ever been. It's really great. But even with the new faster style it still doesn't scale for us the design team to do every single third-party app icon. But that's why we put a lot of effort into documentation and tutorials and sort of making sure that the onboarding experience for our tools is good in order to hopefully foster an environment where third-party apps do their own icons for the most part. And there's actually quite a few decent ones these days. All of the icons on this slide were done by the developers themselves with no input from us as far as I know and while they're not like super sophisticated these are all pretty good and so much better than sort of the baseline random icons the developer does used to be. So I think we've definitely made progress here. It's time for our first demo. I'm going to give you a quick overview of app icon preview and the whole new app icon drawing workflow. Okay, so for the sake of the example let's assume that I've written a notes app and now I want to make an icon for it. So let's click new app icon and put in the name and this is just a regular reverse domain notation name the same that you use for your flatback manifest and so on. So skipping ahead a bit here's Inkscape and app icon preview both showing the same file. This is our notes icon and you can see in Inkscape there's the icon grid but then in app icon preview you see nothing because the app icon grid is ignored. Let's zoom out a bit and this is basically the structure of the template so in the middle you have the grid for the high color and the symbolic these are the areas where we're going to draw the icon and then on the left there's some example icons for the high color and sometimes it's good to like take inspiration from use pieces off these are like specifically chosen to be like archetypal things like a book and the stack of pages and so on and then on the right side we have a bunch of example symbolics to give you a basic idea of the style. Let's have a quick look at the layer setup so we're drawing everything on icons and then grid and base plate are the ones that show the grid around like where the icon is but they're being hidden in the preview so you don't necessarily need to do anything there but you can hide them if you want. Okay let's start drawing so my plan is to copy this logs icon delete all the stuff we don't want and then transform it into a notes icon so I've copied the logs icon and now I'm just aligning it to the grid on the actual canvas and now let's delete everything on top of this paper stack because we don't need it. All right and now we have a great stack of paper that we can use as the basis for our icon let's check it out in preview looks pretty good let's continue and next we want to make our paper stack yellow because that's the color of notes it looks like our paper stack here doesn't already have the corner highlight gradient thing so I'm gonna do that by hand but maybe that's good to show actually I'm adding a horizontal gradient on the bottom part of the object here and I'm moving it below everything so you can see it a little better and basically now we need to add two stops on each side one for the light and one for the dark color I know I'm not being super efficient here but yeah you get the idea and now that we have all the stops we can basically just use the colors from the palette at the bottom okay so the whole thing is yellow now let's check it out in the preview and yeah this already looks like a notes related thing we just need to add some detail for this simple example my idea is to just add a few lines of text and then a pencil and call it a day so for the text lines I'm just drawing a few rectangles but one important thing here is to put them on the larger grid lines because that way they're also gonna be sharp at 32 and as you can see here they do look sharp at 32 cool so now we can just add a pencil so for the pencil we're gonna draw a triangle and a rectangle and then later on we can rotate it but we're just gonna draw it horizontally okay that's the tip of the pencil and now the handle okay so that's our very basic pencil and now we can rotate it here again it's good to place the bottom left corner on the larger pixel grid because that way it will be sharp okay not too bad let's maybe add another line of text okay let's keep that for now and move to the symbolic so with the symbolic the basic idea is that we are gonna draw a smaller version of the large icons obviously to the extent that's possible within 16 pixels and generally we try to do two pixel strokes at least for the most important things we try to stay one pixel away from the borders all around so in this case I'm just drawing a rectangle with a two pixel border all around and that's gonna be the outline of our icon and now we can add a very stylized pencil to it all right and this more or less already looks like a symbolic icon oh okay and it's not rendering correctly because the outline needs to be converted to an actual path and there we go this is more or less the process of drawing an icon from start to finish obviously if this were a real icon we would do a lot more iteration we'd put maybe more detail on some of the things like the pencil and so on but I think you have a basic idea of the kind of workflow with icon preview and kind of like going back and forth which is what I was really trying to do here so that concludes the part about app icons now let's talk about UI icons this part is going to be a lot shorter than the previous one primarily because a lot of this work is still in flux but I think it's important to include here as part of the longer-term vision that we have for icons to give a little bit of background the way icons and apps work in GNOME is that we have a set of symbolic icons in the system icon theme which all have tango style semantic names so system search is the loop and list add as a plus and so on and all of these icons can be used in apps via their name and you can also ship custom icons with your app by including an SVG in your repository and then like including it via g-resource and so on but that's quite a bit more work than just like using them via a string so developers tend to avoid that when they can and only use the built-in icons and that's been quite problematic in practice for a number of reasons so for example we found that a lot of developers don't use the icons necessarily by their semantic name but just because of what they look like and then you get cases like document edit looks like a pencil but someone might use it as the pencil in their drawing app the problem is that the API for it is the semantic name and the actual metaphor what the icon looks like might change at any time and when that happens the app developer is going to be screwed because now the pencil icon is no longer a pencil and the other problem is that since it's so much easier to use icons via the name rather than include them in your app people constantly ask us for more super specific icons in the core set that maybe no other app is ever going to need and that just make the core set harder to maintain and increase the API surface of things that can change from under people at any time kind of in parallel to the whole app icon thing we also came up with a plan to fix the symbolic icon situation and the basic idea is that we would make it much easier to actually ship icons with your app both by improving the developer story and like having better documentation and also by giving people a large library of icons to actually include that are not part of the core icon set and at the same time we would slim down the core icon set to only the stuff the system actually needs and like the important shared patterns like the primary menu and so on that way we would both reduce the burden on the maintainers of the core icon set and also improve the situation for third-party developers because the icons that they're using are not changing from under them the first part of our solution here is our new library of non-semantic icons called the icon dev kit basically it's a large icon set of symbolic icons in the style of the regular gnomes symbolic icons but a lot of these are way more specific than things that we would include in the system icon set so like I don't know a park bench things like that and they're all named after what they look like rather than a semantic name but the real novelty here is that they aren't shipped to the system at all and you can only use them via g-resource these icons are included in a new app called icon library which allows you to search for icons and then guides you through including them in your app with this pretty neat interactive documentation thing that explains how to use g-resource and like you can choose your programming language and it kind of like gives you code snippets and so on but I'll give you a demo of that later this app was developed by Bilal Amusawi over the last summer along with a whole bunch of other really cool design tools all written in Rust so yeah kudos to him and on the authoring side we have another new tool which is basically the symbolic version of app icon preview and basically you can use that to preview the icons that you're drawing in Inkscape to see if they're like on the pixel grid if they recolor correctly and so on this functionality was originally in the same app that we use for previewing app icons but then eventually we split them because the use cases were a little bit more clear at that point and there are some things that we want to do in the future with symbolic icons such as preview like a whole large set of symbolics from a single file that wouldn't really have made sense in the same app as the icon stuff and now another demo this time of icon library so this is icon library as you can see it has a whole bunch of icons and organized in these non-semantic categories like body and food and so on and as you can also see a lot of these icons are very specific in a way to it we wouldn't allow in the main set so there are a lot of things here that maybe one or two apps need somewhere when maybe they need to customize it first and so it's good to have it and have it be available for apps but it's definitely not something that we would ever want to actually ship as part of the system icons you can also search and one of the cool things is that these icons can also be found via tags so those both semantic and non-semantic ones associated with every icon so as you can see here this thing has arrow, container, step, debugger and so on and down here we have the buttons for the two main use cases for symbolic icons which is to either use them in a mock-up or include them in an app and the app art is actually pretty interesting so let's have a look at that basically this view guides you through saving the file to your project directory and then including it in your g-resource file and then if you don't have a g-resource file there's code snippets for a whole bunch of programming language for like how to actually include that and basically it covers the entire range of things you need to do to actually get the icon shipped with your app so if all of this has gotten you interested in starting to draw some icons yourself here's how you can get started so the first link is the icon page on the GNOME human interface guidelines that's got like the basic rules and sort of ideas behind all of this and then below there's a tutorial that I wrote about basically designing a GNOME app icon from scratch and there's a lot of kind of nitty gritty stuff in there that you might be interested in of course you should try all of our cool new design tools most of which are written in Rust which here makes them very hip these days and yeah you can get them on FlatHub a little bit about our future plans for this whole initiative so as I said earlier we're gonna just keep iterating on the app icons but all the really exciting stuff right now is on the tooling side so for example app icon preview just got rewritten in Rust as of last week and as a result we got some really nice workflow improvements like for example the grid is now being hidden automatically in the preview whether or not it's hidden in the actual SVG and we also got SVG optimization that means smaller files and then the more medium term we also have some cool improvements planned for the export workflow in app icon preview but I think other than that we're pretty happy with that up on the symbolic side some of what we want is kind of blocked by technical limitations in how symbolics are handled but in the medium term one of the things that we really want is for symbolic preview to export all the individual icons from a set so basically you if you have an app that has a lot of symbolics you can easily manage them from a single file and then export them to production using symbolic preview so before we close I just want to take a moment and summarize some of the main ideas here a lot of our icon infrastructure on the free desktop is built around the assumption that it's possible to have this centrally managed set of icons that all the apps in the system share with every possible icon an app might need and every icon has 10 different sizes that are all pixel hindered for every possible scenario and unfortunately this only works if you have a handful of apps and no significant ecosystem of third-party apps a lot of the work that GNOME has been doing over the last decade or so with things like Flatback and GNOME Builder and so on was focused around exactly that like creating a real app ecosystem of third-party apps and so I think it makes sense to apply that same lens to icons as well because just like the only scalable way to do application packaging is to decentralize it, have the app developers do it the only scalable way to do icons is also decentralized where the apps own their icons as much as possible and when we design our icon system that should be the first priority that everything else kind of follows from so for example pixel hinting is nice but with today's hardware it matters less and less and as we said earlier a lot of those sizes are never used so in terms of trade-offs it's definitely less important than empowering developers so we can do it where it makes sense but it's not at any cost and that's really the thought I'd like to leave you with if we want free software to be competitive we really need to invest in solutions at scale and sometimes that means questioning and maybe revising some of the best practices that we've had for a long time a few people I'd like to thank obviously Jakob, Lapo and Sam from the GNOME design team it's been an honor and a pleasure working with all of you on this and obviously also the developers making all of the cool tooling happen so that's especially Xander, Blal and Julian thanks guys thank you very much for virtually attending my talk I hope you enjoyed it despite the bad audio this was all a little bit of a last-minute effort and if you have any questions feel free to reach out by email or message on okay so I'm looking at questions any questions thanks for the presentation you're welcome there were some questions before I think well so I can repeat the one from before that I remember and already answered on IRC which was like where is the color palette so there's a color palette app that you can use to get it there's also a git repository on the GNOME GitLab that has the templates for the icons I think also like some templates for drawing on paper and also includes the color palette and I'm not sure what the best way to just tribute a link to that is right now I've put it in IRC before but I mean all of that is pretty easy to find like if you go to the gig you'll find your way there is there a plan to use the palette inside of apps 2 for example in calendar for the colors that people can use for the calendars so there's been like an ongoing effort to use similar colors to these like maybe not exactly the same ones like the idea with this color palette was not to like have these exact shades of every color be the ones we use everywhere because like in practice the use cases are all like a little bit different and you often just want something that feels the same rather than like being exactly that shade I think there's like work on a new color palette for like terminal and builder and stuff so that's happening I know like well I mean the the GTK style sheet was already adapted to that like a year ago I don't know about calendar but probably just a matter of opening an issue any other questions I can scroll up and see if there was something else oh yeah there were some questions before about like whether this is like native or electronic or whatever and yes this is all native GTK no web stuff anywhere question am I a full-time designer yes I'm a full-time designer at Pearson you're welcome any other questions okay so there's another question for someone who is really not a designer at all where can I reach an icon designer for third-party pre-soft perhaps so in general like any of the places where like GNOME design people hang out like on IRC like the usual sort of GNOME hackers GNOME design and so on it's probably a good place um I've been doing a fair number of like things where it's just like if your app is on FlatHub and it's like a modern GTK 3 app it's possible that I will find you so there is that route generally I'm just like sort of going around that if I see a good GTK 3 app that's on FlatHub I try to help out I have a long list of things that I still want to get through but I'm doing a few a month or something so it's it's going but yeah generally like GNOME IRC or like if you want you can also reach out to me personally and some of the places that I put on the slides and then there's another question what are your suggestions for multi-platform applications for icon design how can they avoid being odd man so I mean this this is very difficult because like all of the platforms keep changing all the time and like form factors keep changing all the time and trends keep changing all the time and I think that's part of why especially like on mobile where a lot of companies sort of that's that's their main like touchpoint to their users so basically just like use your logo and put it on a white background and that's icon design now which from an icon designer point of view not great that's one way to do it you basically just like sort of the smallest common denominator depending on like what your sort of brand I don't know like needs are in some cases there's maybe the option to like just redraw your icon like in a similar way for every platform but obviously that's a lot more work and there's the potential for people to like not get it's the same thing and so it's really difficult I think is the answer but it also depends on which platforms you're targeting like if you're going for mobile and desktop that makes everything even harder so yeah I don't know do you have any more sort of specific follow-ups does that answer your question does another one does your open source design work help you in your career to get jobs well I mean it is my job so yes and there's another one do you know if other OS distributions UI toolkits have similar icon resizing workflows or such strict guidelines especially in the open source world I'm not sure what you mean similar to what similar to the old tango thing or the new thing we're doing now or what exactly that issues for inkscape oh boy that's maybe a topic for for more sort of more high bandwidth kind of conversation wait in terms of complexity as far as I know this is the simplest and most streamlined icon like set of icon guidelines that is out there on any platform because like I don't know even the mobile platforms require like six different sizes and like random pngs that you need to render at different resolutions so I remembered like doing that a few years back there was not fun so this is a lot more fun to draw from both like a workflow and a tooling perspective was there anything else are there any plans to have icon design specification free desktop.org space specifications in what way like what we're doing here is still part of those specifications it's not really like outside that we're just basically using it a slightly different way basically like instead of sort of having six different sizes we draw one but like it's scalable it's all with SVG and then we draw it in such a way that it's going to be sharp rather than like redrawing it at a bunch of different sizes and it's a trade-off but like it's it's it's part of that same world or similar kind of time for cursors inkscapes custom cursors look very different from the advaita ones I don't know I've not done anything on cursors that's a question for Jacob I guess but in inkscape case it's probably just a question for inkscape developers because like it's the the GNOME cursors at least like it's all one SVG file I think you could just like add a bunch there and apps could hook into it or something or like apps use that style to draw their own app I don't know not really my department um okay the e has a kind of app I can preview I don't know what else uh someone asks if I would suggest the same one size plus symbolic approach in other desktop environments I mean it really depends like if if another desktop environment presents all their icons at 24 then maybe not but on the other hand like I don't know like I think it the whole sort of like pixel hinting approach it just generally feels old even like when it's even when it works if that makes sense because you get this like cartoony thick outlines and then like I remember we used to get bugs in GNOME when like um because like the the dash on the left side and the overview scales down as you add more icons and at the point where like I can sort of shift from one resolution to the lower one um they would get the thick strokes and people would file bugs where like my icon looks weird uh all of a sudden um and I think like there I don't know maybe I would suggest it to others too like even if they don't use our sizes like I don't it looks fine in practice uh it it really I don't know like I think I went into this with a lot of hesitation about that that kind of pixel hinting thing and like a month into it you never notice it again so that's that's been our experience but again like we we do have sort of the luxury of knowing what sizes we use stuff at and like being careful with that Q&A how do we attract non techie contributors how do you make them feel welcome in the community or maybe uh you have too many non techie ones anyways so you're not looking for them I mean we're almost looking for new contributors in every area um I'm not particularly involved with engagement that's like a question for a different uh kind of part of the GNOME community I mean yeah I don't know like generally we try to make everyone feel welcome sort of like answer questions be available on IRC or or matrix or like wherever people are but um yeah I mean there are people who like explicitly do this in the project and that's that's not me um so they could probably answer that question better uh Q&A do you use non open source apps in your workflow um well we sometimes use like blue jeans for calls if that counts because like someone has it from their work and for a lot of people it it sort of scales a little better than stuff like kidsy but other than that not that I know of I mean basically my workflow is like inkscape and like various things around inkscape so it's it's relatively simple in that regard Q&A follow up under the free desktop question can there be cross desktop environment icon specification under free desktop organization well I mean that is what free desktop is um like I don't know I'm not sure I understand can there be free desktop environment icon specification under free desktop organization I mean as far as I understand free desktop is not actually an organization even like it's more sort of a loose collective of people like whenever someone's interested in something they kind of like do it there as an umbrella thing but um yeah I don't think it's like sort of you know there's sort of a standards organization there per se it's it's a bit more ad hoc than that uh someone asks like I guess with blue jeans is that's just like basically jitsy but um yeah like basically it does everything in one video stream rather than a whole bunch so it's like slightly better for shitty connections but I mean that's what I'm saying if that's not free software anyway I'm not trying to advertise for like that here I maybe I shouldn't have mentioned it at all but it's like the only semi proprietary thing I like interact with from a work point of view any other questions current design trends I don't like I mean like the icon thing that I briefly touched upon earlier like where everything is now like a small icon on a white background on a lot of platforms I don't particularly like it would be nice if like because one of the things that we really care about with with the icon stuff um is keeping kind of like unique shapes for every icon and actually like using that canvas and on mobile and like or just generally other platforms they've kind of like moved the other way where like now everything sort of has like canvas around it and then inside that you like draw your actual icon which is a neat trick to control the background but I don't know I don't like how it basically just makes everything smaller for a good reason and if there's no other questions I think that concludes this all right yeah thanks everyone for joining I hope the my answers were useful and yeah if you want to reach out I'm available on the internet um and yeah I hope you're gonna use the stuff to make great app items thanks everyone bye


Hello, everyone. Welcome to this presentation done by Paula Hunter and myself. Paula is the Mojado Foundation Executive Director. My name is Costa Peric. I'm the Mojado Foundation Chair of the Board and also Deputy Director of the Four Financial Services for the Poor at the Bill and Melinda Gates Foundation. Let's start by putting ourselves in the shoes of someone who lives on less than two dollars per day on average. It is expensive to be poor. Why? Because the poor people, the only way they have to transact for financial transactions is with cash. And dealing with cash in addition to security issues takes time and energy because essentially to pay for things, you have to walk. You have to walk to the utility. You have to walk to school. You have to work to the merchant to actually hand over the cash, which takes time and energy. Because in the case of where these people live, sometimes walking to the school can take you hours. The other interesting case is when a rural household has a child working in the city. The son may want to send money back, but in fact, probably he has to pay to transport this cash back to the family because he has to pay some friend or bus driver to actually travel and do that. So it is very difficult and expensive to be poor and be essentially also be excluded from the formal economy by dealing only with cash. So the basic innovation that first time helped this population, of which by the way, there is 1.7 billion on the planet today. And if we look at Africa, 400 million. So the basic, the first innovation that aimed to help people in this situation was invented in Kenya some 11 years ago through a commercial system called M-Pesa that was run by a telco provider and that's called, that was called mobile money. And the way it works is that it allows you to send and receive money pretty much in the same way that you send and receive text messages. Over time, the system in Kenya has proven hugely successful in terms of helping the poorest access to the formal economy and easing the burden on their lives and in some cases get out of poverty by better managing their money. And Pesa has also proven that it can be profitable to serve this population obviously in a very different way than a traditional bank would do. So over time, if we look at Africa, a number of mobile money operations were created. We see here the situation in 2018 with some statistics. But in fact, today over more than 250 operations exist in Africa in terms of mobile money. And so while this was, this is obviously great and shows great progress. Still today, as I mentioned, there is 1.7 billion people remaining to be connected. And therefore, there is a need to accelerate further this innovation to do that. How do we do that? The key word is interoperability. And in this, for this one, it's Tanzania actually that's innovating a few years ago where the four mobile money operators started essentially connecting their systems together. And by doing that, they actually are growing the market before in, you know, the typical mobile money operation today is like a silos in the sense that both the sender and receiver have to be on the same network to be able to transact. And while it's great, you can see also very limited. Imagine that you had a mobile phone where you could talk to people only connected to the same network as you wouldn't be very useful. Well, mobile money is the same. And in Tanzania, these four mobile money operators realized and interconnected their systems together. So let's see what was the result of that. Yes, so as you can see, interoperability really allows to grow the market. And when financial service providers realize that an internet connect, we observe this huge exponential curve of growth. Another good example of this would be in India, the UPI system, which is also a real time interoperable payment platform connecting banks. In India, we saw this also this huge curve of growth. So that shows how interoperability is the next wave of innovation. And in the, in the case of interoperability, one question obviously comes to mind is how to do it. And that is where Mojaloop open source software plays a role. Mojaloop is an open source free for everyone software that enables easily to connect various financial service providers and payment systems together. And therefore, it is kind of like a tool to, for people to take and implement interoperability in service of market financial inclusion, but also growing the markets in low income countries and elsewhere as well. Before I hand over to Paula to explain in more detail what Mojaloop is, let me just finish with this last slide that shows kind of a typical architecture of a payment system platform in a country or region. And on the bottom side shows the collaborative space where typically we see collaboration to create rules that govern the payment platforms and obviously the regulatory framework that applies. And then the rails that are actually providing the interconnectivity and payment flows. And these two layers are typically considered utilities, so collaborative space to, to create these rails. And this is where the Mojaloop foundation is active and working. The why, why it is important to create this payment platform as a utility, because it's a level playing field for competitive providers to come in to provide accounts and wallet services and also innovative applications. So that's how this ecosystem works, essentially is collaborate to compete better. So that's a brief overview of financial inclusion and payment platforms, the interoperable payment platforms. Now let me hand over to Paula to talk more about Mojaloop. Thank you for this. Thank you, Costa. And thank you all for joining us today to hear more about Mojaloop and the Mojaloop Foundation. I think what I would like to start with here today is to emphasize that Mojaloop is an open source software toolkit that's designed to enable interoperability across payment service providers. So folks are free to download the open source software. It's Apache 2.0 licensed. It's on GitHub. And we welcome folks that want to learn more about Mojaloop, deploy it or operate it to visit our GitHub repository and dive right in and get to know the platform. But let's talk a little bit more about the design of Mojaloop and how it came about. The fundamental principles behind the design of the Mojaloop platform is the financial inclusion level one project principles. The level one project was defined by the Bill and Melinda Gates Foundation. And these principles are an important foundation to our decisions with regard to the platform. First of all, we provide an open loop interoperable platform for providers to engage with. We adhere to international financial inclusion standards. We provide a push payment model with immediate fund transfer and same day settlement. We want to ensure adequate system-wide shared fraud and security protection. Efficient and proportional know your customer standards. Meeting or exceeding the convenience and cost and utility of cash, which is so important in these times of pandemic. Folks are really conscious about shifting away from cash. And we have to provide a customizable software stack so that folks can update and evolve their systems to ensure appropriate compliance with their own operational standards and local and national regulations. So the Mojaloop Foundation is relatively new. We were just formed in May of this year. And we were founded based on the principles of providing inclusive digital payments in emerging economies. We're very fortunate to have the support of both charitable and technology leaders in the space. From a charitable side, the Bill and Melinda Gates Foundation, the Rockefeller Foundation and Omidyar Network have invested in the Mojaloop Project because it lines with their charitable mission and is consistent with the standards that they want to see employed to address financial inclusion. We're also very fortunate to have technology leaders like Google, Coil, ModusBox, Ripple, PhonePage, Jory Digital, and Cybern who have joined in on this initiative to provide the technology leadership and insight to deploy Mojaloop around the globe. So the compatibility between our mission and our technology partners will allow us to expand and grow around the world. And the Mojaloop platform is not new. The good news is we started work on this in 2016. We kicked off the project in mid-year of 2016. We started work on an open API specification. We launched the open source platform in 2017. And then we started launching community meetings. The first one being held in 2018. We've since just finished our 12th community meeting just this past October. And so we've really made a tremendous amount of progress even given the fact that as a legal entity we only formed this year. We're now in our closing days of phase four development. And we're planning for phase five development in January of 2021. And as Costa mentioned, we've been engaging with the marketplace to start seeing deployments of the Mojaloop offering. The Bank of Tanzania is working with the code base to initiate a single payment system. And we also have Moale, which is a first commercial deployment, which is a joint venture between Orange and MTN, which are two very large mobile network operators in Africa. And they have announced a Pan-African partnership to deploy Mojaloop-based platforms. They have launched implementations this year and will continue to expand and grow those implementations into next year. So let's talk a little bit about our development model and why it is so important for us to have this inclusive developer community. We follow a agile development process, which means that we iterate on our work on a regular cadence three times a year. We have meetings where we talk about our workstream progress and we establish our priorities for the next program increment. The community is very much involved in determining what workstreams we will focus on in the upcoming program increment. And that's based on market requirements and gap analysis. Again, that the community articulates as being a priority. It's a very open process. It's inclusive of developers, implementers, and customers. So everyone can participate in our community meetings and everyone has a vote on what our priorities are for the next iteration of work. As I mentioned, we entered phase four of our development cycle early this year. We're wrapping it up and we'll launch phase five in our January meeting in 2021. Some of the core technologies that many of you in this presentation are probably very familiar with. So as you can see, we have an array of open source tools and technologies that are the underpinnings of the Mojulu platform. Of course, Linux-based, but many other important technologies are part of the solution. And I have to thank many of you that have contributed to these other technologies that are really essential for us to be able to deploy this type of solution. With regard to hosting of the platform, we're infrastructure agnostic. Our development platform right now is on Amazon Web Server. We have Azure implementations already deployed. But we also want folks to have the freedom to do on-premise installations with some government and regulatory agencies having very tight control of the infrastructure and the data really dictates how they host the platform. So it's perfectly acceptable and designed to be either cloud-based or hosted in-house. If you want more details on the tools and technologies, you should just check out our GitHub repositories. And you can find out a lot more about the tools and technologies that make up the Mojulu platform. Let's talk a little bit more about our community. From the onset, we really wanted the Mojulu community to be multinational, provide perspective around the globe with regard to this platform. Our center of gravity for early work was to meet market needs in Africa, where there is a large percentage of unbanked and underserved individuals. But we have contributions and input from countries across the globe. We're up to over 650 participants in our community. We span six continents, 47 countries, and we have 10 sponsor promoter members. So when we do those week-long planning sessions, community meetings, as I mentioned, we just finished one earlier in October, we get input from all over the globe from a wide range of participants, whether it be digital financial service providers, central banks, implementers, open source developers. So it's a very rich and robust community that's guiding us through our development. And what we want to do is make sure that we have this ecosystem that benefits everyone. There's a lot of stakeholders here involved in the Mojulu solution. First of all, there's fintechs, fintechs and banks that can use the code to modify internal systems or extend their external, the internal systems so that they can easily interoperate with other payment providers. Central banks can speed up deployment of national payment gateways and work with commercial partners, again having an interoperable platform. Governments can use Mojulu to deliver support payments to citizens right into their mobile wallets. As you know, with the pandemic right now, government payments are becoming increasingly frequent and the necessary for efficient, cost-effective and speedy delivery has never been more important. Merchants want their customers to be able to pay their bills directly from their phones. The reduction of use of cash is always desirable for merchants and banks. And then the users, as Costa mentioned, some users today have to walk miles or pay for someone to transport the miles to send money to their relatives or to pay a small bill. This way, they, using a Mojulu-enabled system, they can use their mobile phones and reduce the cost and complexity of being part of the banking system. There's four primary ways in which Mojulu enables an interoperable payments platform. First, there's an interoperability layer that connects bank accounts, mobile money wallets, and merchants in an open loop system. Open loop is so important here to make sure that consumers are not locked into one platform and can share money across different platforms. We have a directory service layer that navigates different methods that providers use to identify accounts on each side of a transaction. So, specific to what the service provider needs in order to validate those accounts. We have transaction settlement layer that makes payments instant and irrevocable. If you're making $2 a day, if you're living off of $2 a day, you cannot afford to wait 24 hours or 48 hours for a payment to clear. It's so critical to have instant payment settlement. And of course, we have components for designing and implementing strong internal fraud controls. We need that component to be very flexible for the unique requirements of each region and regulatory requirements. Now, I know a lot of you in the audience probably understand the benefits of open source, but it warrants reiterating the advantages of open source software in delivering the Mojulu platform. First of all, there's a lower capital cost upfront to deploy the open source software. As you know, open source software is licensed free and it allows people to not only deploy without those costs, but also to test drive and create a proof of concept or do a sandbox in a very low cost way to get themselves going with the platform. As far as lower maintenance costs are concerned, because this is a shared effort across many organizations, as we continue to expand those that are involved, if we have multiple banks, multiple central banks, multiple fintechs, it's likely that some of their challenges or issues or requirements are similar. And that allows us to share the efforts of maintaining those various offerings and features across the community. There's also no vendor lock-in, so there doesn't require you to go, if you need new features, if you need enhancements, you don't have to go back to a vendor and write a check to see that that work happen. You're able to tap into the community and again, probably find like-minded companies that have similar requirements and share the burden of developing that additional functionality and maintaining that additional functionality. So this is, you know, this development model is the perfect solution for rolling out a low-cost interoperable platform for financial inclusion. And the entire ecosystem benefits. So as MojiLoop comes online, it could reach up to 1.6 billion individuals that currently have no banking accounts today. Businesses will see an increase in the transaction volume. It estimates by the folks that wrote this study, it's well over $2 trillion. Digital financial service providers will see more transaction and activity, new account holders, and new participants in their offerings. And governments will save billions of dollars in being able to disperse funds out to the populace in a more cost-effective way rather than cutting checks or dispersing cash. So there's plenty of opportunities for you to engage with us and we encourage you to investigate more fully on how you might be able to do that. But let's talk about a couple of ways in which you can collaborate with us. First of all, our ultimate goal is to see adoption of the MojiLoop platform out in the marketplace.  You can also contribute to the platform. Of course, we're always looking for developers to contribute code to the various work streams that we are working on. But there's other ways to contribute. You can contribute on documentation, you can contribute on advocacy, awareness, education. So there's a number of ways that you can engage with the community. And hopefully when you come to our website, you'll find a number of ways. And if it's not clear to you, reach out to myself or community manager or product manager, we'll happily walk you through the various areas that need your support. And then finally, you can join the MojiLoop Foundation. As they mentioned, we were formed in May of this year as a 501c3 nonprofit. And of course, there are some operating costs in ensuring that we have the development platform in place, that we have staff to manage the community, that we provide the sales tools and training materials for the community to advance the use of MojiLoop. That always obviously involves some cash outlay. And so by joining as a member of the foundation, such as some of our other benefactors have recently, you can help underwrite the ongoing cost and development of the platform. So with that, a couple of things that I'd encourage you to check out. First of all, do check out our website, MojiLoop.io. We also have a community manager, Simeon Orico, who is available to engage with you to talk to you about how you might participate in the development work or in other areas. There also is a discourse session, the link that you see in the MojiLoop underscore OSS F20. That is a discourse session where you can ask additional questions about this session or about MojiLoop in general. So we'd certainly encourage you to participate, engage and ask any questions. We're here to help you understand more about how MojiLoop can really make an impact on financial inclusion and we'd welcome your participation. Thank you very much.