 Hello and welcome to this presentation about writing good open source contribution policies. Open source contribution policies are often long and difficult to read documents that don't really answer the questions that software engineers tend to have as to what they can actually do when it comes to open source. This presentation will try to clarify this and really help you write good open source contribution policies. So the first question is actually whether you have such a policy to begin with or not. And when that question was asked by a survey from the Newstack and the Linux Foundation a couple of years ago, the answer was that actually most organizations didn't have one. It was a bit different when we asked smaller organizations which close to two thirds of which didn't have a policy and really large organizations was more than 10,000 employees where we really saw that more than two, well close to two thirds of them, they'd actually have such a policy. But what really we should be thinking about here is that this is a highly biased sample. If you broaden this beyond open source savvy organizations, we're probably going to have very different answers. So this obviously begs the question as to what does it mean not to have an open source policy and actually what it really means is that you don't have a written one. Of course you have a policy. It's just not necessarily on paper. And that policy can go from no open source at all to anything goes. And on the other hand having a policy doesn't give you necessarily a pass as I was saying before. That policy can be very restrictive and can be very bureaucratic and can be very opaque and none of these are good things for an open source policy. So let's try to graph how different organizations behave about their policy. On the full quadrant graph we have explicitness like how explicit your policy is on top, how implicit it is, whether it's implicit at the bottom and whether it's restrictive or permissive on the x-axis. So if we put small organizations as we saw before, well these tend to be fairly permissive in their open source practices in general but fairly implicit about them. Rarely have an actual document that describes this. Startups tend to be implicit about everything and they tend to be less permissive about open source because they're really essentially focused on product. Non-tech larger organizations tend to be really restrictive about open source but still really implicit. If you move to older tech companies, well they used to be fairly explicit about not doing open source. So explicit and restrictive. Of course patent trolls will be all over there being highly explicit about open source being something they really don't want to hear about. And if you move to tech companies, you will see increasing explicitness and permissiveness with all the trendsetters that are really explicit and permissive. Let's have a look at what that means in terms of lifecycle for an organization. Starting for example with a startup. So startup starts to be fairly product focused but as the startup scales, it starts to really rely on increasing infrastructure and as we know all of that infrastructure today, well I mean most of it is really open source and so you will see sort of the practice becoming more permissive as info engineers come in and they actually want to upstream some of the fixes that they do, maybe collaborate upstream, et cetera. And suddenly there's an event. It could be some compliance requirements. It could be an IPO, it could be an M&A or even like the prep for an M&A and you start to have lawyers coming in and as a result well the policies become a lot more explicit but also in general a lot more restrictive. And really that's not the kind of outcome that you would like to see. The outcome that you would like instead is more expliciteness but the same level of permissiveness if not an increased level of permissiveness. Alright moving to all tech companies we've seen a lot of those over the course of the last decade. The canonical example of course being Microsoft moved from being extremely restrictive to being increasingly permissive about open source which is a great thing. None tech, large organizations as they sort of digitally transform tend to want to be more explicit about their practices and so they do and unfortunately they don't become more permissive as a result of being more explicit. Again here what we'd like to see is sort of like this move to being more explicit but also at the same time more permissive. And so really what we really clearly see here is that we want organizations to become more explicit more clear in their practices but also more permissive so that engineers working for them can really participate in the broader open source ecosystem. Alright so what exactly is an a policy that doesn't suck? Well it's really a question of perspective right? Engineers, lawyers and business people will have different ideas about that and so let's look at each of them separately. From an engineering perspective a good policy is permissive that means that you can really trust your employees to do as much as they can and really allow them to participate in this broad open source culture that is really an interesting part of software engineering today. You want it to be explicit so it's clear what it is that you can do and cannot do. You want it to be informative so that when there's something that you cannot do the engineers actually understand why and as a result sort of like bring that knowledge into their decision making process of what software to rely on for example and again gives them a stronger and more solid base to be trusted and have autonomy in their decision making about this. And lastly of course you want this to be frictionless you don't want to have red tape around your policies you don't want e-max changes for like a single pull request etc. On the legal side what you want is to minimize risk you want to avoid giving away competitive advantage giving away IP that you are planning to use defensively you want to avoid infringement accidental reputational damages etc. You want that policy to be followed across the whole company it's nothing worse than having open source software happen without the lawyers being aware of what's going on you want that policy to be savvy about written information sometimes you really want things to be in written for compliance and sometimes you don't and really most importantly you want that policy to be able to surface critical problems and not drown them in the sea of menial issues you want to be able to focus on the hard decisions and not the trivial stuff. Alright and from a business perspective what does that mean? Well you essentially want to bounce of the legal requirements and the engineering requirements that fit the business model of the organization so you want engineering happy and productive you want legal to be able to understand and minimize the risks you want good communication between the two and again you want alignment with your business goals and so in order to be able to do that what you have to really acknowledge, understand is the tension there is between legal and engineering and that tension is good it's there on purpose engineering is there to innovate and legal is there to mitigate risk and so as a result like we have that tension and depending on what kind of company you have you will sort of shift the behavior towards one side or the other and then the other things that you really want to understand also is that these two organizations traditionally behave think are organized in very different ways lawyers tend to prefer oral communication the phone they're on a manager's schedule with lots of meetings across the day their favorite spectrum thinking like they're all about the gray area whereas engineering is really focused on whether things are true or false in general and they really have a conservative role in an organization whereas engineering is all about innovation and engineers tend to prefer asynchronous written communication and are on a makers schedule in general so coming to agreement essentially means you have to acknowledge that tension that's what checks and balances are this is good listen to both sides and remind both sides that their role is to achieve common business goals if you leave legal, minimize all of the risks well I mean there's not going to be any innovation done anymore because everything is sort of risky on the other hand if you don't tie engineering's hands a tiny bit you really risk the company's survival what if you open source a key piece of IP that would be a really problematic so really find common ground between the two and know and remember and tell them that a good policy would actually help both of these sides not just one this is not something that's for the benefit of one point of the organization against the other it has to be mutually beneficial for it to be well lived, approved and properly implemented by all sides again align that with your business goals and lastly know that it will change as your business changes as we've seen in the start-up example earlier so what really is an open source policy about well an open source policy is about two things it's about contributing to open source on one side and using open source on the other and we'll focus first briefly on using open source so using open source is a well understood problem today we know what to do, we know how to do it the only hard thing is actually getting really actually doing it so it's really essentially about compliance but it's also about security about making sure that the open source software supply chain as we are starting to think about this today is sustainable and those are challenging questions challenging industry questions today but from an open source policy perspective these are wellness of problems so what I really want to do today is to focus on contributing to open source and to do that we're going to look at contributing at work and contributing outside of work so let's start by contributing outside of work if you ask employees of an open source sorry of tech like engineers whether they're allowed to contribute to open source on their free time or not you're going to get lots of different answers some will say yes absolutely some will say yeah but actually I have to ask for permission which sometimes means that I'm not allowed to some will say well I don't really know and then some will say no I am not allowed to do that at all and so we have data on this again this is from a 2017 GitHub survey of actual open source contributors which I find when you look at the data and you know where that data comes from that is kind of scary to me right so outside of those open source contributors 47% said yes I'm allowed to contribute to open source on my own time 12% said that they had to ask and 37% said that they had no idea and that is to me really really concerning and again like this is also a super biased sample so keep that in mind I think if you broaden that to whole software engineers they don't know what would probably be a much bigger and so why is there so much confusion well that's actually fairly simple it's because the laws around this are very specific to different countries and even different states in the US for example and lots of the US companies own employees production 24-7 if you find something really smart at home or in your shower well it belongs to your employer and then some states have different criteria for example in California if you're working outside of work but they're using your company's equipment to do that like a company laptop well whatever you're creating belongs to your company and all of this tends to really prevent employees from actually contributing to open source and unless they actually are granted permission to do so and in general this is a tedious process a documented process but a tedious one it's usually for large projects and it's limited you have to get projects pre-approved it's a lot of work it's a lot of back and forth a lot of engineers don't do it and this creates lots of misery down the road when there's disagreement as to who owns what and so on and also as we moved increasingly into software with a high number of dependencies that makes it pretty much impossible to concretely work with on a day-to-day basis so there's a better solution to this and that better solution is called BAPA it's the Balanced Employee IP Agreement it's an IP agreement that GitHub created a few years ago based on their own IP agreement and it really sort of scopes the claim of the employer to creations that are made for or relating to the company's business I think like all of you should adopt something like this because it's just much clearer and much better and matches the mental model that everyone has much better and so really strong recommendation here and as you see what's interesting about this is good contribution policies has impact that's broader than the policy itself for example on employee agreements so let's now focus on contributing at work and when we focus on contributing at work well there are really two points to it one point which is patching software and the other one which is actually releasing software that you've created within your own organization and sharing that with the world let's start with that here we see that you want to make first of all really distinguish large open source projects from tiny things if you've written a small really tiny module a large example some integration samples really make it super easy for those to be open sourced Google had this excellent sort of like smaller code and a hundred lines of code rule which is really good thumb rule that you can apply if you have built trust and autonomy in your engineering organization to be always open source for everything else the large projects what matters first of all of course is to make sure that the team that is releasing it wants to continue maintaining that software long term because you don't want to do the open source sort of like throw over the wall kind of strategy it's bad for your organization it's bad for the open source ecosystem it makes you look bad like you really shouldn't be doing this have well-oiled and well-documented processes checklists, templates, tooling to do all of this there are great examples of that on the to the group repository and policies repository and really if you have an OSPO make the OSPO sort of really help new projects to figure out how to work in the open because that's different talking of which I would strongly advise you to promote working in the open from the get-go whenever that's possible because that makes the whole process way smoother lot less risky easier to build a community on top of it the only downside of course is you have to lose the opportunity to have this big release bang but I think this is really something that we have to balance and maybe stop considering open source projects as products that you want to market as much unless it is really at the core of your business so last but not least patching why is patching super important? because it's the most common activity and the most important one in software development when it's tied to open source and you want to make that as frictionless as possible today really open source is part of this broad network of software that you rely on and contribute back to and so you really want to make it super easy for your organizations your organization to be participating in that ecosystem in a smooth way how do you make upfront decisions about what your engineers can do and cannot do you can use approving and denialists for that and you really let legal focus on the difficult cases and as you make those more difficult decisions you document those and you build them into your approving denialists and so it makes it increasingly fast for your organization to be able to make decisions about this and avoids wasting everyone's time okay so we've looked at what makes a really good open source contributing policy it deals with using open source it deals with contributing open source outside and inside of work and then about specifically releasing and patching software but we can actually do more than that and we can turn those policies into services or applications those lists that you were thinking about before you can really essentially automate a lot of the stuff around pre-established requirements for example it's okay to patch anything that's MIT licensed on GitHub maybe that's okay for your organization and you can also automatically reject things that you really don't want to do and again manually handle the rest and so by doing this Adobe was actually able to shorten the review time for everything from roughly a week to roughly half a day and this is for the things that needed to be reviewed all of the rest that had been automated that had been pre-cached was suddenly instantaneous for their software engineers and this has a lot of benefits because as you build software like this you can start to collect data about your open source practices you can start knowing what open source projects are we actually contributing to a lot would it make sense to hire maybe from this project you can start promoting what you do you can start connecting organizations within your org departments buying on the same piece of software but didn't know that we're doing that you can really create a lot of very valuable things on top of this and folks that's all I have for you today thank you very much for attending this talk if you want to continue this conversation my email is right here it's toby at unlockopen.com if you want help implementing policies like this within your organization this is part of what I do as an open source consultant if you want to help automating it this is also something I can help you with feel free to reach out either way thank you very much for your time bye bye