117. Open Source with Jim Jagielski

Speaker 1: Hello, and welcome to Codeish, an exploration of the lives of modern developers. Join us as we dive into topics like languages and frameworks, data and event driven architectures and, individual and team productivity, all tailored to developers and engineering leaders. This episode is part of our dev life series.

Alyssa Arvin: Welcome to Codeish. My name is Alyssa Arvin and I am a senior manager for the open source programs office at Salesforce. I am joined here today with the newest member of Salesforce's OSPO, Jim Jagielski.

Jim Jagielski: Hello everyone. Glad to be here.

Alyssa Arvin: You have a very impressive background within the open source world. Would you mind giving us a run through of what you've done throughout your impressive career?

Jim Jagielski: I actually started off in my first introduction to open source was back when I was working for NASA. I was actually a rocket scientist in many ways. And my job was really in programming the power systems for spacecraft up there in a technique called modeling and simulation. And it was basically to ensure that the sizes of the solar rays and the sizes of the batteries were sufficient so all the experiments could go on inside the spacecraft. And because it really involved a lot of programming, my platform of choice was Unix, basically because of my experience with it back in college. Now at NASA, all we had were VAX VMS machines, not Unix, but we were also migrating to the PC platform. We were moving away from mainframes, moving towards, PCs and Mac's. And around that time, Apple actually came out with their own flavor of Unix called A/UX. And being a big Apple fan myself and being a big Unix fan myself, this was just a natural platform for me.

Jim Jagielski: So early on at NASA, I migrated over to a Macintosh running A/UX, and I started porting a bunch of internet related programs and demons and applications over to this platform. And porting is basically just translating it. It was available. All these programs were available for SAN OS and Solaris, for Linux at the time, but not really for Apple A/UX. And that's what really got me started in the open source movement, because at that time, all the basic infrastructure of the internet, things like sendmail, things like a DNS BIND were all open source, they were all available under very permissive licenses. And even though we didn't call it open source, it was all about collaborative and sharing the software. And that environment really intrigued me because, as I said before, it made my job much easier to port these very important programs over to this platform that I was using, but I also enjoy the idea that I was interacting and collaborating with a huge numbers of people out there.

Jim Jagielski: And so as the internet became very much more successful and the worldwide web started taking off, that really intrigued me more than the engineering I was doing at NASA. And I became really more well-known with my involvement and engagement with the internet and Apple A/UX. Then with my work that I was doing at NASA. It was also around this time that I started my own side business called jaguNET, which was an ISB, an internet service provider. We provided dial up and web hosting, and that's what got me involved with web server technology. At the time, the Apache web server was just ticking off. So I was almost part of the original members of the Apache group. That parlayed itself into the Apache Software Foundation. And that was really my first major involvement and notice or reputation in the open-source community, was being one of the co-founders of the Apache Software Foundation. And what was really great about that is that really for almost 20 years, I served on the board of the ASF. The ASF is a member based organization.

Alyssa Arvin: Sorry, I was going to say ASF stands for the Apache software foundation, correct?

Jim Jagielski: Yes, it does, the Apache Software Foundation. Good catch.

Alyssa Arvin: And what would you say to someone who's either just starting out in open source, or maybe they'd been contributing to open source, but just let's say on the developer side, what would you suggest they do to start getting more involved in the open source world?

Jim Jagielski: Open source and open source projects really allow all contributors, not just code contributors, but people who develop and contribute all kinds of content and media and talents and skills to really engage with a lot of different people out there. And so find an open source project or a set of open source projects that you are passionate about, because, in general, most of the people who are involved in those projects are also passionate in there as well. So even though there are projects that you may want or need to contribute due to your day job or something that you're somewhat interested in, but you feel compelled to contribute on that, open source also provides you the opportunity to engage your passions.

Jim Jagielski: And so I would definitely make sure that you're looking at open source projects and communities that you feel welcomed in, that have a very serious engagement and adherence to diversity and inclusion standards, make sure the community is healthy and engaging and warm and welcoming because what you're doing when you're a member of an open source project and you're contributing is that you really are giving a lot of yourself, your talents and your skills, a lot of your heart and soul into this community. And you should really do that to a community that appreciates it.

Jim Jagielski: So really spend some time finding the right project for you. Don't limit yourself to one technology area and to really, if you're inside of a project or a community and it starts becoming toxic or unhealthy, and you're not getting that much out of it, give yourself the freedom, the flexibility to walk away. There are plenty of other projects which I am positive would entertain you and enthrall you. So just be good to yourself, because there are really a lot of projects out there which are just champing at the bit for everyone's talents and skills.

Alyssa Arvin: I love that part you said that open source is giving a piece of yourself to that projects. I also like how you mentioned find a project that has a focus on diversity and inclusion and has a welcoming community, I know that's something we focus on when we're promoting projects internally. So one way we do that is to look for a code of conduct that the project will have. What are some other tips and tricks to see from the beginning if a project is welcoming and has an emphasis on diversity and inclusion?

Jim Jagielski: I definitely think that the code of conduct is primary in parcel. You definitely need to make sure that the open source project and the open source foundation, if it's under a foundation, has that inside there and that they take it seriously, that they just don't give it lip service. And you can certainly figure out how seriously they take that by the amount of resources they put into monitoring the code and conduct considerations, as well as making sure that people are abiding by it.

Jim Jagielski: The other great thing about open source in general is that most of the activity, most of the communication is done on open, public transparent medias. Sometimes Slack channels. A lot of times it's email lists and these are easily archivable and searchable. So you can really get a very good historical perspective of the history of a project by looking over some of these archives. And I think that's another great way of figuring out whether the project you want to be involved with is really worth your time. And the other thing is by looking at the resources they do to encourage contributions. There are still a number of open-source projects where the only contributions of quote merit are code contributions, which I think is really disastrous. Open-source projects to be successful, to thrive, to be healthy, really require a very wide range of diverse contributions and a wide range of diverse contributors as well.

Alyssa Arvin: So around that diversity side of things, when you're just starting out with a project or you become a core contributor for a project, how do you go about marketing the project to make sure that it is reaching a diverse audience and you're not just hitting up your buddies for contribution, so you make sure you're expanding the circle of contributors?

Jim Jagielski: Yeah, I think the use of social media is definitely a way of doing that. Making sure that the external world is aware that all contributions have value, that all contributions have merit is very important. I also think that in many ways by leveraging the people, the end users, who are using the software project, who are using the open source program that you're developing, whether these are individual people or whether they are corporate customers, they can also go a long way in reinforcing the value and the imperative of having diverse communities, diverse contributors, and diverse contributions come inside there.

Jim Jagielski: It really isn't just something that the current contributors are worried about or should be worried about. It really is an aspect that the entire community needs to be concerned about. And the community is more than just the contributors. The community really are the end-users, the companies and the organizations that consume it. Whether or not they give contributions back or not is in some ways irrelevant because by consuming an open source project, a company is basically almost implicitly supporting the project. And I think by doing that, they also have, in some ways, an imperative to make sure that the project they're consuming matches the value systems that they have inside of the company themselves.

Alyssa Arvin: Yeah. I think that was a great thing and expanded my way of looking at it and I'm sure it did other people is it's not just the contributors, it's the people who are using the project as well.

Jim Jagielski: One way of looking at it is that when companies and corporations use and consume open source projects, they provide technical feedback on issues, problems, enhancements that need to be added to the open-source project to make it much more usable and viable to a larger user community. That very tight feedback loop, again, I think is what sets open source and the open source development methodology different from the old stoic ways of developing open source where people would create software and told you this is what you want rather than end user is saying, "No, this is what I want. And in fact, I'll even spend some time and resources in adding that flavor inside of it."

Alyssa Arvin: It's great that the end users are getting what they want. I'm sure that puts some stress onto the actual open source projects.

Jim Jagielski: It can, yes.

Alyssa Arvin: Would you say that is the most challenging part of open source or what do you think is the most challenging part of running an open source project?

Jim Jagielski: I Definitely think that the interaction, the dynamics between the corporate expectations of software development and the relatively holistic organic drives of community are basically the biggest things that need to be resolved and worked on. There was a point in time when open source projects said, "We release software when it's ready, we don't adhere to artificial release schedules, for example." The idea being that, again, because it was done by volunteers, you wanted them to have the freedom and flexibility to do that.

Jim Jagielski: And so the issue would be that okay, well, if the open source project doesn't have a formal official release, where do we as a company consuming open source say, "Okay, at this commit level, or at this particular point in time in the open source repository, do we go and use internally?" That's really becoming less and less of an issue now as people who are contributing to open source see that it's really in their best interest to have a much more reliable, robust and known release schedule inside there. It's not process for process sake. You're not corporizing open source, but basically again, you're making it easier for people to consume open source. And as I said earlier, that is really something that open source contributors want to do. You do this because you want people to use open source.

Alyssa Arvin: So I want to go back, since we're talking so much about corporations using open source, and go back to the individual contributor at this point. So let's say, especially at Salesforce, we're a really large company, we definitely encourage open source contributions, but how would you give the tools to an individual contributor to carve away the time to contribute to open source, convince their management that this is important to my work, my personal development and the company as a whole?

Jim Jagielski: There are a couple of ways of looking at that. First of all, obviously if the project that you're working on inside of your company is using open source. And so the contributions or the enhancements or there fixes that you're doing as part of your day job directly touch the open source project that you're using. One of the things that you don't want to do from a corporate standpoint is to create this slowly but increasingly diverging fork of the open source project in your internal implementation of that open source project. Because what will happen is that as that fork starts really incredibly diverging, it becomes much more difficult to pull back into your internal copy of the open source project, the enhancements and fixes and patches and improvements that are folded into the external open source project. And so you're incurring a huge amount of technical debt by doing that.

Jim Jagielski: So just by encouraging the people to contribute those patches back upstream to the open source project means that as a company you avoid that sense of technical debt, which is incredibly important and it helps ensure that your software project internally is still as healthy and as viable and as risk-free as possible, because you're not only gaining the advantages of everyone inside the company running the tests on the software, but you're also getting the assurance of the external open source community as well. And there are even parts in parcels of people's growth plan that this, again, falls in great alignment with I want to become a better engineer, I want to become a better documentation writer, I want to become a better technical writer. Well by leveraging and using the experience you're gaining in open source, you're becoming a better employee and a better asset to the company as well. So there are a lot of reasons why it makes sense. Not only for the individual contributor, but also for management to encourage a relatively healthy and as friction free process as possible for external open-source contributions.

Alyssa Arvin: So for you personally, as you have changed companies within your career, and of course now landing at Salesforce, how important was the company's involvement in open source? And adding onto that, for Salesforce as well, why did you end up choosing Salesforce as your next step in your career?

Jim Jagielski: I've seen in my career a wide range of different open source program offices out there in the corporate landscape. There are some which still, even to this day, see open sources like I don't understand why we need to get involved with open source, and just ignore it. And for someone who takes open sources seriously, as passionate as I do, and many other people do, that's not the kind of company you you want to work for. There are also companies in open source program offices that see open source as a necessary evil and well, we have to engage with an open source project. So we might as well have some processes and procedures to make sure we do that right.

Jim Jagielski: Again, that's not the sort of company that gives you the warm and fuzzy feeling that you want as far as their passion for open source, their engagement inside of open source. Salesforce was definitely different about that. Salesforce obviously sees open source as a strategic advantage for the company, but they also understand that it's a way of driving culture. It's a way of ensuring that teams collaborate, communicate, and in the process of doing that, driving the innovation that comes inside of that, and it really benefits not only the individuals involved, but the companies that understand the basics of it as well.

Alyssa Arvin: So if I was working at a company right now that didn't have an OSPO, this podcast would convince me to start it and start prioritizing open source there...

Jim Jagielski: I would hope so, yes.

Alyssa Arvin: But let's say I work at X company, we don't have an OSPO yet. What are the steps we should take to start this OSPO?

Jim Jagielski: The real key aspect of creating an OSPO is making sure that you understand the reasons behind it. It really depends on how important and how valid open source is to you and your corporate culture. And I understand that for some companies it really may not be important. I don't think that's the correct long-term vision for a company, but if that's the case, then I would definitely make sure that you're doing open source correctly, that you're abiding by the community standards of the open source project that you're working with. And I think that's the biggest thing, is realizing that as you create and formulate and grow an open source program office, one of the biggest things you'll be doing is working with and learning from an external open source community associated with a project. But it really is, at the end of the day, a cultural shift. It is an idea that you are working with and collaborating with external entities, external people using open source code.

Jim Jagielski: And you want to ensure that you're a good corporate citizen, that you're a good community member out there. Make sure you're open and honest with open source communities, make sure that your engagement with the open source communities in a very transparent way. Make sure that you're aware of the governance structures of that. If you have an open source project and you are open sourcing it and releasing it to the open source community, that's what's really important, I think the open source community, is that they know what they're getting into and you don't change it for them. There are a lot of great resources out there.

Jim Jagielski: First of all, I think that as a company gets involved with open source and starts creating open source program office, really understand that you're engaging with a community and engaging with people inside the community. And so for that situation I would really recommend Jono Bacon's book, People Powered, but it really is a good example and a good write up on why companies should worry about why that interaction with people and communities makes sense. There's also a group of people from various OSPO's around the world called the TODO Group . That's T-O-D-O group. It's a self foundation under the Linux Foundation, and they provide a lot of resources and guides as far as how to create an open source program office, how to encourage management to create an open source program office, things such as what sort of procedures and processes need to be in place.

Jim Jagielski: Now, it isn't certainly a one size fits all environment, but it's another fantastic resource. Another, I think, resource that would be very useful as far as understanding how you can basically leverage some of the lessons learned of open source projects inside of your internal software development methodologies, there's a process or a methodology called inner source in addition to open source, there's the InnerSource Commons consortium. And this really is another good resource that would encourage people to understand how not only to engage with the open source community, but also how to take some of these open source methodologies as far as software development and bring those in-house. And finally, I would be remiss in not suggesting people also look at what we call the Apache way. These are basically the set of guidelines, some basic fundamental tenants on how the ASF, the Apache Software Foundation, creates and runs open source projects. And I think that's most probably one of the guiding examples of successful open source projects or the projects under the ASF, under the Apache Foundation.

Alyssa Arvin: What are some other resources that you have found throughout your career, let's start with people who are contributing for the first time, that they don't really know how or where to get started? So we talked about finding the right community, but some people don't even know exactly how to get started on open source. Are there any talks or podcasts resources that they could check out to get started?

Jim Jagielski: I'm a big advocate as I may have mentioned earlier to work on various open-source projects, to basically look at the Slack channels, follow them along, read the email list and stuff like that, to get a feel for the vibe of an open source community and make sure it's one that you want to be involved in. Also, look at whatever their bug tracker is, whether it's Jira or GitHub Issues or something like that. The really good projects, the really good communities, the ones that really want to encourage first time contributors to come on board will usually have some flag or tag called good first issue or good for newbies or something like that. So search for them, these are issues or bugs or enhancements which are specifically designed to be relatively easy for someone who's not exactly sure what to do, but also provide basically immediate value and immediate feedback to the first time contributor.

Jim Jagielski: Usually these projects also have at least one or two people who are signed up to be good mentors for these people. So if they see, for example, someone says, "Hey, I'm interested in working on this GitHub issue inside here. And this is a patch I'm looking at maybe contributing," there'll be someone who will help you and guide you and saying, "Okay, that's a pretty good patch. Have you thought about this?" Instead of just saying, "Nope, not good enough. Try again." Those are the kind of communities that you definitely want to avoid. It's really incumbent upon projects to do that.

Jim Jagielski: So then most of the projects, as I've mentioned before, are really encouraging that. So look for projects that have dedicated mentors or have an incubator or onboarding process for new contributors and new community members. Look for projects that have specifically set aside projects or issues for new contributing members as well. These are the ones that are very attractive and promising to people who want to become much more involved in an open source project. And those are the ones that have a contributing .md file or something like that that makes it clear how you can get involved and what the future will hold for you as you do become involved.

Alyssa Arvin: Well, thank you so much, Jim, for joining us. We're so excited to have you as a part of the Salesforce open source team. I know I personally am so excited to work alongside you and see what we can do both internally at Salesforce with open source, but also what we can bring externally as well.

Speaker 4: Fantastic. Yes. I'm looking forward to it as well. Believe me.

Speaker 1: Thanks for joining us for this episode of the Codeish Podcast. Codeish is produced by Heroku, the easiest way to deploy, manage, and scale your applications in the cloud. If you'd like to learn more about Codeish or any of Heroku's podcasts, please visit heroku.com/podcasts.