Asana ❤ open source

Engineers at Asana have been contributing to open-source software since the company was founded. To learn more about this work, I spoke with five engineers who have built open-source projects, from different teams. These coffee chats showed me tangible ways that I could contribute to open source, and helped me appreciate how this community fosters co-creation and collaboration.

Read on to learn about these projects, the engineers who built them, and what they learned along the way.

Drawasana

By Steve Landey, Engineering Manager, iOS and Android teams

I wrote a Swift library called Drawsana to help iOS developers add drawing and image markup features to their apps. It handles line smoothing, transparency, text, shapes, and selection.

I started this open source project when our team was building a feature into the Asana iOS app to allow users to visually mark up images before attaching them to tasks, similar to the iOS screenshot markup feature. There are lots of features and tricks associated with code that does this: undo/redo, incremental smooth path drawing, image compositing, and more. I’ve solved a similar set of problems before in JavaScript; I’m also the maintainer of the Literally Canvas library that does the same thing. So it was natural to encapsulate the hard parts in a library and publish them for the benefit of others.

Bazels3cache

By Mike Morearty, Software Engineer, Client Infrastructure

bazels3cache is a lightweight web server for proxying Bazel remote cache requests to S3. A use case is that after the first engineer builds something, other engineers could download and use the same build from bazels3cache, instead of building locally from scratch.

One of the technical challenges was handling various types of errors from S3 with different strategies! If a user loses internet connection, the goal is to mask this transient error and let Bazel gracefully fall back to a local build. In contrast, if the user runs into a persistent error, we want to display errors to users and alert them.

I decided to open-source the project because it was self-contained and other engineers were having similar issues. On top of it all, I really enjoy working with like-minded engineers in the open-source community.

It didn’t take me a lot of extra time to make this project open-source because I decided to write it in a generic way from the start. Because of this intentional decision, I didn’t spend much more time other than fleshing out the README carefully and making sure everything was configurable. If I had initially written it just for Asana, it would be a lot of extra work to open source it later.

A piece of advice I would give is, you don’t have to make an open source project from scratch to contribute to the open source community. Start with filing issues, then write patches, and eventually you could maintain or own a project! I have been contributing to multiple OS projects before bazels3cache. For instance, I wrote and open-sourced a project that supports vim users to have go-to definitions for elixir, a programming language. It was minuscule and only took me a few hours, but the vim/elixir community really liked it.

Archie

By Joe Trollo, API Program Lead

The open source project Archie is a framework that can power workflow automation in Asana projects using Asana’s public API. It allows you to assemble predicates and actions (like IFTTT or our in-app automation features) to automate your processes, as well as define multi-stage dependent workflows, and even perform multi-sorts of tasks in your projects. Archie is named after a very good golden retriever on my team.

The project has a lot of potential on two fronts. First, open-sourcing enables customers to use it themselves and get more value out of Asana. Second, the composability and configurability of the framework lends itself to having many individual contributors building up a large library of functionality.

It’s hard to measure the impact of Archie yet. One casual developer at a customer could spend 30 minutes defining rules in this framework, which would then drive the workflows of tens or hundreds of other Asana users. Now a large number of customer developers are able to assemble their custom behavior with pieces from this framework. This saves them loads of time that would have otherwise been spent learning all the features of our Asana’s API, writing logic that understands our data model, or debugging requests and responses.

Adding Type definitions for React

By Vincent Siao and Phips Peter, Technical Leads

I started contributing to open-source software because Asana was one of the early adopters of TypeScript and React, and we wanted to make an impact on the community. From 2014 to 2016, I was one of the major maintainers for adding type definitions for React from scratch. I was CC’ed to almost all pull requests against react.d.ts. At the time, TypeScript was new. It didn’t have advanced types like type union! React API was in flux: every (non-major) version had a different set of APIs. Looking back, I appreciated the experience of working with other contributors who were type-system enthusiastic.

— Vincent Siao

I was always passionate about open source and happy to contribute back to the community. At the time, there were very few TypeScript definitions and it was important to add them for the community.

I am most proud of making TypeScript and React work together initially. I wrote the type definitions as well as Asana/typed-react. At the time, React required the createClass syntax which did not work with TypeScript. I came up with a hack that made TypeScript and React work well together.

— Phips Peter

If you’re interested in any of these projects, check them out and play around — we’d love to know what you think! And if you want to work on more open-source projects at Asana, we’re hiring engineers on all teams.