How to Avoid Creating a GitHub Junkyard – Lauri Apple

Kelsey Evans:                         Alright, good morning everyone, and welcome to day two of the Microservices Practitioner Virtual Summit. I’m here with Lauri Apple from Zalando who’s gonna kick things off for us today. But just to walk through some quick features on Zoom so that you can get in touch with the speaker. You have a Q&A button on the bottom of your screen, as well as a chat button. Feel free to use those to ask questions throughout the presentation. And at the end, in the last 10 minutes or so, we’ll stop for questions then. So if something comes up and you wanna type it in before you forget, feel free to do that. And then we’ll answer everything at the end. And we also have a Gitter channel, it’s gitter.im/datawire/summit. You can post any questions in there.

So with that, I’m gonna hand things over to Lauri, Lauri if you want to get started go ahead!

Lauri Apple:                           Alright thank you Kelsey! So I’m Lauri Apple, I’m calling and talking to all of you from Berlin, Germany. I’m American though, you might notice that I don’t have really an accent. So I will tell you today about how to avoid creating a GitHub junkyard.

So what’s on the menu for today? So we’ll do a little bit on intro, and then asking why before hitting the publish button. So I’m gonna just move, ’cause this screen is right in front of my slides. Okay.

So before we hit publish, why do we want to put something online in GitHub? From there we will talk about what happens when you don’t ask why. Building a junkyard on GitHub, and I’ll give you a case study.

Then, what happens when you decide to clean up your junkyard, so what are some of the stumbling blocks in making that difficult, what can make it easier, and how we at Zalando undertook our big dig as you might say.

And then in closing I’ll just give you a little status report of where we are now, and some learning so that if you are also going to undertake a excavation on GitHub, then you will feel assured that you can get through it, and also take some tips from our experience.

So about you, I’m just wondering who out there is managing their company’s or team’s GitHub organization. And feel free to leave comments as you wish. Who is also a GitHub manager at your company? So who is curating the content, creating the policies around what goes live on GitHub. And who does open source because you think it’s fun. I think most of us do open source in some way because it’s fun. There’s a lot of rewards to open sourcing code or documents, from personal recognition to giving back to the community.

And another question I have for you to think about is if you’re a proud workaholic. So I definitely have been in my life, and I try to strive to [inaudible 00:03:14] towards more work/life balance, but it can be hard when work is fun, ’cause you have to draw the line and spend some time away from the computer.

A little bit more about me, so I’m an agile producer, which is like a combination agile coach and project manager with the development team at Zalando, so it’s of course search team, building our search architecture. I’m also the open source evangelist for the entire organization. We’re building a team now for handling open source day to day operational tasks, but for now I’m it. And we have some volunteer developers that contribute as they can.

And then I’m also an open source ambassador with Red Hat. So Red Hat runs a program for improving, or openness in organizations, and driving more openness, which means collaboration, sharing, and transparency in organizations that are not just tech, but in any industry. That could even be your personal open source project team. We would have articles and materials for you to open your processes. And you can find a lot, all of my blog posts and other people’s blog posts, our books, maturity models, et cetera, at opensource.com.

Personally, my biggest open source projects that I’m driving are two. Feedmereadmes, which is directly influenced by my experience writing and editing lots of readmes at Zalando and elsewhere. Basically the project is a help exchange, so it provides project advice, readme guidance and editing for small, usually small project creators and owners, and small project teams, although we’ve gotten from bigger contributions like webpack and Apache [inaudible 00:05:09] that have submitted their readmes for some extra review. And we’ve gotten contributors to help review those and get some nice feedback going with the community.

There’s also a readme maturity model which we recently drafted and posted there. So if you struggle particularly with documentation, then you can get some ideas on how to improve it from the maturity model and seeing what essential ingredients might be there. And I’m bringing up documentation readmes a lot, because I find, and I have strong beliefs as a writer in a past life, that documentation can really make or break your open source project. And either save it from the junkyard, or push it to the junkyard.

My other open source project that I’m driving right now is a list of leadership and management resources from books and videos to talks, articles. So that is about two months old and growing quickly, and would love your contributions to that.

About Zalando. So Zalando is a eCommerce company based in Berlin. We have several tech hubs in Europe, we do business in 15 countries, we have more than 20 million active customers, and here’s some more statistics that show you how big we are.

So you might assume correctly that a team that has to run a company this size is going to be rather large, and it is. So this team of 1700 technologists has been quite active in putting things on GitHub in the past. Today you can go to this website, I have the link here, and you can see what our, mostly our showcase projects. Some other projects towards the end are a little bit deprecated or no longer useful, or were not useful to non-Zalandos in the past. But they just need a little bit of careful transferring elsewhere. But for now, this website is really where you’re gonna find out strongest projects from a community as well as an innovation aspect.

So if you take a look at our dashboard, you’ll notice that we’re rather a polyglot as an organization. So we have primarily six, now, languages. Go, Java, Python, Scala, Javascript and Closure. And Swift for the mobile side, so I guess that’s seven. We’re very big, we have been traditionally rather big in infrastructure tools. We also have a microservices architecture, so a lot of the open source that we release is related to APIs, whether it’s managing them or generating documentation, or being frameworks on top of languages to assist with better API management. And as an organization that’s doing open source we are maturing, so we’re definitely shifting from quantity, which look how many projects we’ve got online, to quality, look how great these projects are.

We open source for all of traditional reasons you might expect of a company, from personal development and giving our developers opportunities to grow individually and be proud of work and share that work with other, to giving back to the community, that we really rely upon to run our business. Also it improves quality as we’ve seen, because developers know that their work is out in public, so we get contributions on bug fixes. We also have to ensure that, even from a security and auditing standpoint, that the work that we put out there is very carefully developed so that we don’t risk ourselves putting things out there that we might not want to be public. Like personal data about our customers, we really can’t do that, put that out in public.

It also helps us build our reputation to show that we are open source friendly and that we actually encourage open source development, both creating projects and contributing to other projects. And of course it helps with recruitment because if you are doing open source then developers looking for new opportunities can understand better what’s unde the hood.

But those are all rather cosmetic reasons for open sourcing, pretty standard reasons. Why do we open source in particular cases? So what are our motivations for putting something live on GitHub? This is my primary question as open source evangelist when I’m asking developers what are you planning for this project, what are you trying to achieve, why you think it should be public. And why this way? Why did you build it this way? What do you hope to help people resolve? What are the technical challenges that you’re addressing with this? How does your personal experience inform the development of this project? Are you aware of why you want to put this online.

I also, I have asked broader questions based on how much work we were putting out in the past. Why do we make so much of this stuff ourselves? Are there existing solutions out there, and would it be better to contribute to that, to someone else’s project instead of making our own? Are we developing open source sustainably? So are we being kind to ourselves in our approach? Are we creating enough work that we can actually manage? Are we sure? Is somebody asking us are we creating a sustainable amount of work who is not me? Is it our manager? Or the business, is the business enabling us to ask these deeper questions about what we’re trying to achieve with open source and our workload around that? Or are we creating burdens for ourselves by releasing so much work that we end up losing sight of what we even have that’s public? And we have pages and pages of things to come through.

I ask these questions because of personal experience. Of course we all bring our own experiences to work. So I was a journalist and writer in a past life, and I worked in two primary for a … I worked in print journalism and then online blogging. And so my experience as a print journalist was rather slow in comparison to online blogging. I had to spend more time on an article, I would call people on the phone, I had an editor who would limit my word count because there was only so much real estate in publication that you, a physical paper. So I had to really, and they, the editors had to, we worked together to really shape something that had a bit of craftsmanship around it. It took time, development, maybe a story would even take several weeks to report on and collect all the essentially information.

With online blogging, that was a rather different work approach. I worked primarily for Gawker Media and Hulk Hogan is in the corner because Hulk Hogan put Gawker Media out of business last year by suing them in Florida and winning. But my experience with Gawker and online blogging elsewhere was that there was more of a focus on speed and volume, on producing material that would then generate traffic and discussions. But it was very fast. And there was unlimited space, so if my writing was blah blah blah, and not very carefully curated and edited, then there was more leeway around allowing that to slide because there were no parameters on space, and just keep blogging until you’re done, and that could be pages. The post will accommodate it, the CMS will allow you to run on.

Also the editors were rather time crunched, so often I would work at night, so there wouldn’t even be an editor on the premises. And I worked from home primarily as well. So the editor would be in bed, and so there would be, it was really flying blind. There’s nobody to help challenge what I was putting out there in public, it just would have to go out in public.

And I think these two experiences were markedly different in that for the latter, and online media, I started to feel a bit like a hamster on a wheel, just churning out material. And so when I see some of my colleagues that are putting out, or have put out lots of repos on GitHub, and they’re just putting out more and more, it starts to really feel like we’re hamsters on this wheel, just turning out all this material. We only have 24 hours in the day, so how we manage it as individuals becomes a real constraint. We only have as much time as anyone else.

But that might not be so apparent, that time constraint in the beginning, if we really feel like, “Oh we want to share this code, and it’s fun, and we’re saving someone else the work of, they can go on Google and search for our code and find it, and there we are, we’ve shared something.” We might get a personal high off of that or feel very good about that, but if we create so much work that we can’t manage it anymore, we will burn out. And as research has shown, multitasking and having too much to do, it not only makes us poorer decision makers, but it also just wears us out mentally.

So in recent months, there seems to be a little bit of an uptick towards people writing and sharing ideas about this hamster effect, and how we are always feeling too busy to really get to all of the work that we might have. And so this tweet really resonated with me from Jeff Gothelf, who is a leading [inaudible 00:15:40] LINUX and agile movement, he does a lot of talks and has written several books that are highly influential. And this tweet says it all for me. “‘Everyone is too busy’ is a cultural symptom of a lack of a clear strategy and prioritization process. We need an objective process for saying no.”

So bringing priorities to open source requires a personal discipline, and also really listening to ourselves to understand if we are creating more work for ourselves than we can realistically maintain, and if we’re buckling under that pressure or not. And I recently asked a colleague who has put out a lot on GitHub, “How do you feel about maintaining all of these repos for which you’re the only person names in the maintainers file?” And for him, he said it was a hard question to answer. And I’m wondering, should it really be that hard. I know this person is up at midnight sometimes fixing things, and maybe he enjoys it. But maybe in some cases he’s doing it because he’s the only person who’s in that maintainers file who’s there to be asked, “How do I work? I have a problem with your software, can you fix it?”

I asked another colleague who works in the same team recently, would we end up in these situations of high work burden if GitHub charged per repo? [inaudible 00:17:09] it make decisions better? And he seemed to agree, that yes, it would definitely change things if GitHub were to suddenly start charging us for all of our individual projects. But my question is, why not change the things now voluntarily to reduce that feeling of busyness and to restore focus and priorities to our open source portfolios.

And when you think about it, it’s kind of a really smart business decisions to do this, because open source isn’t really free. So we might be able to put all of our code online infinitely, but there is a cost to it. Whether it’s maintenance, or good will. So if someone’s trying to use our work and we don’t get back to them for six months or a year, they’re gonna have an impression about our dedication and our responsiveness to queries about our software.

Craftsmanship suffers as a result of having too much that we can’t focus on specific projects. It also becomes a bit of a throwaway aspect ’cause we can just keep making and making and making, and not investing back into some keystone projects that we might really want to drive.

And then if nobody’s editing all of this work and you’re working in a big company, you might just end up with a GitHub junkyard, like all these abandoned projects that are deprecated and no one’s really sure if they work or if they can use them or what’s happening.

And I put this tweet by Andrea Goulet, another person I follow [inaudible 00:18:44] who suggested maybe we should start mending more instead of making, because when we make make make, it requires a lot more resources to mend. And given how the open source infrastructure is already in desperate need of more contributors, we might not be doing ourselves too many favors by increasing the amount of infrastructure that we need to all maintain.

So I’m a big believer in less is more, you’ve probably picked up on that by now. What I’m really advocating is not to put no, and not destroy the fun of all the enthusiastic open source developers in the world, absolutely not. But to really release less and invest more into what’s released.

And this comes from personal experience of seeing what we’ve done at Zalando so far. So a little bit of history about how Zalando has done open source in the past is that from 2008-2015, the management structure was really command and control, and so open source work was minimal. And developers really didn’t feel like they had a lot of freedom to release much on GitHub. So the offerings in this time period were quite minimal, restricted mainly to infrastructure tools, and Python and some post [inaudible 00:20:08] related projects.

So there were a couple other Java libraries and things like this, but it was still quite small. And then in 2015 the tech organization shifted to a model of management more defined by Daniel Pink’s DRiVE, where autonomy, mastery, and purpose were to preside. So this opened up opportunity for autonomous teams to made their own technical decisions about what languages and technologies they would use to get their work done. It also helped us really to become more open source first. So thinking about how to make something open source from the start of development, and how that might manifest. So you could share your work internally, and then eventually if it gains enough users and interest, it can be strong enough to go public, and also help externalists solve their technical challenges.

So with open source first, we had a list of principles to help guide developers towards how they would open source. And there were several quality and security and documentation suggestions. There was also a suggestion to share code. So share the code really kinda became the primary focus, somewhat to the exclusion of all the other suggestions. So we shared a lot of code without maybe following the other nine principals, so there were 10. Like the 10 commandments. We maybe focused a little bit on one and not on the other nine.

And so what happened was that our GitHub release cycle was just basically like the Lucille Ball clip of the chocolate candy coming out really fast, and so fast that she starts to eat it, and her colleague, they just have to eat the candy that’s coming off of the conveyor belt to keep up with the rapid pace.

By January 2016 we had about 400 repos online. We were really open sourcing all of the things, and doing a lot of coding in the open as well. So just sharing code that was very specific to our systems, but of very little use beyond as a project, as standalone projects, to anyone else. With all of this volume we started losing sight of what we had. The release cycle was rather compulsive, and the question why and what value all of this work had for the public beyond just simply sharing code was often hidden or not present at all.

It was, our GitHub organization became rather unfriendly, because if you were an external user and you wanted to check out what we were building, you couldn’t be sure that you had have a consistent experience from one repo to the other. There were lots of missing docs, files, even licensing files. Some teams were not responding to pull requests in a prompt way. So you really couldn’t know what you would expect.

And this project is an example of one of the offerings that we had published in 2015. So this is called [Schtoops 00:23:25], and we use it today. It’s a very effective set of tools for us, it’s worked rather well and has served the business very successfully. But as an open source project, it’s quite unwieldy as you might be able to see, all of the orange blocks are different components, and so asking somebody to install and configure all of these different components is a rather large ask from a company that was not historically known for doing open source until very recently.

It was sort of like high friction was our aesthetic. So even though the software works and the code might be of a really high quality, just to use it would require really extensive onboarding period, and we were really providing that at all times. And documentation, or responding to requests and things like that. So the value of this was often hidden. Eventually the team behind Schtoops realized that hey maybe next time we oughta create something simpler for the world. So now they’re developing a lot differently, and even deprecating some of these parts.

But in hindsight, would we have built this project this way if GitHub had charged per repo? Or if we had asked the community to help build it with us. If the team had actually had more time to plan out this as an open source project and develop it with the community involvement. They were really working under pressure at the time just to spin something up to serve our autonomous teams. And then what are the thoughts about cost? So once you build something, then you have to either improve it or your deprecate it, and how much does that add up to in the end?

We don’t plan junkyards, we don’t plan deprecated work. When we release something shiny and new we’re really proud of it. And we don’t often think about what might happen to prevent us from investing, continuing the investment in work that we release. But these, we often hope for the best and hope that the project will take off. And it’s a very nice belief to have. And that’s how every company has started out, is a belief that it’ll take off and it’ll succeed.

But when things don’t succeed, we might end up with an incredibly harsh open source ecosystem where even we might not be able to walk through it with certainty that we know what we’re looking at, that we can use what’s in front of us successfully, that it’ll support our work, that it’ll help us solve our technical challenges.

So this comment by Sarah Mei really gets to the heart of it. “A code base isn’t a thing that we build, it’s a place where we live. And if we don’t seek to finish it and move on, but to make it livable.”

So a lot of what happens now is when we end up with a junkyard, then we can clean it up. At least GitHub makes it easy. So with our situation, that’s where we are now. We are undertaking a big dig, an excavation to find the gems in the rough and to polish them up and really ensure that they’re of maximal value, not only to ourselves, but to the open source community at large.

And for doing this, you just have some basic ingredients that help you get underway. So applying basic storytelling to such a process. What stories are we trying to tell with our GitHub organizations? What do we care about? What is compelling for us? And then how do we transfer that engagement and enthusiasm to the community at large so they’re also excited?

Building and craftsmanship will help you tell that story even better because suddenly you’re really thinking about what you’re trying to achieve on GitHub, and what you’re hoping to happen when you release a project into the wild.

And sustainability, thinking about all these questions slows down your development process. Suddenly you’re not hitting the publish button anymore reactively, you’re taking time to think about what you want to have happen with your projects, and then you might hit the button. Or you might not, you might just keep it on your own in GitHub Enterprise, or on your account.

So this kind of dig requires time and care. There are a few aspects of it that can happen rather quickly. Creating some guidelines and rules around what to release, and what needs to be maybe archived elsewhere. You can also use GitHub organizations to curate your offering, to categorize different types of projects and different levels of usefulness, things like this. What takes more time is to bring up a team of people to support this kind of mindset, especially if they’ve been previously able to just release whenever they wanted do.

We do have a set of guidelines that we have had in place for about two years, and the open source first principles that I mentioned earlier, they’re kind of like 10 philosophical tenants for how one can release open source are part of this “how to” set of guidelines. The guidelines themselves are in way greater detail, and you can find them here at zalando/zalando-howto-open-source.

So what they encourage, and have encouraged all along is striving for a minimum viable product, and the idea is that they provide a minimum viable process for helping developers make the right decisions in releasing things.

We’ve also vetted this set of guidelines with a couple templates to help developers craft readmes that are thorough and understandable. To also initiate those questions about why am I releasing this and who am I hoping to help. So there’s a product template that’s attached to the “how to” to help developers ask these questions, and maybe even do user research to find out who is gonna be interested in what I have to offer, and how can I make my project better, or even encourage them to contribute to what I’m trying to build.

A lot of what we’ve done is rather recycled, so there’s no original ideas really driving any of this. We’re referring to what Google, GitHub and other companies have produced and have applied themselves. And then there is a little bit of a unique spin to what we do because of our situation, but most of this is rather rudimentary to be honest.

We’ve been using the ability to curate different organizations, to create side organizations to take some of the questionable development that needs more work away from our main dashboard that you saw earlier in this presentation, and kind of incubate it elsewhere to give it a little time to grow. And so the Zalando incubator is rather self explanatory, but that’s were we try to park some of these very early stage projects to see if they gain traction. And previously it was kind of like a double incubator graveyard, but very recently we cleaned out a lot of repos, archived them elsewhere, and so now it’s really functioning as an incubator.

Part of the process of trying to change your culture and reduce or eliminate your junkyard and make it a healthy garden of open source is that you have to bring people on board and help them understand what you’re driving at. So help them maybe develop [inaudible 00:31:30]. Instead of releasing all the things, release a few things and then focus on those. And sometimes this might feel like an obstruction for a developer who wants to share their code, but it actually can be freeing, because suddenly you don’t have all of this work to take care of by yourself anymore, and you don’t have people asking you for things. You minimize your workload.

And this helps you avoid burnout, it helps you optimize your offering, to really build projects in a focused and careful way. And it also helps you ask certain questions and keep asking certain questions iteratively. So as you develop something, your audience might change, their needs might change. And so having time to listen to your audience, go to them, ask them, “How are we serving you?” can help you refine your project’s focus so that it’s even better and grows even more.

One and a half years into doing open source as an initiative, we’ve seen a lot of progress, and bringing more craftsmanship and quality to our offerings. So I showed you early the slide where we had 400 repos in January 2016. We’re now featuring 55 on our main dashboard, so that’s a huge reduction in code. And yes, some might say, “Well that’s sad.” But you know, the code quality that we’re offering, we can guarantee a lot more because we actually know what we have. We can actually look at it and tell you what we’re offering.

There’s more of a why behind what we’re releasing. So we’re becoming more community oriented, we’re onboarding more external contributors as we strengthen our offerings. We’re enabling better project discovery, we’re archiving more to GitHub Enterprise. We have other companies using our “how to,” like Nike and Starbucks. I’m gonna close this little window, okay. We’re doing more testing, more documentation, more of the essential files that one might expect in an open source project. Contributing files, security files, things like that. And as I said, the incubator has recently become an actual incubator, so in the last two months we’ve gone from about eight pages of repos to 1.5.

So there are challenges to all of this, and I’ve touched upon some of them already. But changing habits and developing a craftsmanship mindset can take time if someone is not familiar with the reasons why they should maybe do things differently. There’s also kind of an unclear understanding from many people, even myself, about what an MVP might be. And so there might be this assumption that you have to have something in perfect, polished shape for it to go live on GitHub. And so convincing people that no, you just really need to have something. It can be rudimentary, but comprehensible to your audience is sufficient. That’s an MVP. Throw your essential files on that repo and you’re done, you’ve covered your bases, and you’ve guaranteed yourself that you might be able to get contributors because they will know how to contribute to your work. That you have some badges showing that you’ve done testing and have good code coverage. So that will increase the likelihood that people will believe in the stability of your project.

There’s a feeling of FOMO that comes up when you’re telling developers, “Hold on, let’s not release this yet.” There’s this belief that, and it’s justifiable, that somebody else might beat you to the punch, and that you might lose your opportunity to really make a dent in the conversation about a specific technology, or a concept. But it goes back to the previous point of MVP. If you just make sure your essential files are all there and you have some documentation so the world can understand what you’re trying to show them, then there really doesn’t need to be any FOMO at all. You can go live with something right away.

Sometimes when you’re undertaking a shift like this you end up getting compliance instead of engagement. So there’s definitely a sense that you need to do more to engage people behind this process, and so they don’t feel like this is just a set of rules that they’re having to fulfill. That can take time.

And also to build trust around if you’re changing your processes, that the processes aren’t there to harm anyone’s fun or to stop them from doing something exciting, that you’re only trying to provide guidance.

And sometimes developers might not see the potential of their projects because they might think that no one will care. But maybe the world will care a lot, and they just improve their readme a little bit, and then they’ll start to see it. They actually have something more exciting on their hands than maybe it was at first.

As we undergo this process, our GitHub organizations are getting friendlier over time. So we’re using readmes, I said earlier that I’m a big believer in writing and documentation. So with more investment and more time to invest in our readmes we can manage expectations better. Anything from providing a bill status note in the readme to a expected time for response, so a pull request. Giving people notice so that they don’t wonder if they will ever hear back from you, say, “I’ve tried to help you build your project.”

I know some developers don’t, they just don’t want any contributions at all, so they will say, “Don’t expect to hear back from me, so don’t make a pull request on here because no one’s gonna merge it.” And that’s fine, because then you’re at least informing your audience that they should not expect to hear from you, and maybe they go and fork your work and do something on their own. But they’re not sitting there waiting.

It helps you to also be clear about your plans and you’re future with the project, what you’re trying to achieve next, and what you might need help with. You can also use your readme to say, well if the working software isn’t your goal, ’cause that might be a pretty reasonable expectation of your audience, that they’re gonna look at something and it’ll work. But maybe you’re just playing around. So you can use your readme and say that, just show what kind of problem you were trying to solve. But that you’re not fully solving it, or that you don’t have any plans to improve the work over time.

When you’re dealing with an organization the size of ours, this will take quite a lot of effort, and you have to compete with a lot of different priorities, getting things out the door that are directly serving the business, changing minds, changing people’s beliefs about what’s possible and not possible. So these are some of the obstacles you might face if you’re trying to change your organization’s open source strategy. You really need middle management I believe to make it work. So it can’t be just a grass roots movement from the bottom, because eventually it will hit a wall. And if it’s from leadership, then it’s gonna be too top down and you’re not gonna really have the opportunity to get organic buy-in as much as you would if you have people from all levels of your organization contributing to a change like this.

Empowering leads and heads can be particularly difficult if they have a lot of competing priorities, they might not see the time for focusing on open source development, because it’s not in their OKRs. So there’s all kinds of potential we’re looking at right now in how we can actually do this better.

Finding time to do open source for development teams and individuals is also a challenge that our organization and other organizations face. So how do we manage that? And I think it’s really tying whatever development we do to make sure that it’s delivering business value as well. So it’s actually serving the business that we’re running. That will definitely increase the chances of engagement and also having leads understand the direct impact of all this work on their own priorities.

So based on our experience, definitely having some kind of maturity model mindset really helps. So if you’re exploring your own organization’s culture and trying to work that out, you might not want to be too restrictive at first about what you release on open source. But if you don’t manage it just enough, you might end up with a junkyard on your hands. So definitely thinking about your continuum, releasing things a bit. But how you want to manage and govern those release cycles is something that will be different for every organization to figure out.

Some things that we have incorporated for ours in the recent months as we focus way more on the quality versus quantity aspect is having mechanisms in place to help us change our culture. So building a peer review group of stakeholders as well as developers who are particularly active in open source. Helping to coach and mentor teams on how to develop differently and develop more effectively. Getting management support is a lot easier as well when you kind of have your continuum in place and people can understand where you’re trying to go with your open source developments. Making community non-negotiable, that’s kind of an advanced step for an organization like ours where we were releasing a lot of work for ourselves just in the open. So engaging with the community is a new frontier for a lot of our teams and developers. But we’re building in ways to help them navigate those new relationships, and it’s primarily through a lot of training and coaching.

So my closing tips for you, I’m giving you a few. But definitely don’t wait to clean up your GitHub organization until it’s so massive that it’s an enormous undertaking. And maybe you don’t even have the resources the be able to do it in any kind of calm and relaxed way. For us it had gotten so big that we really had to focus on it for about two weeks, just tons and tons of checking in and archiving projects, and there’s teams with competing interests, and they don’t want to do it. Just a larger workload, and you can avoid that just by doing it gradually, incrementally over time. I think some companies do this over every quarter or every year, look at their GitHub organization, see what’s not under development any more, and then deciding where to do.

If you’re a new company, start now. Build this habit of GitHub hygiene into your culture so that later on, as you scale up, then it’s just your culture, it’s not a new thing that people will have to get used to. Ask why when you release things, so understand, have an idea in mind, like a persona of who might be served by your work, and what would they do with your work. These are always good and will help you grow your project, ’cause you’re starting to engage with the world at large.

Don’t make clean up your burden. If it’s already too late for you and you have a big GitHub organization full of mysteries, don’t make it so onerous that it’s not a learning experience for people. So be a little soft about it and try to work with people instead of just telling them what to do, ’cause then it’ll help them understand what your goal is, a lot better.

And my final ask is please respond to people who are trying to contribute to your work or just ask questions about it. And this quote from Josh Berkus at Red Hat is great for this, he’s helped us develop [Patroni 00:44:13], one of our own projects, and has a lot of experience in the open source over the years. And he wrote recently that, the moment a new contributor posts something a timer starts. So the longer you take to get back to someone, that’s the less the chances that they will ever try to contribute again, because most people don’t like to wait. So don’t make them wait.

Thank you, so that’s pretty much all I have, and I guess now I will take some questions?

Kelsey Evans:                         Hi, thanks Lauri, that was great. So we have had a few questions come in. If you are in the audience and have questions, feel free to post those interview the Q&A now. So the first question that came in is about the tensions between the culture of CMM models and open source software. So do you have any commentary on applying the traditional enterprise software, CMM maturity models to open source?

Lauri Apple:                           So I haven’t applied those, so I really can’t speak on the experience [inaudible 00:45:25] there. What I can say is our maturity model is kind of a loose definition. We have some rules of play to help guide folks along, to tell them when your project is mature. But it’s not really developed in stages on it’s face. It’s kind of like we have a new strategy that’s developed over what we were doing previously. So the model is more about stages in our open source development cycles than it is a single document with different levels or indicators that are graded for how healthy a project is.

Right now what we’re basically doing is here are the minimum standards for your project to go live, and those cover those that have readmes, a readme comprehensible, do you have a contribution file, security file, a license file. Do you have at least two maintainers in case one of you goes on vacation? So it’s fairly basic things like that.

But it is a maturity model in the sense that it’s a more concrete, and a little bit less advisory, and a little more compulsory than it was.

Should I read the second question? Kelsey are you still there?

Speaker 3:                               I think Kelsey is frozen.

Lauri Apple:                           Okay.

Speaker 3:                               So I’ll jump in. So the second question is do you have any tools or scripts to clean up unused repositories in GitHub?

Lauri Apple:                           So no, because we actually need to document everything that we release through compliance, so we need to inspect things to make sure that if we’re going to delete a repository of it, it’s been cleared with compliance so that we can account for it later if our auditors come knocking on the door. So we don’t really automate any removal. We are going to try to automate making sure that all of the repositories on public GitHub have the required files to comply with the guidelines, but yeah.

Speaker 3:                               Great. Are there any other questions from the audience?

Lauri Apple:                           I guess not.

Speaker 3:                               Okay we’ll give everyone a moment to type. Sometimes we find that it takes a few minutes.

Lauri Apple:                           Sure, sure. Should we sing?

Speaker 3:                               Yes we can. Sing a song, or do a show.

Lauri Apple:                           (singing) Open source of course of course.

Speaker 3:                               There you go.

Lauri Apple:                           That’s it. Very short songs.

Speaker 3:                               Okay well it sounds like there are no other questions, so Lauri, thank you so much-

Lauri Apple:                           Yeah.

Speaker 3:                               For presenting, and thank you everyone for joining us, and this afternoon we will have Paul MacKay from Ancestry talk about their journey towards [inaudible 00:48:47] microservices.

Lauri Apple:                           Exciting.

Speaker 3:                               Okay. Thanks everyone.

Lauri Apple:                           Thank you! Ah thanks Aaron!