 Hello everyone, over there in Singapore for FOSS Asia. I'm so sad that I can't be there in person. I was really looking forward to my first FOSS Asia event and to talk about the projects that I've been working on around open design and open source design. But instead of me being there in person because of these unsure times, I'm here recording what I would be talking to everyone about for you to watch afterwards. So let's get on with the design contributions to open source, the learnings from the open design project. OK, so a little bit about me. My name is Errol. My pronouns are they, them, theirs. If you want to tag me in any tweets or any content, please use my pronouns that are the ones that I use, they, them. I am a humanitarian designer, so I primarily do work in the design field around humanitarian and human rights cases. So for things like election monitoring, things to do with crisis response and things to do with street harassment. And these are all tech responses to these kinds of humanitarian challenges. I've been in the product and digital and web space for about 10 years now, working in design and UX across lots of different titles. And I've been working in humanitarian and non-profit sector for around seven years, both voluntarily and professionally, so both paid and unpaid work. And I'm fairly new to open source. I'm fairly new to the world of openness and open source. About two years was when I had my first role in an open source technology non-profit doing design work for their tools. And when I was working in this open source organization, this non-profit, one of the things that me and my colleague, my other design colleague used to talk about a lot was why there aren't many design related contributions to open source. So we were there working within the open source day-to-day and we were seeing developers and people that could code and people that could write documentation. Anybody really that was from a sort of technical background or perhaps like a part of the coding community or that kind of techie community, they were ready and able to be contributing anything that they could to the repo when they had the time. And us as designers we were really curious as to why there weren't design related contributions as well because we were working openly in issues in those open repos as well, publishing our design work as openly as possible as we could while still using proprietary tools at the time because we weren't really sure about what options there were for design open source design tooling. So yeah, we were curious why aren't there more design contributions. We did a couple of different projects around this. We did one within the open leaders and Mozilla open leaders program to try and break down some of the barriers to design contributions or at least investigate it like very early on. We also did that for product management and a few of the other kind of functions that you find around design and tech products in general. We were basically just really confused as to why people that aren't coders don't get more involved in open source as well. One of the partnerships that we had really early on was with an organization called designer. They're an agency, a global agency of many, many designers all around the world and they approached us to do some pro bono work. So free work for a non profit and they were really interested in us at the time. The open source organization that I worked for was called Ushahidi and they made tech products for lots of different cases like I said humanitarian cases but predominantly the tool that they were doing some pro bono work on was a tool called 10 for which was looking at how to solve the communications problems in crises. So when you try and get in contact with multiple people through multiple different methods all at once to try and find out whether they're safe. And this was a real use case for the tool when we first created 10 for within the Ushahidi open source nonprofit. It was off the back of a terrorist attack that happened in a mall in Nairobi where some of our staff were present in the mall as the attack was happening and we couldn't get in contact with them. So we went through this frantic process of trying to get in contact with them trying to get in contact with their families through just, you know, the regular ways you get you communicate in a crisis, you know, texts, calling, WhatsApp, all the different kind of methods to try and find out whether they're okay. And we didn't find out if they were okay for many, many hours and it was very frantic and very upsetting at the time for the team that was working at the time. And on the Monday, they decided that, well, we create open source tools. So let's try and find a way to create a tool that helps this process. And that was the tool called 10 for. And the organization, the agency designer were doing some work on this tool. They did, they did some work in just in isolation as they do as an agency. But then one of the things that they suggested that we do was a kind of a hackathon, but for designers, they called it a design jam. And this was our first event that would later become some of the format for open design and the open design work that we did within Ushahidi on the tool 10 for in communities really around the world. So we did that first event in Berlin in 2018. It was a really interesting event. We learned a lot about how to do the next one, which was in Seattle in 2019. And the main thing that we learned about designers engaging with open source tools and contributing to open source tools and specifically open source tools that aim to do some kind of very obvious good in the world. So very obvious nonprofit or humanitarian use case is that really designers want to work on projects for good. It's a real fundamental part of the design designer brain that we want to solve problems. We want to solve problems using our skills, which are design skills. And one of the things that we don't get to do as often within commercial corporate roles is work on projects that very clearly are for the common good of humanity or the earth or for any kind of for good process. And it was really a simple learning that we discovered at first this designers wanting to work on projects for good. And after those first two events we were having conversations with Adobe at the time. So Adobe, if you're probably aware of what they create, they create proprietary or commercial tools for designers. And really there are lots of other design tools that you can use nowadays both open source and still proprietary or commercial tools. But Adobe is one of the most popular ones. It's one of the ones that we typically first learn to use as designers. So it's really important that Adobe came on board with the with the idea of this project really early on. And they were present at the Berlin event and at the Seattle event. And they were curious how they could progress this work, you know, how they could support designers working on projects for good with the added benefit of learning better, how designers want to contribute and collaborate in an open source kind of way. There was some, you know, things that Adobe were going to get out of that kind of engagement. They were going to learn better how designers collaborate across different time zones and different kind of complications and maybe not as part of a employed team. So they really wanted to find out how they could make things better and genuinely how that they could surface open source projects that need design help a lot better within their tooling. So together, the three of us, that's Adobe, Oshihidi and designer created the project called Open Design. And we were trying at first to investigate and solve questions around the why aren't there more designers in open source. And what we what we really wanted to do at first was a lot of in depth research. So we spent a number of months researching how to go forward with the with the project and how to how to build on the success or the learnings of the first two events. So we came up with the with the statement that we kind of wanted to wanted to go with which is designers still collaborating and contributing to specifically at the moment humanitarian open source software and tech for good at challenge gatherings. And these this was the primary focus initially of open design to learn and to carry on the format and carry on learning from the format again in an open way. But there are lots of challenges. There are too many challenges actually that we really learned within the process of both our research and doing the challenge events to really go into any depth within within a short talk time. But I'm going to cover some of the challenges that we discovered some of the most important ones I think. But if you are curious as to know what all the other challenges were, then they're all available on our open repo which has a link at the end of the talk. So lots of different challenges. One of the first challenges is really that most designers don't have a clue what OSS can be or is. So when you speak to designers and other kinds of roles that aren't necessarily coding or development roles, they can really be perplexed or surprised or just largely unaware of what open source software is. Maybe they've heard of the term. Maybe they've talked to coders or developers before and they've heard of it. But if they have then often their response are, you know, unencouraging suggestions that open source is really limited to terminal based tools or very developer heavy tools or things that are very complex and code related. And they actually really get very surprised that there are open source tools which are much more, you know, accessible to a designer, both for use from designers, but also to be involved in how those develop. So that it's not just about trying to understand the terminal or very, very code heavy things in depth, but there is a whole world of open source to discover that is very much on the kind of for good or humanitarian side of things. And often what happens when you talk about the kinds of open source software that is out there to two designers, like try and break their misconceptions of what open source is, they then are able to better understand why the developer tools for open source exist. And they then are able to start understanding that a lot of these open source developer tools and things that are created and used predominantly by developers are the foundations of the open web and how they also use the open web. And then they can better start to understand and engage with open source software as a larger concept. The second challenge really is a pretty huge one to be honest. It's the open source software isn't really part of design education or at least not explicitly so. So when you are in formal or informal education as a designer, a lot of what gets covered is not at all really code related or open source related. There even might be certain modules within your design education, again, formal or informal that actually use open open source tools or that have some kind of open source tooling within it. But the designers really don't get kind of educated or told about open source as either a set of principles as a movement as a history or as a practical kind of application that they are likely to be using. So it's absent from my education largely and it's coming more into educational practices now. So I know that I've worked with a university in West Germany in Darmstadt that do modules on open source software and building on open source software and teaching the principles of kind of open source software in us like the ethos of how you work openly. And really that's like one of the first times that I've heard an educational institution of any kind really talking about open source or openness. And connected to this issue around education is another issue, which I won't go into too much depth about, but it really is then connected to how designers go into employment. So if we're not teaching open source and contribution to open source within our educational institutions, and we're also not educating our hiring companies, our companies that are looking for designers, then even if we did teach open source within design education, when they go along to the interviews for these companies or these organizations, then the people hiring them are not going to be knowledgeable about open source either. So when they have these designers come to them with these portfolios full of maybe lots of great design contributions to open source, they're not really going to know how to digest that information and regard it as highly as it possibly should be. So what we'd love to be looking at and doing is like this synchronized effort for education within the industry and within the community as a whole. So not just within design education institutes, but within our workplaces and within our community as well, because that's how the practices and the ethos scatter throughout the whole of the design community, and how it becomes part of how we operate in general and how we engage with each other and with a better understanding. So hand in hand with education needs to come our workplaces as well. So another problem that we have is even if the designers know about open source, so maybe they really have an in depth understanding of open source or maybe they have worked on open source tools like myself, or are really really interested in the process of open source and they don't need convincing, then the fact that a lot of open source exists within GitHub or GitLab or places where repositories and projects are stored is a really huge barrier for a lot of designers and basically people that don't consider themselves technical, which is really, really toxic kind of view of things. It's one of our big problems within the tech industry in general. But basically whenever you talk about open source and GitHub with a designer, if they're not comfortable with a certain what they consider a certain level of code competency, they think that it's not for them. So that's just a place, a sector of the internet that they just don't feel included and they just don't feel like they have access to that. And often this is because a lot of the open source software projects really do require you to have a very basic level of knowledge of like how to even navigate the interface on GitHub, how do I even find where issues are if I've never been shown before, let alone try and clone a repo and then create a local instance of open source software to contribute to maybe a UI improvement or some kind of UX improvement. That's not even going anywhere near actually cloning and creating like an instance of the open source tool. And yeah, so GitHub is just really, really tricky space because it's where a lot of things happen. It's a great place and it works really, really well for some of these existing functions. But for designers, it's really, really a barrier. It's really, really tricky and really can often only be successful if you have somebody that knows the open source repo really, really well working alongside you to help you set up an instance. Okay, so another another problem for designers within open source is on the other side of things. So from the open source software side of things and when you talk to them about design. And often when you say the word design to them, they often immediately think of logos and graphics or basically user interface or visuals. So anything that you can see essentially. And this really, you know, removes a whole huge section of really valuable design practice like user experience and usability and interaction design and research led design and design thinking and discovery pieces. And all the all the stuff that is less about the visuals and less about the implementation of those actual sort of interfaces or products and actually really about how you design an experience that's right for the people that are using them. And this is actually a kind of really tricky problem because a lot of this can be attributed to a problem around, say jargon or really specific functional language. So even when I was describing some of the design functions, then some of those you might have been familiar with others you might not have been familiar with in that process of when we hear technical jargon for a function or a job that isn't our own, we can get quite, you know, closed off and scared when somebody starts, you know, really sort of talking about their jargon language. And so what we really need to do as designers and as open source projects within this problem is start having bigger and better and more inclusive conversations about what design can offer an open source project beyond like logos and graphics, and be really sympathetic and inclusive when people within open source projects do understand design as logos and graphics and really help them along with with how much more design can can offer open source projects beyond beyond those those things. But also those are also important things that are great contributions as well logos and graphics are very important too. So open source issues within a typical repo can also be a problem they can be really restrictive. So I think most of the audience at FOSS Asia will be familiar with issues or tickets or how we describe pieces of works pieces of work within repositories on our on our open source software. But they are often really solutions focused technically wise. They use again, like I was saying about design jargon, they use a lot of technical jargon or code jargon and a lot of these issues are really just not accessible to designers. So even if they might want to help on a specific part of the open source software, they might really even not know how to read some of the issues that actually are part of, you know, that section that they want to work on. And what we can do for this is make our issues a lot more friendly, a lot more informational and a lot more open to other kinds of ways of explaining what is needed in that issue. So that if it's a technical issue, it's solving a technical problem, then you can explain it in less technical terms, maybe, or in a really simple terms. And if somebody that isn't a coder stumbles across that issue, or if you think design might be able to actually help that issue and you tag it as a label, then with a design label, then a designer could come along and read that issue and say, hey, I think that there's a way that we can improve that from a different perspective. And that way you can actually grow your open source project in new and kind of unknown ways by being much more inclusive in how you write your issues. But alongside restrictive issue descriptions that are typically found within most open source issues within the repositories, when you take these issues to, or when you take generalized problems around a piece of software to design workshops and you say, hey, we want to improve this part of this product, this feature, they then become unfocused and the design responses to those problems lack relevancy. So what will be created there by the designers, and this is what we experienced in the first two design events that we had, was designers came up with these great sort of responses to solve those problems, but none of them were anywhere near implementable by the even a full time like huge tech team, let alone an open source contributions tech team. So what you really need to do with issues that you or features that you want to take to a design community or to designers for open source design contributions, is find that middle ground between a restrictive technical sounding issue and an open explorative design issue that still has the relevancy to that implementation. So you have to find a really good middle ground between these two places. A huge problem that designers have is lack of version control in both our software that we use proprietary or a lot of open source tools don't have this just yet. There are some things that are happening, which is really exciting, but our software and our processes are very removed from the idea of version control. So within coding there is this whole way of branching code and conflicts when you try and merge and there's this process of communication that is really reasonably well established within the code community. But within the design community we don't really have the technical ways of doing these things and a lot of it has to happen through communication and through almost our way of pair designing. So that we're not basically two designers working on a same issue and in conflict or that we're also sharing our resources really, really openly and collaboratively as well. So we have a huge problem around version control conflict and processes for designers to participate in open source. And one of the best things that could happen is in the future is seeing this not only within the tools that we use as designers, both proprietary and open source, but within the systems where open source software is housed. So the GitHub and the Git Labs and the places where the projects exist as well. So to move on from the many, many challenges that we tried to solve, at least in some way with our next few events that we did for the open design project, we're going to go on to what we did for the open design events. So we did a lot of research, we did a lot of investigation and we created a comprehensive set of tools and methodology and framework and approaches that were based on really robust research with people that have done similar things before. So we partnered really, really closely with a lot of organizations that have looked at things like this before or done similar activities to this before. So you're talking about your open IDOs, you're talking about your global virtual design sprints, you're talking your open source design community and things like the Hague Hacks, which is again another design event that's focused around humanitarian cases. So we worked really closely with these people that have done some of these things before to say, hey, how can we make some progress within this on our events? And we created a framework and then we did two events. We did one in Bangalore in India for the Design Up Festival, the Design Up Conference there. And we did one in Taipei in Taiwan for the Open Up Global Summit there. And we focused on the tool within Ishihidee's open source tool base, which was 10-4, the one that I mentioned earlier on, which was crisis communication. And we focused on very local events that had happened in those countries that were very relevant to the people that were coming to these events. So in Bangalore, we focused on the floods that had happened in the southwest of the country in the Kerala region. And in Taipei in Taiwan, we focused on the effects of typhoons and hurricanes around rural farming communities and the loss of livelihood there. So we wanted to make them really specific and really relevant to the locations as well as bringing the processes that we'd created as well. So what we did at these events is we did a series of different design activities. So these are what we chose as initial activities to do over a full day workshop. And they are empathy mapping within our user base for our tool 10-4 and for our use cases of floods and typhoons. We did a exercise which was called define the problems, which helps you really identify the problems that are part of the issues that you're trying to solve in the open source way. We did ideation around the defined problems that came from that activity. There was a storyboarding exercise to try and fill in any gaps and see if there were any things that we'd missed when we were thinking about our solutions. And then we looked at sketching and prototyping within the workshops as well as our final contribution to the open source. And I think one of the main things to talk about here is the pre-work that went into these workshops. So when we were constructing these workshops, there were a series of different things that we created as a team, as the open design team, in order to make these workshops go a lot smoother. And one of them was the process of taking a restrictive issue and an open design challenge and finding that middle ground. And we tried two different approaches. We tried a more restrictive, less open approach in Bangalore. And in Taipei, we tried a much more open approach but still some restrictions. And we think that we found pretty much the middle ground between testing those two different extremes. We've now found after these two events the kind of the sweet area for where you would like describe a challenge for a set of designers that would still be able to be implemented by a technical team in an open source repo. And one of the great things about the events that we held is that they were for designers largely, but they weren't isolated just to designers. So within Bangalore, we had developers, we had product managers, we had different kinds of designers of all types, all different kinds of functions, all different kinds of backgrounds participating. And in Taipei and Taiwan, we also had people that were from every section of the design community. So people that were still studying and people that had been part of the design industry for a number of years and worked on different kinds of tools and different kinds of cases as well. And one of the really big learnings from the events that we did and the way that we'd be taking the open design project further is the first one is around the locations specificness and how it builds community. So because design in open source, it's relatively new and our processes and communities, they're not structured or socialized in the same way as developer communities. We really need the design workshops for open source to be really location specific in the beginning. So this might not be the case much further in the future and we might be able to do much more like remote less location specific things in the future. But right now, as this initiative and as designers in an open source is growing, we really do need it to be location specific for the people that are new to open source. The designers that are new to open source, it really needs to make sense to them and there really needs to be that community building alongside the practical elements of contributing. So this means that the that the location should ideally be somewhere where the open source is used. So when we were choosing where to go with the open source open design workshops, we were choosing places like Bangalore and Taipei where there was a real use case for 10 for the open source tool that we were contributing design tool to. And we were lucky that 10 for in a sense is very global has a very global use and crises are kind of, you know, universal everywhere, especially at the moment we've got a global crisis happening at the moment. So a lot of we were a lot of benefit was from a tool that was very global in nature. But if you have a tool and open source tool that is much more specific to a certain region, a certain location, a certain group of people in a sense, like if it's specifically for people from Nigeria that are interacting with the Nigerian government, perhaps like open data around the government use, then it would very much make sense to hold it in that location at the very least in the beginning to grow that community and to really strengthen the community. And this really, there's a second benefit to this and it allows designers to really understand what's involved in building a team around open source and how to communicate with an open source. And the process of discussion and collaboration and sharing that is inherent within open source software and the kind of coding community that we're again beginning to explore as designers. So this is really, really important location wise. Eventually we'll be able to move to more remote processes, I think, but the moment it does really matter about making things location specific. And in Taipei we trialled actually doing a different format. So in Bangalore we did a full one day workshop where we did about six or seven hours nonstop except for with breaks for lunch and coffee. And they did that whole workshop within a day and in Taipei we split it into two workshops. So we did four hours on a Saturday within the conference. We did a remote week of activities where the teams could self-organize remotely. They were given tasks that they could do each day that typically would take around anything from about half an hour to an hour of somebody's day, depending on how they split up the different work and when they wanted to do different pieces of work. And then we did the last four hours on the following Saturday, so we had a week sprint in the middle. And that worked really, really well in a lot of ways. But again, we were trying things out and seeing what worked well for the design community. We're trying out a lot of new things within these processes. So there's a format for that as well that is again open on our repo. So first learning from the open design workshops was location specific and building community very important. The second thing is a little bit more specific to the actual workshops that you do. So inviting what we called a witness to the event. This is absolutely essential. It's absolutely critical. I actually would not have gone through with any of the events if I wasn't unable to get witnesses for the events. And what a witness is is sometimes you might hear them called users or you might hear them kind of called like users or personas. It's basically people that use the software basically in a lot of ways. But it's so much more important within the use case that we were doing which was crisis around our tool ten four. It was much more critical to call them something different to call them something more sympathetic. Call them witnesses because they were there and they witnessed the crisis and they were affected by the crisis. It humanizes their participation and it legitimizes their participation in a way that often isn't afforded to the kind of label of user in a way. So they were critically important to the workshops that we did. So we had in the Bangalore workshop we had a person called Akila come along and she had done a lot of work within an NGO with the populations in Kerala and produced a really comprehensive report on the process of the flood and what happened and who was affected by it. And in Taiwan we had two people from an organization one rural farmer that actually sadly had his farm devastated by a typhoon and a person who helped organize the volunteer response to not only that farmer but other rural farmers in the area and then organize a community group or an NGO afterwards. I can share the links for the places that these witnesses worked and the information of how to find out more about them. But they were involved in the whole process so there was briefings for them prior to the event and why we wanted to involve them and how we wanted to involve them and how we valued them. And also they were there throughout the whole event as the designers were working on the issues or on the challenges. They gave around a 30 minute or an hour long talk about how they experienced the problems that the designers were going to be solving within the open source software. So they had the chance to really speak from their own experience because that's vitally important within designing better experiences for not only commercial tools but also open source tools. And they were also there to, so the designers within groups could ask them questions at any points if they weren't quite sure whether they were on the right track with what they were designing they could validate their assumptions and they could validate their direction with the witnesses and they also were there when the designers would present their prototypes at the end so they would show what they'd created within that day for their open source design contribution and they were able to have that feedback with the witnesses and say the witnesses would be able to say hey this wouldn't quite work in this situation for these reasons and that really is the direct feedback that designers need to iterate on the things that they're doing so they're actually not only creating open source design contributions but the best kind of open source design contributions for the use case that they're designing for so what we're really trying to do is not just have a design contribution that's created in isolation but that it's created in this really user centric, witness centric and really specific to the tool kind of way so that's why it's vitally important to include witnesses and a slightly connected note as well is also vitally important that you pay your witnesses it's hugely important that a lot of these people are taking time out of their own lives and their days to be there and participate in this process so we made sure that we paid our witnesses their time or if they didn't want to be paid themselves we made donations to their NGOs or the community groups that they were organising and the link there on the screen at the moment is the brief that we sent to witnesses and the information about how we decided or how we explored the idea of witnesses within open design so the last finding from the open design workshops that we did was something that I've talked a little bit about already so translating issues into design challenges and there's an example here on the screen within the open 10-4 repo on the Oshihidi account this is an example of an issue that we took from sort of very technical issue language through to a design challenge language and this was one of the ones that we took through to the workshop in Taipei in Taiwan and this is one of the ones that works really really well and it's sectioned in different ways and it really is carefully constructed in that it has a section for describing the challenge it has a section for describing the people that are going to use that function, that feature or the people that you need to design for it also has a section around constraints so things that need to be in place for you to be able to design so this is the bit that makes the implementation a lot easier so the designers understand the limitations or the restrictions that they're working with i.e. the example is that a lot of the challenges that we were working on they had to assume that the people that they were designing for were already part of the system so they'd already been added onto the 10-4 system in some way shape or form to solve that challenge so we took these restrictive issues or these issues that were very technical and we translated them into the design challenges we still have some work to do on this really because what you can find within the design challenges is even when they are created collaboratively with your technical teams or with people that are going to implement things it's really hard to not want to describe the solution that you want or to describe the thing that you know that you can implement and it's a really tricky place to be because what you want to know within any kind of software that you can implement the solution but what you really want to do by engaging designers within this is understand whether there's actually a more valid or a more beneficial solution that you haven't discovered yet so you really want to allow for that design discovery that is not prescriptive so that you could potentially discover a really groundbreaking new way of solving a key problem that your users, the people that are using your open source might have and you can do that by engaging these designers and balancing really carefully between restrictiveness and open to design thinking and design interpretation so to move on to the outputs that you get as actual design contributions so we didn't really want to restrict people too much as to what their design contribution would be but we did suggest that one of the best things they could do is offer a prototype and to be able to offer these prototypes we internally as the open design team created a template file of 10.4 the open source software so we had a Adobe XD file Adobe XD is a prototyping tool that Adobe create and it's the tool that we use internally in Ushahidi on all of our tools so it was the tool that made sense to use so we created this template so it basically had every single screen within the tool within the live open source tool and it also had a design, what we call a design system so all the different elements within that tool and we created that and we made it available to the designers to explore and to use and to pull pieces out to redesign certain pieces of the UI, of the visuals and it gave them like a starting point because one of the hardest things to do with design contributions is not really having a starting point and also not really knowing exactly what the system the open source software system actually looks like and how it operates and if that how it operates the barrier is that you need to do this cloning of a repo and creating a local instance what this does is it bypasses that process of needing to do that and it actually allows the designers to see oh well this is how it's set up at the moment and we can solve this design challenge within our groups and contribute this design open source in an open source way by using these certain elements and we can really clearly see how it's structured so the designers would create a prototype often the prototypes didn't have to be a certain way they didn't have to be this many pages this many functions they didn't have to look a certain way or anything like that it was really to see what happened and what we could create within teams after one workshop and what was feasible within that and also to add to the kind of sort of limited timing of a prototype it was actually great to give them a stopping point as well because then the witnesses could give them feedback on what they'd already created and they could actually change things for the next iteration of the open source design contribution so prototypes are really really useful but we also got other contributions in other ways so documentation, sketches we got the empathy maps like empathy maps that were created for the different users both digital and physical ones so physical ones with post-its and paper and digital ones we used a tool called mural which I can share and we created a lot of different templates that they could use especially when they were doing a remote sprint so there were lots of different things that ended up as contributions lots of different artefacts lots of different insight, research understanding that ended up as open source contributions to this project and to now kind of move just a little bit into the future so those are a lot of what happened within the open design the first phase of open design essentially so this was about six months of doing all the different kind of end to end open design work so right through from starting the project and setting up all of our cons and outreach and starting to formulate all of the different things that we wanted to deliver right through to finishing our last event this was what we did within that time period and I've not actually mentioned it yet but it was actually funded by Adobe so Adobe have a fund which is called Adobe Fund for Design and we received funding enough for a very small team of people to deliver this over the course of around six-ish months in 2019 so the future of open design I think is really really bright and it's really really fantastic that we were able to do this project through the support of Adobe and really what we're looking at continuing is increasing and sustaining contribution to tools like Oshahedi's 10.4 but also to other open source projects as well so taking what succeeded within the open design project on Oshahedi's open source tools and really making it known that you can use that for all the other open source tools that you might want to use it for supporting a community of collaborative and peer led designers learning new skills and working together and mentoring each other we do that alongside the open source design.net community who have been doing this work for around five or six years now we really want to do more building of understanding between design and open source and we want to help open source projects better understand design and the design community better understand open source and we need to do that at the same time and as synchronously as we can so what we really want to do is build that understanding in a really compassionate way so that nobody feels like one function or one sector is taking advantage of the other and that we all understand each other's aims and goals with open source design and then bringing open design to education and workplaces so this goes alongside the understanding within the community it's about getting into those educational practices educational institutions and getting into those workplaces and making open source design contribution a part of a designer's experience as a designer and likewise with developers and with open source projects making understanding design and working with designers a part of their process to do so really what we want to do by being virtually at Fossasia is we want to build more relationships with open source projects and start to understand how we can deliver these kinds of workshops for more open source projects and build communities around these with designers and we want to build the same relationships with designers and developers globally because when you isolate this kind of experience this kind of project to one place in the world is where a huge failing can occur especially when you've got open source switches used across borders so lots of open source tools are multifunctional for lots of different kinds of people in lots of different countries and it would be absolutely foolish of us to not want to grow the community and engage with people everywhere and not just in the places that are convenient for people leading these kinds of projects and initiatives it's really a global initiative it's a global need as well to participate with everyone in this process so you can find the open design like open stuff on this link here the github.shihidi.com so it's got the methodology there it's got all the frameworks that we use to create the workshops it's got the processes it's got a lot of our learnings a lot of writing and articles and a lot of our positions on certain things it's got a whole lot of interviews that we did and all the research that we did before we conducted the workshops as well so if you want to contribute to any of the things within the open design project as well it's fully open and you can do a pull request for any of those pieces of information and you can fork that repository and modify it however you see fit and use it widely, use it energetically and use it in the ways that you think are best and lastly if I can leave you with the link for the community of designers with an open source which is the opensourcedesign.net community so this is where designers that have had an interest in open source collect and congregate and communicate for many many years now and I'm part of the core team there I lead some of the meetings and I do some of the sort of welcoming new people there and coordination but there's a whole load of amazing people that also coordinate and lead this group so you can find a lot of those core members within the forum that's on the website and you can also find a section on that website where maybe if you're not quite sure what your first design issue should be or how to engage with designers you can add a post on the forum the discourse forum on this website asking for support so anything from oh we actually know that we need a logo or a set of buttons or we need some UX help or we need some user interviews for our open source tools and we'd love a designer to help us with those right through to we're actually not really sure how we can improve this tool but does a designer want to take a look or does a designer want to have a synchronous pairing session where one of the developers, maintainers of an open source takes them through the tool and they can do some feedback there's also some great first design issues that I can suggest and I have a Twitter thread on so again if you want to know what some just good first design issues that you can create are that are very exploratory to sort of test out the waters of design engagement then please find me on Twitter you can find my Twitter handle on the bottom left hand of the screen there at Errol does design and you can find the open source design team at OpenSRCDesign on Twitter as well so I'd like to thank the Fossasia folks for screening my talk I hope that you found it interesting and informative if you want to talk more about open source design open design any of the things that I've talked about throughout this talk then please contact me in any way that is most comfortable for you I'm on most channels and I believe we'll be doing a Q&A as well so thank you very much for listening and now I must find how to stop the recording so thank you very much, bye bye