Rules to keep you sane in the open source world: All Things Open 2025, Chris Short

So the Linux kernel is one of the best examples I can give of an open source project. Who in here has heard of Open Source Initiative? Okay, cool. Great. They basically created the definition for open source. Chris Short: And what makes up open source. They also handle like, hey, is this license in compliance with the open source definition, which is ten things - I don't know all of them. That's why I link to them. But the idea is that there's this organization out there that says yay or nay, and they have lawyers that work on staff, and they work with the community members to actually get new licenses approved or disapproved as open source.

Chris Short: Who's heard of Apache? Not the web server, the software foundation? Probably no one's heard of Apache, the web server, here, if you've only been in tech for like ten years or so. So yeah, Apache started as I think the web server, the foundation came along later. Maybe, if I remember that correctly. Don't hold me to that. Chris Short: Free software. Who has heard of the GNU public license? The Free Software Foundation made that license, which was then approved by OSI. So now we all use the Linux kernel and any number of things from our phones to our smart TVs to you name it.

If you modify something in GPL or general public license code, are you required to redistribute it? Chris Short: Yes. No, you're not required. But if you're going to distribute it in any form or fashion, you have to include your modifications along with the original source code so that others can pick it up and distribute it as they see fit. It's an interesting licensing scheme. Essentially, Free Software has all these licenses - GPL, LGPL, AGPL, version two, version three, version one is gone, thankfully. Chris Short: But those licenses carry some responsibilities when you're redistributing that code. And then who hasn't heard of the Linux Foundation?

So it's okay. Great. Awesome. I like to consider them like they're a nonprofit or - not a nonprofit - they are more of a trade organization as opposed to a nonprofit. What they do is create smaller subprojects or sub-foundations, for lack of a better term, that include, you know, all the people from a certain community. So like the Cloud Native Computing Foundation is the foundation that holds all the IP and trademarks and everything else for Kubernetes. Chris Short: CNCF is actually part of the Linux Foundation. So think of them as the foundation makers of the world.

They have a lot of open source foundations under them. I do not have a count. It's changing every day it feels like too. So what is open source? Chris Short: The OSI has a license review process. Includes, you know, legal professionals when it comes to intellectual property law, copyrights as well as industry experts. I have a friend that is part of the team that, you know, helps say a license is open source or not. And, you know, does the rigorous work to make that happen. Chris Short: There's tons of open source licenses. You can go to open source.org.

There's hundreds of open source licenses. I'm sure you can find one that meets your needs there, whatever they are, unless you're not doing open source. So best thing I can ask is, like, if you ever have a question about how to release something is to talk to your compliance or if you're lucky enough to have an open source program office, talk to them. Chris Short: They will have opinions. So the different licenses grant different freedoms or restrict them depending upon the wording. So choose wisely. There's a few we'll touch on here. The more popular ones, the more widely used ones. I can't talk about open source without talking about free software, which is kind of different.

So there's permissive licensing and then there's reciprocal licensing or what they call copyleft. Chris Short: We'll get into that in a second. But the GNU GPL was created by the Free Software Foundation so that they can build an entire operating system and all the tools necessary as something that is completely open source and free and redistributable and requires redistribution with the original source code. If you have ever used Linux, you have used a piece of code that is under the GPL. Chris Short: If you've ever made a product out of something that is the GPL, you then have to release it as open source because that's what the license says.

You have to redistribute this along with the original code and your modifications. So that has to go out to the world essentially. So the license is interesting in the fact that it helps perpetuate the same free software community in terms of, hey, this software is now something I can use freely and there's no cost or obligation for consumption. Chris Short: There is some obligations for redistributing anything under a certain license. So just keep that in mind. And obviously the general public license family is all OSI approved. Chris Short: So popular free software. Like I said, the Linux kernel. If you've used Ansible or VLC, the compiler GCC, Git, that's all licensed under a GPL, which keeps it nice and open and free, and no one person really controls it unless you're Linux.

So yeah, let's talk about the two kinds of licenses. So the APLs, the GPLs, the MPLs, those are considered weak or strong copyleft, right? Chris Short: The GPL is more strong copyleft as in this will perpetuate throughout anything - any modifications you make, you have to distribute them; you have to share them. And you know, even linking depending on how you link to it, that could, you know, flag a certain need for the license as well. Some things you can statically link, some things you need to link dynamically to actually be in compliance with the license. Chris Short: But this isn't a talk about licenses.

So think of it as copyleft or reciprocal in that the people need to reciprocate the licensing model or as permissive in terms of, like, the MIT license, the BSD license family, the Apache 2 license. Those are all considered permissive in that you don't have to necessarily take the code and your modifications and distribute them all freely. Chris Short: That's not required. You can do that, but it's not required. That's the biggest thing when it comes to licensing. So I always have to include this slide in any open source talk. Open source is not a business. That used to be very important ten years ago, not so much anymore.

People are starting to understand that now. Just doing something open source does not guarantee business success. Chris Short: Those are two very different things. Just keep that in mind. Okay. So let's talk about working and open source a little bit. I always like to say, you know, up front, don't take yourself too seriously. Right. Like, yes, the thing you are doing is very important, but what you are doing might not be important to the open source project you're trying to work with. Chris Short: So that's how you build context essentially is making sure that folks know what you're doing so you can help the project and the project can help you do that.

Not always cut and dry, but that's a good way to think about it. Feedback. You get a lot of feedback in open source - a lot. Some of it could be, you know, negative, some of it could be positive. Chris Short: But just remember: it's feedback. Don't take it personally. Right. That's the biggest thing. When someone questions something you've learned through pain and suffering and hard work. Yes, it's human nature to push back. But their pain, their suffering, their experiences are what led to them asking you to change something. Just keep that in mind, right? Like there's a two-way street of learned shared experiences.

Chris Short: It's an opportunity to improve yourself and your work. So use that feedback wisely and as a gift. Believe it or not, having somebody review your code is a gift because chances are, if it's all open source, they're not getting paid to do that. They're doing that of their own free will. Chris Short: Staying grounded in the here and now is something I like to tell folks, right? Like, don't worry about in five years from now, worry about the thing you're trying to tackle today. And if there's a series of events that need to happen for you to be able to tackle that, then break them down.

And, as always, with any open source project, community over product or company is something you will see. Chris Short: I know in the Kubernetes space you see that a lot because many, many, many companies have things based on Kubernetes or work with Kubernetes that are all open source, but they also make products out of them, which is totally fine. When you're working in the community, you need to put that community hat on and think with those community values versus corporate values or any other values in life. Chris Short: So like I said, in the Kubernetes community, it's actually even baked into our community values.

So go to https://www.kubernetes.dev/community/values/. And it's in there. So there's many open source projects that hold this mantra. Just keep that in mind. It literally is a different hat that you wear. Let's look. Let me give you an example of open source going wrong and somebody taking themselves too seriously. So before I worked at Amazon, there was somebody in the Amazon Web Services ether team - was using Clair, which is an open source container scanning tool. Red Hat, I think, released it originally. No, it was CoreOS, which was then acquired by Red Hat, and it's still open source, and it's very much commercialized by RedHat, which is great.

The Clair community announced something was going to change. They put it out on mailing lists. They shared it wherever they could. The whole world was supposed to know about it. Chris Short: It was a breaking change. So that's why they informed people ahead of the change. But that change broke something in some unknown or not widely consumed AWS product pipeline. So Clair was included as part of the tooling. You know, some user flag changed or something was added that you needed to, you know, modify to have Clair scan your containers in the CI/CD pipeline. Chris Short: And, a very, very prominent AWS customer - they have commercials that talk about what's in your wallet, I'll just say that.

They were asking for something to be done that included Clair, and that got delayed due to the need for this fix. That was communicated in advance, but AWS didn't pick up on, so… If you've never worked with anybody at Amazon, they're a different beast. Chris Short: They are very customer obsessed. It's one of their values, and that's great. But the problem is, when you're open source, the customer is literally everyone. So there's some responsibility of sharing, of, you know, hey, by the way, we're releasing this breaking change. Like they did their part, but for whatever reason, no one touched Clair in this one pipeline.

Chris Short: And thus it broke. They actually picked up the phone. A product manager on the AWS team, and literally chewed out an engineer at Red Hat for implementing the breaking change as they scheduled to do it. Chris Short: Which is not the right way to do open source in any way, shape or form. You need to be actively involved. You need to be on the mailing list. You need to be aware of the communications coming out of that open source project. Chris Short: Work upstream so that your downstream products and services are not impacted negatively, but are even better.

You can contribute back and make the project better for people like you who are doing the same things. That's kind of the idea. The for-profit company complaining to an open source project is not how you do open source. And you'll see that over and over again in the world, sadly. It's because of the paradigm between businesses and open source. Chris Short: That's very much an apples and oranges kind of comparison. Chris Short: All right. Be humble, be open, be honest. You would think being open and honest would be part of open source. But I have to tell people that. So just gonna throw that out there.

Like all things, people try to game the system, right? So learn from others. Have an open mind about that. Right? Like someone's been there longer than you. Chris Short: Take their feedback and, you know, use that feedback. Chris Short: Never make an assumption - like you should always check. And when I say check, that could mean check issues. Check the knowledge base. Check pull requests. Check the code base itself. You can go find the why behind almost every line of code being added to the project. Because hopefully there's pull requests, merge requests, depending upon which tool you're using - I think there's more, other kinds of requests now.

Always assume positive intent. Always be friendly. Like, these are things that are necessary, to do, like, really good work. Disagreements are normal. Passionate debate should be expected because there's a reason why the things, they are the way they are. And, you know, it's a two-way street. That whole: I'm doing this this way, you're doing it that way. Chris Short: You know, maybe both of you could learn something from the experience. Just keep that in mind. Welcome newcomers. So hey, welcome, everyone to open source! If no one said welcome before, I am the person that can welcome you. Be very open and honest, right?

Like, you don't need to ask questions in, like, a DM with somebody you trust. Chris Short: Unless it's like a security thing, right? Do it in the open so everyone else can benefit from it. Be that in a forum, Slack, Discord, insert chat tool here. Just make sure you're doing it in the public and always share what you learn with others. Having more than two people familiar with things prevents bottlenecks. It prevents single points of failure and enables very important contributors to take vacations, which we all deserve and kind of need in this life. Chris Short: So sharing things, documenting things, steps, you know, how-to-use, those guides.

The whole nine yards are all necessary parts. So feel free to share them. I think the biggest example of folks sharing knowledge is like right before any Kubertnes, like the ones that I see on a regular basis in my role in the Kubernetes community, are very much the released blogs from people that don't have a Kubernetes domain, right? Chris Short: Like all the Kubernetes vendor products tend to do some kind of release announcement if they have a feature that changes the way you use the product, and they include everything, because that's all open source and it's all licensed under Apache, which is awesome.

So there's no obligation to share things outside of how you distribute it. So everyone has their agenda and that's usually okay until it isn't. Show of hands. Who contributes to an open source community? Chris Short: Awesome. Can I ask you, or anyone for that matter? Why do you contribute to an open source community? Go ahead. “Because I run the tests that are in the open source projects. A lot of them are busted. So I just fix that.” Fixing tests. But why are you fixing the tests? Because you're the one using them. Chris Short: Okay. Interesting, Cool.

People contribute to projects for different reasons. I've worked on a project because work needed me to do something like package an RPM out of HAProxy, for example. It's a necessary thing that some companies need. You know, at work, I've done things, I very much have helped document or fix things so that I could use them. Chris Short: I've contributed to things that have, you know, helped me personally in my career. And that was the reason why. Right? Like, if you share, everyone has a reason for, you know, starting to contribute. If you share that, people will help you continue contributing and they'll help you find your way in a project, right.

Like, hey, I'm after this one feature or this one thing. Great. They will send you in the right direction to get you what you need. If you're just: I want to give back. I've used this project for a long time. I figured I could help somehow. Chris Short: That's also totally fine. And people will ask you what you're passionate about or the things you do. And, you know, as part of your job-job and how that applies to the project. So be open with folks about why you're there so they can help you find the right place to do that thing. Anyone heard the term ‘coopetition’?

Very normal in open source. Chris Short: Red Hat, Ubuntu, everyone. They all contribute back to the Linux kernel, but they all have their own products and, you know, downstream projects and so forth, so on. That's what we call coopetition - all these companies working together. If you work, if you've ever worked at Red Hat, you probably know that their relationship with Oracle is bad. Chris Short: But yeah, when I worked at Red Hat, I worked with people at Oracle because they were all working in open source along with me and the walls of the companies and the policies and everything else start crumbling down - like the teams I was on at AWS, I worked upstream with literally every company AWS told us never to talk to.

Chris Short: So that gives you an idea of what coopetition really is. We're all doing this to benefit a larger group of companies or people or users for that matter. Chris Short: Just remember that community over product is or community over company is always how those teams should operate. So if Red Hat comes up with a really novel feature, but the Linux kernel team wants it done differently, Red Hat might say, okay, fine, we'll release it as a different thing and create another open source project out of it. That's totally normal too - doesn't mean that's the way to do something, right?

Chris Short: There's always a different way to do everything. You know, I always say, like, share why you're there. Because it will help you find people with shared goals. So I started in documentation and side projects and moved on to other roles and side projects. I'm now leading an entire Kubernetes sub-project because I was interested in giving back and helping the Kubernetes community expand, essentially. Chris Short: So it's natural, it takes certain, it takes all kinds of people to do open source. So even if you're just really good at video, that skill would be appreciated by many number of projects, right?

Oh, great. You know, DaVinci Studio inside and out. I'm sure that project would really benefit from your skills. It's just finding the right way to contribute them. Chris Short: So always share those goals. And, when you're doing code reviews, make sure you review them objectively and subjectively. If there's a style guide from the project that is subjective and hopefully is reflected in the any commit or pull request you make - even blog posts for that matter get reviewed by somebody at some point. So there's always a chance that you will find something, and it's maybe not the most efficient way to do it.

Chris Short: So feel free to contribute more efficient ways to do it if you see something. Subjective reviews express opinions or feelings, you know, like, hey, I wouldn't have done this this way, but go ahead. You use four spaces for a tab. I use the actual tab. That's fine. Like unless there's a style guide that tells you to do something different, it's free game, essentially. So yeah, focus on correctness. Focus on the action that you actually want to have happen when communicating with somebody about a code review, right. Like the objective of: here of this ten line stanza is to do x.

So just put that out there because that's what matters right. Like what are you actually trying to accomplish? And if somebody can think of a better way to do that - awesome. Chris Short: Take that feedback and run with it. And never disguise your goals or your agendas because gatekeeping fiefdoms and clicks are basically poison to open source communities. So if you're adding a new feature, but you're very selective about who you work with, that's not exactly the most open way to do things. So be, you know, be open and honest about what you're trying to achieve, and the community will help you achieve that.

Chris Short: If they're interested. So yeah, also, you know, you represent yourself in open source to some extent. You can also represent your company to some extent. So just remember, you know, which side of the fence you're on as you're contributing. Some people contribute 100% independent of where they work, and they don't want those two identities to ever overlap either. Chris Short: So they do it under an anonymous name or something to that effect. And that's totally fine, because maybe even their employer doesn't want them contributing to open source for who knows why. But both can be true at the same time.

You can represent your company and yourself in open source. You can give your company, your entire company, a bad name if you're not careful. Chris Short: So just work within the confines of the project and their policies and rules and style guides and everything else. Chris Short: Curiosity will often help more than just you learn how to do something. So be curious. Feel free to ask questions. Everyone has a certain way they do things. This is why style guides are important. The way I write a Git commit message might not be the same as how you write a Git commit message.

And that's okay. Chris Short: Meet the community where they are and follow their guides. And, you know, use their expectations. And if there is no guide, don't be afraid to create one. Chris Short: If you're nitpicking things like line length or grammar, you may be spending too much time in code reviews and not enough on documentation. That's a good lesson learned there, right? Like, if you expect commits to be written a certain way, then there should be a guide on how to write those commits. And if there isn't, that can be a contribution in and of itself is just writing that guide.

Chris Short: Consider the positive alternative, the possible alternatives, right? Like they could be positive, they could be negative. But there are alternative ways to do almost everything in computing. So just keep that in mind and be open and honest with that feedback.