Open Source at Uber: A Conversation with Nicolas Garcia Belmonte, Head of Visualization

In college, Nicolas Garcia Belmonte became interested in visualization engineering, and developed the JavaScript InfoVis Toolkit, a set of tools for creating interactive data visualizations on the web. In addition to making data visualization more accessible, open sourcing that project gave him global recognition, letting him travel from his native Argentina to conferences around the world.

For the last three years, Belmonte has worked at Uber, rising to his current position as Head of Visualization, and helping create open source software that makes data easier to analyze for users worldwide. We sat down with Belmonte to talk about his experience getting started in open source and the role it plays in his work at Uber:

What inspired you to study computer science in college?

I actually wanted to study things that are very theoretical, but probably not very useful. Computer science seemed like a good compromise, as it applies higher concepts to practical solutions. I began my studies at the Instituto Tecnologico de Buenos Aires in Argentina, and a few years into the program I discovered visualization, which is a sweet spot for me given my interests. This field involves using math, geometry, and computer graphics to render data into visual forms that people can interpret and analyze.

What was studying computer science like in Argentina when you were getting started?

My early years there were really enriching, but we did things that might seem a little outdated. For example, sometimes we wrote code by hand, on paper. We learned to do binary operations and write assembly code from scratch. It was a good, deep dive into things like object-oriented, imperative, and functional programming.

Later on, though, the program started focusing on preparing students for jobs in the industry, which in South America typically meant working for a company that does outsourced programming. That seemed pretty boring to me. Since I was already interested in visualization, I decided to go down that route for my career.

What was your initial exposure to open source software?

In college, I started contributing to open source visualization libraries, adding small modules for lighting, along with different objects. And then, in a visual programming class, the professor showed this amazing visualization called Hyperbolic Tree, which used hyperbolic geometry to show nodes in a graph. I was really excited about it, so I started reading papers on visualization.

To understand the algorithms, I reverse-engineered examples from these papers. I open sourced my code and, as I added to it, I ended up developing the JavaScript InfoVis Toolkit. At some point I started to have customers, a Google group where developers could discuss contributions, and, soon, thousands of people were using it, including organizations like Mozilla. Going open source seemed like a good way to both market my work and make it useful to others.

What is the biggest value of contributing to open source projects?

What really makes open source satisfying for my team at Uber is that our projects don’t just have internal impact. We have about 30 applications using these open source frameworks, but there are also more than 100,000 npm downloads a month, and that’s from students, individual engineers, and companies. There is a whole ecosystem of people who find our software valuable and contribute to make it even better.

Open source helps the engineers on my team get recognition for their work. They are very happy building things that are widely useful, and they get the opportunity to go to conferences and talk about what they do.

Did you feel that building the JavaScript InfoVis Toolkit as an open source project gave you international recognition?

Yes, absolutely. I did the biggest chunk of this work in France, where I was continuing my computer science coursework, and that gave me exposure beyond South America, in Europe and the U.S. As a byproduct of that, I traveled to lots of different countries. I gave presentations in French, English, and Spanish, and wrote book chapters and blog posts about my work.

I think open source is an honest way to market your work because people can actually see if you’re building good code and architecture. If it’s really valuable and well-built, then it will be more widely used.

What is the most interesting or valuable way somebody has used or contributed to your work in the open source community?

We get two different types of users. Some come from academia, and they use our tools to visualize interesting phenomena like vector fields and wind or to build games. Other folks work in the industry. Collaborating on open source projects can build relationships between companies in the context of pure engineering, where individuals contribute to making software work better, not only benefitting the individual companies involved, but anyone else who might have a use for the tool.

Using the deck.gl open source visualization library developed at Uber, researchers can view wind vector data in a web browser.

Which open source projects have you benefited from?

Uber’s tech stack is built on a lot of open source software. On the client side, most engineers use React and Redux. On the visualization side, D3 is a popular library for my team. It has everything right out of the box and is written in an easy-to-understand and scalable way. It modularized a lot of interesting theoretical knowledge into practical APIs. And there are projects that derive from D3, like Vega.

What is the best way for an engineer to get involved with open source?

One way is that, if you’re using an open source tool to build an application and you realize that there’s a bug or a feature that’s missing, you can go to the repository and open an issue. Maybe you can find someone who knows how to fix the bug or add the feature, and you can work with them. Or you can do what I did and find something that you want to understand better—you want to see how something works, so you build it. From there, you find other people working on similar efforts that can be complementary to what you are doing.

How about if an engineer is building something that they don’t think will be generally useful? What’s your advice?

Speaking from my experience in college, I didn’t really think anyone was going to use the code that I wrote. I just put it out there. If you put enough effort into one thing and keep on building it, it becomes valuable. For example, on a blog if you only write one post, then you won’t get many readers. But if you write often about interesting things, you will end up attracting a nice little community of readers. It’s the same thing for open source: just put it out there and think of yourself as the customer, that you’re building it for yourself. As you continue building it, you’ll see that other people might find your library useful.

For technology companies like Uber, what do you think is a good balance between using open source projects and proprietary software?

There are many trade-offs you have to consider when leveraging both proprietary and open source software. For example, if you go with an open source solution, there is a risk that the project will get discontinued, that the developers working on it will move on to something else. One question I have my team ask before deciding to use an open source software project at Uber is whether we have the skillset to fix that codebase. We also might have to take ownership of the project if the original developers abandon it.

Of course, with a third-party solution, if you want to add a new type of visualization to the library, you won’t be able to. Instead, you have to argue with the vendor to try and get them to develop the product for your needs. And there is the cost, of course. Both have trade-offs, but if you’re a small start-up and need to develop fast, open source has some clear benefits.

How does Uber’s open source culture impact your work here?

As one example, one of the libraries we open sourced was deck.gl. It started with a specific use case where we wanted to visualize tens of thousands of vehicles in real-time on a map. Showing that in a web browser posed a lot of performance challenges, but once we solved it, we found more use cases within the company, including visualizing self-driving car perception and pathing, geospatial mapping, machine learning, and business intelligence in a browser.

After successfully deploying and supporting our solution and gathering enough success stories, we decided to make it available externally. That’s the mindset at Uber: we empower engineers to build things, then we start considering if we can broaden the scope, making software that’s useful beyond our immediate needs. That strategy also gives back to Uber in that we get partnerships with companies and universities and our engineers get the opportunity to go out and present their work.

The open source luma.gl library enables this Myriahedral Projections demonstration, which combines map projections and origami techniques to show maps without area or angle distortion.

In what ways does Uber support your team’s efforts to open source software?

We get people from project management, legal, and engineering helping to facilitate moving projects to open source. We have a pretty streamlined process to open source the software we write. It wasn’t always that way, but we’ve learned quickly. Among teams contributing to open source, we have Core Infrastructure, which usually contributes and develops Go libraries; Web Platform, which has developed quite a few open source libraries centered on platform work; and Marketplace, which recently released H3, a new way to partition the earth for geospatial analysis.

Uber’s visualization team has open sourced the following projects: deck.gl, luma.gl, react-vis, and react-map-gl. If you want to learn about all of Uber’s open source projects, check out our Github page, and, if you are interested in joining our team, visit the Uber Careers page.

Subscribe to our newsletter to keep up with the latest innovations from Uber Engineering.