Spearheading Open Source: A Conversation with Jim Jagielski, Staff Technical Program Manager with the Uber Open Source Program Office


Jim Jagielski’s fascination with open source software began out of necessity. He was working at NASA Goddard in the 1980s, and the agency had just received fancy new Macintosh computers loaded with Apple’s new A/UX operating system. There was only one problem: None of the tools Jagielski needed ran on A/UX. It fell to Jagielski to port everything himself.

“That’s what got me involved in open source,” says Jagielski. “The idea of being able to take this source code, add patches to it, get it running on your system, and then provide those patches upstream so the community benefited—that seemed really neat to me.”

Neat enough that Jagielski dedicated his life to open source, going on to help found the Apache Software Foundation. “I’ve always said that open source has done more for me than I can ever give back to open source,” he says. Jagielski served on the board at Apache for nearly two decades, proving a tireless advocate for open source software and a staunch defender of the so-called “Apache Way.” 

It’s said that no two members interpret the Apache Way the same, but when asked for his own definition Jagielski talks at length about fostering community around projects, ensuring everyone has a fair chance to contribute, and a desire for transparency and openness. Directives any good open source advocate should live by.

And Jagielski now brings these beliefs with him to Uber’s Open Source Program, where he recently joined as a Staff Program Manager. Having resigned from the Apache board in 2019 in order to make way for a new generation of talent, Jagielski is set to help direct Uber’s open source efforts and figure out how best to contribute back to the community. 

“The opportunity to join Uber in the Open Source Program Office was a perfect opportunity,” he says. “Everything I’ve been learning about the last several decades, I’ll be able to put into my efforts at Uber.”

We sat down with Jim to discuss his passion for open source software, what that passion looks like post-Apache, and how he plans to keep advocating for open source from within Uber.

How did the Apache Group and Apache Software Foundation come about?

Back when the internet was starting out, the most popular web server software was called the NCSA web server. I owned a small independent web hosting company and ISP called jaguNET, a small ISP web hosting business I ran out of my house. NCSA was vital to that business. I needed it up and running. 

Unfortunately NCSA was developed primarily by a single person, Rob McCool, and when he left NCSA to join Netscape a bunch of people were left without a piece of software that they all depended on. There was nobody really developing it, so we pulled ourselves up by the bootstraps, created this informal group of people that we called the Apache Group, and that’s what started the Apache web server project.

A lot of the basic tenets of The Apache Way arose from that origin story. We depended on a piece of software that actually had no long term future, and we wanted to ensure that nobody else would be left in that situation again.

Can you explain the Apache Way and what it constitutes?

The Apache Way is all about ensuring there is a community that can survive the ebb and flows of volunteer efforts and corporate interests and corporate sponsorships. Building an open source project is important, but creating a healthy and viable and long term community around that open source project is really the focus of what Apache does.  

There are three major principles of the Apache Way. First of all, there is this idea of meritocracy. I understand meritocracy at some point has a negative connotation, but the main idea behind it is that you are valued by what you provide to a project. Not who you are, not who pays your salary. The more you do, the more respect and authority you have within a project. By making sure people are valued by what they do and not who they are, you leave the floodgates open to as many people as possible, and encourage as many people as possible to contribute to the project and get involved with the project.

The other tenet associated with that is the idea that collaboration is incredibly important. Some open source projects like Linux are run as what was called “benevolent dictator for life,” or a BDFL, the idea being that there is a single person or a small group of people who have the ultimate say on the direction of an open source project. We figured—again based on our past experience—that if they get hit by a bus, if their interest level is no longer what it was, it leaves the community in a lurch. Apache tries to drive collaboration and consensus building as much as possible, rather than stopping while somebody else decides. The community is intimately involved in the project and has total control over where the project goes and how it grows.

Finally, the third tier is a real desire and need for full transparency and openness. All decision making is done in the public open forums—usually mailing lists, because those are asynchronous by nature and you’re not disenfranchising large groups of potential collaborators. If development only occurs in real-time over Slack or whatever, then you’re disenfranchising huge sections of potential collaborators and contributors who don’t have the time to dedicate. Having all development occur in open mailing lists means people can, in their free time, look over the archives, find out how the community operates and makes decisions, and it becomes easier for people to get involved in the project.

Again, the Apache Way is designed to make it as easy as possible for anybody who has a passing fancy to get involved with an open source project.

You’ve said in the past that some people argue open source needs to change or our conception of open source needs to change, that email lists and that asynchronous style are slow and outdated. Do you feel like there’s a time and place for fast-paced communication and for older styles of communication, i.e. email?

Yes, I think there is a time and place for each of those. One of the things that we always say is “If it didn’t happen on the list, it never really happened.” Even if you have small groups of people talking about things over Slack or at meet-ups, always bring those conversations back to the mailing list. That way the entire community is aware of what’s going on and they have the ability to be able to provide insight and input on the decision-making process. 

We’re not saying email is the only way to do it, but you have to be careful. You have to be careful that you don’t abuse synchronous communication, because it does run the risk of alienating parts of the community. I think all open source projects and open source communities are struggling to balance those who are basically paid to do open source by their companies and the underlying volunteers who are contributing simply because they’re passionate about it. You need to have a balance of both because company priorities shift. You want to ensure there are people involved in the projects who are doing it for the love of the project.

Open source is an acknowledgement that contributors, especially developers and engineers, want to contribute. They want to collaborate. They want to hone their skills. They are social animals by nature. It harkens back to the old days of the hacker culture where you had a great hack and you shared it with everyone. Open source provides people an opportunity to satisfy that artistic hunger inside of them, to hone their skills with people who are better engineers or better developers and learn things from them. It also provides them the opportunity to mentor up and coming developers as well.

One of the challenges open source faces is a subset of developers saying “Well, this idea of volunteers being the blood and the catalyst of open source, that’s passé. That was good enough for a decade ago, but it’s different nowadays.” But I think that the community needs to be aware that making those kinds of sweeping changes can have a detrimental impact on the open source culture.

You’re very clearly passionate about open source ideals. Why step down from the Apache board, where you were a visible champion of open source?

Every time I would run for the board, I would be re-elected. It became obvious to me that by doing so, I was preventing somebody else from taking a spot on the board. It felt selfish. Apache has a nine seat board because we wanted the ability to have as much fresh new blood in there as possible, and by constantly accepting the nomination, I was preventing that from happening. The ASF is not, as I said earlier, a benevolent dictator for life. I was getting somewhat uncomfortable being seen as “the face and voice of the ASF.” The ASF is a community of people.

It was also important to me that by giving up my seat, as it were, it opened the spot up for increasing diversity at the board level at Apache. And finally, to be honest, it was becoming not as fulfilling and rewarding. The ASF had long been about focusing on the community, focusing on the projects, and the foundation existing to serve the projects. But over the last handful of years, some people have wanted it to become a foundation more worried and concerned about its status as a foundation, especially as compared to some of the larger and more bureaucratic ones out there. We started focusing on being a foundation as a means unto itself, and we were forgetting that the membership determines policy, not the executives. It was hard to fight against that. I’m happy to see that with the election of the new board of directors, we are going back to our roots and we are becoming more recognizable as the foundation that we were in the 15 or so years, rather than the one we’ve been lately.

I’m still involved with the ASF. I’m still a member. I still hack on a lot of code. But it made sense to bring in new leaders, new points of view, especially to address some of the challenges I just mentioned. We need to make sure that the ASF continues to grow and thrive for the next 10 years, the next 15 or 20 years. You can only do that by making sure the knowledge the previous generation had is shared and communicated and embraced by the newer generations. That’s easier as a member, as a peer, than as a figurehead.

What encouraged you to join Uber?

What makes me passionate about open source is the empowerment and the enablement. It’s about culture, not just software. That was one of the things that really drew me to Uber. Uber is all about enablement and empowerment of the people who are providing the services, the people who are using the services. Everyone I talk to at Uber is passionate about what they do from a technological point of view—but also passionate about what Uber is doing to make the world better and people’s lives better.

I’m excited to parlay the talents and skills and experience I have and bring those to bear inside of a company that believes technology is here to make the world a better, easier, more fulfilling place for people—and for that to be not a cliché, not just a mission statement, but something people ardently believe. It was obvious to me that everyone inside of Uber took that to heart. I want to work at a company that makes a difference, where I can feel happy about what I do and provide value not just to shareholders but to the world.

What also excites and encourages me is that my hiring by Uber to be a major participant in their Open Source Program Office (OSPO), clearly shows that Uber is serious about Open Source, and acknowledges that it is a strategic advantage for the company. 

 

Outside Uber, on a more general level, what open source tech do you think is going to take off in the next five years or so? Do you have any predictions?

It’s funny how the pendulum swings. Before, it was all about having your own network centers, these very monolithic architectures and things of that nature. Then there was the move to the cloud, which was designed to make growth and scalability easier.

Now we’re running into situations where latency is a concern. Microservices is a great idea, but sometimes results in a user experience that is less than ideal. I think we’re going to see companies try to figure out a sweet spot between using public and private clouds and leveraging microservices, and an awareness that in some instances a monolith is the better option.

Right now, the software is really designed for an either/or. “This is how you coordinate things for the cloud. This is how you coordinate things in a monolith or a traditional map.” What we need is something that combines the two, and I think that’s what we’ll be seeing. I think you’ll see a lot of stuff going on with Kubernetes, for example.

I think right now we’re also seeing an awareness, especially from large corporations, that a remote distributed workforce can work, and that it’s easier to coordinate than they originally thought. And with that awareness, I think, comes an idea of, “Okay, how can we leverage that? How can we regionalize services in a way we didn’t think was possible before?” So, I think that one of the results will be – not only much more of an embracement of a remote workforce, but also what business opportunities are now going to be available now that we know that we can manage and definitely run remote collaborative workforces out there.

Open source projects have always functioned remotely. In a way, it’s as if the tide of history bends towards open source, yeah?

If you look at the success of open source, it’s kind of funny how much has leaked into corporate enterprise development. Early on it was about external repos and code reviews and sharing the code among people instead of having siloed environments. Then corporations became interested in leveraging open source projects themselves, and contributing back to those communities. Now, it’s about working with distributed teams and building consensus with a remote workforce, just like open source.

There’s even an “offshoot” (for lack of a better word) of open source called InnerSource, which is about bringing all the lessons learned from growing and creating successful open source projects back in-house. That’s a big area of interest nowadays this idea that we can run a lot of our internal projects and internal teams as if they were open source projects, and gain some of the benefits evident in the open source world.

What advice would you give to up-and-coming developers interested in participating in open source projects?

There is a saying inside of open source that open source thrives when developers work on projects that scratch their own itch. If it’s something that’s personally interesting to them, then they’re going to be much more successful in getting involved with it. One of the great things about open source nowadays is there are tons and tons of projects out there. If you’re interested in astronomy for example, there are lots of open source projects which are focused on either robotics and moving telescopes, or improving photographs from astronomy. Whatever your interest and whatever your level, there are at least a dozen open source projects you can get involved with, guaranteed.

Related, there are some projects which are warm and welcoming and inviting to newcomers. There are some other open source projects which are, quite frankly, not as nice. When you’re getting involved, choose a project that values you and your talents. If a project isn’t the right fit, that’s absolutely not a problem. Dust off your shoes and go find another. Find a place where you’re happy, because the benefits you gain from your involvement inside of an open source project should be greater than anything you put into it. 

I mean, I’ve always said that open source has done more for me than I can ever give back to open source. That’s one of the reasons why I still do a lot of volunteering nowadays with open source ecosystems, because open source changed my life and I want to make sure that other people are aware that their lives can change too.

Learn more about Uber Open source by following Uber’s official Open Source twitter account (@UberEng, and @UberOpenSource) and at our Uber Open Source site: https://opensource.uber.com



Source link