Making More of Open Source

Unknown Speaker 00:00
Though Welcome to our session making more of open source. I'm Greg Albers. I'm joined here, joined on the panel here with Megan Forbes, from collection space and lyricists, and Ellen Martin from Definity. And we're all going to be talking about open source software. today. I'm gonna start with just a bit of a intro, and I'll do some specific stuff, and then we'll kind of pass the mic down. We're going to try to leave a lot of time for questions and discussion afterwards as well. So with that, without further ado, let's get into it. So this this session really is a kind of a follow up to a session that I did last year on MAP project that I did called mapping open source in museums, where I looked at museums on GitHub. Who was there, who was there, what kind of activity I couldn't kind of data mined from that. And if I could see any kind of any evidence of sharing of open source software like what what did the sector look like? What did the environment look like the ecosystem of open source open source software museums and and where we're sharing where we're reusing this material? Or how, what were we doing? I did some updates to that data for now. So that website that was just up, sorry, the website is g albers.github.io/mapping-open-source. So that website, I've updated it with newer with new data from from this, this coming this year now. And a couple of bits about that, that I wanted to point up, point out. So these are these two graphs show museums joining GitHub. So last year, when I was looking at this, if you look at the graph on the don't know, my left and my right, my left, you can see that back there, we had very few museums joining in 2018, there's a kind of a big drop there, the updated data similar, like the sort of shape of the of the graph has changed, mostly because I found more museums, some of which had been joined GitHub earlier. And so we kind of added old data. But the basic shape of the curve there is not changing. There's a very big spike in 2015, for museums joining and then it's really been a downhill down sort of slope from there. And I could posit that that's going to be that's maybe we've saturated the market or that GitHub has gotten as many of us iums largely as as it can. Now that should be taken with a grain of salt, because the museum's that I've mapped on GitHub are only ones that I've happened to have been able to find. So that's, you know, knowing people that are there, having lists with it's compiled from a number of lists of other people who put together over the years, and then just going around in searching museum on GitHub and see if you can find user. So there certainly could be more there that we're missing. But I think that it's fair to say that would probably like there's there's certainly saturation. And in terms of the repositories of the projects that were being created. And GitHub last year, again, we saw this sort of drop in 2018 is sort of a steady rise in projects in GitHub. And then in 2018, there was a little drop. But now looking at that data and 2019 Actually 2018 is at went back up again. So that far side of the graph, the far right, under the 2019 version, that's 2019 projects starting. So those are lower again, but I think we'll see if I was gonna do this a year from now, I think we'd see it come up. So I think a lot of museums are on basically a lot of museums are on GitHub, they're adding an increasing number of projects there that are and these are all public projects. These are things that museums have put up and left open for others to go and use or look at, in various ways. And there's certainly more museums and more projects that are being kept private that museums are just using as they're developing work.

Unknown Speaker 03:36
All in all the right now and 2019, we have identified 158 museums on github 18 145 public repositories, which is a huge number of projects, I think, you know, we had, there's a list of them on that website that I did, where you can just kind of start scrolling all of those projects in the descriptions, and you scroll and scroll and scroll and scroll, and it's a lot, it's a ton of things. And also all of that the 18 145 repositories in there are over 3000 contributors. Certainly more contributors than there are working in museum technology. I think a lot of that it's, you know, people museums are bringing in open source projects, they're they're reusing things from outside the sector, and the country country, contributor count is going up as a result. I talked about the kinds of things that are in there and others 18 under 45. There's a lot there's so I just grabbed some names from the list. There's a helper class for drawing an animated sine wave into a canvas element might be helpful for you. I don't know cover for closing a logic duel, which I don't know what a logic tool is. Someone might our internal front end boilerplate, a tool to download and store data and images Drupal module for generic to Verna workflows and SIdora. A lot of names there Kiosk App wrapper for museum media exhibits file storage for email signature images, and app to backup photos from Flickr and Aptech for collection for collecting gallery reading data. So there's actually I think some of those some of those I put in because there's Funny and made me laugh. And I like words. But some of them actually sound like I can see that other museums might have used for some of that information. But I don't think we're seeing, we're not necessarily seeing that reuse now. And I think that not not being able to see reuse, and this all of these repositories, all these projects that are being posted to GitHub, I kind of think that that's a case of that. It's we're using GitHub as sort of passive open source. So it's the idea that we're putting up there, we're leaving these repositories open. Sometimes we're putting a license on them, sometimes not. But we're not really doing anything to help develop or grow or help grow that software, or help other institutions find and use that software sort of more explicitly. It's more like if they happen to find it. Or if I want to talk to him, maybe if I share it directly with someone, then they'll then they'll use it. So that's what brings us here today is really the question of how do we make more? How do we take this sort of passive, this huge repository of what could be actually useful code contributions that other museums might be able to use? How do we take that to the next level, if we want to, and make some of this useful, make it discoverable, have other institutions and others outside of the sector adopt it more. And so that's today's topic, today's topic. So I'm going to start out by talking about some GitHub, GitHub, sort of following up on my work looking at GitHub museums on GitHub, I'm going to talk about some GitHub community tools, then Elena is going to talk about Mozilla's open Leadership Program. And then Megan is going to finish this up with it, it takes a village guide book that she worked on through lyricists. So we'll go from there. Alright, I'm gonna put on a timer for myself at this point. So I don't just ramble too long. And because I do want to make sure we have room for questions at the end. So terms of what I do, I'm in the digital publications manager at the Getty. So I work in the print publishing department, we have a robust print publishing program, and I started at the Getty six years ago ago, to kind of figure out what it meant to make that digital. One of the things one of the sort of our core projects is what it's a thing called choir, which is an open, it's a multi format, publishing software that we're building to use. And we've been using it internally for many years now, to publish online books, but also those books come out in PDF and ebook. It's really we're looking for books, looking for a website tool, or web publishing tool that would bring sort of some discoverability, and some longevity to these digital publications projects that we're building. So we've been using it for a while, we always intended to or we always wanted to make this open source. But we were kind of thinking originally like, kind of more of a passive open source, like we'll use it, we'll, if it works, great, we'll put it out. And maybe someone else don't want to use it. But now it's we're now we're taking that a step further, and wanting to really do something more explicit. And so we're working with our internal digital team. And we're in the process now of hiring for a two year period, a full time developer and a full time community manager to help take choir and kind of make it into a fully fledged open source project. So far, we have about 100 people in our beta using it various institutions are are testing and some have actually published some works with a beta version of choir, which is great. But again, we're looking for ways of continuing that growth. So that's kind of what I'm what I'm doing here today, what brought me into the sort of these questions about open source and museums.

Unknown Speaker 08:22
So GitHub tools, so GitHub is a place where where a lot of people share and work, and share code and, and share projects. GitHub has some built in sort of tools that we can use to help community use and adopt those products. And any repository, any project on GitHub if you go to github.com/then users name and then slash the name of the repository of the project. And then slash community, there's this little community, sort of profile bar or, or a profile that's looking for a variety of things. And I'm sorry, this is small and small on both of these screens. But it's looking for certain documents inside that project that will help contributors, help contributors use, use that software, understand and use that software. So you can check out this if you have if you're hosting GitHub projects yourself, or if you're looking at GitHub projects that you might want to adopt, you can go to the community profile and kind of see where see where they stand. And I'm going to go into more detail. That profile that Community Profiles looking for certain certain files inside your project. And these are what they are. The first one is called readme and the.md. If you're not familiar with it, it's just markdown. It's a plain text file format. And so this is this sort of all capitals naming and then the.md Is this sort of convention that GitHub uses to to store information inside a project like this. So read my README file supposed to answer a few questions. What does this for someone else not for yourself? Well, maybe for yourself, too, if you've forgotten if you've written software and then forgotten what it does. You want to go look at your own reasoning, which is the thing that happens, it should say, what does this do? What problem is being solved? How does it work? So this is the sort of introduction to To the software that someone's looking at, then there's a license.md file. So that would contain what license? Is this being released under? And so open source, you can put something on GitHub, if it doesn't have a license, technically, it's not yours to use. It's, it's open, it's, it's there for you to look at. But without an explicit license, you're you shouldn't necessarily take it into something you use in production, in sort of an institutional sense, certainly. So a licensed viable, more explicitly tell an institution or someone else looking. What exactly can I do with a software? Are there limitations? Do I need to give anyone credit? Or how do I handle that support.md This is actually a newer file that just started a newer kind of thing that GitHub is looking at, it's basically answers the question of what if I need help? Like, what do I do if I need help as a user? So the support.md file is a way of of pointing users to discussion forums or help lines or wherever they need to go to find help to use their use that software. Next is contributing.md, which answers the question How can I help? So if I want to contribute to this, this project if I want to adopt it, but I also want to fix it or add more to it? How do I go about doing that? What are the standards that I should follow? And then the code of conduct? And that's sort of I'm part of this community, if there's many contributors, many users using this, how are conflicts resolved? How are we how are we working together? Over on the far side there, there's a little pop up box is that with these files in place in your GitHub repository, GitHub itself will actually look at those files and add little sort of helpful tips for users as they're logged into the site, they'll say, Oh, if you're, if you're looking to use a software, and there's this, you know, be sure to check out the readme dot file or whatever, and they can point you to it. So GitHub is looking for these files as a way of all augmenting how it supports the community around your project. So these, those things basically split up into two categories. One is if you want people to use your code, those first three documents are really helpful. And if you want people to help write it, the second documents are helpful. in museums, in general, looking at those repositories that we identified, 75% of them already have a readme, 43% of them have a license.md. Very, very few do anything beyond that, like very, very few. And actually the the ones that are there, the two and 3% on contributing and code of conduct, I went in and kind of looked at a bunch of them, to see what they were and a lot of them are sort of boilerplate things that they're kind of copied over from another thing, or you could tell that they were they're not necessarily really engaging like a contributing a contributor would would be. So that's kind of where we're standing in the standard museums. I mentioned this table on that project that I that we put together on the map mapping open source museums. So there's this Tate open, there's a table of all of the repositories that were identified, this is a great place to go. And I would love to feedback on it from anyone, if you go and look at this, if you'd like to see more information there, if you think it was something else would be useful. I feel like if we had a place where we could collectively share some projects that we're doing and some source some places, we could go to see what other museums are doing in this or have done rather in code, it would be great. So that's sort of nascent version of that little plug. Okay, GitHub, user issues. So

Unknown Speaker 13:12
GitHub also has issue tracking. So one thing we can do to help help people bring people along into contributing to open source software is to really think about how we how we share and how we post issues about that software, when there are bugs to do or Bugs, bugs to be fixed, or things features that need to be built. There's certain ways you can do that in GitHub with issue tracking. But the one I wanted, once I want to talk about it are these issues that are called that GitHub is looking at specifically that are default issue tags that you can say good first issue or Help Wanted. And these are good ways of encouraging contribution, because GitHub is looking for those and can help will help promote your site, if you've got these things in there. But also contributors coming to it, they might want a small bite sized piece of thing that they can contribute to contributing to code to your contribute documentation to in your project. And using this issue labels is a good way of helping helping nurture that. Thinking about contributions, that kind of last point I wanted to make before I pass it on. And we talked about some things that are not just GitHub and not just code, but also more broadly community related. Our contribution, the idea of contributions to code, GitHub, when you're working on a project, and you're hosting and and GitHub, GitHub is aware of every contribution and who it's been to that codebase and who it's been made by. And it's tracking that. So if I make some commits, there's a screenshot of one of our projects, that choir project, actually. So when I every time I make a commit or a change, it shows up here, it's sort of added into that and they can graph that participation. The thing that I think GitHub doesn't do really well is acknowledge other kinds of contributions. So as you're gonna you're gonna hear in the later part of the talks here, software, you know, building open source software, it's not just about writing code. It's also about documenting that code and getting funding for that for that project and writing tutorials and training and doing workshops, and designing the logos and everything is involved in that is a big community of people. And GitHub really only tracks. People who, who put code contributions and who actually write code into the thing into a project like that. So, aside from GitHub, I wanted to kind of give a shout out to this project called all contributors.org, which is a website you can it's a little bot, you can plug into your repository on GitHub, but it really tries to capture different kinds of lets you gives you a way of capturing different kinds of contributions to code. So this is the different types of contributions that and I just said a few of them, that it will help you track. So answering question is someone who answers questions on your forum, someone who blog posts about you about your thing, someone who's just gives you ideas, or help builds infrastructure, who does a talk or tutorial or writes tests or designs, writes content or documentation of any kind, all of that is about as it is sort of involved in building code and writing open source code and, and getting people to use it and all contributors.org is a great way of trying to start to to capture that. Alright, that was a lot. And I'm gonna pass it on now. So these are my last points, just add Community Health files is, I think, a positive thing to do, right and label bite size issues to encourage people to start contributing to your to your software, and then credit them when they do. And thank you very much. I'll pass it on.

Unknown Speaker 16:29
To me or to Yes, to me. Okay. I think the sun Yep. Okay. Hi, I'm Megan Forbes, and I'm the co director for the it takes a village open source sustainability project, and also the program manager for the open source collections management system collection space, both of which are housed at lyricists. So just talking about, it takes a village today, and I will say I didn't name the project. That name came in, then I came up with a project so sorry. So so the first thing I want to say, we see the word sustainability a lot in a lot of different contexts with a lot of different meanings. So today, when I use it, I'm using it like in a really specific context like the it takes a village sustainability framework context, that context is sustainable software is that which is viable and effective for as long as it's needed. So there are many other definitions of sustainability. But this is the one that I'm talking about today. I'll follow that up by saying that sustainability does not equal perpetuity, so viable and effective for as long as it's needed. So it doesn't mean that everything lives forever, it means it lives as long as we want it to when we need it to. So just talking a little bit about sort of how it takes a village came to be so there is a large and growing body of open source applications that support cultural and scientific heritage organizations, in collecting, organizing, preserving disseminating our content or information, right, you might be using Omeka, or Drupal, or you know, any of these million projects that are out there. So some programs have been really successful at creating robust products with widespread adoption, engaged communities, again, looking at something like Omeka, while others have really struggled to determine what's going to work once that grant funding or institutional support runs out. So when this project was proposed to the MLS in 2017, there was really no standard method for folks to evaluate or think about or plan or have discussions about LSS sustainability. So we wrote this grant to the IMLS, we had a couple of intended outcomes. So we wanted to just survey the program, some of the major programs that are out there, because this came out of lyricists, lyricists has primarily at the moment in academic library library audience that were sort of biased in that direction in terms of the programs that we surveyed. We just wanted that kind of baseline of information about program size, financial health technology, stack technology, roadmap governance, we held an in person forum where we brought together stakeholders from all these different applications, so that we could talk about sustainability, what does it even look like? You know, how do we talk about it? And then we wanted to create a guidebook that would help people move along the sustainability path. So from an unsustainable, hopefully to a sustainable application. We also wanted to increase awareness around sustainability. You know, it's like increased awareness. But it's really often we see it in grant applications. It's an unfunded mandate, and a lot of grant applications. What's the sustainability plan for this thing? And people didn't have a great way to answer that question. So we wanted to help with that. And then just create a space where people could meet each other and talk to each other and find out hey, there are people that have the same problems that I do. And I thought I was alone in this and it turns out I'm not. And so that was a really great outcome of our in person meeting. So project leadership was comprised of lyricists, staff advisors from me Demmick institutions and other nonprofits. And so we had a pretty diverse mix of programs who responded to our survey joined us at the forum. So 27 programs total. So some people might be familiar with like specify, which does specimen management for museums, locks, which does digital preservation Omeka. So that that gang all came, and we had about 50 people come, again to talk at this meeting. So so the results of both the survey and the forum were really, really clear. So the first was that sustainable programs tend to grow from projects that were direct responses to community needs, rather than programs that started with somebody had a really cool idea, and then later thought that maybe they would find somebody who was interested in it.

Unknown Speaker 20:47
Also, sustainability is not a thing, you can't say, yes, now my program is sustainable. Or if I solve this one problem, then we will magically be sustainable. It's not one thing, it's not a straight line, it has facets, they move in phases, they move together, they move separately. There's a lot going on. So we published this guidebook, last year that sort of walks through all of it in great detail, but we're just going to really kind of talk about the highlights today. So three general phases of development. So getting started, this is programs that are in the early stages, planning, design development, the work is often grant funded or has sort of one strong institutional supporter. And the work is sort of exactly what you said you would do in the grant, you know, you're not thinking outside the box at that time, staff are usually pulled from initial stakeholders. So I'll say choirs moving now into growing, right, they're hiring staff, they've got public releases, growing is really big, right, this is where a project can take off and become sustainable, or stall out and go away if they can't really take root. So this is sort of when we're really trying to transition from that grant, or institutionally funded project into a sustainable program. And then stable, but not static. These are programs that are mature, they're established. But it's really easy to feel like at that point, you can coast. And so we'd have the stable, not static, because you need to be really vigilant to ensure that complacency doesn't set in. So things are going well, but you want to make sure they continue to go well. And then there are four facets. So there's phases, and there's facets, all wheels within wheels. So governance, is about establishing a model in which roles are defined for project participants supports that process for strategic and tactical decision making, right? Like very shortly how to decisions get made. That's sort of your governance. Technology. So you know, as Greg said, technology is but one slice of it, you know, we're talking about open source software, there are parallels with proprietary software development, but added challenges because of all these other facets, right, you have community, you have governance, you have resource constraints that you might not find outside the open source world. Resources, OSS projects need human and financial resources in order to grow and thrive. And so on the human side, right, that's everything from code writing, community members, colleagues, organizational homes, and then all the money going in and out on the financial side. And then the last facet is community engagement. So this reflects both efforts to foster involvement within a community. So we want our users working together and talking to one another, really participating in and championing the work. And it also includes communicating to the world outside about the project. So you know, who are the decision makers out in the world who were the funders who we want to be telling about telling our projects about telling. So then, within the guidebook, what we tried to do is create a resource that would help projects move forward along this path to sustainability for each facet. So within the book, you know, you flip to the part about governance, you feel like that's the part you're not doing so well at so you flip to governance. And you might see characteristics. So where am I am I in phase 1am, I in phase two, your Phase One in tech, maybe you've never had a public release, you're at phase two in resources, maybe you're hiring some dedicated program staff, you know, you're not 100% grant funded anymore. Then we talk about concerns, right? So all of those things that are sort of nagging you and you feel like maybe they're keeping you from moving along. So like governance, it adds so much overhead, or why is our community so needy. So all these various issues that you might have. And then moving forward is basically how to sort of overcome those things. So finding the right balance of governance or expanding your income streams or you know, figuring out the best way to engage with your users. So that you continue to move along that path. The next steps for it takes a village. So we have applied for funding for a second round from the IMLS. So the irony, of course, is that it takes a village itself is not financially sustainable. So we applied for some grant funding for round two

Unknown Speaker 25:01
And then we're looking for. So we have the guidebook and the guidebook is nice. And it gives you a framework in which to sort of think about it and talk about it, which people didn't really have before. But now we get a lot of feedback saying like, Okay, but what do I do? Like, how do I do it. And so we're trying to develop really concrete exercises that you can like, literally print out and go through with your team, with your community, to sort of help get you into that sustainability mindset. So it's not something that would necessarily take the place of something like strategic planning. We sort of think about it as like a layer. So when you're thinking about strategic planning, and when you're making those decisions, like we want, it takes a village to be the little angel on your shoulder who's like, what about sustainability. And so you just sort of think about those things as you're planning along. So an example of one of our exercises, and just because it's a fun one. So for governance, again, how decisions get made one of our favorite activities called catastrophizing, where everybody in the project takes a big whiteboard, and you write down like all the truly awful things that could happen. And or really, you know, there had to be catastrophe. So here we, you know, say choir, Greg wins the lottery, and he moves to a, you know, you move to an island and they don't have the internet, they're, you know,

Unknown Speaker 26:13
so long.

Unknown Speaker 26:14
So I'm getting, I don't need you anyhow. So you know, right, we try to say like, right, I know the traditionalist to get hit by a bus, but wouldn't it be nicer if he moved to an island, when you're not hitting me with the bus, right? So, so this is a really good governance exercise, though. So here, we have the choir project, you've moved to your island where they don't have the internet. So like, how would that work? Like, can choir keep going? Do people know who to ask if Greg is gone, and I presume, I don't know if you're actually the program manager for the project, and assuming, you know, but so you know, figuring out what's the right amount so that we can sort of weather some of these catastrophes we can move on from them. And so it helps to get some of those examples out there. And it's also something you know, we try to make it strategic planning and writing your mission and writing your vision can often be sort of painful. So it takes a village, we try to make it more on the fun side of life, you know, we all are doing this, because we want to be doing this. And so that's where we are right now. So we're in that sort of funding, you know, IMLS, please give us some money. So if anybody's grant reading for them, just keep that in mind. And that's it. So that's it takes a village. You can of course, download the guide book that's, you know, freely available lyricists at org slash, it takes a village, you shoot me an email, obviously, I'll talk about it all day. So I'm happy to answer any questions that you might have, if you have a project that you know, needs a little help launching. We're there for you.

Unknown Speaker 27:40
Thank you. And I'll say to when we'll put back up but the we have all the links in the slides as well, at the end, there's a bunch of links that you can get to and there'll be Oh. So the links are in the slides, and we'll in there we'll share with you when we get to the end, again, the bitly, that will get you to the slides as well. So you have all that information, which is

Unknown Speaker 28:05
fantastic. So you've heard a little bit now about some tools that you might want to use in your open source journey and some kind of models for thinking about where your projects might be and why where you might take them to more sustainable place, I am going to share a few lessons learned from I guess, to use the terminology, we just learned to stable but not stat but not static project called Open Data kit and some possible resources for you to take things to the next level through the Mozilla open leaders project. So my name is Ellen Martin, I'm a committer. On the Open Data kit project, I work for an organization while I am part owner of an organization called called affinity. And I am not directly museum affiliated. So Open Data kit is a series of tools that replace paper forms with mobile devices. So again, I'm not directly museum affiliated, but I know these tools are used for in various museum contexts to do things like catalog remote artifacts, and to engage with users within a museum context. So actually was looking at the program and seeing that, in the next hour, there are a couple of sessions about getting live feedback from users and engaging in a dynamic way with users. Some museums use these tools to build custom forms that will allow their, you know, their I don't know if you call them users, but their visitors I guess, to to engage with whatever exhibits you have in a different way. So we have tools to build forms to collect data and to aggregate results. So to give a little bit of context on on this project, and you know why I call it stable but not static. So it's been around for about 11 years now. 2008 was when it was founded. This is a university project. So not again quite the same as During museum context, but pretty similar, right, I guess some of you are probably from academic libraries where it's very, very similar grant funding lots of access to students who are considered free labor, right? Of course, they're not. So they get paid somehow. But that's kind of the way this project was jumpstarted. Between that start and 2016, it was maintained by U DUB staff and students and kind of, organically, you know, as as, as some of the other panelists have said, when there's a need things happen. There's a big ecosystem that emerged around these tools. So there are now tools that are compatible to do analysis in different contexts to do data collection on computers rather than mobile devices. And these are all maintained by people that I have never met.

Unknown Speaker 30:49
And in 2012, is when Definity the company that I'm now co owner of was started, I wasn't involved at that time. But it was started as a services company. So it was offering consulting services on top of this, of this set of tools. In 2017, the project, well, you know, the research group, you'd have moved on. And so the project had to sort of find a new home. And that's when I joined the funding, and we decided to say, we can be that new home, we'll, we'll be kind of making sure that things move move forward and the project that somebody is at the GitHub repository triaging issues, that someone is thinking about sustainability, and making sure that there are folks to carry on the work. So that's why I say maintained by community, you know, there's always the dream that, oh, there'll be this great big community of a bunch of people who show up and do the work. But in reality, it's our small consulting company, that kind of keeps it going. So we do a mix of services and grants to keep it to keep it going. We consider that a form of sustainability, although, of course, it's a grind, you know, we always have to make sure that we have funding to keep ourselves going. In 2018, we took a big step towards being more community oriented by having a Technical Steering Committee. So this is the governance that we heard about is how do we make decisions. We formalize that by having folks from a diverse set of organizations sit on a board and help steer the software on a day to day basis. I also participated in the Mozilla open Leaders Program, which I'm going to tell you a little bit more about. So Mozilla open leaders is a program open to any kind of project that wants to, to work openly. It's 14 weeks of training and mentorship on broadly open practice. So it's helping answer the question of how do we make decisions and create artifacts publicly, that could be software, but it could also be guidebooks are various kinds of, again, collaborative projects, it's cohort based, so you have a group of people working on very different projects are getting together and talking about these issues. You get mentorship from someone who's, who's previously participated in the program. So someone who is working on an open project and can share their experience. And then you get practical experience, the kinds of exercises that Meghan was talking about, actually doing it and having a little bit of social pressure to get it done, right, because it's one thing to say, we're gonna do a catastrophizing exercise one day, and it's another to have a mentor who's going to say, hey, so you said last week that you and your project members, were going to do this exercise, did you do it? So to me, that was the real value of this program is just someone's watching over your shoulder and actually make sure that you're not, you know, pushing governance and sustainability and all these things that make an open source project thrive to the next week, and the next week and the next week, it's very easy to do when you're really focused on your artifact, right? Your museum probably has a need yesterday that you need to fulfill. Why do you all this community building, the positive effects are probably further out in the future. So Mozilla kind of describes the program in this way so that open leaders design and build projects that empower others to collaborate within inclusive communities. So the idea is to take all these awesome tools that your organizations are already building, and adding as part of the process, bringing others in and making the community a little bit broader so others can benefit from your own understanding of your communities and the tools that you're building. There are links throughout and as Greg said, there will be an easy to jot down link that gets you to all of this. So the framework that Mozilla uses, is that idea that any community project an organization can be open with these three characteristics, understanding, so making sure that the work is accessible and clear, making sure that your GitHub page has a readme or someone can actually know Oh, what is being built here? Right? There are wonderful projects that just say, builds widgets, and you're like, Okay, well, you know, and you never know what it is.

Unknown Speaker 35:10
It promotes sharing. So that means that the work is easy to adapt to reproduce and to spread. So again, you might have a beautiful description of what your project is. But if nobody can actually run it, then they can't make use of it. So emphasizing sharing from the start can ensure that, that that work is available to a broader group of people. And then again, emphasizing participation and inclusion. That means sharing ownership. So even though you're focused on your museum, your organization, there might be others around the world, who would like to participate and could bring really great value to whatever you're building, if they also had a little bit of recognition, maybe in contributors, and a little bit of ownership of what is being produced. So these two dimensions I talked about, and Mozilla puts in this kind of grid of as we're developing an open community, we can design build an empower, for understanding sharing, participation and inclusion. So I think this fits in really nicely with with what Meghan shared, you know, we can see she was talking about governance, we can think about that as designing for participation and inclusion, you know, if we have a clear decision making process process that's in the open, then we're more likely to get other organizations to participate. So I encourage you to take a moment, if you're interested in Mozilla open leaders at looking at their their framework, I think it gives you a nice sense of how you can evaluate your own project for how it is doing and an open, how open it is, and then make progress towards being more open. I mentioned there are a lot of hands on exercises that we do throughout the 14 week long mentorship session. And one of the tools that gets used is this open canvas. It's adapted from the Lean Canvas Oh comes kind of from a startup mentality. But it's it's a very simple, but powerful tool for organizing one's thinking when you're trying to make progress towards a more inclusive project or more open project. And we're looking at what problems do we have? There aren't any contributors, it's just me at my desk doing stuff, you know, you can kind of go through this process to get insights on how you might, you might solve it. And the real value I think of doing the open Leaders Program is someone's looking over your shoulder saying, Did you do your open canvas for this problem that you identified? And are you going to actually put some of these great ideas that have emerged into practice. So as they went through this program with again, are pretty mature open source project, I found a few targeted prod projects that I could work on. One of them was providing greater visibility into roadmap, I think this is a really common problem that open projects have is that there's a lot of context that people have in their heads that the programmers have in their heads about where they're going. And you know, what they think the next feature is going to be. And it makes it very hard for others to engage even as users if they don't know where things are going. So I had definitely identified that that wasn't a problem for open data kit for our project. And what I ended up doing with the open Leaders Program was building a process for roadmapping. And making sure that that was always available and up to date. So we used a GitHub board for that. And you know, it's simple Kanban board kind of things, but we've committed to keeping it up to date, and to making sure that the Technical Steering Committee reviews it on a bi weekly basis. And that way, users have a lot more visibility into what's being built.

Unknown Speaker 39:00
Another thing that has really worked very well for our community, and that I also did some work on during the open Leaders Program was using our discourse forum to provide again, more visibility and more sharing with our community of users. So if you're not familiar with discourse, it's a bulletin board kind of message board, software, piece of software, it's open, source free, etc. It's actually it offers free hosting for open source projects. So it might be something you're interested in. And to me, it's really the missing part in in GitHub. So GitHub is great for I found this bug, Greg, can you fix it for me? Or, you know, I'm going to fix it myself. But it doesn't provide the greater context. It can through things like roadmapping, but it doesn't provide the, you know, Hey, Greg, do you think that we should be going in the direction of publishing our books on watches? You know, that doesn't fit well in a GitHub issue. But it fits really well in this kind of freeform discussions. Same thing with support, user support doesn't fit so well and GitHub, people file issues, but it gets lost in the shuffle. Discourse is really, really great for that. So one of the things I did with open leaders was, again, getting some process for where things should go, what categories we should have, and making sure we had a really vibrant conversation going on about the tools, and so that everybody could kind of stay up to date on on what's happening. So, you know, I think of museums, I'm a user of museums, I'm a lover of museums, I'm not a contributor to museums, yet, maybe I will be. But from my perspective, I think of museums as a great public goods in our community. And open source can also be great public goods, right software that anyone can pick up and change has the power to be tremendously valuable. So I think it's a really Nash natural combination. I'm a little bit sad to see Greg's analysis that it looks like people are just throwing things out there passively, and not finding ways to, to collaborate. So hopefully, some of the tools that we've shared today will, will give some ideas to move in that direction.

Unknown Speaker 41:09
Thank you. Alright, so I think let me move to that slide that has that link. So you guys can grab this, all of them if you'd like them? And does anyone have any questions? We can? Do you have any? Does anyone have any questions? I'll just leave it there. Otherwise, I'm gonna ask you all questions. Alright, so the link is a Bitly. Link bit.ly/more-of-o. Open, more of open. So that will give you the slides and the slides have all the links. I'm curious, just in the room, if I could ask you all in the room is anyone who here is sort of putting things up on GitHub yourselves? Like who's doing that work? Who's putting one hand? Two and a half? I'll give you a three. Okay, so it's not that many. Right? So that's okay, good. So what maybe? Now I want to ask you all all kinds of things. Now that I know that. Let me start here. Actually, Megan, I had a question for you. You said sustainable programs grow from community needs? Do you have any and so and one of the things that I you know, one of the things that we see or that I feel like seeing on GitHub and museums use of GitHub and throwing the projects up their repositories is that we're, we're first responding to our own needs internally, right? We have projects, we have things code that needs to be read, we have functions that need to be done. So we do that, and we put it up there. Can we reverse engineer? Do you have any other? Do you have any sense of other tips for this? And when you can answer this as well, for going back and saying, Okay, we've done all this work? We did it anyway, we're happy to share it. Can we go identify if any of these actually meet a community need? In which case, then we can maybe put some more energy to it? Like, how would you go about reverse engineering, rather than starting from the community, but rather trying to match a community with existing something?

Unknown Speaker 43:11
I think this community should have a discourse.

Unknown Speaker 43:13
Well, that was my answer, like here, here, everybody is. And so I think, you know, thinking, you know, I know that MCN made changes this year. And so that's something to think about sort of moving forward is like, here's the OSS, you know, Scrum room, and people are going to come with some of the tools that they have, and they're going to talk to people about whether they're useful, and what might make them more broadly applicable, you know, how do I turn this from something that's useful only at the Getty to something that's useful everywhere. Because that's really what it's about, it's about going out and talking to people and finding out what the needs are. And then right, seeing if your tool can can support those. And so you know, conferences are such a nice place, because here we are, you can actually talk to people face to face in groups of them even. So, yeah.

Unknown Speaker 44:02
I think it's also really valuable just to bake that into the start of a project. So I think with the with open data kit, one of the things that has made it an ongoing concern is unusual for a research project to last 10 years or to last more than a few months, really. And I think one of the things that makes it different is that it was developed with field partners. So in this case, it was the Jane Goodall Institute of I think World Health Organization, but a few folks who had very clear data collection needs in the field. And so they became the champions and so I think as one of your organization's is thinking about building custom software, you can right away say, Well, hey, you know, I know folks at this museum and that museum and that museum and why don't I just contact them and see if they're also interested. I think it sounds obvious, but it can be hard with funding to make that work, but it can really pay off.

Unknown Speaker 44:58
That's one thing we talked about a little bit the fun ng model to me we can chat about that a little bit. This is what are the models out there? So Ellen, you're using a services and grants combination of things is that common, and they're seeing that a lot and other other options that people could be thinking about in terms of sustaining their, or sort of finding funding for a project that maybe started as an internal museum project and expanding it out into the world. What should people be looking at?

Unknown Speaker 45:26
either. So yeah, services super common. The other probably biggest model that we see is membership, either membership or sponsorship. So bigger in academia, where you kick in, you know, so I want Fedora or, you know, big institutional repository. I want Fedora to last. So I'm Stanford. So I'm gonna give them $20,000 a year, I get a seat a governance, you know, and I'm ensuring that that software is going to live a long time. So I would say yep, services grants, I mean, almost nobody is completely grant free. So people can often get to sustainability for like operating expenses. But if you want to do something else, so this bit of the software is going to is end of life thing. We need to replace it. That's almost always grants. And you have services is very popular.

Unknown Speaker 46:19
And I used to feel uncomfortable about grants, because it doesn't feel sustainable. But then I realized that, you know, at least in our sector and global development, and I think it's, it's true in the museum space, if you're doing services, a lot of the services are grant funded, probably as well. So might as well just go to the store.

Unknown Speaker 46:37
The middleman. Exactly. No, that's exactly right. What else? Yeah.

Unknown Speaker 46:44
I just wanted to read during this talk, by the way, community is worse, because we have all of our code repositories. Is it? Okay, for now? Yeah. But yeah, they're solving all the problems we have at our institution, wherever our big brand. But it takes effort to change something from like a custom piece of software that solves my problems, and suddenly, are probably useful. Secrets and like, there's big elements that you would want to revisit. Like if there was a place to go to know, though Hey, like, other people might be interested in this piece of software.

Unknown Speaker 47:22
Awesome. Plus one noted, thank you. That's great. Yeah, in the back.

Unknown Speaker 47:28
We talked a bit about not just the financial sustainability, technical part of it, like, how in the planning stage, you're not those situation where you have a migraine distributor, and then a computer later, turnover, separate, it's gone. Nobody else is making that.

Unknown Speaker 47:46
Yeah, that's a good question. That's something I'm looking back to David Newberry, sitting in the back. He's overseas loss software work are all in software work at the Getty in many ways, and that's something that he's dealing with directly. David, do you want to talk about that? Even? Do you want to answer that a little bit? Or you want me to paraphrase what you do? Okay, all right. I'll take it. Now I can make up my own answer. No. So one of the one of the big things is we had that a lot that was an issue across the Getty and a lot of different ways, because digital was spread out throughout the institution. And people were singular people were building things, solutions, and then and then they would move on. And they were the ones that built and knew that solution the most. So one thing we're doing is making sure that developers are actually not being assigned or not being relegated to a single thing, but are getting experience in on the whole platform in a whole suite of of areas. So like in my case for choir, I don't have we don't have necessarily one developers dedicated to choir, we actually have five developers or not really, but But yeah, I want five developers, David, we have several developers who are all working a small portion of it. And so that helped that sort of, from the beginning, spreading around the work and not just relying on that one person, even if one person came up with a vision, if they started it, bringing other people into work on it as early as possible is one way to do it. For sure. Yeah,

Unknown Speaker 49:08
do you? Right? And then I would say, again, sort of thinking about sustainability, like from day one, as opposed to when you start the panic phase, like so doing it pre panic. So that you so that you think about it so that you say okay, well, we've made these technology decisions, and we've made these technology decisions, because this is the problem that we're trying to solve. And so, you know, this JavaScript framework is the correct solution, you know, but then thinking about okay, so, so collection, space anecdote, you know, we had a funder, the funder, strongly recommended that we, we partner with somebody who had a framework that was not sustainable. We didn't have contributors that didn't have documentation. And so we sort of got locked into it. And that turned out to be really unsustainable for us because then we couldn't have contributors and we couldn't have people sort of sharing with the software. So luckily, we could go Go back to the funder and say, like you got us into this mess, can we have some money to get out of it now, but thinking about those decisions really early on like are the technology decisions that you're making is the software sort of decoupled from itself enough that you can swap pieces in and out as things sunset? Again, instead of five years down the line being like, great, Microsoft has discontinued support for FoxPro. And that's what under pins our entire application, you know, so, so not having to be something that you do after but that is really baked into project planning from day one.

Unknown Speaker 50:35
A couple of things I would add to that these are all great answers is building a culture of code review. So I don't know if that's something all of you are familiar with. But the idea that for before anything actually gets merged, becomes part of the the source of truth for a piece of software, someone else has to look at it. So that forces you to have at least two people who've looked at everything. And that's something we've instituted in the last three years on open data kit. And it's it's really paid off, because there's always another person who knows what's going on. And then this is harder, I don't know how to do this exactly. But I think there needs to be a bit of a cultural shift between it for developers to value maintaining existing software a little bit more. And so maybe that's something that, you know, if you're a project manager, it's something that you can reward and congratulate folks for doing that more than, you know, starting something new, I think it's, it's always very sexy to start something new. Right. And it's, it's easier in a way, because you only have to deal with your own brain. And I think really rewarding and recognizing the work that maintenance and, you know, understanding what somebody else did, even if it's not exactly the way you do it, I think is a really important part of shifting towards collaboration, rather than, hey, I'm gonna get to build a whole new thing in my corner.

Unknown Speaker 51:55
So some of the early open source work that I've done, the developer community and user community are the same people, they tend to be tools for developers, a lot of work that I've been doing more recently, there are two communities, the user community and development. As we've seen, it's much harder to work with these two communities, we have different views and different things. Can you give us any advice or insight in ways that people deal with that problem?

Unknown Speaker 52:22
Have a discourse Forum? I'm very serious, actually. Because because it's much more approachable for a user. And you can have templates that have user language rather than things being about issues and pull requests and ticket like, what are these things, I just want to use my cool museum software, or whatever it is, we're we have that split. So our users are mostly non technical, mostly in Sub Saharan Africa, they have power intermittently, you know, they do not want to deal with the code. And so I think having a place that is welcoming, that's not that's jargon free, where people can come and talk about their workflows and their, their, their needs for on a non technical level is really, really important. But it's somewhat uncharted territory. So that's why we look at Mozilla, for example, a lot of users are non technical, or, you know, there's like QGIS, the GIS community has kind of similar universes. And so we look at those for ideas, and their user forums are really important.

Unknown Speaker 53:31
If your developers are able to sit with people who are doing the work, and truly understand what they're doing, sort of sit there and watch them use the tools and try to accomplish the things that they're trying to accomplish. We have similar tensions, like we have collections, managers, and registrar's on one side, and, you know, software engineers on the other. And so, honestly, having them sit down and look over the shoulder of people who are doing the work to understand, like, some of the daily grind stuff, I think helps this, the engineers be a little more empathetic on the one hand, and then also being very open. So you know, something like discourse or that for the end users to understand, because somebody earlier brought up, you know, what do people want search, they want Google, people also sort of don't understand, like, some of these projects might have one or two developers versus 1000s. You know, well, Google can turn this stuff around in a day. Well, sure. They have 1000s and 1000s of people working there, we have to, and so understanding the work that they do, and so being really open and sharing so much of that out to say, you know, we made these architecture changes because you know, it's going to have this benefit for you the software is going to be more sustainable or whatever, so that it doesn't feel like this super opaque. Oh, they updated the JDK. I don't know what that means. Sort of here's how it affects you and here's why it's good and you should support it. And we want to make sure we let everybody go to get to the two o'clock thing. Yeah, yeah. Yeah. So

Unknown Speaker 55:01
you have this mapping of the first museums project. And I see I'm going to continue expanding into external vendors and firms, which makes a lot of sense, especially in the context of the conversations that we would have earlier this morning about how museums or this field is set themselves apart from others, or you're doing very similar things. Um, one thing you have now that you've sort of gathered a certain amount of data, do you have further questions to ask this sort of data set? And how, how is it? How is this interfacing require?

Unknown Speaker 55:34
Good one? So in brief, certainly, like, it's, it's that mapping the open source and has been sort of a side project for around this get around MCN. So I would like to see it expand, I would like to to be seen as a resource in some way. I think that it would, it would involve being a little bit more collaborative and bringing actually in a community to help like open sourcing that project, certainly, and maybe playing in a discourse and like having finding ways that we can we can involve other people, I think, is the sort of key thing. The one thing that the one, the big sort of thing that I didn't get out of that data is that you miss, like, what's actually going on? Like, are people using it in other ways, GitHub can only tell you so much. So I really ran into a point where we can know a few things we can put some numbers to some things but we can't really dig into like the the whys in the house so that it's more survey and more people work. Certainly. Okay. I do have one. What did you have a question as well? Yeah. Okay, great. Thank you all very much. Appreciate you coming.