the 188th episode of Think Tech Hawaii's Human-Humane Architecture. And we're broadcasting live from the opposite ends of the world.  Hello, everyone. And we're continuing to look for better ways to build in Hawaii. And we know very good ways from way back mid-century. But whenever we bring this up, people say, oh, that was then. And now is now. So now we're going to show up around in the world of contemporary buildings that might fit just as well or even better in Hawaii, right? Yeah, absolutely. And we're going back to the same campus that we looked at last week, which is the, I can't remember what it's called. Do you have to explain? I know its initials are TUM, but I don't remember what that stands for. Technical University of Munich. There we are. And we took our new PI mobile, this strange 2U Audi A2 that was made from 2000 to 2005 and never made it to the US. And so here it is. And so let's go to the next slide and keep driving. Now we're basically, we just scratched the surface of that. There is also some housing on this campus. And here there's a similarity between we've been showing the audience and the students another housing project, a very vintage one. That's the Olympic Village back from the Olympics in 72. And from the north that's been hidden behind the berm. And similarly, that's the situation here. And now we're going to the next slide and go behind the berm. And here is something very innovative, right? No, it's not innovative at all. This is just standard German row housing. Now, to me, this looks exotic. To me, this looks different because we don't have any buildings that look exactly like this. But there's nothing innovative about this. We're going to have to turn from the view that we're looking at here, which is the outside world outside the university campus, and look behind us because that's where we're going to see something really remarkable. Let's do that next slide. So what in the world is that? Well, it doesn't even look like a building. It looks like a textured wall. And if you look more closely, you can see that that's actually vegetation. That's actually a plant that's growing on the exterior of a building, but not in the way that you might imagine it is growing. And why don't we go to the next slide. And this is the plant in question. This is called Virginia Creeper. And it is a plant native. It's a vine that's native to North America. But it's been introduced, obviously, to Europe and grows very well there in a temperate climate, just as it does in New England. This is what is used on the exteriors of many buildings in the Northeast in New England in the United States. And in fact, the colleges, which are known as the Ivy League because the buildings are supposedly covered with ivy, actually they are covered with this plant, the Virginia Creeper, which can grow very high. And it can just cling to solid surfaces like brick, which normally is what happens. However, in the case of this building, it's got an entire structure that it is growing on that we're going to examine as we continue to go forward. So you're telling us they should be called Creeper schools, right? They should be called the Virginia Creeper League. Yes, they should. All right. So next slide, we're also going to have your weekly German lessons. So here you go. You're on your own. Well, I'm going to say that this is for the first of all, at the top of this metal plate is the address. And it's on Enzienstraße, that's the street. And there are three buildings, I presume, one through three, numbered one through three. But the lower words mean student housing Munich. Yeah, exactly.  They only grow in very high altitude and they're very precious and pretty. Yes. That's what the name is. Name is talking plants. Let's go to the next slide. Because we see something on the ground here. We see some vegetation growing up.  And we see an irrigation hose. And what that does, we see on the next slide. But we also see what it's for, right? Well, first of all, if you look carefully at the sort of on the right hand side, you can look through all this vegetation, which at this point, because it's fall, it's just consisted of sticks with no leaves on them anymore, because these are deciduous plants that have lost their leaves. But beyond that, we can look into a room of the student housing. And as you pointed out, right in the center, there's a person sitting down. But the bottom part of this large plate glass window is a dark area. And you pointed out that that's where a student has applied a foil or some sort of baffle to cover up the window for more privacy. Unfortunately, there was a system in place to deal with that, which is extremely innovative. But, well, let's just keep going and see what we're going to uncover. But here also, you see the exterior vine covering that shrouds this building in a very interesting way. And I knocked on the window of this guy, and he came out and told me that what we see on the next slide that the maintenance people just basically took out what the architects has very cleverly designed. This mechanism here, you see the top part of some roll-down screen, and then the upper tube is also operating a pulling-up system that we see on the next slide. So this is the lower part. So you had a very sort of flexible way of when you wanted basically protection from below, you brought the bottom one up to any kind of level. And you had clearance above for light and sun. But if that one was glaring you, you brought the top one down. And if you wanted the light to pour in from below, so you could adjust according to your need and desire. And again, we think all the maintenance people should have talked to the architects and sit down and think how they could basically perfect that or improve it. As it reminded us tragically of our favorite Alamoana building, which had the sun-retractable louvers that for the same excuse of maintenance issues, they threw them out. And then all of a sudden the building lost its major performance mechanism, which is bad. Talking performance and non-traditional unconventional, let's go to the next slide. This is an interesting detail that fascinated us.  And it is located close to the ground. It's located down where you need to see when you're walking. So this just illuminates the path, in this case, or what would on the upper floors be kind of the lanai or the hallway, an exterior hallway. So that little fixture just serves to light where you need to walk rather than throwing light all over the place and wasting it if you don't need to see the upper parts of where you're walking. I do wonder at night how much illumination that little fixture provides and how far out it extends, because it doesn't look like it can reach very far. But we don't know, because neither of us has been there at night. Well, I was going to say the best way to find out is go there at night. There we go. Well, maybe not soon, because Angela just issued another curfew for us over the Easter holidays. So that's going to cost some $25,000 then as a fine to violate that. So let's do it after that. So let's go to the next slide, which is showing us why that light is there, because this is the entrance, a door to the unit. And you were saying, hey, wait a minute. This is temperate climate. It gets cold. So this door needs to accommodate for that. But it also needs to accommodate for the warm summers, because that's what temperate climate is about. It has both extremes. And the next slide is basically showing that we were able, and I took the students there remotely with my camera, and we had this resident who happened to be from China to let us in. And he basically was residing in the corner units of each of the two bars, which is four people sharing a central communal space that has the kitchen in there. And the top right picture illustrated to you the cleverness of that door system, right, DeSoto? Right, because the door is solid metal, as we just saw. It has an exterior opening with the small holes that have been cut into an inner pattern. But then on the inside of that, not only is there screening, which we'll just see in a second, but there's also a panel that you can open up so that you have full air circulation through that upper panel at the top of the door. And that's what you would do during the summer when it's warm. But again, to emphasize, that door is exposed to the elements outside, because as we'll see, this building is completely open all on the entire exterior. So you have to have that insulated so that when it's in the frigid cold of a German winter, the air is not cold, wind is not blowing in from your front door. That's why that's so solid. But it also has the capacity to allow air circulation when it's not so cold. Which we call easy breeziness in Hawaii. And then we do. And since we got the plan there, there's also different varieties of room. There's one in the middle of each of the bars that is basically cutting all the way through. So you can actually get cross ventilation and the other ones are single units. They're only one side of the corridor. Let's go to the next slide because this is giving us an up close view of that perforation in the door that you said is close enough. It's perfectly calibrated that it allows you privacy. And since I was getting very close and shooting this picture, you can also see a bug screen behind. But there's an even more fascinating meshing netting that we're gonna get to in this slide here. And this looks rather unconventional, right? Because you're starting to be high up there. And this doesn't look like anything we know, right? That's right. Have we gone to the next slide or are we... Oh, we should now, 15, sorry, yeah. Yeah, there we go. There we go. Yeah, so we're up on an upper floor and we're standing on the exterior corridor on the outside of this building, which is where how you access those doors we just looked at. But there's no railing. It looks like it's completely open almost. And I was just thinking that if somebody was afraid of heights, this might be kind of a scary building. Although, in fact, you're very well protected. And that's because this metal mesh, this metal screening, extends all the way around the building. And that's also what the vine is growing on. And we're gonna see that this mesh is not identical everywhere on the exterior. But this is an incredibly innovative way for this building to look. Yeah. And to that extent, it's actually more safe because again, there is like the three to four feet guardrail. And then above that, you're on your own. Here again, you can let your kids go wild and free and basically always be protected. Next slide shows us sort of the philosophy of the building is essentialist. There is nothing to the building that is not needed. So it tries to do once again, the most with the least. Here are the ends of the slabs. There is this bolt with a hole cut through and a cable. And then the nettings being stitched to that. And the next slide shows us something interesting. We're looking up and we're seeing the nature of plants. They thrive the most where the soil is. And then the more they have to work their way up, the more effort it is for them and the longer it takes.  The Virginia creeper, yeah, the Virginia creeper is a very vigorous plant and it will get to the top of this building at some point. So it may not be there yet, but give it time. And of course it only has a growing season of a short part of the year, unlike here in the tropics. So it can only grow during the spring and the summer and taper off in the fall. So it doesn't have a full 12 month growing season. So it'll take it a little bit longer. But also what I noticed when I looked at this picture earlier when we were talking is that the edges of these slabs that are the exterior corridors are not just straight. They are in fact zigzagging. And you pointed out that that requires two different, these are pre-made slabs. They have to be cast in two different forms to make them look like this because the bottom and the top texture will not be identical based on how concrete forms. But this gives a little added sort of texture and difference to what would otherwise be a fairly straightforward as you said, just really stripped down building. It's not just parallel lines, it's got a little difference to it. Yeah, and so with that, it's a little luxury, but as you just pointed out through the technology of Prefab, it's an affordable luxury. And it's certainly alluding to the sort of organic appearance of the building, unless in the Baroque where they were cutting plants into strict geometric forms, but usually in nature it doesn't do that. So this is certainly alluding to the organic nature of the fenestration in a very clever way. Next slide is basically, this is the Southern facade. So since the creepers haven't been creeping all the way up, the students got creative and attached these kind of temporary shading screens there that still allow some light through, but block the sun. But at that time the sun actually would have been, if it would be out there, it would have been beneficial because the sun is low in the winter and this is south. So they would have gotten solar gain. And the next slide is showing, gives you an indication of how cold it was because that was the end of the, well, the summer was over obviously and fall started to kick in and winter was announcing itself. That's why it was bundling up. But you also learned something from what we see here that you'd never been thinking about in the tropics where it takes like a short amount of time of your clothes to dry, if you let them dry in the trade winds, which we should because electric dryers are the biggest energy hogs. But what did you learn from this picture? What kind of physics? You pointed out something that I had never thought about that even when it's very cold, you can hang clothes outside or wet fabric outside and it will still dry partly because the humidity goes down so much in the winter. So the wet clothing will give off or exude the moisture into the drier air and they'll still dry even if it's cold. And that's what these people are doing there. They're putting up what looks like towels or blankets on a drying rack outside and that's, as you said they don't have to use a dryer for that. Exactly. So the next slide is a very crucial and critical one because it shows us the plan and North is up in the plan. So it shows you that the building basically it's long sides are either facing North which you can see on the large picture to the right side where you can never get any overheating also never any passive solar gain but you do get that on the South side and the lanai circulation is then shading it while to the most critical sides to the East and the West where the sun is low. And all we're saying is although we're at the ends of the on the opposite ends of the world this applies to Hawaii as in Germany these basic principles. You keep the East and West facades closed which they have been doing here. The two doors you pointed out are actually the front doors to the units with a shared space in the middle that we were able to walk in. So you can also see here two things. One we're looking from another building. So again that emphasizes this is a cluster of buildings. It's not just a single building by itself. You can also see here if you look carefully that the size of the metal mesh is different or the configuration of the mesh is different. It at the bottom those holes are smaller. It's closer together. At the top they're stretched out and that serves in the same way as a balustrade does. You pointed out for code it's stronger at the bottom and unless it doesn't need as much strength towards the top. Yeah and talking codes, right? I think we also figured out why the building is broken up into two parts because when you enclose everything the way the question is how do you get out of the building in case of a fire? And we figured that the allowed distances from any point in the building are within that code requirement in each of the individual ones. So you're getting out of the egress staircases fast enough to evacuate the building. Right and I'm sure there are also how those interior spaces are broken up is also serves as fire breaks or firewalls to refine fire into smaller areas. So it can't spread as easily. Yeah so as innovative of that undoubtedly is we're getting overly excited about that. Don't you think this would have been an incubator for the neighborhood? And that inspires further developments that gets to the next slide which is also your second German learning lesson of the week. Right and I figured this out before I even asked you. I was able to figure out that word even without being told. It means free spirit and I looked it up online to confirm that that's what it actually does mean. But despite the name of free spirit, this is not a very free spirited looking building. It's a very common place group of solid blocks and not innovative like the vine covered buildings that we've just been looking at which are just right next to it or right close to it. Yeah and it's particularly cynical because this is we're in a break of a series of episodes with Larry Medlin collaborator of Fry Auto, the masters of tensile systems and to use the word fry is in a multitude of ways. It's just very ironic here and cynical. And so let's get us to the next slide and we're also working on a show with our friend Ron Lindgren. It's gonna be many shows about vehicles for thoughts, what all the motives are for us. And here in the slide, once again, there is an Audi which was too ahead of its time. And that seems to be the case for the building as well according to what the neighbors are now doing because they didn't get any of that. And ironically or coincidentally, both have been made so the Audi and the building in the same year of 2005. Behind that, the blue car is the next generation. That's the most sold electric car in Germany which is by the car maker that also makes our other vintage pying mobile or Twingo and that's Renault. And so if we go back five more years and that gets us to the next slide, we're basically in 2000 where my sleepy little hometown of Hanover basically took the world stage and we had the expo in 2000. And as we were covering, we were building these tram stations leading to the expo. And by that time, infrastructure has to go in first and the housing wasn't developed. This ended up being the largest housing development in the world, just like for the Olympics, the Olympic dwelling complex was at that time. You need to provide for all the workers and all the people there. So think in Yoha then who are the architects of both projects and you see them at the very top left to the left is Mr. Yoha and right is Mr. Fing. Basically Bill is this housing block here, which is basically good dwelling quality of floor to ceiling glass, these windows that you kind of find interesting and admire that you could ventilate in different ways. And they got these shutters you got excited about. But then next slide, again, five years later, they were turning the more static brick red into some way more organic dynamic vegetative red because this is how they turn when they shut down their nutrition in the fall before it gets winter and they turn into this beautiful intensive red that we see here, right? And the thing that's wonderful about this is for a temperate climate in the summer, when you want shade, it's covered with leaves. In the winter, when you want sun to be able to come in, the leaves have fallen and so you're exposed to the sun. So this deciduous nature of the Virginia creeper works really nicely as a covering for an entire building. And it isn't just decoration, the way it is in most places, it's just a little bit of exterior sort of decor. Here it's actually functional. Performative as well, yeah. And so next slide, it also works in sort of in the hot air in my two years in the desert in Arizona at the very bottom right where my school building was designed by Eddie Jones. And he's adjusted the same it to be crawled over by creepers in the summertime. It took a little longer because it's so hot there. But the two pictures above that is basically showing our other extreme situation here in Munich which is the winter that we're just trying to come out of. And this is the head of the maintenance department, this lady, and while she was appreciating the building, she said, oh, well, I'm looking not so much forward to shoving all the snow from the outer circulation and then trying to shove it through the netting when it's sort of wet snow is kind of, could be kind of a challenge. But then again, we're looking for ideas for Hawaii, right? And unless we're up on a field where we're not building any housing, we don't have that white stuff. So not a problem, right? I think your dog agrees a lot. So let's go to the next slide because we have that sort of metal mesh in our hands, you and your one hand and me and the other one because we have a little sample in my alchemist chamber back at you age. And we've been using this some three years before thinking Yoha have used it for the school for disabled children. And I threw these pictures in again because at the very bottom right where the sun is not hitting it, it's almost unnoticeable, right? So it's very dematerialized and not in your face at all. And that's why if you've followed our shows it has been inspiring us for many of the tree texture projects as the primitivas and the cargo cordial cabana clusters because it seems such an attractive tropical exotic fenestration device. And last but not at all least, we're working on it again basically for primitiva three which shows us on the right are working progress here. This is inspired by fry auto. So this primitiva's nature will be all tensile it will all be suspended. It will all be meshed, it will all be netting not just vertically but also horizontally. So let yourself be surprised, right? And if the show points out something there is interesting similarities and interesting things to learn from. And we should add that just like in the last show where the most exciting building actually on the research campus itself because the housing is a little off was designed by an architect who also is an educator at Tom, Mr. Kaufman. So it's applied research. So it is in this case because Mr. Fink is also a faculty at the department of architecture. They're merging now. So they're gonna be school of engineering and design soon. So once again, as we're saying last time tap into your resources and use the university to be innovative, right? Because if not us, who else will be innovative, right? Right, correct. And I was saying as we were talking right before the show I'm looking forward someday to seeing an actual structure built with this mesh exterior here in the Hawaiian islands. It can be done in Germany, it can certainly be done here and it would be innovative. It would be eye-catching. It would be a lot of different things. And I look forward to somebody someday, somebody doing. I think that's a perfect closing note to Soto. So with that, thank you guys for watching us and getting ideas for Hawaii above and beyond it. And so we look forward to see you soon for another show. And until then, stay increasingly tropically exotic. And healthy. Exactly and happy.


So hi, I'm Eric Sorensen. I'm the product manager for Ospo at GitHub. I've been a Huber since last August. Come on in, folks.  Feel free to find a spot anywhere. Prior to starting at GitHub last year, I worked at Pubbit for about eight and a half years. And prior to that, I spent most of my career as a systems administrator and an SRE with a focus on what's now known as DevOps, but at the time was just called Configuration Management. Worked in the open source community there for a long time, and it's really great to be back amongst my people here. Today, I'm going to talk about open source at GitHub. I'm the product manager for our open source program office, and GitHub has a unique position, I think, with respect to the open source community. Software development generally is deeply collaborative and sort of the world's largest team sport. Open source software is... Don't have to belabor the point for this audience, but enabling organizations and individuals to collaborate that we can all use together to build better solutions. There are great advantages to doing this, and at GitHub we've seen some tremendous growth, particularly in the past few years where things seem to be catching on in the mainstream in a way that previously we'd only really dreamt of. GitHub, as a company, is committed to helping our customers make a better world through open source, and as presentation, I'll talk about that through the perspective of our open source program office. So we truly believe that open source is a differentiator for enterprises and our mission is to enable organizations and individuals to achieve more. This is a quote from Thomas Donke, our CEO, and he's spent much of his career as a developer, and I have to honestly say it's been wild and refreshing to have people at the highest levels of the executive chain at GitHub who really truly get it about open source. We're not having to constantly justify the rationale and the investments behind why we do what we do, we really get it and have continued to pervade the DNA of the company with a deep commitment to open source. There's sort of an outdated stereotype of open sources, the realm of hardcore hackers and fringe hobbyists. It's really completely invalid now. It's squarely in the mainstream to the extent that if you're at an enterprise that isn't establishing an open source brand, a phrase which I hate, but there's no better option, that you're probably losing out to a competitor who is. And just on the merits, open source in the enterprise means that your developers can focus on building differentiated value instead of toiling away on commodity or utility components. You're not in the container scheduling business, or if you are, you should probably rethink that plan. You're not in the logging framework business or any one of the hundreds of necessary but already invented wheels that go into a complex application. But being able to use an existing library really accelerates your development cycle. It lets you leverage the power community and enables you to focus on what matters to the business. But as Scott Neely said a long time ago, open source is free like a puppy is free. It's not free like free pizza. It comes with a set of responsibilities and different risks that many enterprises are not used to. And it's particularly relevant if you care about doing open source right and being a good open source citizen is the phrase that I've heard several times over the past couple of days and re-engaging in the community in an authentic way instead of sort of plundering the labor of others and not contributing back and becoming part of the community. So at GitHub we don't inherently do everything right but I do think we have a pretty good perspective on open source and enterprise. And first and foremost we are a software company just like any other and we've gone through our own journey with multiple twists and turns with open source. So I'll start talking about that. So we have a strong open source program that encourages contributions that respects the license obligations and allows engineers to use open source with ease to work out on the open and release their own projects while still maintaining security and compliance. At GitHub we see that our developers are using open source in order to get their jobs done more effectively. We're using something like 45,000 numbers probably higher now, different open source components across all of the software that GitHub builds and ships. And this allows us to focus on innovating as I mentioned before to sort of eliminate a bunch of that toil and focus on what really, building things that really matters. One interesting thing that happens too when the employees are allowed to contribute freely to open source is that the distance between developers and the customer shrinks and they don't need to go through support, sales, product management necessarily to learn how their software is being used and what the customers want. They directly interact with people using it and that's satisfying to developers as well as to customers who get their needs heard directly. And this is going back to that point about establishing a brand. I've heard from a lot of OSPAs that I talked to amongst our customers that it's really important in a hiring market to have established credibility as a organization that participates in the open source ecosystem to be more attractive to job seekers. So a big part of the depth and the breadth of this adoption is cultural. We have what's called a balanced intellectual property employment agreement. It says that employees are welcome to work on open source outside of work. So a passion project that you have working on Arduino stuff or Raspi's or whatever is that there's no inherent approvals that you need to go through in order to work on those kinds of things. And additionally, for things which are work related, there's really just some very minimal impediments to contributing upstream and to working out in the open. And for projects which are developed internally and which we want to release out into the open source world, that's also, I'll talk about that in more detail in a minute, but we have a pretty streamlined process for a developer that's built something and wants to release it out in the world to make that happen. And I'll talk more about each of these points, but the idea here is that we want to both help the projects that we work on to share and maintain our own stuff and work on the community while still maintaining some of the same kind of compliance and intellectual property protections that every other organization has. So we're heavily involved in upstream projects to the extent that there are engineers and whole teams at GitHub that are dedicated to working upstream and in ecosystems that are critical to the business. There's just a few of them. Get, obviously, we have core maintainers on the Get project and the programming languages and frameworks that we use most frequently also get upstream involvement. From an ecosystem standpoint, there are, these are more open source sort of platforms for hosting artifacts and building a marketplace that GitHub's also involved in. There's a few larger projects that started off as independent open source like Dependabot or NPM or things that were created by GitHub initially like the desktop and CLI client that started off as open source from the very beginning. Foundation-led open source is increasingly the way work gets done out in the community and that's been interesting, Chef, for me personally because the infrastructure tools where I started off in my open source career like Puppet, Chef, Docker, Terraform, those were coming out about 10 years ago and were really, they were nominally open source but were really dominated by a single vendor in a lot of ways and where they were an open core project that was tied into a larger commercial thing and so the shift over the past few years towards foundation-led open source, obviously a CNCF and the Linux Foundation which is why we're here are sort of leading that charge and clearly there's companies that are built around CNCF projects but it's very difficult to walk in with a thing that you've built as a single vendor and find success in those communities. It's more about working with the special interest groups and building collaborative relationships with people that are also working on the same problem space and then moving on into implementation. So again, we want all of this to succeed because more open source equals more good and we want to continuously improve what we can do as a platform, as the platform we're so much of this discussion, design, development and support and community interaction actually happens. Culturally, we try to work in the open as much as possible and I'll talk a little bit more about the mechanisms behind that but I think it's really important to model the community interactions that we want to improve. So these are a few things that we're pretty adamant about publishing and keeping in the open. The docs, entire docs system for docs.github.com is open source. Primer, it's our design system, had a really good conversation with a couple of folks yesterday about open source in design and how people are reinventing things over and over again like icon sets and that sort of thing. It's not really differentiated value if obviously design is really important but making a pixel by pixel representation of a save file icon is not something that people need to keep reinventing. And Primer is sort of our, we use both for everything that's on GitHub and in our products. It's also an open source site at primer.github.com that you can go and check out. The roadmap is interesting. There's a repository at github.com. That has all of the things that are flagged as being public in the internal roadmap project and it's a great way to get community and customer feedback on issues and to be as transparent as possible about the things that we're trying to accomplish in the future. That said, there are exceptions and some restrictions may apply towards working in the open. Obviously not everything is open source and I think that's true for every company. In some cases the tools and the projects that I'll talk about here are not open source because they just aren't open yet but they could be and in some cases the teams made a decision not to open something even if it was potentially a good candidate because there's a non-zero cost doing that. It does, once you put it on the world like Scott Manele put a minute ago it's sort of like giving a free puppy. You do have to continue to feed and care for it over the lifetime of the project and so sometimes we'll make a strategic decision not to open source something. So a bit more about that roadmap item if you want to check this out. It's amazing the level of detail that you can get into and if there's a particular problem that you're having with GitHub I would encourage you to look here first and see if there's already an issue that you could comment on, add your voice or use case to. Some things are obviously not on there so like co-pilot for example wouldn't show up on this until it was actually launched but for in-market features we really do encourage teams to keep the public roadmap updated and to get real-time feedback from the customers and community through that way. Under the hood there's a private repository with a super set of all these issues and the ones that are tagged as being public roadmap periodically get synced out to the public repo. So maybe something to think about for your organization. Obviously we heavily use GitHub issues so it's easy to implement that sort of automation but I think in general the idea there are plenty of other companies that have opened up their products roadmap. GitLab for example has taken the theoretical extreme has literally everything on their roadmap going out a couple of years but it's amazing to see what people are interested in and to get that near real-time feedback about what's important to your customers and your community. So though we've been working in open source for a long time in 2021 GitHub established a formal OSPO program to sort of centralize governance and coordinate activity around managing our own open source projects and working upstream. This is the group that I'm in and I'll talk a little bit more about how we work and what we're doing. Our mission overall is to as it says help individuals innovate more through open source. But we're in the interesting position of having sort of a dual role where we maintain our own open source projects and work on things inside of GitHub as well as help everybody out in our customer base and in the wider community that are using GitHub as the central point for their open source activity to do so more effectively. We kind of think of this in terms of program, the program side and product side. Programs being things that are internal facing work that help us primarily and products being outward facing work. And I'll dive into each of these in a little more detail but just to give you a quick overview from a program standpoint we're really concerned with the problem of license compliance. We're working on durable ownership at KS Cons. Sylvia mentioned this concept of sustainability and to differentiate between a point in time project health from the idea of how long and how sustainable is that over the long term. Resilience was a term that came up as a more descriptive phrase for that. We're using the term durability. That just means that the projects that are out there in open source have a defined maintainer that we know who is responsible for them and they have sort of a SLO in the same way that the software that runs internally does. And the release process I mentioned that a moment ago and we'll get into more detail. On the product side personally I think this is really interesting. We're building things into GitHub that help people work at that intersection of large organizations, large enterprises and the open source communities that they work in. So our primary user here is the Ospo manager which I think there are several here. And so I'm really concerned with the problems of how do you use GitHub to maintain and manage the open source that you both have generated internally and have maintainership over as well as working upstream in projects and communities that are outside of ones that are under your purview. We have a dashboard that shows organizational health metrics and I'll show an example of that. The open Ospo project is something that I'm really keenly interested in hearing your responses about. We have open sourced a bunch of the policies and procedures as well as some tools and guides that we use internally and are trying to see if those are helpful for people that are bootstrapping their own open source program office to just have a template or a starting point for things like a contribution policy for your employees to work on open source. And the last one is sort of a catch-all bucket of friction fixes around things that are maybe cross-cutting concerns that are primarily affecting Ospo managers but may also be painful for maintainers of large open source projects but things that wouldn't necessarily bubble up to the top of any one product team's backlog at Ospo we can sort of look broadly across the platform and say can we help out people who are experiencing pain in this particular area can we dive in to this part of the code base and help improve that for the customers that we care about the most. So I'll talk a little bit more about these programs. As I mentioned earlier we use a ton of stream projects to build GitHub. There are lots of dependencies across thousands of repos and many of them got pulled in back in the distant misty past so there wasn't good governance around their usage. So one of the first projects that we undertook was to get a handle on what those dependencies were to mitigate the risk particularly of software that we distribute and ship out to customers of unapproved licenses. So the idea is to implement a get clean workflow that is to get to the point where we understand the current state of things we have everything nicely bucketed and we know where there are exceptions what those exceptions are to try to be minimally annoying and not bug people unnecessarily. A lot of the times if people have a license or if the license date is incomplete in their repo they're the only people who can go in and really understand what the ramifications are fixing that but to alert people unnecessarily and to cause a bunch of chaos amongst the development teams would not be a successful way to go about this so we want it to be minimally obtrusive. And lastly to sort of do this with an eye towards potential future productization to think about what this would look like if we were to make it available for customers. And just to get into a little bit more detail about this there are some cool open source components of this project the overall thing itself is again one of those things I mentioned at the beginning that the team made a decision to implement in a particular way and not to open source the whole thing but there's definitely big pieces of it which are reusable and which are working in the open the biggest of which is a project called Clearly Defined which is a service that is now under the purview of the OSI which is a service that runs with tens of thousands of packages and their license information about them and the provenance of those packages so we use that as a source of truth for finding out license information. We've written and open sourced a Go library called Go SPDX we've seen a couple of talks in the past couple of days about SPDX this library allows you to express in the SPDX language a list of permissible licenses and the service compares that policy against the results for packages that it's scanned from repositories against the Clearly Defined database and opens up issues if there are something that's on the disallowed list. It's a big undertaking it's been a big project we've learned some interesting lessons as we've gone through it there were it was not a huge set of repositories that had problems which is the first one like you kind of look at that number of them and the state of things and worry that it's going to be tens of thousands of alerts and it's going to be a massive undertaking to try to fix them it's definitely a relatively small number of repositories that were affected and about a thousand total issues that were initially came up after we sort of cut down the initial data quality problems and even amongst those 350 most of those were just bad data like a licensed file that wasn't in the right place or had terminology that the software couldn't parse correctly very very few of those required actual code changes the absolute kind of last step in the chain of having to fix something is you have included this dependency the dependency is written in a way that has an incompatible license and there's no way around that and so we have to change the code that we've written in order to use a different library or use a different implementation of those 350 I think there have been zero of those cases like we haven't found anything we've had to actually go in and retool in order to fix a irrevocable problem with but despite all that it's still pretty annoying we've definitely got some feedback from the developers as the issues were opened up in their repositories that the documentation needs to be clear the chatbot interactions that are available in the issues are maybe not as intuitive as they would have liked so we're still trying to work on the developer experience and the UX around making that less subnoxious and ultimately more and better documentation more automation to go through and fix those things would be great additional curation of the clearly defined data always helps and having being able to send in a pull request to the upstream source of truth for that data means that everybody that is affected by that by a bad license gets or bad license information gets the benefit of it and additionally as we expand the scope more dry runs and just sort of eliminating those spurious alerts will be a huge boon to the end users and as I mentioned you can see the Go SPDX library that's available clearly defined itself is the service runs and you can communicate with it over API but the service is itself open source so as I mentioned we're really also interested in this problem of durability and durable ownership we use the term durability around internal software components indicating that it's got human owners who agree that they are maintainers that's an important part of it they're not going to write in a file somewhere but they also have agreed to take on their responsibility that it has an SLO that's appropriate to the criticality and that the users of that component have a path to getting support for it so last year we started a project to extend this to open source projects under the github organizational umbrella there's a bunch of work here involving getting an inventory of these organizations migrating them to a new enterprise management repositories from those with external collaborators bringing the unmanaged organizations into our access control system and then adding the ones that were actually live into a service catalog that you can see here so they live alongside of the internal software and that they have a clear path of ownership and all of the good things that come along with that I thought this one was going to build out too some lessons learned from here so if you are in a similar situation in your organization where you're trying to wrangle a large mass of open source that has been written over the course of several years and maybe has unclear provenance maybe you can learn from the work that we've been doing the first one is to go invent a time machine and go back in time before all that stuff is created and prevent it from going out the door in the first place without having this kind of ownership setting in the absence of that try to handle on it as early as possible because the longer you delay the more chaotic it becomes and the harder it becomes to wrangle it's important to backstop those written policies with automation and tools so it's one thing to say that you can't create new organizations it's another thing to actually physically prevent that from happening inside of your tooling and ideally you want to make it easy to do the right thing like I think most developers want to do the right thing but often can be confusing or difficult to know what that is if you also make it so that there are checks and balances or protections upstream of the point at which they could go wrong that helped keep them on the paved path and makes it easier to stay clean over time and this last one is around providing incentives and not just deterrents I think this is true broadly speaking but in this case we want to show them that even though there's some work that you have to do or there might be some changes you have to make that there's benefits at the end of it in the case of say this migration into another organization it meant that they didn't have to go through an on-boarding process to add external collaborators to an open source project they could just go ahead and add them ad hoc as they wanted to because it was no longer there's no longer a risk of associating them with an enterprise so that was appealing and so we wanted to highlight that and make that as easy as possible for folks last program piece that I want to talk about is our open source release process and this policy and the process itself is available in that github-ospo repo that I mentioned you can use the template that are there to start this start up a repository for yourself that has some of the same setup that we use at github it starts off with a written policy that's around how you can release a piece of software they've written internally as open source and it's obviously something that needs to be get by in from across your organization from your legal department from the other stakeholders that are that are involved in that but once it's established and published you're done and you can just point back at the policy for people that are working on software the policy points at the implementation which is in a repository that has those issue templates that I mentioned users can go in make a new issue fill out a pretty simple form it's quite maybe it has gotten procedural scar tissue over time as all process does but still pretty compact that describes what the software is that they want to release whether there's any burdensome intellectual property concerns that we might want to be concerned about any cryptographic related things like those kinds of things and a short checklist of things that they can do to make sure that the repository is in good shape to be open source that is does it have clear code of conduct file a clear license a clear set of maintainers once that's once the issues are in we have a periodic triage amongst the Ospo team where we go through and review all the issues that have come in since the last time as well as ones that have we've been shepherding along the process but aren't quite through have back and forth with the folks that are responsible for the software and have open office hours where they can drop in and frequently we'll just work through one person's problem during that office hours and get their code released at the end of the office hour session so that works out really well and then once it's once it's out the question of sustainability and maintenance comes in for those for those releases and hopefully if they've gone through the process correctly they are now set up for success with respect to you know the list of maintainers some external collaborators who can help out with issues and pull requests and those kinds of things and again I'll put the URL up in a minute but this is this is all available for you to use as a starting point for your own organization it works really well it's I think one of the more satisfying parts of the job that I do it's really great to work with the developers internally and to help them take something that they've written and you know have maybe been trying for to get traction on for a while and actually get it out into the world it's a pretty fun process so I've been talking a lot I'm going to pause for just a moment here if there's any questions about any of those program pieces I just talked about I'm happy to take them now and from them on the next section are the issues clearly defined resolved now is that a question I believe so it's definitely been had some additional attention put on it in the past in recent two to three months and I think the transition over out of being purely Microsoft project and onto into the purview of the OSI means there's a dedicated person that's responsible for it and that you know whose job it is to care about and maintain the service itself so I think we're in a better in a better shape than we were several months ago and on the right trajectory the other question is how recursive is the checking for license compliance it goes through a full dependency tree so if you have package.json that pulls in files it will recurse all the way through there and check those oh my god I knew that was going to happen I'm so sorry um sorry I'm a sound guy myself and I just put my water next to the amplifier and I'm like mortified that I did that sorry okay I'm going to keep going the drinking our own champagne section so what parts of github do we use to foster collaboration and open source culture sponsorships if you're in the room earlier Mike and Gerald from Stripe gave a great talk about how they use github sponsors at Stripe to build a sustainable set of open source dependencies that they contribute monetarily towards sponsorships really do move the needle for maintainers particularly sponsorships from organizations like a single organization sponsor can make a project more sustainable than 100 individual sponsorships Steph Lakin who runs the program wanted me to mention that the average sponsorship from an organization it tends to be out 14 times what an individual sponsorship is and so it can really help out for projects that are underfunded that are trying to um find a path towards sustainability and to take to scale up their their work so we've been focused on removing friction so that organizations can sponsor at scale like adding invoice payments and a dashboard for insights these features are now available to all organizations and we've used sponsorships ourselves to help fund projects that we rely on at github we heavily use discussions internally and I chatted with somebody their day who has wanted to uh encourage more collaboration amongst their uh the developers in their organization but because everything was centered in issues they felt like it was a high bar for people that weren't necessarily technically involved with that code base to get involved and to participate in a meaningful way at github we use discussions to solve exactly that problem and there's sort of an internal philosophy that everything should have a URL and having a discussion about a question that you have or a problem gives that problem a distinct URL that people can go to that can contribute to they can chime in on the discussion with what feels like a lower uh level of maybe commitment or a lower cognitive barrier than uh having to go and make a pull request or to create an issue that can just chime in on a discussion and have their voice heard that way um this is heavily used in engineering and company-wide communications and individual teams have really adopted this workflow for uh talking about things that are in the early design phases and haven't quite yet moved into a more formal kind of engineering plan I talked a minute ago about the metric dashboard this is a product piece that we in the ospo engineering have built and are made available to users on a opt-in beta basis um it's um we really focused on surfacing these community standards and making it so that you could as a ospo manager or as somebody who is responsible for a large number of open source or repos in an organization you could find ones that were missing a read me or missing a code of conduct or had a license that was uh incompatible with uh with your policy as well as to surface some of the contribution data and project activity uh so you could see um projects that were becoming stale and where the activity levels were tapering off and weren't getting as much um interaction with the community as they had been saved through four months ago and there's a quick snapshot of it um we're at a place with this where we're um finished up the beta and are looking at what we need to move on to the next phase had some great conversations at chaos con with folks and I'd love to talk with any of you if you're interested in this this sort of metric and this question of uh getting uh your arms around the uh state of the repositories that are across your organizations and finding out um maybe problem spots where a maintainer is burned out or maintainers have left and there's a backlog of pull requests that aren't being addressed or conversely projects that have unexpectedly gotten popular and uh need more love and attention in order to break through to the next level so I'd love to chat with you more about that if you're interested in it come find me afterwards so as I've mentioned a couple of times many of these policies that I've talked about are available in this open OSPO project so this repository at um github slash github-ospo uh we're gonna keep adding more resources over time but the contribution policy the open source release process are up there today as well as the templates for new repos that you might make in your organization and some more guide how to kinds of docs so check it out let me know if there's anything on there um that uh you you find useful for your organization or more types of things that you'd like to see either other things I've talked about today or things that would be helpful to you to expand the open source practices inside your organization so we have a uh community that um we started up I mentioned discussions earlier there's a um OSPO focused discussion area uh underneath community slash OSPO um this initially started off as a way for the beta users to provide feedback on the dashboard but we've gotten uh discussion started from uh folks asking for feature requests in other parts of github there's a great discussion with uh Jordan and with Tierney around uh two factor authentication and and how we could improve the workflow rolling out to FA um the github OSPO one that I mentioned and just a shout out to to the to-do group ospology uh repo which has a ton of great information particularly if you're getting started uh trying to figure out how you can uh establish a OSPO or establish open source practice inside your organization you want help doing that that's all I've got thanks for your time and I'm happy to take questions thank you I honestly can't believe I spilled water all over the receiver I'm so sorry go ahead yeah sure so the question is about the uh dashboard beta what are the next steps now that beta is closed the first one is that we are um exploring options for a different back end data store so that the hitting our target of organizations that we wanted to onboard uh coincided unfortunately with the rapid sunset of the platform that we're using on the back end there so we've got to rethink that a little bit but part of it is um making the data that people find most valuable available in the github apis so you can incorporate that into your own dashboards and uh make it um you know incorporate it with your own data sets that maybe we've had requests for wanting to overlay things like that PR uh close rate over an SLO which is an internal bit of data that we don't have insight into uh if we make that available what available through the API that becomes a lot easier for you to build on your own so that so yeah investigating a new back end making that stuff available through the API and figuring out um what the whether we're um whether we can enable it for uh organizations on demand instead of it having to go through kind of a manual onboarding process that's sort of what's up up next for it and I'm sorry about the timing there it's probably unfortunate any other questions yeah go ahead so are there questions when the license compliance scanner finds a problem with the license what are we what what's next are we making recommendations about what what they ought to do again it really depends on what the nature of the problem is and we have a few steps which uh uh to your to your later point of your question what how can we make that that information available certainly the process and the decision tree that we've built is a good candidate to add into the open source repo and make that available because it's implementation agnostic uh and it might be helpful to answer questions like this but it really is like a sort of flow chart of decision making about is the problem that the license data is incomplete or inaccurate if so can we fix that uh in the clearly defined in the upstream source of truth or do we need to fix it in the repository if we need to fix it in the repository is it something that's really like maybe it's a typo where they put you know a p a c h w instead of a patchy and we can just fix that typo and improve the the quality of it that's a surprising number of things like that are are are really easy to fix uh if not if there's really a uh a substantive problem with it in the sense that it's a the software really is licensed under something that's incompatible with the policy uh which to a point of your question we did not explicitly set the policy we worked in conjunction with our legal organization to determine which uh what categories of licenses were okay broadly like uh permissive licenses more restrictive licenses very restrictive licenses and categorize the licenses that we found into those buckets so that we can make policy determinations without having to go back and make the attorneys read every single open source license in the world um so we help get you know shape that with them um but uh if there is a if there ends up being a problem we'll work with the developer team developers that are responsible for it to go through and fix them but again so far we haven't found anybody that actually had you know it was a serious problem in the sense that there was a completely incompatible license that was against policy that was deeply embedded into the software and so we had to go out and find another replacement that was under a better license but had equivalent functionality as the one that was not allowed there haven't been any of those cases yet but if there were we would definitely want to work with them to get it because that's especially if it's a big you know that's the big fear is that you would have to rework a ton of engineering we work not because of anything that's wrong on a technical level but purely because the policy says that you can't use it but so far that has not been it hasn't been a real problem any questions alright thanks very much I'll be around uh out at the booth probably this afternoon so stop by the github booth and chat and grab some stickers and I'm happy to talk talk more about any any of this stuff thank you very much


Hey, so I'm in the office. Happy Saturday. I'm literally mapping out how we go to $10 million in with just a sales team in the back of our office, okay? So our sales team has been growing like crazy. We've got about a dozen sales people. We need about 24. I'm trying to think about how we break down walls. And I'm going to be sharing you everything that we do from recruiting, hiring, training, activity, energy, scaling, mapping out, profit and loss, hiring the right personality. When you do hire them, how do you keep them accountable, how do you track your numbers? Everything I know about building a sales team, okay, that will be close to a million bucks a month pretty soon. And how you can too, will be at this master class, how to build a eight figure sales team master class, okay? I'm going to show you a little behind the scenes of a big reason why we get a ton of leads for our sales team, all right? This is our studio. We get about, I would say we get about, now we're probably getting close to three to 400 people a week, reaching out, asking to do business with us. And I'm going to be sharing all those things, the marketing behind the scenes, how much should you spend per rep? How should you market? How should you advertise? What do you need to do to scale your own personal sales team? I'm going to be sharing all of that this next Tuesday night at five o'clock, okay? It's the eight figure, it's going to get you to think a little bigger. It's the eight figure sales team master class, how to scale your sales team, everything I know about scaling a sales team, how we've done it here and how you can too. So do me a favor, stop right now, click the link below. It's only 197 bucks. It'll be the best 197 bucks that you've ever invested and it'll get you thinking bigger about 2020, I guarantee it. I'll even add a personal disclaimer. If you hate it and you say, dude, I learned nothing, I'll give you your money back. Click them below, register right now. See you Tuesday.