Open Source with Jim Jagielski
28:08 Share

Hello, and welcome to Kodish, 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 DevLive series.

Welcome to Kodish. 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. Hello everyone. Glad to be here. 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?

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 arrays 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 Macs.

And around that time, Apple actually came out with their own flavor of Unix called AUX.

And being a big Apple fan myself and being a big Unix fan myself, this was just a natural platform for me. So early on at NASA, I migrated over to a Macintosh running AUX. And I started porting a bunch of Internet related programs and daemons and applications over to this platform. And porting is basically just translating it. It was available. All these programs were available for Sun OS and Solaris.

for Linux at the time, but not really for Apple AUX. 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 DNS bind were all open source. They were all available under very, 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, very important programs over to this platform that I was using.

But I also enjoy the idea that I was interacting and collaborating with huge numbers of people out there. And so as the internet became very, very much more successful and the World Wide 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 AUX

than 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 ISP, 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 kicking off, so I was almost one of the original members of the Apache group.

That parlayed itself into the Apache Software Foundation. And that was really my, I guess, 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 like 20 years, I served on the board of the ASF. The ASF is a member-based organization. Sorry, I was going to say the ASF stands for the Apache Software Foundation. Yes, yes, it does. The Apache Software Foundation. Good catch.

And what would you say to someone who's either just starting out in open source or maybe they've 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? 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

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. 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 impact.

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

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.

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 community and it starts becoming toxic or unhealthy and you're not getting that much out of it, give yourself the freedom and the flexibility to walk away. There are plenty of other projects which I am positive about.

would entertain you and enthrall you. And so just be good to yourself because there are really a lot of projects out there which are just, you know, champing at the bit for everyone's talents and skills.

I love that part. You said that open source is giving a piece of yourself to that project. I also like how you mentioned, you know, find a project that has a focus on diversity and inclusion and is 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

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?

I definitely think that the code of conduct is primary and 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 don't give it lip service. And you can certainly figure out how seriously 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. 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, you know, 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, really, 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. 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 contributions to make sure you're expanding the circle of contributors? 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 imperative of having diverse communities, diverse contributors, and diverse contributions come inside there. 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.

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.

Yeah, I think that was a great thing and kind of 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. Yeah, I think 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 sort of very, 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 you

people would create software and told you this is what you want rather than end users 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. You know, 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. 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? I definitely think that the interaction, the dynamics between the corporate expectations of software development

and the relatively holistic, organic way

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, you know, we release software when it's ready. We don't adhere to, you know, 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.

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 sort of like 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.

So I want to kind of 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, you know, 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 say,

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.

There are a couple 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 the 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 and 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 and

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.

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 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 and parcels of people's, you know, 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.

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 I guess adding on to that for Salesforce as well, why did you end up choosing Salesforce as your next step in your career?

You know, I've seen in my career a wide range of different sort of open source program offices out there in the corporate landscape. You know, there are some which still even to this day see open sources like I don't I don't understand why we need to get involved with open source, you know, anymore.

and just ignore it. And for someone who takes open source as seriously and passionately as I do, and many, many other people do, that's not the kind of company you want to work for. There are also companies and open source program offices that see open source as sort of like a necessary evil, and, well, we have to engage with an open source project.

So we may as well have some processes and procedures to make sure we do that right. 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. 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. I would hope so, yes.

But let's say, you know, I work at X company. We don't have an OSPO yet. What are the steps we should take to start this OSPO? One 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, you know, 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 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 open source communities in a very transparent way. Make sure that they are aware of the governance structures, that if you have an open source project, then you are open sourcing it and releasing it to the open source community.

That's what's really important, I think, to 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. 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 the community and engaging with people inside the community. And so for that situation, I would really recommend John O'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 is also a group of people from various OSPOs around the world called the TODO group. That's T-O-D-O group. It's sort of like a sub-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. Now, it isn't certainly a one size fits all kind of 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 is

inside of your internal software development and methodologies. There's a process or a methodology called Inner Source in addition to Open Source. There's the Inner Source 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 tenets 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.

What are some other resources that you have found throughout your career that 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, you know, 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 podcast resources that they could check out to get started? Um,

I'm a big advocate, as I may have mentioned earlier, to lurk on various open source projects, to basically, you know, look at the Slack channels, follow them along, read the email list and stuff like that. To sort of like 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, 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 sort of 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 contributors.

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 this.

you know, 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 in saying, OK, that's a pretty good patch. Have you thought about this? Instead of just, you know, saying, nope, not good enough, try again. You know, those are the kind of communities that you definitely want to avoid. It's really incumbent upon projects to do that. So most of the projects, as I mentioned before,

really encouraging that. So look for projects that have dedicated mentors or have sort of like an incubator or an 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.

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. Fantastic. Yes, I'm looking forward to it as well. Believe me.

Thanks for joining us for this episode of the Kodish Podcast. Kodish 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 Kodish or any of Heroku's podcasts, please visit heroku.com slash podcasts.