Adobe Tech Blog
Published in

Adobe Tech Blog

We ❤️ Open Source

A core tenant of Adobe Experience Platform Launch is to function as a platform — a system where marketing and advertising technology providers can build integrations to make it easier for customers to deploy, manage, and leverage those technologies. In order to do this, it made sense to open up our system for a seamless end-to-end experience. It’s difficult to truly reach platform status without building and leveraging open source technology.

Why open source matters


If you’re a user of Launch, it’s no secret that a significant amount of your business’s money and goodwill hinges on the quality of our product. We take this seriously and understand the enormous responsibility that we hold to ensure your website continues to operate as expected. We give a great deal of focus to code quality. Even so, why take our word for it?

Through open source, you get a full view into the code that we deliver to your website. While open source isn’t inherently more secure than closed source, it provides the opportunity for you to review the code with your own eyes (or with the help of a hired professional) to see for yourself whether it is secure and sound. With closed source software, you are required to fully trust the author. We prefer you didn’t have to.

Ease of development and implementation

Our code doesn’t run in isolation. We have a rule engine that integrates with code from extension developers, tools that extension developers use while building extensions, and a wide variety of configuration options for our users. Our code even interacts with the code on your website. We recognize there are times when it’s helpful for you to understand how our code functions. Reading our code can be useful, but even more useful is the ability to step through the code while it’s running in your environment.

Continuous improvement

We recognize there are intelligent engineers in the community that may wish to contribute to Launch (and, ultimately, other users of Launch), whether it’s fixing a bug, pointing out a security flaw, or implementing a feature they’ve been waiting for. We hope to foster these opportunities as much as possible to provide the best platform available.

Where to find the source

All of our current open source software is published to Github and can be found in the following repositories:

This is our user documentation that can be found at

This is the rule engine that gets published as part of the runtime library to your website. It is the “brains” of the runtime library and coordinates with extensions to execute rules, retrieve data element values, and more. Understandably, this is our most popular open source code.

This is a command-line tool that quickly gets extension developers up and running when beginning to build a new extension. By answering a few questions, we’re able to build out an initial file structure with templates that provide a starting point for their extension.

Extension developers are able to create user interfaces that allow users of Launch to configure how the extension behaves. The extension’s user interface is embedded inside of the overarching Launch user interface. The extension bridge is a small script that allows the extension user interface to properly communicate with the Launch user interface.

The extension sandbox provides a local environment that allows extension developers to quickly test out changes as they iterate on their extension.

This tool runs behind the scenes during extension development, notifying extension developers when their extension appears to be malformed. Catching issues as early as possible is the name of the game.

This simplifies an extension developer’s life by automatically bundling up extension code so that it can be published to Launch.

A command-line tool to simplify the process of uploading an extension.

A set of schema we use internally for validating extension manifests and property configuration that gets emitted in a Launch library.

This is a very simple example of an extension that extension developers can use as reference material.

Most of these libraries are published to npm, which is a popular dependency management system among the JavaScript development community. The packages can be found here.

Where to find developer documentation

Part of being an open platform is allowing third-party developers to integrate with our system. With Launch, developers can create extensions that add functionality to the system and benefit a variety of users. Many of the repositories listed above relate to extension development. Developers can also use our APIs to manage any part of our system (e.g., install extensions, create rules and data elements, deploy libraries) without using the Launch user interface.

To learn more about how to build an extension or how to integrate with our APIs, see our developer portal at

Viewing unminified code at runtime

Under normal circumstances, the library you publish to your page is minified (compacted) as much as possible. While this helps with performance (the file is smaller and takes less time to download), it’s generally unreadable by mere mortals and therefore difficult to debug.

One of my favorite features in Launch is the ability to view and run the unminified version of the library. Let’s assume your embed code looks something like this:

<script src=”//”></script>

See the .min in the URL? Take out the .min so that it looks like this:

<script src=”//”></script>

If you reload your page, you’ll notice the loaded script will be unminified for your debugging pleasure.

In the case that you’d rather not modify the embed code within your page, you can use a tool like Charles Web Debugging Proxy or the Launch Command Chrome extension, which can dynamically modify the embed code for your machine only.

How to contribute

First, use our code. Become a Launch user and play around with a smattering of configurations. Publish libraries to your website and take them for a spin. Dig around the unminified code. See if it passes your smell test. If it doesn’t, let us know why not.

Once you become a more seasoned user (or — gasp — an extension developer), you’ll inevitably have a feature request or see something not working quite the way you might expect. Poke around in the code and see if you can spot where something needs to change. If you’re feeling particularly adventurous, code up the change and submit a pull request through Github. Don’t feel like your code needs to be perfect; we’re here to help and we ❤️ contributions.

Most importantly, “If you see something, say something.” Now that you have a peek under the hood, let us know how it can be improved. Help us help you!

Follow the Adobe Tech Blog for more developer stories and resources, and check out Adobe Developers on Twitter for the latest news and developer products.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store