Vega is a declarative language to define data visualizations. It allows users to describe the visual appearance and interactions of a visualization and generate web-based views using SVG or Canvas.
Both Vega, and one of its subprojects, Vega-Lite, are heavily used at Datadog, as part of their custom visualizations product offering (Wildcard Widget in Dashboards + Notebooks / Custom Charts in App Builder). Using Vega or Vega-Lite, a grammar for configuring graphs, Datadog customers can build their own custom visualizations, on top of the ones Datadog offers out of the box.
Since Datadog started working on this feature, the team behind it started contributing to the project. In this article we highlight some of those contributions and we speak with Cameron Yick, a Datadog engineer who has been a Vega maintainer since 2023 and was elected for Vega’s steering committee in 2025.
Contributions to the Project
Security
Vega is now an important core component in Datadog, and security is top of mind at Datadog. A lot of the contributions that Datadog has made to Vega has been related to improving the security of the project.
We have fixed several security vulnerabilities (for example, CVE-2023-26486, CVE-2025-26619, and CVE-2025-27793). We have also established an organization-wide security policy, to make it easy for researchers and engineers to have a safe path to reporting security vulnerabilities, helping to keep Vega, and its sibling projects, secure.
Maintainer Experience
Maintaining an open source project is usually a big time commitment involving a lot of toil. Reducing this toil is something that will not only help maintainers, but will also improve the contributors experience, by receiving better and faster feedback.
For both Vega and Vega-Lite, we have contributed to a series of workflows that allow maintainers to build a local preview of a PR branch that will help them quickly test the PR in a real environment.
Another improvement to maintainer experience that we have contributed to is a set of workflows and scripts to automate releasing new releases of Vega. This set of tools allow maintainers to easily create new version tags for a release, and to publish the built packages to the NPM registry.
Talks
Outside the core project, Cameron has been sharing his knowledge, through internal conferences and public events like NYC Open Data week and the New York Data Visualization Meetup. These are some of the recordings of his talks:
NYC Open Data Week 2022: Low Code Visual Data Exploration
New York Data Visualization Meetup: Bridging the Code-Click Gap With Low Code Data Visualization
Insights on Contributing to Vega
Cameron, you started contributing to Vega in 2018. Can you tell us more about why you decided to make that contribution and how that first experience was?
My first contribution to the Vega community wasn’t a code contribution, but an interactive demo. For Pi day, and as a way to learn new capabilities, I decided to implement the Monte Carlo Pi approximation using Vega-Lite. I got a lot of feedback from the Vega community, which allowed me to create an improved version of that same demo and it also opened a door into joining the Vega community Slack. Meaningful contributions to open source projects are not always code contributions! This was soon followed by a tutorial as I was interested to apply to work with Vega public datasets, such as the NYC Event permits list.
You have contributed to a set of areas that are less visible for an end user, like security, or developer experience, but that are very important for the success of an open source project. What made you choose those areas as the focus on your contributions?
I view Vega and Vega-Lite as technical projects that demand a multi-disciplinary background (both originated from computer science PhD research), as making changes to the library requires a strong understanding of software engineering concepts (it’s a modular, plug-in oriented library with many sub-packages), reactive programming, and familiarity with the core abstractions of data visualization grammars.
When I started I did not have first-hand experience in these specialist areas, but I had felt the power of being able to rapidly create new visualizations, and was interested in contributing the areas where I had more professional experience (thanks to my day job) back to the project.
It’s possible to be overwhelmed if you consider how much of a large codebase you would need to understand to contribute a new feature. Starting from the path of documentation and developer experience allowed me to reuse techniques that I felt made others open source projects successful. Over time, the combination of this along with code dives into Vega internals to address my own feature development needs or bug reports from users allowed me to get familiar with Vega’s internals gradually.
I didn’t start with security (partly because privately disclosed security vulnerabilities aren’t visible until you become a maintainer), but I’ve found this type of contribution to be very motivating. If such issues are left unresolved, it compromises the credibility of the project and prevent many people from being able to use the library at all, especially in a commercial setting. Vega is an exciting project to be involved with due to its wide adoption in both commercial and academic settings,
A larger subject that I feel both security and developer experience progress are related to is open source project health. I've noticed that several libraries that I found useful were no longer actively developed, often due to maintainer fatigue or a lack of new contributors. While reading “Producing Open Source Software” by Karl Fogel (recommended by my mentor, Erik Uzureau) I came to understand the importance of working on making it easy for new contributors to get started, thereby reducing the risk of Vega reaching a similar state.
How was your experience in your Vega contributor path from first time contributor, to maintainer, and then being elected part of the steering committee? What would be your recommendations to folks who want to follow a similar path?
I did not set out with the goal of becoming a maintainer, much less a steering committee member. My Vega journey was as a user of the library, not someone with any plans to contribute to the internals. In fact, I was not working as a frontend engineer at the time, I was simply a data engineer looking to learn about the strengths and limitations of the data visualization libraries that would let me build customized graphs more quickly without needing specialized Javascript experience. I didn’t feel “expert” enough to build my own library or change features, but I knew enough to write detailed bug reports or to share a perspective on how to onboard as a new user.
I was drawn to become more involved as other contributors (such as Dominik Moritz and Jake VanderPlas) were active across Github, Stack Overflow, and on the community Slack. I found it intriguing how this library was used both by companies as well as researchers.
I started to become more invested in contributing regularly once the features I had prototyped using Vega/Vega-Lite started being used by more teams, and in production. In order to ensure that a library that is as wide in scope and capabilities as data visualization was something we could trust in production, it felt important to have someone from Datadog involved in supporting its future. After learning the Vega core team introduced a formal project charter in 2023, it felt very natural to apply.
I would encourage other folks who want to pursue a path of supporting an open source project to think about what libraries are pushing the boundaries of a field they care about, and use at work (whether it involves data visualization, databases, or something else). This ensures the project will grow your skills, and that you’ll have the time to use this library during your day job, not just in your personal time.
I would also say that it’s important to observe which projects are building a user community, often expressed through the existence of documentation or project charter. If you understand the external API of the library, if the library is important to your work, and the maintainers are open to it, they will help you find a way to contribute to the project that makes use of your skills. Over time, your skill ceiling will increase, and you’ll be able to grow your responsibilities.